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.
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.
Guess I'll have to see if this builds on IRIX when I get home...just to see.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
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.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
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.
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
Oh good, now we can get that vital VMS, DOS, and MacOS 7 support so they're not stuck on OpenSSL.
I read the internet for the articles.
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.
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.
Heartbeat support is optional and negotiated. I don't know why you think it 'must' be supported.
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
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.
Well, FIPS is mandated by the same group of people who want to subvert any strong crypto. So why worry ?
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.
Almost no one uses OpenSSL on Windows.
The sad part is that you actually believe it.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
No, because they're right and you're stupid. Not judging; just saying ...
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.
Dewey, what part of this looks like authorities should be involved?
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.
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.
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.
And the tarball is unsigned.... why?
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.
Robots. Lots of robots.
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.
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.
LibReSSL is 100% posix compliant. Just create a posix wrapper for Windows for the required parts.
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.
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:
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:
Digital Citizen
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.
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).
There's no place I could be, since I've found Serenity...
Considering that FIPS is a USA abortion and OpenBSD is Canadian, eh...
The word you are looking for is "abomination".
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.
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.
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.
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.
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.
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.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.