While I really enjoy Theo's talks and writings, I wonder if the fact that the VCS is CVS ain't a security issue in itself?
It's been really a long time I haven't used CVS but I remember that attempt to introduce backdoors in projects using Git as a (D)VCS have been caught (it was in the Linux kernel I think). IIRC some attempts were caught precisely because it's hard to fake SHA hashes and so people can't really "mess" with the history of a DVCS like Git: too many people noticed a critical file having no business being modified being, well... Modified.
Once again, it was quite a while ago but I'm pretty certain that both the fact that Git was decentralized and that Git was using cryptographically secure hashes was touted as a "Good Thing" [TM] that helped catch the backdooring attempts.
Git uses SHA-1 hashes, which have not been considered cryptographically secure since 2005.
Git and CVS are both just tools. They each provide a server implementation, but it's uncommon to use either of these for write access in large projects. It's more common to wrap CVS or Git with a different frontend like HTTPS or SSH. My guess is that the OpenBSD guys use OpenSSH.
This team is fanatical about security and process. I am completely comfortable with them using whichever tools they want.
As far as I read up about this some time ago, it boils down to the following reasons:
- CVS is simple - it's small (fits on a floppy with bsd.rd) and easy to use on exotic/slow architectures
- CVS is preferable for their current contribution workflow (centralized)
- CVS is treated as a tool that, currently, just works (tm)
I understand the point but this comes across as immature. OpenSSL has provided years of free software, supporting thousands of sites and applications.
Of course it has its problems, and there is nothing wrong with adding more competition in this space.
But what this space needs now, more than ever, is professionalism and pride in craft (by which I mean demonstrable unit test coverage, regression testing, fuzz testing and documentation) not silly music video jabs.
They've already done massive amounts of work already - adding missing checks, documenting a metric ton of magic numbers, removing VMS support, fixing year 2038 bugs, removing insecure cypher support, removing less secure replacements for secure OS inbuilts, unused code, and more, see http://opensslrampage.org.
On a side note, I was really hoping for the name to be OpenTLS (consistent with OpenBSD and OpenSSH, which are also OpenBSD maintained projects) or ValhallaTLS
I still can't believe such a fundamental backbone of the web runs on $2000/year. This is a -worldwide- service, and it runs on peanuts. It's flabbergasting. Please donate today if you can.
>OpenSSL has provided years of free software, supporting thousands of sites and applications.
And has done it so poorly that it has been a security nightmare the whole time. Just because something is given away, doesn't mean the world is obligated to be thankful for it. Giving away crap doesn't make it not stink.
Agreed. This is a bit scary. I feel the resources would be better off focusing on merging with the official OpenSSL project rather than forking and _then_ asking for funding, essentially taking any potential funding from the official OpenSSL project.
> removed MacOS, Netware, OS/2, VMS and Windows build machinery
What are the plans for native Windows support? I don't know what they mean by "The right Portability team in place", but it'd be a joke if the lib would require CygWin or some other external portability scaffolding. And without proper Windows support LibreSSL will simply fragment OpenSSL user base. I guess it's still better than nothing, but it definitely won't be an OpenSSL "replacement."
FWIW the usual OpenBSD story is "get it working, reliable and simple, on (Open)BSD, then add porting shims" (they'll have to add shims for linux anyway if they start using strlcpy)
maybe it's better to switch to NSS, the original SSL library developed by Netscape (now by Mozilla, Google, etc.), that is available under better open source licenses, is used in Firefox, (Chrome), OpenOffice, etc. and has an optional compatible API to OpenSSL: http://en.wikipedia.org/wiki/Network_Security_Services
I don't see why this product would have a different porting strategy to the usual way OpenBSD projects (such as OpenSSH) handle it - target OpenBSD exclusively in the core project, and support other platforms with ports. Presumably that's what they are going to do here.
Probably none. Windows has its own CSP library which is a little more convenient in a win32 context than OpenSSL or anything POSIX TBH. I think they're doing the right thing here.
While it is funny, I think using Comic Sans is actually more hipstery than ranting against it, which is too mainstream today (the same goes for blink tags).
Ah yes, the kind of professionalism I've come to expect from OpenBSD. They make decent software, but boy could they use some work in the PR department.
Mine doesn't show up in comic sans. However, the link to OpenSSL is to We're Not Gonna Take It (http://www.youtube.com/watch?v=mRCGDUsdRDU)... This all seems like a joke to me.
While most of us just talk, this guys actually did something of great importance. Hell yeah they have all the rights to step on some toes and make fun as they see fit.
I'd always salute doing stuff vs being politically correct.
One annoying thing about OpenSSL is its license. I hope The Better Replacement™ fixes that as well (especially if its name gets to contain the string "Libre"), and it is not going to happen by forking OpenSSL.
They are already placing completely rewritten files under ‘better’ licenses, so the license switch might happen file-by-file over a long period of time.
This is the problem with any sort of viral license in Free/Open/Libre software. Different people have different notions as to the best way of distributing it. An advertising clause is pretty minor compared to the rights you have to give away to use certain other "Libre" software.
It seems that is is indeed the official site (as linked-to on http://www.openbsdfoundation.org/), just in case there are any doubts…for no reason whatsoever.
Not really considering you have to buy certs if you want people to use your site, it doesn't have any sensitive data on it (not even source code or binaries), and they haven't finished cleaning it up to their standards yet.
I've been thinking recently about Heartbleed, and I was wondering if by writing C code to implement various network and cryptographic protocols, we're acting as human compilers for something that might be better represented in a more abstract format. I know there's some research on this already (the Austin Protocol Compiler), but does anyone here know of any other serious efforts to take the human out of the equation in terms of implementing protocols in C?
I'm curious what they mean by "free", they put it in bold caps. Since it's a fork of OpenSSL that probably implies that the OpenSSL license remains attached to the code at least until all of the relevant code has either been rewritten or removed.
Some of the commit comments are entertaining:
"Fix some serious pointer-arithmatic-magic-number-unchecked-return eyebleed that I stumbled into here and got stuck with. If modern society can get past selling daughters for cows, surely we can decide to write modern C code in an "application" that is probably 3 lines of shell/python/cgi away from talking to the internet in a lot of places.. (This file still needs a lot more love though)
"oh god yuck" deraadt@
ok tedu@"
It should rename to LibibreSSL instead, so that one can link the library with `-libressl`. Other than that, I appreciate this effort (no pun intended).
With close to years of C under my belt, I believe it's a major error, today, to write a critical cryptographic library in C.
OK, do the codecs in C if it's the only way to meet performance requirements. But the rest must be written in a language that's reasonably analyzable statically, and with adequate abstractions. Seriously, have you looked at the filthy mess of leaky abstractions that OpenSSL's BIO system is? How many bugs could be found and/or planted by a 3-letters agency in that crap? Is there anyone who's comfortable with its #ifdef labyrinths?
Finally, I don't think you can retrofit clarity in OpenSSL any better than you could, say, retrofit virus-resilience in a Microsoft OS that hasn't been originally designed for hostile network environments. I used to believe OpenSSL was made messy in order to sell consulting hours, since Snowden I have a more paranoid hypothesis.
How can they know that they have not broken something in their flensing without any automated testing since no tests is one of the big problems with OpenSSL?
It's indeed a great effort. Lets just hope that it delivers what is promising and doesn't bring other sorts of vulnerabilities due to the new implementation/code.
I don't get the point of this fork. Usually when a project is forked, it means that people want to keep the code base but disagree with the way the project is managed.
After heartbleed everybody blamed OpenSSL's bloated code base and it became apparent that many contributions came from volunteers with very few financing.
By forking the project, LibreSSL will keep the problematic code legacy and split the community. Maybe I am missing something, but it looks like opportunism here...
[+] [-] TacticalCoder|12 years ago|reply
While I really enjoy Theo's talks and writings, I wonder if the fact that the VCS is CVS ain't a security issue in itself?
It's been really a long time I haven't used CVS but I remember that attempt to introduce backdoors in projects using Git as a (D)VCS have been caught (it was in the Linux kernel I think). IIRC some attempts were caught precisely because it's hard to fake SHA hashes and so people can't really "mess" with the history of a DVCS like Git: too many people noticed a critical file having no business being modified being, well... Modified.
Once again, it was quite a while ago but I'm pretty certain that both the fact that Git was decentralized and that Git was using cryptographically secure hashes was touted as a "Good Thing" [TM] that helped catch the backdooring attempts.
Ain't using CVS potentially an issue here?
[+] [-] gnoway|12 years ago|reply
Git and CVS are both just tools. They each provide a server implementation, but it's uncommon to use either of these for write access in large projects. It's more common to wrap CVS or Git with a different frontend like HTTPS or SSH. My guess is that the OpenBSD guys use OpenSSH.
This team is fanatical about security and process. I am completely comfortable with them using whichever tools they want.
[+] [-] q3k|12 years ago|reply
- CVS is simple - it's small (fits on a floppy with bsd.rd) and easy to use on exotic/slow architectures - CVS is preferable for their current contribution workflow (centralized) - CVS is treated as a tool that, currently, just works (tm)
[+] [-] ColdHawaiian|12 years ago|reply
[1]: http://arstechnica.com/security/2013/09/who-rooted-kernel-or...
[+] [-] copergi|12 years ago|reply
No, why would it? If you don't trust the openbsd developers, the don't use their code.
[+] [-] sarahj|12 years ago|reply
Of course it has its problems, and there is nothing wrong with adding more competition in this space.
But what this space needs now, more than ever, is professionalism and pride in craft (by which I mean demonstrable unit test coverage, regression testing, fuzz testing and documentation) not silly music video jabs.
[+] [-] nailer|12 years ago|reply
On a side note, I was really hoping for the name to be OpenTLS (consistent with OpenBSD and OpenSSH, which are also OpenBSD maintained projects) or ValhallaTLS
[+] [-] slight|12 years ago|reply
[+] [-] sergiotapia|12 years ago|reply
https://www.openssl.org/support/donations.html
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] copergi|12 years ago|reply
And has done it so poorly that it has been a security nightmare the whole time. Just because something is given away, doesn't mean the world is obligated to be thankful for it. Giving away crap doesn't make it not stink.
[+] [-] thebackwardsman|12 years ago|reply
[+] [-] alexcroox|12 years ago|reply
[+] [-] abcd_f|12 years ago|reply
What are the plans for native Windows support? I don't know what they mean by "The right Portability team in place", but it'd be a joke if the lib would require CygWin or some other external portability scaffolding. And without proper Windows support LibreSSL will simply fragment OpenSSL user base. I guess it's still better than nothing, but it definitely won't be an OpenSSL "replacement."
[+] [-] masklinn|12 years ago|reply
[+] [-] frik|12 years ago|reply
[+] [-] ZoFreX|12 years ago|reply
[+] [-] bananas|12 years ago|reply
[+] [-] teacup50|12 years ago|reply
They should use the operating system-shipped APIs, along with the OS-shipped certificate stores.
That means SChannel and CryptoAPIs in native code.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] vayarajesh|12 years ago|reply
This page scientifically designed to annoy web hipsters. Donate now to stop the Comic Sans and Blink Tags
[+] [-] seszett|12 years ago|reply
[+] [-] zorbo|12 years ago|reply
[+] [-] okamiueru|12 years ago|reply
[+] [-] binaryapparatus|12 years ago|reply
I'd always salute doing stuff vs being politically correct.
[+] [-] mehrdada|12 years ago|reply
[+] [-] legulere|12 years ago|reply
[+] [-] claudius|12 years ago|reply
[+] [-] edwintorok|12 years ago|reply
[+] [-] the_mitsuhiko|12 years ago|reply
[+] [-] Sanddancer|12 years ago|reply
[+] [-] claudius|12 years ago|reply
[+] [-] edent|12 years ago|reply
[+] [-] anaphor|12 years ago|reply
[+] [-] gjvc|12 years ago|reply
[+] [-] broodbucket|12 years ago|reply
[+] [-] DonHopkins|12 years ago|reply
[+] [-] einrealist|12 years ago|reply
[+] [-] gpcz|12 years ago|reply
[+] [-] Xylakant|12 years ago|reply
[+] [-] deegles|12 years ago|reply
http://freshbsd.org/commit/openbsd/fc55d7f9ab6fcadd0ca2f8231...
[+] [-] lifthrasiir|12 years ago|reply
[+] [-] marlin|12 years ago|reply
[+] [-] fab13n|12 years ago|reply
OK, do the codecs in C if it's the only way to meet performance requirements. But the rest must be written in a language that's reasonably analyzable statically, and with adequate abstractions. Seriously, have you looked at the filthy mess of leaky abstractions that OpenSSL's BIO system is? How many bugs could be found and/or planted by a 3-letters agency in that crap? Is there anyone who's comfortable with its #ifdef labyrinths?
Finally, I don't think you can retrofit clarity in OpenSSL any better than you could, say, retrofit virus-resilience in a Microsoft OS that hasn't been originally designed for hostile network environments. I used to believe OpenSSL was made messy in order to sell consulting hours, since Snowden I have a more paranoid hypothesis.
[+] [-] EGKW|12 years ago|reply
[+] [-] tete|12 years ago|reply
http://openbsd.com/lyrics.html
[+] [-] facepalm|12 years ago|reply
In any case forking OpenSSL seems like a knee jerk reaction?
[+] [-] rurounijones|12 years ago|reply
How can they know that they have not broken something in their flensing without any automated testing since no tests is one of the big problems with OpenSSL?
[+] [-] pikimeister|12 years ago|reply
[+] [-] MonsieurHoho|12 years ago|reply
After heartbleed everybody blamed OpenSSL's bloated code base and it became apparent that many contributions came from volunteers with very few financing.
By forking the project, LibreSSL will keep the problematic code legacy and split the community. Maybe I am missing something, but it looks like opportunism here...