LibreSSL: More Than 30 Days Later
openbsd.org
openbsd.org
This article is a good reminder for me to get off my arse and cut my meager grad-student checks to the EFF and OpenBSD project.
Disproportionate based on/compared to what? (I agree that the openbsd folks do a ton of good, I am just trying to understand your references here)
Even though I'm more likely to use OS X or Linux these days than OpenBSD, OpenBSD would fare better in the absence of most Linux distros, than most Linux distros would fare without OpenBSD.
I agree that the CDs are becoming an anachronism, but they still provide an easy way to contribute to the project. Buy the CD, throw it away if you don't need it.
Are there any strange tax or accounting advantages for the organisation I'm supporting if I buy actual stuff rather than donating?
ps. Donations by users are kinda hard to help (in term of numbers) but donations from companies, should be really waaaaaay more towards all BSD project but ESPECIALLY towards OpenBSD for reasons already mentioned.
Also happy to hear a bit about the ressl API. To me it sounds like a focused, high-level API that makes it easy to get right and hard to get wrong. So kind of like NaCl. It's clearly the future -- look at the huge amount of software being written for Sodium now, for example. It's huge.
In which you can see the clear focus on usability rather than capability. To examplify how easy it is, he actually implements the API with a go "backend".
I also really like the concept of a simple API where you can't go wrong by default, hope it can make its way into other pieces of software as well.
It's a really interesting project, but it's not ready for production use just yet, and even when it is I don't think that replacing SSL is necessarily what it's targeting.
This makes me think of the laudable approach taken by the developers for the Cryptography library for python. Expose functions to users with sane and safe settings to users, and provide the abilities to override the defaults if you really must (but in such a manner that it's extremely clear that you're stepping into dangerous territory)
Is OpenSSL being notified of security bugs you all find in your pairing down process?
Determining whether a bug can actually be exploited (on what system, under what configuration?) is hard work, and it's harder still to prove a negative. Mostly the OpenBSD devs just fix the bug and move on. If it looks like the typical kind of a bug that could lead to crashes, they release a patch against the previous two releases (assuming the code is present there).
A lot of the bugs they fix turn out to be "security bugs" only long after someone else finds that out on a version of the code running on another system not hardened by the OpenBSD devs.
After 5.6, if any serious bug is found, you can expect to find a patch for it on http://www.openbsd.org/errata56.html ; however, as the code between LibreSSL and OpenSSL diverges, it won't be obvious whether they apply to OpenSSL at all.
I have heard that a lot of their devs will use git or hg on their local checkout to help manage their own dev environment.
You can find out more about the openbsd philosophy by reading some of the presentations on it at http://www.openbsd.org/papers/
And having used CVS myself, I strongly disagree with any connotation of "productivity loss because of old SCM" etc. — it all depends on workflow. Kind of like Vim certainly isn't inherently less productive than a shiny new Visual Studio 2022.
The release cycle is illustrated here: http://www.openbsd.org/papers/asiabsdcon2009-release_enginee...
They do branch and tag the tree for releases, but development is done in HEAD not in branches as would be customary for git.
I'm not an OpenBSD developer but my understanding is that the branches are used for subsequent patching of that release, not as part of "normal" new development work.
But this is not all that much of a problem in small cohesive teams where everyone with commit rights knows what the others are likely to be working on.
At Arbor, the last CVS job I worked (back in ~2003), we did release and dev branches no problem. I don't remember fretting about it much.
The big issue I remember is, it was a much bigger deal not to break the build.
Using CVS over git in this day and age is a very dumb decision. They may make up for it in other, good decisions. But this decision is a dumb one.
What is it with this obsession with telling people how to get sh't done? If they write their code on used kleenex using wax crayons and share that using carrier pigeons, I don't give a sh't as long as the finished product is fine.
Most readers have no way of evaluating their crypto primitives, or their nuclear power plant, or a zillion other things.
But we can evaluate their source control!
The main reason is that CVS works well enough for our purposes. Most of the diff sharing and discussion happens over email anyway. That's where all the action is.
The main use case is that CVS distributes OK'd patches and allows us to revert them if they are later found to cause problems.
Everyone works on the head branch so there are never any surprises caused by delayed integration. Instead of using branches, the workflow switches between development mode and release mode when the time is right. Release branches receive only a handful of patches (usually less than 10) for the most critical issues discovered during their 1 year maintenance period. Again, CVS is entirely adequate for that.
It's not like there was no usage of git at all. Some devs actually use git in private and even mail git-generated diffs around. If those diffs fail to apply to the CVS tree the burden is on them to fix that. Since x.org runs git, all the X11 and other graphics code is ported to OpenBSD in git branches by our X maintainers and committed to the main CVS tree once it's ready to go live. This can be cumbersome but there's always a price to pay when integrating code from third parties that use different tooling.
But, if you don't think you can contribute code or money to the BSD folks, but really think that they are stupid, you can certainly convince them that moving to git is a good idea by developing a roadmap and reconfiguring their infrastructure. I'm sure they'd appreciate your effort.
(Most) people don't use git (or hg, or whatever) because it's shiny and new, but because it gives them a better workflow and higher productivity.
Probably migration to svn would be smarted since it doesn't change current workflow, granted they actually have a need to migrate.
You don't provide any compelling evidence to the contrary.
Whether that's because there's a demand to host the code on Github as well, or because they like Git, or a little of both is something I wouldn't presume to know.
http://www.openbsd.org/papers/anoncvs-paper.pdf
http://www.openbsd.org/papers/anoncvs-slides.pdf
It makes sense, if you consider the fact they have been using for the last ~18 years.
<h1>LibreSSL: More Than 30 Days Later</h1> Ted Unangst<p> tedu@openbsd.org<p>
LibreSSL was officially announced to the world just about exactly five months ago. Bob spoke at BSDCan about the first 30 days. For those who weren't there, I'll quickly rehash some of that material. Also, it's always best to start at the beginning, but then I'll try to focus on some new material and updates.
<h1>openssl</h1>
The site uses it incorrectly, though: The <p> tag belongs at the start of a paragraph - it is not a separator like <br>.
i prefer closing tags personally, but its not required.
> At the moment we are too busy deleting and rewriting code to make a decent web page. No we don't want help making web pages, thank you.
> This page scientifically designed to annoy web hipsters. Donate now to stop the Comic Sans and Blink Tags
A more chronological catalog is at http://www.openbsd.org/papers/
C is clearly the wrong language for something this security critical if that's where your bugs are. C++ solved this many years ago.
Ada is - as far as I remember - much safer with regards to buffer overflows and bounds checking. But the bigger problem is probably that far more developers know C than Ada, and that something like an SSL library intended for widespread use needs to work with many different compilers and linkers. If you use GCC, I think it is possible to compile Ada code using the GNU Ada compiler and link it to C code compiled using the GNU C compiler, but I am not sure how things look if you use some other C compiler.
* it's broken on other platforms
* they broke features in their releases (no QA/testing?)
* they're making a new API based on requirements of their own programs that doesn't provide many of the OpenSSL features.
* they're using CVS, no public code reviews available. There's no evidence some of the changes were reviewed by someone other than who made the commit. (OpenSSL now does reviews)
* no public audit available.
* they have some hateful note about hipsters on their web page as an excuse after 5 months to not make it readable. So unprofessional it hurts.
* Most changes were done five months ago, with not much at all done for two months.
* The test/ directory has very few changes at all. No extra tests have been added.
* I can't find a release plan, architecture documentation, or any documentation a serious software project should have. (OpenSSL is working on these though)
Finally... their official distribution website doesn't use SSL. That's a major security issue of the face palm variety.
Not. Inspiring. Confidence.
The OpenSSL project on the other hand has been doing some good work. Please see the projects road map from July to see what they are changing. https://www.openssl.org/about/roadmap.html
Are you talking about this http://www.libressl.org/ ? That's one of the most readable webpage ever.
Currently it's comic sans (or a clone of it).
I personally fucking love the site and wish wish wish more people would stop throwing weird stuff in websites. I do think the dig at hipsters is pointlessly antagonistic. Isn't there an evangelism guide for people in open source projects?
There are, tons of them. OpenBSD traditionally doesn't give a fuck, and backs up that attitude by shipping solid products.
Not exactly surprising given the history of the project (started by de raadt after being kicked out of NetBSD for being hard to work with).
If external reviews, github pull requests and documentation galore are important to the GP, they better stop using OpenSSH, which is developed using the same unfathomable development methods as libressl.
That is odd, it is perfectly readable on my phone.
> Currently it's comic sans (or a clone of it).
Chalkboard: http://www.identifont.com/differences?first=Comic+Sans&secon...
Oh indeed. Somebody needs to check out http://motherfuckingwebsite.com/ :-)
Which might be OK for making sure the download isn't corrupted, but are useless for defending against an attacker, since the checksums themselves are hosted on a non-HTTPS site.
SSL secured downloads would be pretty much snake oil for ensuring file integrity end-to-end. You will find the same practice pretty much everywhere among the larger projects.
* In case you missed the memo, LibreSSL wasn't stable back then (nor is it still, AFAIK). Of course things will break, it was still development releases and pre-alpha testing. You can't fix a mess without inevitably breaking someone's workflow.
* They're making an API that will improve on the cruft of the old one, and actually be reasonably sane. Being agnostic of implementation internals will mean easier language bindings. They also explicitly stated it's meant to be independent of LibreSSL and can be adapted to other stacks.
* Stop bikeshedding about version control. It gets old. OpenBSD has had probably the most proactive security auditing and code review practices out of any other project in nearly two decades: http://www.openbsd.org/security.html. Code review isn't some magic process, it's a practice that can be done using a variety of methods. No doubt independent audits will emerge as soon as LibreSSL nears sufficient finalization.
The LibreSSL website is only a brochure. It's made to be "unprofessional" on purpose. The developers have a technical, no-bullshit and take-no-prisoners attitude.
And of course, next time we hear of OpenBSD having more difficulties, people will jump about Theo de Raadt being mean. I'm starting to understand where he comes from.
The stuff about the "hipsters" comment is not about being mean, it's about needlessly pointlessly being mean.
This stuff matters. It matters because it creates division for no gain.
Why not just use comic sans and make no comment? Why not use fixed-width?
It might be bad manners to spill the beans, but it's a very deliberate move. The comic sans and hipster jab let them identify the people who want to bikeshed presentation instead of content.
Version control matters when you don't know who actually made the change. Are the changes signed? No. Besides, my main point was a lack of openness about code reviews. They're not public, and there's no evidence they are even done.
An accessible readable website happens to be important to people, and is a legal requirement in Canada. Documentation is important, and there is none on their website. How do we know what changes they made? Documentation is part of software, and they have none. Fail.
If they want to be jerks and bash other projects, they should be able to take crits themselves.
They clearly state in the article that there hasn't been much activity for periods of time. You can see yourself by looking at the project history in CVS.
The documentation is largely identical with OpenSSL's currently, I presume. This will change once the new ressl API is introduced. No extra tests have been added because there are no new major components that need testing yet.
For changes, you look at their source repository?
Take your personal vendettas elsewhere.
Could you help me out with a pointer in the right direction to find/understand this legal requirement? I did a little googling, and could only find evidence of laws that restrict the government itself.
* They kept the core functionality intact. Were you going to use heartbeats over TCP? Do you know even know what it is? How many of those on-by-default-workarounds were you using? Yeah they removed features. But for crypto code the lack of a rats nest is a feature.
* They are maintaining compatibility with the old API for legacy code and developing a more sane API. Do you have something constructive to say about how an API might look for interop with your favorite flavor of software? Great! To the mailing list with you!
* This was a tear down of code, not a reimplementation from scratch. But yeah, I agree. People should be looking over LibreSSL much more closely than OpenSSL. Sounds like that's something you would be interested in? ;)
* It's open source? And there are discussions on the mailing list? What kind of public audit did you have in mind?
* Don't really think hipster comments have much to do with LibreSSL's quality?
* Can you point to evidence of the claim that not much has been changed in the last two months? Can you point to things you would have liked to see change?
* No extra tests are needed, as they removed features. As features get added, yeah they're going to need to add some tests.
* They don't exactly sit around in conference rooms and write reports for upper management. Have you checked out their mailing list?
Aren't their packages signed and CVS transported over SSL? It's not like the code/packages are compromised. Otherwise, yeah I agree. It would be nice to have secure hateful hipster notes. ;). Kidding aside there's no reason not to add SSL. They should get on that.
I'm thankful that someone is doing something about OpenSSL, which is a blight. I'm sorry I can't personally afford to do more to help. Criticality is a positive thing, especially with regard to crypto/security code. But aren't you being a little smidge cynical?
Modern code review tools provide public conversation of the code in question, and allow people to sign off on it. Is LibreSSL doing this? How can I trace a change or branch to a discussion (if there are even branches)? How are others supposed to easily look into their changes? They say this is a problem in the article we are talking about with their 12,000+ line diffs.
What kind of audit? The traditional kind. Like the third party one the OpenSSL people are funding.
Extra tests would be good if they are rewriting functions, which according to the article is what they did past month one. Is their test plan do a release and see what happens? I can't tell, since I can't see a test plan anywhere. If you're changing a function, and not doing so with even basic tests, and are holding your development practices up as 'best practice' you are lying.
I'm being cynical because I care. They aren't doing many things the OpenSSL project themselves were taken to task for. As well, the OpenSSL project has now taken on many of the practices that LibreSSL are doing, but also they're doing much more (see their roadmap https://www.openssl.org/about/roadmap.html). To let LibreSSL get away with being careless is kind of silly when they are holding it up as being better.
It's fantastic you care though! I highly suggest you write some additional tests where you feel that there are test gaps or write a comprehensive test plan. I bet they'll happily accept test code/plans!