Slashdot Mirror
30-Day Status Update On LibreSSL
ConstantineM writes: "Bob Beck — OpenBSD, OpenSSH and LibreSSL developer and the director of Alberta-based non-profit OpenBSD Foundation — gave a talk earlier today at BSDCan 2014 in Ottawa, discussing and illustrating the OpenSSL problems that have led to the creation of a big fork of OpenSSL that is still API-compatible with the original, providing for a drop-in replacement, without the #ifdef spaghetti and without its own "OpenSSL C" dialect.
Bob is claiming that the Maryland-incorporated OpenSSL Foundation is nothing but a for-profit front for FIPS consulting gigs, and that nobody at OpenSSL is actually interested in maintaining OpenSSL, but merely adding more and more features, with the existing bugs rotting in bug-tracking for a staggering 4 years (CVE-2010-5298 has been independently re-discovered by the OpenBSD team after having been quietly reported in OpenSSL's RT some 4 years prior). Bob reports that the bug-tracking system abandoned by OpenSSL has actually been very useful to the OpenBSD developers at finding and fixing even more of OpenSSL bugs in downstream LibreSSL, which still remain unfixed in upstream OpenSSL. It is revealed that a lot of crude cleaning has already been completed, and the process is still ongoing, but some new ciphers already saw their addition to LibreSSL — RFC 5639 EC Brainpool, ChaCha20, Poly1305, FRP256v1, and some derivatives based on the above, like ChaCha20-Poly1305 AEAD EVP from Adam Langley's Chromium OpenSSL patchset.
To conclude, Bob warns against portable LibreSSL knockoffs, and asks the community for Funding Commitment. The Linux Foundation has not yet committed support, but discussions are ongoing. Funding can be directed to the OpenBSD Foundation." Update: 05/18 14:28 GMT by S : Changed last paragraph to better reflect the Linux Foundation's involvement.
Bob is claiming that the Maryland-incorporated OpenSSL Foundation is nothing but a for-profit front for FIPS consulting gigs, and that nobody at OpenSSL is actually interested in maintaining OpenSSL, but merely adding more and more features, with the existing bugs rotting in bug-tracking for a staggering 4 years (CVE-2010-5298 has been independently re-discovered by the OpenBSD team after having been quietly reported in OpenSSL's RT some 4 years prior). Bob reports that the bug-tracking system abandoned by OpenSSL has actually been very useful to the OpenBSD developers at finding and fixing even more of OpenSSL bugs in downstream LibreSSL, which still remain unfixed in upstream OpenSSL. It is revealed that a lot of crude cleaning has already been completed, and the process is still ongoing, but some new ciphers already saw their addition to LibreSSL — RFC 5639 EC Brainpool, ChaCha20, Poly1305, FRP256v1, and some derivatives based on the above, like ChaCha20-Poly1305 AEAD EVP from Adam Langley's Chromium OpenSSL patchset.
To conclude, Bob warns against portable LibreSSL knockoffs, and asks the community for Funding Commitment. The Linux Foundation has not yet committed support, but discussions are ongoing. Funding can be directed to the OpenBSD Foundation." Update: 05/18 14:28 GMT by S : Changed last paragraph to better reflect the Linux Foundation's involvement.
https://youtu.be/GnBbhXBDmwU
If you clear out the various multi-platform work for OpenSSL, _of course_ it can progress more quickly and more securely. The multi-platform work is where so much of the work has been done.
I had read early on that most of the code they had stripped out was code supporting Windows and OSX. Is that true or was that just the initial pass? Dumping hundreds of thousands of lines of code is impressive--but if it comes at the cost of multiplatform support it's not surprising.
if its a festering insecure pile of shit who cares if it runs on more platforms? got to start over at some point, maybe work on a better foundation before more platforms...
Like the big-endian x86 support in OpenSSL?
OpenBSD's OpenSSH has a separate portability layer, and they're doing just fine without the extra malloc wrappers. And no big-endian x86 support, either!
There have always been security bugs, but it seems like it's only in the last couple when it's actually cost enough people enough money for people to invest in it.
PS: I don't reply to ACs.
What is this "C dialect" of which you speak? Last I checked, they are using standard compilers for the various platforms.
Writing cross-platform code is tricky, and you need to avoid using some things that appear fine, but work differently on different platforms. That will make your code look a tad peculiar to the regular single-platform programmer; but I'd hardly call it a "dialect".
These guys are just awesome!!! I am so grateful to the OpenBSD team for taking this on. I'm going to back up being grateful by supporting this team in any manner that I am able to, and also try to find a way to support their efforts. Be it pizza, donating cash, or maybe even help them test their latest patches and provide any feedback I can.
they're mostly throwing out really old multi-platform stuff, like dos, vms, ebcdic, win16 etc.
This is a joke. I am joking. Joke joke joke.
I have met many security "Gurus" over the years who's primary skill is convincing Baby boomer management types that only they can save them. They then start spouting all the usual things like PKI infrastructure. Military grade encryption, Don't roll your own, industry standard, certified, obfuscation is not security, end to end encryption, and so on with little regard to properly implementing this stuff and generally no regard as to the business needs.
They will do an audit that will show that Russians and Chinese are trying to get into their servers hundreds of times a day and that it is only a matter of time before they do.
Often one of the first things these guys will do "after getting the billing spigot turned on" is to start pushing hardware that gives them the largest kickbacks and ideally require a certification they happen to hold and the IT people don't. So if the system uses switch A they will say switch A is vulnerable and prove it by showing the 10,000 security patches that company has been "forced" to release over the years. So they will install switch B. But if the company uses switch B then they will go with switch A.
The greatest part is that they effectively can deliver nothing but a pain in the ass and look like a hero. "I set up your IPTables to block a custom series of threats my company has identified (Boca Raton)" and if they are really good they will cut off access from root from the company's own administrators.
Often these Guru's entire credibility is based upon some nebulous activity in the past. I could see being an OpenSSL guy would be a huge one. I have long suspected that the main guys at OpenSSL have been spending most of their time giving keynote addresses and rounding up the consulting bucks. I am glad now that anyone who was associated with that project now basically has doggy doo doo on their faces and look like halfwits.
I have worked with these types of guys and they even tend to fall into 3 basic body types. There is the ex-cop looking guy, 50, 5 foot 6, white hair, moustache, round head, round body and talks like they are god's gift to security; these types will use obscure systems that nobody knows so nobody can easily call them on their BS; also these people came into their own in the Y2K days. Then there is the quasi hippy, Longer hair (still balding) not enough light, often thinks they are god's gift to women and security and will give endless advice on both. Usually have a Novell certification in some drawer and will defend Novell to this day. Then lastly there is the fat slob security guy. This one usually works with one of the other two. They are a half assed in nearly everything they do and only manage to keep the demons away by being in the server room 24/7. These people have built their credentials 100% by putting down other people and their technologies. The worst part about this last type is that sometimes they are actually quite skilled but do everything in as stupid way. "Oh I had to rewrite the Linux kernal using code from my wristwatch to make for a better time function for the random number generator. The only problem is that I have to manually reset it every 15 minutes.
The portability approach of openssl was wrong. The idea is drop all multi platform support in order to recreated in a proper way.
The goals of LibreSSL include preserving API/ABI compatibility (keeping LibreSSL as a drop-in replacement).
The thing about OpenSSL et al is that everyone who used it had exactly the same opportunity to review the code and make a decision about its use.
What actually happened was that, for the most part, was that it was just used blindly as its the case with most cryptographic systems and API's.
Whatever the motivators for the OpenSSL group were, whatever the decisions that were made or not made, the simple fact of caveat emptor still applies.
Its good that LibreSSL is getting created, and thanks.. Seriously though, stop bashing the OpenSSL project, it is just as much the product of its community as its developers.
You're still running OS/2, VMS, ancient DEC Unix or pre-NT Windows?
I'm split. Clearly there are a huge number of problems with OpenSSL, and it appears that a lot of cleaning has been done, but most of it before the fork to LibreSSL. The Linux Foundation(tm) doesn't want to backstop LibreSSL, but at least its looking 'clean'. OpenSSL is still a steaming heap, suffering massively from bitrot, and no real cleanup in sight. So do I go to clean, non-crappy LibreSSL, or do I stay with the 'Funded', bitrot filled OpenSSL? Time. I will give the BSD boys (beastie boys), a few months. If LibreSSL is clean and running, and OpenSSL hasn't seen a lot of love in the next few months, I'm kicking OpenSSL to the curb. I've got other GPL projects I'm cleaning up, and I don't think the (one) cryptography class I took in university qualifies me to do serious work on OpenSSL.
I'm assuming you're running a system with full blown CGA or EGA drivers, then. 1990 called and they want their DOS floppy back.
API/ABI compatibility is not the same as cross platform compatibility: the difficulties with 'malloc' incompatibility that led to replace a core libc function clal are precisely the sort of thing that the LibreSSL developers can simply throw out. Replacing it for cross-platform is an excellent example of the difficulties of just such cross compatibility work: preserving the ABI for some of the odder platforms on which OpenSSL currently works is precisely the cross-platform work that the LibreSSL developers can discard. And yes, it will speed the performance of the code. (Rewriting and replacing malloc for cross-compatibility is _guaranteed_ to be slower than native libc functions.)
I'm not suggesting that OpenSSL did not need a stripping of debris and a rewrite. I'm suggesting that if you ignore cross-compatibility and the installled user base, it's much easier to clean up old code.
Who the hell writes up slides with Comic Sans as the font.
I am becoming gerund, destroyer of verbs.
I'm curious what the relevance of stating where they're incorporated is.
I couldn't care less if someone is a prick as long as they produce good product.
It's a matter of mistranslation. In Canadian, "Fuck off or I'll beat you with a hockey stick!" means "We would like to help you with your problem. However, I'm afraid the solution you are proposing would not work for the reasons we have already stated on a previous correspondence[3]. Maybe we could work together in the future.".
Unfortunately the summary gets several important facts wrong, including the status of support from the linux fooundation -- last status is ongoing discussions, not total ignore as the post summary says. And you can see what Bob actually said in the video jason Tubnor uploaded to youtube The real Bob Beck on OpenSSL talk
-- That grumpy BSD guy - http://bsdly.blogspot.com/
If you clear out the various multi-platform work for OpenSSL, _of course_ it can progress more quickly and more securely. The multi-platform work is where so much of the work has been done.
Interestingly enough, that principle doesn't apply to OpenBSD itself, which considers it important to support dead platforms like the Alpha.
Bob Beck has a pretty healthy track record of throwing verbal grenades with regards (but not limited) to open source licenses, security, and other people's code.
That said, looking at published vulnerabilities (CVEdetails.com), OpenSSH and OpenBSD have a tremendous record for fixing (or simply not having) serious security bugs. The total number of vulnerabilities in OpenSSH (application) since 1999 is 61 (11 being DOS) and NONE have known exploits. OpenBSD (an entire OS) has 136 (57 being DOS) since 1999 with 4 known exploits.
By Comparison, OpenSSL (a protocol library) has 87 (46 are DOS) with 5 known exploits.
None of these are egregious compared to other UNIX OS platforms like AIX (316), Solaris (533), and HPUX (278).
I don't think the OpenSSL folks are bad, but they let the product stagnate a bit. Getting some new perspective on it is a good thing.
Ummm, Jon, aren't you supposed to be dead...? - Otter(3800)
This is because the C standard is full of crap such as undead(maybe it was half-unsigned?) chars and non-zero NULL and Harvard architecture hacks. If you want to be sure your program will work as intended when some starry-eyed clang/gcc developer reasons he can optimize away your security code because it is undefined behavior, you must support all the brain-dead architectures that motivated the standard, in order to serve as canaries.
This is not related to supporting non-standard shitty libcs and OSes which run on 64-bit architectures and yet do not support 64-bit pointers.
10 little-endian boys went out to dine, a big-endian carp ate one, and then there were -246.
Wonder if the OpenSSL guys have a good consulting business maintaining exactly those ports for ancient government projects.
They are re-writing LibreSSL for *OPENBSD* across all the hardware platforms OpenBSD runs on.
Once they have stabilized it, another team, the Portability team, will then add a portability layer for other OSes.
What is so difficult to understand, and why is everyone getting their knickers up in a bunch over it?
If you like OpenSSL, continue to use it. If you want a safe, secure ssl implementation, you wait for them to finish LibreSSL and use OpenBSD. If you want a safe, secure ssl implementation on other OSes, you wait for the Portability team to finish its work. To help speed it up, donate $$ so that they can bring in more programmers.
Any other bitching just shows what an idiot you are (not saying you're bitching, just pointing that out to the general peanut gallery).
LibreSSL needs to be portable to wide range of OS's if they want to replace OpenSSL as the "industry standard SSL/TLS implementation". Portable doesn't just mean BSD and Linux.
I hope the people working on LibreSSL appreciate what it takes to achieve broad OS and toolchain portability. OpenSSH is not a good model. OpenSSH is only portable to other POSIX-ish systems, and LibreSSL needs broader reach.
I was in this talk, actually the person behind this camera and at no time did Bob state the following above:
Linux Foundation is turning a blind eye to LibreSSL
This is totally incorrect and should be removed. The slide doesn't even state that. Slashdot editorial committee needs to review their posts a lot closer prior to posting in a public space.
I think people forget that GNU has their own communications library for secure sockets... [url=http://www.gnutls.org/]GnuTLS[/url].
I know why OpenBSD won't use it (because it's LGPL), but why won't anyone else?
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Has anyone looked at source code for any staple unix program or library?
These things are universally teeming in preprocessor defs for every platform you could imagine. Autotools enshrines defacto standard operating procedures with entire header files, replacement libraries, #ifdef's and funky meta programs for virtually every function and historical errata imaginable.
Existence of these things in and of themselves is not a problem if managed properly. When I see commit comments full of snark and rage while concurrently support for leading platforms and necessary features are dropped this is unfortunate when I can't use it... even if LibreSSL was 100x better in every way... it won't even compile so no point.
Hold up. We're going to use CGA until this new-fangled EGA stuff proves itself in production. Kids these days, always onto the next fad.
To help speed it up, donate $$ so that they can bring in more programmers.
Any other bitching just shows what an idiot you are (not saying you're bitching, just pointing that out to the general peanut gallery).
Good idea.. I think I'll donate to the OpenSSL team who created and maintained the project for all these years.
Personally I have no reason to believe BSD is any more capable considering laundry list of CVE's for OpenSSH including an insane PAKE credential bypass.
Also turned off by lack of professionalism. Too many commit comments are childish reflecting lack of discipline I am uncomfortable seeing applied to a project of this type.
It's tedious and inglorious work, carefully removing all the weeds, deadfall and garbage blown in by years of wind; and in pulling out weeds one might also pluck a few desired plants out by mistake. But the only way to remediate a neglected garden is to clean it up enough to see what's there that is really worth preserving, turn the soil underneath, and then give it some TLC to grow and thrive. One can add back those few plants that got mistakenly pulled in the cleanup if they're really that important...
I was stunned reading the slides at what cruft was in there -- really, VMS? Win16? I think the presenter was right -- somebody was concerned about job security with the FIPS crowd and wanted to keep this crap in to scare everyone else off. And the openSSL Foundation is incorporated in Maryland? As in Ft. Meade Maryland, NSA home turf? If one had a tinfoil hat on, one would think the NSA *wanted* openSSL to be as scary as possible so no one would ever look at it.
What is so difficult to understand, and why is everyone getting their knickers up in a bunch over it?
The OpenBSD project used to be pretty rude to a number of people (mostly you could understand why, but that doesn't justify). While some of this is just ignorance much of it is likely people wanting to get back at them and people from the various security services trying to spread dissent.
Any other bitching just shows what an idiot you are (not saying you're bitching, just pointing that out to the general peanut gallery).
He's bitching, whether he realises it or not. He didn't point to a single instance of Alpha support slowing down other platforms. His analogy doesn't apply just because they provide portability. It applies if providing portability to old platforms such as the Alpha slows down the development of OpenBSD, which it probably occasionally does and on the other hand probably keeps people interested in developing on their old Alpha machines contributing and so overall has a positive effect.
Good idea.. I think I'll donate to the OpenSSL team who created and maintained the project for all these years.
You mean the ones that made the heartleed bug and let bug fixes and reports rot in the tracker for 4 years?
Personally I have no reason to believe BSD is any more capable considering laundry list of CVE's for OpenSSH including an insane PAKE credential bypass.
To which CVE do you refer?
Also turned off by lack of professionalism. Too many commit comments are childish reflecting lack of discipline I am uncomfortable seeing applied to a project of this type.
Well, here's something you'll hate even more. You know that the mathematiians that develop the underlying crypto algorithms also have a sense of humour and sometimes say things/crack jokes in frustration? Basically the jokes on you. Because the "unprofessionalism" goes all the way down to the maths and you can't escape it.
You have weird ideas of professionalism, by the way to the extent where I suspect you're a suit. It seems you consider cracking jokes in commit messages and on a project mailing list to be more important indications of professionalism than, say, letting bugs rot in a bug trcker for years and coding up and effective anti exploit mitigation layer in a crucial security library.
SJW n. One who posts facts.
If you clear out the various multi-platform work for OpenSSL, _of course_ it can progress more quickly and more securely. The multi-platform work is where so much of the work has been done.
As a person making their living writing software for MacOS X and iOS, do I care about this code running in MacOS 9? I don't care one bit.
They explain it very well: You don't need to be "multi-platform" if you are standard. Instead of "we have thirteen implementions of SSL_memcpy that run on a dozen completely outdated platforms that nobody cares about", they use memcpy and say "if your platform doesn't support a standard C function correctly, fuck you and your platform". Which is the correct approach.
How can they claim API/ABI compatibiliy if they are dropping features and adding others?
What is so difficult to understand, and why is everyone getting their knickers up in a bunch over it?
The OpenBSD project used to be pretty rude to a number of people (mostly you could understand why, but that doesn't justify). While some of this is just ignorance much of it is likely people wanting to get back at them and people from the various security services trying to spread dissent.
Any other bitching just shows what an idiot you are (not saying you're bitching, just pointing that out to the general peanut gallery).
He's bitching, whether he realises it or not. He didn't point to a single instance of Alpha support slowing down other platforms. His analogy doesn't apply just because they provide portability. It applies if providing portability to old platforms such as the Alpha slows down the development of OpenBSD, which it probably occasionally does and on the other hand probably keeps people interested in developing on their old Alpha machines contributing and so overall has a positive effect.
I haven't watched the full talk (yet), but previous outlines of what OpenSSL did reeked of a Javaesque approach, provide such a thick runtime library on top of the OS, that you don't really need to care about what the platform gives you. That gives you a great portability story, once the layer is in place. The bad thing is that you do not benefit from the specifics of the platform. If you let your portability/base layer rot, you are also behind everyone's game. What's happened during the last 5-10 years is a lot of work to make the C standard library (or slight variations of it), as well as base system calls, much more hardened, to some extent providing security in depth. The LibreSSL critique has been based on the fact that OpenSSL went with their home-rolled, slightly inferior, slightly unpredictable (not handling NULL values in places, at least not in the same way any sane platform did, etc) layer for far too many things, even on modern platforms. As a provider of a platform with security in mind, I can understand the frustration of having a crucial library saying "hey, we don't care about that stuff, we can implement everything we need".
If you clear out the various multi-platform work for OpenSSL, _of course_ it can progress more quickly and more securely. The multi-platform work is where so much of the work has been done.
As a person making their living writing software for MacOS X and iOS, do I care about this code running in MacOS 9? I don't care one bit. They explain it very well: You don't need to be "multi-platform" if you are standard. Instead of "we have thirteen implementions of SSL_memcpy that run on a dozen completely outdated platforms that nobody cares about", they use memcpy and say "if your platform doesn't support a standard C function correctly, fuck you and your platform". Which is the correct approach.
A slightly more pragmatic approach is to keep those implementations, at least the most crucial ones, but please make sure that you use memcpy etc directly on any sane modern platform.
I couldn't care less if someone is a prick as long as they produce good product.
I have to ask the question "Why didn't the BSD development team fork OpenSSL, fix the issues with it even if initially the fork only supports OpenBSD, and retain the name OpenSSL? Are the OpenSSL developers against any outside assistance? I realise BSD is a monster unto itself that prefers "my way or the highway" but seriously.
the difficulties with 'malloc' incompatibility that led to replace a core libc function
The malloc replacement was made due to 'performance issues' on some systems, the incompatibilities only came later when OpenSSL started to use malloc/free as first in first out storage (free in function A, malloc in function B, no pesky parameter passing or overall design needed).
And yes, it will speed the performance of the code. (Rewriting and replacing malloc for cross-compatibility is _guaranteed_ to be slower than native libc functions.)
What? You are aware that there are tons of specialized malloc implementations that can beat the platform provided default depending on the type of workload and independent of the platform?
I haven't watched the full talk (yet), but previous outlines of what OpenSSL did reeked of a Javaesque approach, provide such a thick runtime library on top of the OS
There was no thick layer on top of the OS, they simply reimplemented the libc calls that just weren't there or where incompatible on the now more exotic platforms. The main problem is that they did that in a way that left them incompatible with the platforms that provided a working implementation and even when they where compatible left the code to rot (the platform provided malloc was never enabled during build and some genius used the OpenSSL malloc/free as stack).
If we took your definition of Javaesque even modern libc implementations (and every other minimal runtime) would fit it.
Bob reports that the bug-tracking system abandoned by OpenSSL has actually been very useful to the OpenBSD developers
If LibreSSL is managed anything like the OpenBSD project itself, it won't have a public bug tracking system, which I find quite annoying... Don't get me wrong, I like OpenBSD and have used it since 2.9, I just don't understand why they don't have a publicly available bug tracking system.
OpenSSL® is a registered trademark of the OpenSSL Software Foundation, Inc.
source: www.openssl.org/docs/fips/UserGuide-2.0.pdf
... just sayin'
Actually, they don't even say "fuck you". They suggest you use your resources to implement that feature within your OS. Which, makes sense. I have a friend who runs tons of stuff on some Alpha servers he got in exchange for helping the university port off those systems. Basically what libreSSL is suggesting to him is a decision tree. If underlying library or function that we assume the OS should handle is not available on your system. Here are some suggestions: 1). Fund adding/implementing those needed parts to expand support (seems reasonable that exceptions help cover these costs) 2). Consider moving to support core line of OS and/or hardware 3). Help expand support and code solution (again seems reasonable) Now, obviously not every option is available to everyone. If you don't have money, you might not be able to fund it yourself (though you could solicite other parties and pool resources). If you're not comfortable coding, 3 is probably not possible (unless you have the time and interest in learning). Just saying not so much "FU" as it is focused approach based on plethora of reasons where exceptions can help add and expand support. Instead of people saying "How rude they aren't offering improvements for Mac OS9, I don't like them". Perhaps look at what they are providing cleaned up SSL solution with compatible APIs for variety of modern OSes ... (More to follow).
I come from networking world, so to me their approach makes the most sense for long term. OSI model of layered approach, seems appropriate to use OS random number generator and accepted libraries rather than record for exceptions.
Over time if openssl continues with its different approach, time will tell who is better. Could be both survive (as SSL is used everywhere) or one proves better. It will not just be picked on coding value. It will be host of other things as well.
Respect the Constitution
Personally I have no reason to believe BSD is any more capable considering laundry list of CVE's for OpenSSH including an insane PAKE credential bypass.
Since 2007, OpenSSH has had 11 CVEs issued, while OpenSSL has had 61:
http://www.cvedetails.com/vendor/7161/Openssh.html
http://www.cvedetails.com/vendor/217/Openssl.html
In that time: OpenSSH's worst CVE score was a single 7.5 in 2007; OpenSSL has had six 7.5s, one 9.3, and one 10.0 scored CVEs. Note that Heartbleed (CVE-2014-0160) is rated as a 5.0.
There is too much cruft in OpenSSL. Cruft that some obscure people may want, but which may also be full of bugs. Therefore OpenBSD deleted everything they don't want. KISS.
Actually, they don't even say "fuck you". They suggest you use your resources to implement that feature within your OS. Which, makes sense. I have a friend who runs tons of stuff on some Alpha servers he got in exchange for helping the university port off those systems. Basically what libreSSL is suggesting to him is a decision tree. If underlying library or function that we assume the OS should handle is not available on your system.
One solution for folks using more obscure/old platforms would be to create a "libportable" for those platforms as a compatibility layer for POSIX/Unixy software. This is what the Portability Team of OpenSSH does: keep the core sane and secure, and bring in functions on as needed on those platforms that don't have them.
By having a separate libportable, it could also be leveraged by many more projects, and not just lib(re)ssl.
However, OpenSSL uses their own funky versions of malloc and free which pre-allocate large chunks of memory from the OS (as in, many pages), then implement their own in-process memory management on top of that.
And this would have been partly fine if they had used a semi-sane, widely-used, third-party malloc like jemalloc (which Mozilla uses) or tcmalloc. Or if they allowed folks to disable the internal one and go with the OS-provided (there's a flag there, but it breaks things).
But they went with their own, and they had it such that you couldn't turn it off.
Why is your security code depending on undefined behavior? And why would you port to other architectures to serve as canaries for the architecture you're presumably running on? How about a test suite instead? Do you you tie your shoes in the morning, or do you have an elaborate Rube Goldberg machine try to will them onto your feet?
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
https://www.schneier.com/blog/.... Also OpenSSL-related, funny enough.
To all the ancestor posts b/w this & mine, I was pointing out the irony of the team removing portability layers of OpenSSL, while supporting it in OpenBSD. Not critical of either approach one way or another, but just noting the difference in policy.
Throw out ebcdic? Really? Not a good idea in any middle to large enterprise environment. If you mean Z/OS support bei "ebcdic".
Everyone who can, will jump ship to Theo's version ASAP. Being strong enough to demand the best, and accept nothing less is a good thing when it comes to software security.
Many of these libraries are essential, and mostly taken for granted.
How many people thought that it was already an OpenBSD project, and had Theo's scrutiny already?
There are some true leaders within the OSS world, and we are lucky to enjoy what is made of their efforts. As the TLAs become increasingly invasive in our daily lives, having well written clearly documented textbook code is the only thing you can count on to provide any level of security.
Version 4.0 of Linux will be the same way. Linus will take his kernel, and go where things are sane again, and there will be no compromises. Take it or leave it. This is how things are done. Correctness is the law of the land.
Or you will be taken of your privacy, and computer security at every possible turn.
Oh its insecure? Heatbleed is fixed. What *useful* exploit do you know about that the rest of us don't?
Also turned off by lack of professionalism. Too many commit comments are childish reflecting lack of discipline I am uncomfortable seeing applied to a project of this type.
Oh great, another one of those who thinks that "professionalism" equals "emotionless automaton who can do nothing but work all waking hours".
You're what's wrong with corporate environments these days. Why don't you shut the fuck up and let those of us who still have a soul try and create a decent work environment even when the job at hand sucks (e.g. cleaning up the horrible OpenSSL codebase while under the pressure of not fucking up crypto).
If you check the slides, there are a few areas that they failed hard on. I don't know if you're a C developer, but I've coded a bit, and the slides scared me a bit.
Yeah, there was the "cross platform" stuff. Do we really need EBCDIC support? There's a simple rule about code. If you can't test it, you should pull it. Do you have a machine you can test on? They had Win32 Winsock code, which is a special case. But all modern Windows computers have a Berkely sockets type stack. This doesn't need special code, which means a lot less code to debug.
When the OpenSSL guys state (with some justification) that they have no resources, part of the problem is they waste it by having unused code paths. They'd save some testing time by having removed this code before.
But they also did "cross platform" it badly. They had their own printf, when printf has been done and safe for years. But just in case on some oddball platform, we have our own. They had 17 levels of nested #ifdef. If you don't know C, that's SCARY. There's no way you'd unwind that in your head, and there's near zero chance you'd be able to code a test plan for that. Why? Because you can think of #ifdef as a way of doing simple code modification... 17 levels deep of this type of modification is near impossible to think through and is nearly guaranteed for bugs.
Worst of all, in name of one platform, they came out with an oddball memory allocator. They added things to this allocator to the point where they couldn't run a normal one. Worse off? They got so used to BUGS in this allocator that they couldn't move off of it. And these bugs are directly related to the Heartbleed bug - it's a memory management bug. Instead of thinking "hey, we're doing a lot of weird stuff just for this odd platform" they made the decision "hey, lets go even deeper down the hole of bad code"
So, in name of "cross platform" they had many many design mistakes, including something that broke much of HTTPS. I wouldn't use "they were doing cross platform" as an excuse for their mistakes, because in this name, they had made much of their mistakes.
This wasn't in some text editor. This was in a piece of core crypto. The level of sloppiness allowed is zero.
They OpenBSD folks take their tone from Theo De Raadt, who generally is one of the ruder people out there. When i first heard the rants about OpenSSL, i was thinking "well, they didn't have to smack them down so hard." After reading the slides, Im thinking "yeah, I'd rant that hard" though i don't have the same Forum as the LibreSSL guys have.
CVE-2014-1692