So from what I understand, Google has a bunch of OpenSSL patches they use. They used to re-apply those patches to each new OpenSSL release, but now they're going to keep their own branch (BoringSSL) and pull and merge changes from OpenSSL?
What are the costs/benifits of one method over the other?
I think the costs and benefits are pretty much what you would expect. If your diff from upstream is small, then the tradeoff strongly favours rebasing against upstream and tracking it.
However, as the diff becomes larger, the tradeoff shifts. I think we passed that point a while back but, since we were going to switch models anyway, I took some time to clean up some bits of the code too.
With your own patches you know exactly the reason and intent for each one - you wrote it! So you can rapidly figure out what to change to make them fit with the new release.
But in reverse you are going to have to grok every new change sent your way, and that it going to be a massive amount of work.
Some of it will be easy stuff: It's clear what they are doing, or it patches cleanly and you don't worry about it.
But then you'll run into more confusing changes and you're going to have a harder time. There is a human tendency to ignore that which you can not understand, and you'll have some of those, then a patch on top of them, and the final result is more work than you started with.
There is no singular "you". Google is a 50,000 person company. The 70 patches were likely written by dozens of different employees for different projects with different code bases. Some of authors may no longer even work at Google.
The trade off is that your patches are for things that you clearly care about, and do not want to lose. Having played this game several times, several ways, whichever branch the "patches" come from is lossy.
Fewer surprises. You don't wake up one day and discover that TLS heartbeats have appeared in your library as a result of previous upgrades. Every upstream change has to be reviewed because that's the only way it gets in. Also, local changes are much less likely to be lost as a result of merge conflicts.
The downside is that you may miss some upstream changes that you do care about.
Great news! Hopefully between LibreSSL and BoringSSL, OpenSSL will go away and never return. I think AGL and the LibreSSL team will be able to do some fantastic informal collaboration. I'm looking forward to a healthy TLS ecosystem.
That's pretty brutal. One reason why Heartbleed was such a potential problem was the monoculture that tends to come when FOSS software becomes reliable and popular. Having more options out there is good, but I don't see why OpenSSL needs to go away. It had one major zero-day, then when people started paying attention to it, it got 1. a lot of attention to its security and 2. a not insignificant increase in much-needed financial support. Hopefully, we'll see more stable and well-tested TLS libraries out there, and the fact that there are now a few forks of OpenSSL is a good start.
Not that I necessarily disagree with you, but I do want to add two points for consideration:
1. a lot of attention to its security
That doesn't help if bug reports rot in the tracker for years. The developers' attitude might have changed under the current media attention, but for how long will that last? I have yet to read a public statement by the OpenSSL team on how they plan to improve code quality and processes in the long run.
2. a not insignificant increase in much-needed financial support
But we’ll also be more able to import changes from LibreSSL and they are welcome to take changes from us. We have already relicensed some of our prior contributions to OpenSSL under an ISC license at their request and completely new code that we write will also be so licensed.
Android already uses the OpenBSD libc (IIRC), so it's not inconceivable that they'll eventually do the same thing with libssl and switch to the OpenBSD implementation.
What's great about this, though, is that Google's contributions are potentially helpful in LibreSSL's eventual cross-platform porting efforts; their willingness to adopt the ISC license for their contributions is already a promising sign of that collaborative potential.
Totally agree. I love what libressl is doing and my great hope from this effort is that Google's people will port libressl PROPERLY onto Linux. That is critical for the parts where OpenBSD clearly states that the underlying OS must provide key pieces like random number generation, but the implementation must be done right and is often done poorly in initial ports.
I'm hopeful for that, too. Many of the qualms with the preliminary libressl ports revolve around (IIRC) the lack of exploit mitigation features in the operating systems being ported to; perhaps a proper port would be yet another encouragement for those features to be implemented in non-OpenBSD unixen (given that - from what I understand - both FreeBSD and Linux already have the code to support those features, and just need them to be enabled)?
"i maintain Android's C library which, as you may know, contains a lot of OpenBSD code. i've been working to clean up our mess and get us back in sync with upstream, and currently have 173 files that are exactly the same as current upstream OpenBSD. (more than we have from the other two BSDs put together.)"
I'm not tired of it at all. Programming ain't free, and if anyone could use some funding, it's them.
I mean, it's not like Apple's going out of their way to make Aqua work on non-OSX unixen, or systemd's going out of its way to work on non-Linux unixen. Just like how those rely on features of their host platforms, LibreSSL currently relies heavily on OpenBSD-specific security features in the kernel and userland, and it'll take quite a bit more effort to port that to other platforms in a secure and correct way.
Now granted, I'm an OpenBSD user, so my opinion on this is biased. However, it's the same opinion that many Linux-specific or BSD-specific or OSX-specific or Solaris-specific or Windows-specific or VMS-specific or MULTICS-specific or what-have-you-specific projects seem to already have: focus on your primary target(s), then help with porting efforts to secondary targets when it works well on the primaries.
The OpenBSD Foundation has actually been one of the most receptive projects when it comes to software portability. Yes, they target OpenBSD first, but they provide compatibility shims for all other platforms. In general, their philosophy is that it's better to reuse tried and tested code, rather than reimplement poorly from scratch. And their politics reflect that.
Makes a hell of a lot more sense than rebasing 70-odd separate patches for your internal use! Making LibReSSL-portable is a good goal, and this work can be used to improve both (and OpenSSL, too - some of this found its way into the OpenSSL 1.2 branch).
I think the "safe" (EC)DSA nonce implementation is interesting but could use some review, and I've communicated that to the author: it's not as good as the proposal in RFC6979[1] (which uses HMAC_DRBG - which is good - to generate a truly deterministic DSA nonce, with test vectors and everything!). In particular, BN_generate_dsa_nonce from these patches uses modular reduction down into the prime order, which has a small bias towards 0 of course. The NIST prime orders aren't as close to powers of two as you might like to get away with that, and if I'm being honest, I'm not sure you can get away with anything with (EC)DSA - it is extraordinarily fragile in a way I think was always deliberate. The practical impact is probably limited, but I really don't want to take any chances there. (Ideally I'd want Ed25519, or something very like it - there really ought to be some more discussion on CFRG about that - although it's going to be quite some time before anyone can roll it out in certificates widely.)
Right now, it's still lipstick on a pig. OpenSSL is hairy as fuck. Long-term, I think the LibReSSL cleanup-via-demolition approach and then carefully rebuilding what's left over is what's needed. But I'm not sure I'd want to run LibReSSL in the middle of such fundamental reworking - and in the meantime, some of these patches look quite familiar to me. :)
___
1. https://tools.ietf.org/html/rfc6979 - Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)
Yeah, I agree. I thought this was an article about someone claiming SSL is boring. BoringSSL makes it much clearer that its referring to something with that name.
F5 load balances are a good example, where they reject TLS packets between 256 and 511 bytes in length, requiring user libraries to pad packets in that range to longer lengths.
That history has been really sad from the Android side too, not just the users who can't chat together any more. In the first Android beta there were a lot of XMPP classes that were really powerful, if you had all the right permissions and the user had the other people friended and running the same app, you could fire system events (intents) right in the other app through them. But in the second beta the XMPP classes were renamed GoogleTalk classes, and then on release they were all taken away. Now every app has to include a huge smack lib to have even less power than they had in the beta.
True but this implies that everyone should just use what's free so it can all be the same; even if the standard has many years-long unfixed bugs and is unresponsive to community fixes. I'm glad it's come to a head if it gets rid of a false sense of security.
