Hacker News new | past | comments | ask | show | jobs | submit login

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

This is horrible for a large scale open-source project. Glibc, gcc, as examples. Trying to get them to fix their broken crap or reverse their idiotic decisions takes decades. If OpenSSL is less opposed to change, it's probably a good thing, considering the purpose of it.

> NSS has a clearer identity, as the TLS core for Firefox and Chromium. OpenSSL is a grab bag with hundreds of different stakeholders.

Do you not remember the myriad bugs that came out of Microsoft's, Netscape's and others' independently-developed SSL implementations when their only relevant benchmark was their own tools? They didn't give a shit if it broke someone else's tool because they didn't make it to support someone else's tool.

> 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.

So clean up the OpenSSL code! If your previous claim that it's easy to get code into OpenSSL is true, fix it! Don't throw the baby out with the bathwater!

> 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.

OpenSSL is used in hundreds of TLS clients in all kinds of environments around the world. It's the de facto client library for 90% of open source tools. As opposed to whatever environments run NSS applications which is far fewer.

It seems like these are arguments for OpenSSL, not against it.




It's the de facto client library for everything but the most important TLS clients.

Ryan's argument that it's too hard to remove NSS code is compelling, but making it to easy to add code is exactly the problem we just had with OpenSSL. Heartbeat wasn't just bad code; it was code that was inappropriate for inclusion by default.


Would clean up of the OpenSSL code be accepted? I mean just from a quick glance at the fragments that have been posted, the first thing that would need to be done would be to get rid of all the ifdefs, i.e. decide on a canonical value for each of the flags in question; would this be accepted, or would the existing stakeholders respond with a list of reasons why they are committed to keeping the status quo?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: