First Release of LibreSSL Portable Is Available

ConstantineM writes: It has finally happened. Bob Beck of The OpenBSD Foundation has just announced that the first release of LibreSSL portable is now available, and can be found in the LibreSSL directory of your favourite OpenBSD mirror. libressl-2.0.0.tar.gz has been tested to build on various versions of Linux, Solaris, Mac OS X and FreeBSD. This is intended to be an initial portable release of OpenBSD's libressl to allow the community to start using it and providing feedback, and has been done to address the issue of incorrect portable versions being attempted by third-parties. Support for additional platforms will be added as time and resources permit.

Comments

first security vulnerability to be discovered!

[Anonymous Coward]

in 3....2.......1............

Re:first security vulnerability to be discovered!

[Noryungi]

in 3....2.......1............

That was the goal from the vey beginning: make the code less horrible to get people involved and correct as much as possible.

So, yes, they will find more problems. They expect that.

Re:first security vulnerability to be discovered!

[TechyImmigrant]

in 3....2.......1............

That was the goal from the vey beginning: make the code less horrible to get people involved and correct as much as possible.

So, yes, they will find more problems. They expect that.

But in the RNG? FFS! Pay attention. It's always the RNG to fall first. Friends don't let friend write crypto libraries without doing a competent job on the RNG. In fact putting an RNG in a library in that way is just stupid and they all do it.

Putting the RNG in place that enables state duplication is stupid beyond belief. A single RNG service serving all comers is able to separate state between them. The sensible consumer will source multiple sources of entropy and mix them if they have a trust problem in the platform. A good OS will do this for you. A linked library will not.

Donate

[Anonymous Coward]

Through my student years I was very much supported by donations.

The LibReSSL effort was the first time I donated ever. So FFS donate, it is that kind of asshole attitude that produces good code, so support it.

Re:Donate

[Anonymous Coward]

I use free software because I don't have money, you insensitive clod.

Do you go to homeless shelters and ask for donations from the homeless too?

Re:Donate

[tepples]

Do you go to homeless shelters and ask for donations from the homeless too?

If by "donations" you include donations of one's time, yes. Some homeless shelters expect those people who are able to perform some sort of work to do so.

Re:Donate

[akpoff]

Development of portable versions of other OpenBSD projects doesn't appear to have suffered.[1] What makes you think LibreSSL will be any different?

[1] The OpenBSD Foundation:
OpenSSH
OpenNTPD
OpenSMTPD

Re:Donate

[Noryungi]

Oh boy, there is so much wrong here... Where to start?

First of all, OpenSSL problems are not ''getting fixed''. Part of the problem is that funding for OpenSSL was primarily based on company XYZ sponsoring function ABC. This gave incentives to the OpenSSL devs to add more functionalities on top of the cruft, the horrible mess that was the code base. More funding equals more developpers equals more eyeballs, but we haven't seen the progress so far.

Second of all, OpenBSD has given a HUGE amount of (BSD licensed) code to the rest of the world, Linux included. Try typing "ssh -V" on any Linux machine and I can guarantee you will get OpenSSH. And if you are like me, this is something you use EVERY. FREAKING. DAY. So please stop the trolling about OpenBSD, mmmmkay?

Third, the amount of code that has been cleaned up, improved, deleted and just plain scrubbed is simply amazing. You can say whatever you want about OpenBSD cranky devs, they know their stuff and they know their way around C code.

Fourth, OpenSSL is BSD/Apache licensed, and not GPL, so stop spouting off about supporting GPL software - not everything has to be blessed by Stallmann to be acceptable. And, yes, the Linux Foundation recognizes this - while you don't.

Re:Donate

[WaffleMonster]

First of all, OpenSSL problems are not ''getting fixed''.

http://www.openssl.org/about/r...

Third, the amount of code that has been cleaned up, improved, deleted and just plain scrubbed is simply amazing. You can say whatever you want about OpenBSD cranky devs, they know their stuff and they know their way around C code.

Nothing structural has changed.

Heartbleed didn't arise from confusing seas of preprocessor macros or broken allocators we've been hearing so much about. It was allowed to happen because there were no structures in place mandating early data validation up front.

Re:Donate

[Anonymous Coward]

I would rather support a BSD project than a GPL project. As it is I don't see the point of LibreSSL any more than I see a point to LibreOffice as both OpenSSL and OpenOffice remained in the "open source" sphere. MySQL to MariaDB I do see a problem with because Oracle has just been downright douchebaggy over everything they got from Sun, including Solaris. So we should get out of "captive market" problems where the source is not available.

At any rate, the most appropriate time for something to be forked is when there is a real danger that the software is going to be closed, or depreciated. Look at things like zlib and libpng where development only happens when bugs are discovered, sometimes years later. These libraries as-is are useful, but they do not take advantage of modern multicore processors. Why has nobody forked these libraries for multicore? Because the algorithms used can't be run in parallel.

So to come back to the point of OpenSSL, having a standard library that can work with everything is a blessing, not a curse. It's extremely difficult to use to begin with, so forking it just makes things that much harder to use. Politically forking it is much like the reasons FreeBSD, OpenBSD, DragonflyBSD, and NetBSD exist in the first place, some part of the development feels that it's moving in the wrong direction. Other forks like FreeNAS exist because the default operating system is incomplete for the needs given.

The BSD operating systems are better "unix" systems than Linux is, but that says nothing about software developed on them. You often find software developed on Linux fails on *BSD because of reliance on parts of glib or pthreads, while things fail on linux when they require POSIX compliance. There's enough middle ground that a build script can in a sense work around the differences between FreeBSD, OpenBSD, NetBSD, Linux, and MacOS X with only some minor shoehorning. It's when an open source project that didn't originate on windows needs to run on windows (here's looking at you Apache httpd, php, openssl and openssh) where the lack of POSIX, glib and pthreads on windows comes home to roost. Windows is windows. Still, there is too much assumptions made in build scripts and not enough functionality testing.

Re:Donate

[the_B0fh]

The OpenBSD group does a number of things. LibreSSL is one of them. They ask for donations to the general fund. If you like, you donate. If you don't, don't donate. OpenBSD runs a lean organization. Everything they do is open sourced and standards driven. And they make it _portable_ correctly.

If you have an axe to grind against them for forking a piece of shit code, take it and shove it.

Re:Donate

[DuckDodgers]

I prefer GPL to BSD. But any FSF-approved open source license trumps proprietary, so I'll happily use OpenSSL, OpenSSH, LLVM, etc... I make my arguments in favor of GPL, but if the people giving their free time to open source don't agree, it's no skin off my back. I'll take a full top to bottom OpenBSD stack over a walled garden from Apple, Microsoft, Amazon, Google, or anyone else any day of the week.

Re:Donate

[thegarbz]

Nothing structural needed to be changed in this phase.

Step one of the LibreSSL project is and always has been clean up the code to make it readable by mortals. An illegible clusterfuck does not attract volunteer developers to help audit. Heartbleed arose because OpenSSL was a perfect contradiction to the idea that "Because it's open source anyone can look at the code and therefore bugs get fixed quickly." Structural changes are still to come.

Also posting an about page from OpenSSL doesn't really mean all that much. Lets see some action thanks. Here we are 3 months after the Heartbleed fiasco and the LibreSSL team have forked and started a major cleanup, whereas the OpenSSL team have written an about page living up to their reputation as a bunch of consultants chasing government contracts.

Other OS's

[armanox]

Guess I'll have to see if this builds on IRIX when I get home...just to see.

Re:Other OS's

[phantomfive]

Post when you get home. I'm betting it will build.

Re:Other OS's

[armanox]

Does not compile. ./configure fails when used with MIPSPro Compiler, and when using gcc I get the following:

    CC libcrypto_la-malloc-wrapper.lo
malloc-wrapper.c: In function 'CRYPTO_strdup':
malloc-wrapper.c:143:2: error: implicit declaration of function 'strdup' [-Werror=implicit-function-declaration]
malloc-wrapper.c:143:2: error: return makes pointer from integer without a cast [-Werror]
cc1: all warnings being treated as errors
*** Error code 1 (bu21)
*** Error code 1 (bu21)

Re:Other OS's

[phantomfive]

Fascinating

Re:Other OS's

[armanox]

Got it to get along a bit further with some editing of the configure file.

Changing CFLAGS="$CFLAGS -Wall -Werror -std=c99 -g -Wno-pointer-sign" to #CFLAGS="$CFLAGS -Wall -Werror -std=c99 -g " brings us to a different stopping point.

    CC asn1/libcrypto_la-n_pkey.lo
asn1/n_pkey.c:92:2: warning: implicit declaration of function '__INTADDR__' [-Wimplicit-function-declaration]
asn1/n_pkey.c:92:2: error: initializer element is not constant
asn1/n_pkey.c:92:2: error: (near initialization for 'NETSCAPE_ENCRYPTED_PKEY_seq_tt[0].offset')
asn1/n_pkey.c:93:2: error: initializer element is not constant
asn1/n_pkey.c:93:2: error: (near initialization for 'NETSCAPE_ENCRYPTED_PKEY_seq_tt[1].offset')
asn1/n_pkey.c:101:2: error: initializer element is not constant
asn1/n_pkey.c:101:2: error: (near initialization for 'NETSCAPE_PKEY_seq_tt[0].offset')
asn1/n_pkey.c:102:2: error: initializer element is not constant
asn1/n_pkey.c:102:2: error: (near initialization for 'NETSCAPE_PKEY_seq_tt[1].offset')
asn1/n_pkey.c:103:2: error: initializer element is not constant
asn1/n_pkey.c:103:2: error: (near initialization for 'NETSCAPE_PKEY_seq_tt[2].offset')
*** Error code 1 (bu21)
*** Error code 1 (bu21)
[Octane]:~/Downloads/src/libressl-2.0.0 $

Re:Other OS's

[phantomfive]

You could try removing -Werror and changing -std to -std=gnu99, that might fix some of them

Re:Other OS's

[Anonymous Coward]

removing -Werror would defeat the purpose of a security library.

Re:Other OS's

[phantomfive]

Not really, it would mean you would need to visually inspect the warnings to make sure there were no problems. If you were actually going to use it in a place where security was crucial

Re:Other OS's

[armanox]

No dice. I've posted it over on Nekochan to see if people who are more familiar with compiling things in IRIX can come up with anything. In the mean time, I'll go back to trying to get Qt5 to compile...

Re:Other OS's

[armanox]

Which I already eliminated that possibility saying I was building it at home. I'd also like to believe that there are very few security critical things still using IRIX, even though I know better (at least SGI was still releasing security patches until this year....).

Re: Other OS's

[staalmannen]

I want to check if it builds on Plan9 APE. There is an old openssl port, but when I tried a more recent one it choked (lots of symlinks generated during configure, not supported on Plan9)

Re:Other OS's

[phantomfive]

In the mean time, I'll go back to trying to get Qt5 to compile...

Brave man

Re: Other OS's

[armanox]

I'd be surprised. I'm running fairly recent software on my Octane, but it is time for a round of updates (Apache/2.2.27 (Unix) mod_ssl/2.2.27 OpenSSL/1.0.1g PHP/5.4.27)

Re:Other OS's

[Kumba]

Just an FYI, but IRIX support was removed in gcc-4.8, in case you're thinking of trying that. Not that Linux is going to get you any farther on an Octane, as I am currently chasing down a futex hanging bug in 4.8 on MIPS R10000 platforms. See gcc PR61538 and Gentoo Bug 516548 for the gory details. Have to git bisect gcc to chase this down, which is _not_ fun.

Re:Other OS's

[armanox]

Slowly moving along on that one. Working on all the prereqs for XCB right now. I also have a hatred of autotools right now.

Re:Other OS's

[phantomfive]

What's wrong with autotools?

Re:Other OS's

[prat393]

Why IRIX? Used at your job?

Re:Other OS's

[Anonymous Coward]

everything ?

Re: Other OS's

[armanox]

Not in production, at least. IRIX happens to be my favourite UNIX.

Re:Other OS's

[armanox]

We've got progress - it's continuing to build now, thanks to some help from nekochan - apparently it really doesn't like MIPSPro, and despite being farther down in my $C_INCLUDE_FILES, the MIPSPro headers in /usr/include were causing issues. Changed $C_INCLUDE_FILES to remove /usr/include and it's continuing to build. I wonder what else will decide to build with that removed.

Re:Other OS's

[armanox]

The easy answer is I don't know how to use them, and they're required to build the Qt5 prereqs (pthreads-stubs)

Re:Other OS's

[armanox]

Certainly doesn't sound fun. Looks like I was stuck with something it didn't like in the MIPSPro files (/usr/include). Removing that from $C_INCLUDE_PATH got it to move on a bit further.

Re:Other OS's

[phantomfive]

oh, that's super annoying, especially since the entire purpose of autotools is to make things cross-platform compatible

Happy to let someone else test it

[Anonymous Coward]

It will be interesting to see how many things break as a result of the house cleaning and discarding of "obsolete" porting support...

I'm sure there is cruft in the code base - I'm also sure that there are features/work-arounds in the code that will look like pointless cruft until someone re-encounters the original field issue that required the work-around.

Still, a good thing that the effort has started as OpenSSL seems to have stagnated - but I expect it will be a bumpy road for a while.

Also not clear what this implies of terms of people who need FIPS certified crypto modules since OpenSSL was the incumbent in that arena.

Re:Happy to let someone else test it

[Noryungi]

There is not just ''cruft'' in the code base: if I remember correctly, they removed thousands upon thousands of lines of code from OpenSSL - think VMS, Borland C, Windows 3.x, MS Visual C++ (etc) support.

And they tested the whole thing on the OpenBSD ports - so far, nothing has been broken.

Oh and FIPS support? Not gonna happen. Bob Beck has been very very clear on that subject. OpenBSD does not care too much about US government standard.

Re:Happy to let someone else test it

[Anonymous Coward]

Unless you are using 15+ year old C compilers, unsupported and dead OSes or want to use insecure ciphers and hash routines, you're not gonna miss the cruft.

Re:Happy to let someone else test it

[Bengie]

The OpenBSD people do not believe in "work arounds". Their answer to an OS not properly doing something is "fix the OS". As it should be.

Re:Happy to let someone else test it

[WaffleMonster]

Unless you are using 15+ year old C compilers, unsupported and dead OSes or want to use insecure ciphers and hash routines, you're not gonna miss the cruft.

Bottom line LibreSSL is useless here as long as it won't run Windows. Need DTLS heartbeat support so they are going to have to find a way to get over that too.

Re:Happy to let someone else test it

[Anonymous Coward]

The OpenBSD people believe in removing features like it's 1989.

Re:Happy to let someone else test it

[Bengie]

Heartbeat support is optional and negotiated. I don't know why you think it 'must' be supported.

Re:Happy to let someone else test it

[Anonymous Coward]

Wasn't FIPS the stuff that essentially gave the NSA the ability to decrypt? Just like the funny DE mail stuff where your mail is extra safe because the government says so and it is decrypted on the mailserver to check for virii?

Re:Happy to let someone else test it

[Anonymous Coward]

That is the difference between a techie living in an ivory tower and someone who is concerned with the usability of a package. Failure to provide work arounds will inherently limit adoption of the project.

Re:Happy to let someone else test it

[Anonymous Coward]

The only good thing about the DE government is GNUpg. And someone better check that, too. It underpins essentially ALL OF LINUX.

Re:Happy to let someone else test it

[Anonymous Coward]

Yeah, because Uncle Steve decreed that every new variant of his polished turd needs another worm stuck into. So the BSDers are obviously HARAM.

Re:Happy to let someone else test it

[Anonymous Coward]

Almost no one uses OpenSSL on Windows.

Re:Happy to let someone else test it

[Zero__Kelvin]

"Bottom line LibreSSL is useless here as long as it won't run Windows.'

The sad part is that you actually believe it.

Re:Happy to let someone else test it

[Anonymous Coward]

The source is open. If you're a Windows user and would like to use the library, then fork and add the capability yourself.

Otherwise...shrug?

Re:Happy to let someone else test it

[Just Some Guy]

Failure to provide work arounds will inherently limit adoption of the project.

I'm certain the OpenBSD guys have literally never cared a single bit. Their goal is to make a secure, clean, and open codebase that people can use and build upon. Anything beyond it simply existence is a bonus.

Re:Happy to let someone else test it

[Anonymous Coward]

If you're ever curious, check out the gnupg development scene (lists, web pages, etc). Very few of the gnupg devs actually seem to use it and almost all of their keys are ten year old 1024 bit DSA. Something to think about...

Re:Happy to let someone else test it

[Anonymous Coward]

Almost no one uses OpenSSL on Windows.

In my experience, the only significant user of the Windows native SSL implementation is IIS. Very few non-Microsoft programs use it. Most non-Microsoft programs I've encountered use OpenSSL.

Re:Happy to let someone else test it

[WaffleMonster]

Heartbeat support is optional and negotiated.

All support was completely and unconditionally yanked from LibreSSL.

I don't know why you think it 'must' be supported.

UDP is connectionless. No session is required to be setup and managed prior to normal operation.

When making existing UDP protocols work over DTLS there is now a session and associated need for session management Including heartbeat to reason about continued health of the session.

Without heartbeats the only alternative is custom modification of each protocol.

Re:Happy to let someone else test it

[WaffleMonster]

Bottom line LibreSSL is useless here as long as it won't run Windows.

The sad part is that you actually believe it.

Real world runs Windows. If we don't support Windows we go out of business.

Re:Happy to let someone else test it

[WaffleMonster]

The source is open. If you're a Windows user and would like to use the library, then fork and add the capability yourself.

Unacceptable if LibreSSL is to be a viable alternative to OpenSSL. Last thing we want to do is take responsibility for maintaining an SSL stack.

Re:Happy to let someone else test it

[dibos]

So donate to the OpenBSD Foundation, and in your donation leave a note that you want LibreSSL to work on Windows. If enough people do that, guess what... it is pretty likely. Or find out who is on the porting team, and pay them DIRECTLY to put a little extra effort in to make it run on Windows. Put your money where your mouth is.

Re:Happy to let someone else test it

[lilrobbie]

Well... perhaps it's actually a more realistic acknowledgement that if the OS is so badly broken it misses things like proper random number generation, chances are, it can't ever be made secure.

Let's switch to a metaphor. Imagine your OS is a house, and OpenSSL/LibreSSL is some type of security screen being fitted to your Windows (hah! do you see what I did there?). The OpenBSD people are basically saying if your house doesn't have the relatively industry-standard secure mounting points for putting their screens on, they won't install the screen. Why? Because by the time they rip apart enough of the house to embed these mounts into the walls and foundations where they belong, the expense is massive, and the result still inferior. And... if the security of the house was that low a priority to begin with, there are probably dozens of other ways this new screen can be circumvented.

You can't easily retrofit security. It tends to be as strong as the weakest link... if that link was the OS, you will never be able to achieve good security with that platform (e.g., yay random number generation is secure... oh, unpatched security flaw in memory allocation allows access to private memory of other apps... damn :-/). So why should the OpenBSD folks pretend otherwise by attempting to support it?

Keep in mind, most modern OSs have everything needed for LibreSSL. It's only either strange/old embedded systems (which really *should* be upgraded to fix the other hundred unpatched security flaws they have), or that poor grandparent stuck on Win95 somewhere who's computer is probably already part of a bot-net.

Re:Happy to let someone else test it

[Bengie]

Heartbeat is only to let the other side know the connection is still expected to be alive when no data is being transmitted. It's not hard for the application level to issue data every 4.5 minutes when it detects an idle connection. The time out length is also configurable. Set the timeout for 24 hours, enjoy.

Re:Happy to let someone else test it

[Bengie]

LibReSSL is 100% posix compliant. Just create a posix wrapper for Windows for the required parts.

Re:Happy to let someone else test it

[Bengie]

Their "Ivory Tower" is a tower of "don't be f*cking retarded". The OpenBSD group is one of the most respected groups because they don't give two sh*ts about politics or making people happy. They only care about doing things correctly.

As a professional programmer, I no longer have respect for people who don't take pride in their work, and these people have a lot of pride.

Re:Happy to let someone else test it

[Anonymous Coward]

Your comments are extremely trollish, and you need to climb out of your crumbling ivory tower.

There is doing things "by the book" which is what OpenBSD does, and there is "doing the right thing" which is what nobody ever does. "by the book" rules are for those who are inflexible and have no regard for the well being of anything that isn't perfect. OpenBSD is not perfect, no matter how hard you want to believe.

The fact is, simply forking OpenSSL was was a clear example of "taking my ball and going home" type of bullshit thinking that goes on in the open source community. Perhaps there are people who think the same way, but the fact you were in the minority to begin with means you have no clue as to why your thinking was percieved to be incorrect in the first place. We wouldn't have had Linux in the first place, nor OpenBSD, NetBSD, or DragonflyBSD had someone not ignored the "doing things by the book" and forked AT&T Unix in the first place.

Re:Happy to let someone else test it

[cbhacking]

The sad thing is, NT itself has (or rather, had) a POSIX API. Up through Win8 (but not 8.1) you can actually get a basic but functional *nix environment running on NT natively (or as natively as NT runs Win32 at least, which is to say it works pretty much seamlessly and nobody back a handful of hacker-types care about the underlying guts). Shells, libraries, utilities, GCC-based build toolchain... pretty nifty, and it integrates better with Windows than Cygwin ever has, while also being faster and supporting things that Cygwin doesn't (setuid, etc.)

However, Microsoft has seen fit to stop funding the maintainers of the package repo for it (there are third-party repos - NetBSD has one, last I checked - but SUACommunity/InteropSystems was where you went for most of this stuff) and to discontinue the POSIX subsystem entirely as of NT6.3 (Win8.1). Very irritating. They say to use Cygwin instead, which is technically a viable option for most of what I use SUA/Interix for, but it's not one I'm happy about needing to take (and move everything over to).

Re:Happy to let someone else test it

[Anonymous Coward]

If this feature is that important, perhaps you should go for a commercial SSL product or pay developers to add it to whichever opensource SSL lib you prefer... But I guess whining how you cant make money of off others' free work is much better.

Re:Happy to let someone else test it

[Anonymous Coward]

Sure. Can somebody care about the WinRetards ?

Linux has conquered mobile devices and as soon as it is considered too insecure, wait for some *BSD to take over. Just admit defeat, Mr M.B.A.

Re:Happy to let someone else test it

[greg1104]

OpenSSL is used to add SSL support when compiling PostgreSQL on Windows. It's a constant headache to the developers and packagers of the database. We were all complaining about how much the OpenSSL license sucks, too, before it was cool to rag on OpenSSL.

Re:Happy to let someone else test it

[greg1104]

Most of FIPS is a certification process oriented on testing. However, there is a checklist of things you need to support, and one of them used to be the easy to backdoor Dual_EC_DRBG.

Now that the requirement for Dual_EC_DRBG has been dropped from NIST's checklist, it would be possible to have LibreSSL meet FIPS requirements without having the troublesome component. Most of FIPS certification is about throwing money at testing vendors, as described by OpenSSL themselves. Doing that would really be incompatible with the crusade LibreSSL is on though, because the result is believed by some to be less secure than using a library that isn't bound to the FIPS process. I don't see those developers ever accepting a process that prioritizes code stability over security.

Re:Happy to let someone else test it

[Bengie]

Either you're trolling or ignorant of the real issues. The LibReSSL fork was entirely deserving. OpenBSD is inflexible when it comes to doing things properly, but their code quality is the best. It is the quality of their code that makes them flexible. They write the most portable, secure, and easily understood code of all projects. They've spearheaded nearly every security advancement that has made it into any OSS OS.

People who think like you are the reason OpenSSL has so many bugs.

Welp, time to start the VMS port

[jandrese]

Oh good, now we can get that vital VMS, DOS, and MacOS 7 support so they're not stuck on OpenSSL.

Great..

[Anonymous Coward]

Now we have two libs with bugs to worry about.....

Can anyone for once just talk each other and try to solve problems instead of the "I'm RIGHT! and you are stupid!!" attitude?

Re:Great..

[Anonymous Coward]

With freedom comes diversity.

Re:Great..

[Bengie]

OpenSSL is a hopeless caused of poor design, bad code practices, and poor leadership. No one person to point a finger at, but it is a situation where starting over would almost be a valid option. OpenBSD decided to take the route of heavy re-factoring to maintain backwards compatibility with most projects.

The OpenBSD group had no intentions of "working with" anyone. They wanted to get it done and do it correctly, no beating around the bush to get permission from the current project managers for a massive overhaul.

OpenBSD is considered to be a top contender for the most secure OS, along with some of the most readable code and best coding and security practices. OpenBSD is a a pioneer for many modern security designs, which Windows, Linux, and FreeBSD all make use of.

Re:Great..

[Anonymous Coward]

Too bad the left doesn't get that.

Re:Great..

[Zero__Kelvin]

No, because they're right and you're stupid. Not judging; just saying ...

Re:Great..

[Anonymous Coward]

Too bad the right doesn't get that.

Re:Great..

[Anonymous Coward]

No. We now have one library to be concerned with. LibReSSL.
What else are you referring to? OpenSSL? That was so yester-month. Do you also use DOS, and daily recite the Pledge of Allegiance to the flag of the Confederate States of America? (Especially for you non-Americans, I'm referring to the temporary government defeated in Amercia's civil war during the 1800s.) If you don't do these things, then please also do not talk like people are going to keep using OpenSSL. There is a simple solution to solve the problem that you're alluding to in your first sentence: stop thinking of OpenSSL as one of the contenders.

To answer your question: it was tried. The people behind LibReSSL determined that the OpenSSL team's code development efforts repeatedly led to code which was not only difficult to comprehend (so that it may be audited), but code which contained numerous critical errors. And, even worse, the OpenSSL team was ignoring crucial feedback that led to already-reported bugs just sitting around unfixed.

Drop OpenSSL, because careful examination of OpenSSL code has found that OpenSSL sucks! As painful as that may be, this is the reality, and so that truth mustn't be ignored. Help the world: Get the word out.

Re:Great..

[Anonymous Coward]

Now wait for CanadaGov to come down hard on them, as soon as it "poses too tough a target" for their UK-USA pals.

'Finally'?

[Anonymous Coward]

It has been, what, three months?

Re:'Finally'?

[Anonymous Coward]

I too was surprised they released a portable version so soon, would have thought more cleaning should be needed. but great to get the code out there.

Also works fine under NetBSD

[ci4]

Test suite summary for libressl 2.0.0
'make check' under -current amd64:

TOTAL: 41
PASS: 41
SKIP: 0
XFAIL: 0
FAIL: 0
XPASS: 0
ERROR: 0

Re:Also works fine under NetBSD

[ConstantineM]

Awesome! Another good test would be building pkgsrc on top of LibreSSL, with no signs of the original OpenSSL present.

Re:Also works fine under NetBSD

[Anonymous Coward]

Of course, it it were OpenSSL code ported to OpenBSD, it would be:

      if $OS != OpenBSD; then
                      return true
      else
                    RunTest
      fi

Does app incompatibility count?

[tepples]

Their answer to an OS not properly doing something is "fix the OS".

How would someone go about fixing an operating system whose biggest problem is that it can't run many of the proprietary applications on which he relies? There are plenty of applications for Windows that aren't ported to any *BSD.

Re:Does app incompatibility count?

[Bengie]

Well, sucks to be you. That's really what it comes down to. When it comes security and design, don't compromise because some idiots painted themselves into a corner.

Re:Does app incompatibility count?

[tepples]

So if the whole PC gaming industry or the whole graphic design industry paints itself into a corner, how are end users supposed to not compromise?

Re:Does app incompatibility count?

[Anonymous Coward]

By not running that broken OS with an Internet connection?
That's fine if you need it to run your proprietary apps, but don't inflict its security problems on the rest of us.

Re:Does app incompatibility count?

[Zero__Kelvin]

"How would someone go about fixing an operating system whose biggest problem is that it can't run many of the proprietary applications on which he relies?"

Agreed. Way back when we were all warning you of the hole you were digging yourself and you kept spouting loudly and proudly that relying on garbage was "Tony the Tiger Great" we knew this post was coming. The answer of course is: Get yourself a clue stick and start digging

Happy to let someone else test it

[Anonymous Coward]

Well, FIPS is mandated by the same group of people who want to subvert any strong crypto. So why worry ?

Great..

[Anonymous Coward]

You mean your friends at NETWARCOM are upset about those damned Canadians spitting into their nice Insecurity Soup ? Or is it AFISR ?

Unsigned

[Anonymous Coward]

And the tarball is unsigned.... why?

Re:Unsigned

[Anonymous Coward]

just making up an answer here... because it's not an official release?

By the way, I notice that your Slashdot post is unsigned. No digital signature to prove authorship, nor even any sort of identifier for claiming authorship.

BTW BTW, I notice that is also true of this post...

Stallman's "blessings" are for software freedom

[jbn-o]

[...] not everything has to be blessed by Stallmann to be acceptable

Regarding this point, Stallman certainly does endorse Free Software. And so much of what is in OpenBSD is Free Software—software that respects a user's software freedom—and the same goes for OpenSSL. Stallman (and his organization, the Free Software Foundation(FSF)) are known for standing up for a user's software freedom. Non-copylefted Free Software is Free Software. Furthermore, in 2004 the FSF gave Theo de Raadt an award for the Advancement of Free Software, "[f]or recognition as founder and project leader of the OpenBSD and OpenSSH projects, Theo de Raadt's work has also led to significant contributions to other BSD distributions and GNU/Linux. Of particular note is Theo's work on OpenSSH". A free system need not include GNU software or be licensed under a GNU license (such as the GPL) to respect a user's software freedom.

The FSF is quite clear why it doesn't list OpenBSD (or the other BSD distributions) in their list of Free system distributions:

FreeBSD, NetBSD, and OpenBSD all include instructions for obtaining nonfree programs in their ports system. In addition, their kernels include nonfree firmware blobs.

Nonfree firmware programs used with Linux, the kernel, are called "blobs", and that's how we use the term. In BSD parlance, the term "blob" means something else: a nonfree driver. OpenBSD and perhaps other BSD distributions (called "projects" by BSD developers) have the policy of not including those. That is the right policy, as regards drivers; but when the developers say these distributions âoecontain no blobsâ, it causes a misunderstanding. They are not talking about firmware blobs.

No BSD distribution has policies against proprietary binary-only firmware that might be loaded even by free drivers.

Including nonfree software and pointing users to nonfree software is quite common among those who endorse the open source philosophy, as the FSF has long pointed out (older essay, newer essay). The open source movement's philosophy is a development methodology built to toss aside software freedom for practical convenience in an attempt to be "more acceptable to business". So this philosophical difference sets up a radically different reaction in the face of reliable, powerful proprietary software. Quoting the newer essay:

A pure open source enthusiast, one that is not at all influenced by the ideals of free software, will say, "I am surprised you were able to make the program work so well without using our development model, but you did. How can I get a copy?" This attitude will reward schemes that take away our freedom, leading to its loss.

The free software activist will say, "Your program is very attractive, but I value my freedom more. So I reject your program. Instead I will support a project to develop a free replacement." If we value our freedom, we can act to maintain and defend it.

Re:Stallman's "blessings" are for software freedom

[Anonymous Coward]

OpenBSD does not contain any binary blob in it's kernel. They're the ones that fought so hard to kill off binary blobs, and ended up with a FSF award for it.

Re:Stallman's "blessings" are for software freedom

[Anonymous Coward]

Binary drivers (the thing the BSD community call blobs) -- no. Binary firmware, the thing FSF calls blobs, yes. OpenBSD does contain nonfree binary firmware blobs.

LibreSSL vs OpenSSL Speed test

[Anonymous Coward]

I saw the updated http://www.libressl.org/ page with details for the portable version.

Saw someone else did a speed test https://gist.github.com/bertjw...

and thought I would do the same

http://pastebin.com/SBVWPQmB

I'm not an expert but at this stage it appears

                                LibreSSL Speed as % of OpenSSL
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes

Aes-128 cbc 152.40 152.34 152.66 59.87 59.49
Aes-192 cbc 159.14 158.30 158.25 60.78 60.49
Aes-256 cbc 166.15 166.91 167.14 64.48 64.51

Results -
LibreSSL about 50~60% faster for 256 size blocks or smaller
OpenSSL about 50~60% faster for 1024 size blocks or larger

Notes: To compile on Ubuntu need to use ./configure LDFLAGS=-lrt
There are posts about the same requirement on RH also.

FIPS, schmips...

[Anonymous Coward]

Considering that FIPS is a USA abortion and OpenBSD is Canadian, eh...

Re:FIPS, schmips...

[the_B0fh]

Considering that FIPS is a USA abortion and OpenBSD is Canadian, eh...

The word you are looking for is "abomination".

Technical discussion

[jgotts]

There is a lot of political discussion on this thread. How about a bit of technical discussion?

I spent about 20-30 minutes code reviewing the first few files in ssl/*.c.

The codebase looks better than most C code I look at. The indentation is a pleasure to look at.

I did notice a few issues. Wrappers are apparently still being used around memory allocation functions. I don't know if this is for API compatibility or what. There is more casting than I would like to read. I hope it is all absolutely necessary. If you look at, for example, RSMBLY_BITMASK_MARK, that code is absolutely horrible. Never write code like that. To me that is how not to write C, C++, Perl, Java, or PHP (all would look very similar).

Lots of gotos. Not necessarily considered harmful. May not indicate bad coding practices, but something to think about. gotos inside of a case-switch. Yikes. Hope you really needed to do that.

Functions are very long. Linus Torvalds's rule of thumb for a function is that it should fit nicely on a screen. You should be able to look at it, conclude, that does x, and move on to the next function.

There you have it. I debug other people's code for a living, and sometimes write my own.