[agl]

> NSS has more institutional constraints; random people in Germany can't, as a general rule, add support for new TLS extensions to it.

Why not? NSS is handled by Mozilla. Mozilla prides itself on being open-source. People can submit patches to NSS by filing in Bugzilla.

> The most important code in both NSS and OpenSSL is the SSL state machine. The code for that state machine is incontrovertibly clearer and better expressed in NSS.

I agree with this to some extent (although I don't think it's quite as much better as you suggest), and cleanups in that code are needed. Other parts of NSS can certainly rival OpenSSL on the "dear god" scale however. I'll take the low-level parts of OpenSSL over NSS any day.

> NSS has had better battle-testing as a clientside browser TLS library than OpenSSL, which, apart from Android Chrome, isn't a big factor in TLS clientsides.

This is true. We will have to rack our brains and our bug database for some of the unwritten rules of TLS to port over to OpenSSL. I'm not too worried about this in the long term however.

Ultimately the proof will be in the pudding. Ask again in 12 months :)

[blinkingled]

>> NSS has more institutional constraints; random people in Germany can't, as a general rule, add support for new TLS extensions to it.

> Why not? NSS is handled by Mozilla. Mozilla prides itself on being open-source. People can submit patches to NSS by filing in Bugzilla.

Maybe he meant Mozilla as an organization is much better equipped to handle patching of NSS better than the OpenSSL team. I have seen Firefox bug reports number of times and there seems to be a proper process in place to review patches before accepting. I am not aware of anything that good on the OpenSSL side.

[tptacek]

Am I wrong that it's easier to get code into OpenSSL, and thus into pretty much every product that uses OpenSSL, than it is to get code into the branch of NSS that Firefox and Chromium use?

[agl]

I've submitted code to both. I don't feel that there's a huge difference. (Although NSS has Wan-Teh reviewing, who is a great code reviewer.)

[tptacek]

Ok, wait: the code you've submitted to both has also probably been more obviously applicable than, say, the Heartbeat extension.

"Chromium developer has elliptic curve code accepted by NSS: film at 11."

[sleevi]

Part of the reason it's so hard to get code into NSS is because no one really knows who owns those bits, and so they linger in obscurity. I think my TLS Channel Bindings patch is lingering on 3 or 4 years now.

However, I think you're doing a disservice if you only look at how easy it is to add code. As important is how easy it is to remove code. With NSS, it's far, far harder to remove code - and that makes it far, far harder to reason about any new code you might want to add, for who knows what grues are lurking in those shadowy depths.

[blinkingled]

Not being able to easily add or remove code is good from a security standpoint though. I would take a bugfix only, stable-API NSS over anything that is in constant flux. So it's not how fast you can add features that should be in focus for a mature product - it's how safely you can add bug-fixes, including security fixes. Unless you are saying you have a security fix lingering for 3-4 years, I think Mozilla is doing it right.

Edit: Not to ignore the valid point - having a designated code owner that responds would of course be good.

[kbenson]

With NSS, it's far, far harder to remove code

I'm not sure how to interpret that statement. It could mean any of the following, or something I'm not even thinking of:

The code is inscrutable and/or the documentation is poor: That's obviously a problem.

Commits removing code are delayed/ignored: Probably also a problem, but maybe there's valid reasons for this, such as more thorough testing?

There's little cruft to remove: This would be a positive. Not having much of a mess to clean is hard to consider a problem.

Am I close with any of those?

[emn13]

It could also be that the public API is too large and exposes unnecessary bits that now make it hard to change even incidental, conceptually irrelevant behavior simply because some user probably relies on it. Even a clean, well documented implementation with active, capable maintainers is hard to refactor when the API is large and intrusive.

(I have no reason to believe this applies to NSS.)

[doe88]

> Am I wrong that it's easier to get code into OpenSSL

I might be wrong but the idea I have is that currently Google more or less owns OpenSSL and thus it is maybe more easy, makes more sense for them to get patches in OpenSSL and try to migrate exclusively toward OpenSSL.

Another question I have is since when the HeartBleed flaw was discovered by the Google's employee? Was it formally reported to the OpenSSL team or only to OpenSSL members working for Google? And if the other independant group of engineers had not independantly discovered the flaw would have it been disclosed as quickly as it has? Bottom line it seems to me (and I'd like to be wrong) that the current opacity of OpenSSL disserves everyone but Google.

[nl]

Another question I have is since when the HeartBleed flaw was discovered by the Google's employee? Was it formally reported to the OpenSSL team or only to OpenSSL members working for Google?

I think it is generally regarded as sensible practice to disclose major problems like heartbleed that have wide ranging impact directly to the people responsible instead of a catchall "security team" address whenever possible.