3 ms·

> you have to quadruple check each function invocation with the docs to make sure you got it right. If the docs contain that information ¯\_(ツ)_/¯

by dom0 9y ago

kbenson 9y ago
There's always a trade-off between how complicated the docs and usage are and how many people will use it. OpenSSL is problematic because it has very complicated docs and usage, but people still used it anyway. This leads to a situation where people use it incorrectly, and for a crypto library, that's a very bad thing. If OpenSSL wasn't the de facto king of OSS crypto libraries for so long (partly because it was the only one for so long), then people might have been able to make more informed choices about what library was better.
- the_why_of_y 9y ago
  > If OpenSSL wasn't the de facto king of OSS crypto libraries for so long (partly because it was the only one for so long), Netscape released the NSS library in 1998, and as far as I can tell it hasn't even changed its ABI incompatibly since 2000, but perhaps this is too recent for programmers to take notice.
  - kbenson 9y ago
    I have no idea why NSS never got more use, but it didn't, for the most part. I assume there's a reason, but for the most part major adoption seemed to have been limited to Mozilla projects, Sun Enterprise Java, and OpenOffice (possibly because it also originated from a Sun project, and it seems to have enjoyed some popularity at Sun). If I had to make a wild guess from that info, it would be that it's more complex to work with, as odd as that sounds given the current context (although I guess it's possible OpenSSL got more complex over time, and was much simpler a decade ago).
    - ibotty 9y ago
      For one, NSS is not the kitchen sync that is openssl. With openssl you can do anything with any file you can get from the anywhere. Secondly, when using openssl-based servers it's usually easier to specify certificates and keys. You don't have to import them into a database, you only configure the filesystem path.
bostik 9y ago
Ow. The memories. Back in 2004 I was writing a piece of networking code that had to do handshakes with parameters that were not exposed in OpenSSL API. After many days of code diving and mailing list digging, I came across an old thread. Some kind soul had written up the man pages for the family of low-level functions I needed to use. He sent the doc update as a patch to the mailing list, and the response from the devs has seared itself to my memory: "NAK. If you use these functions, you need to understand all the code around them anyway." That day I learned everything I needed to know about OpenSSL and its development.

> you have to quadruple check each function invocation with the docs to make sure you got it right. If the docs contain that information ¯\_(ツ)_/¯

by dom0 9y ago

> you have to quadruple check each function invocation with the docs to make sure you got it right. If the docs contain that information ¯\_(ツ)_/¯

kbenson 9y ago

There's always a trade-off between how complicated the docs and usage are and how many people will use it. OpenSSL is problematic because it has very complicated docs and usage, but people still used it anyway. This leads to a situation where people use it incorrectly, and for a crypto library, that's a very bad thing. If OpenSSL wasn't the de facto king of OSS crypto libraries for so long (partly because it was the only one for so long), then people might have been able to make more informed choices about what library was better.

the_why_of_y 9y ago
> If OpenSSL wasn't the de facto king of OSS crypto libraries for so long (partly because it was the only one for so long), Netscape released the NSS library in 1998, and as far as I can tell it hasn't even changed its ABI incompatibly since 2000, but perhaps this is too recent for programmers to take notice.
- kbenson 9y ago
  I have no idea why NSS never got more use, but it didn't, for the most part. I assume there's a reason, but for the most part major adoption seemed to have been limited to Mozilla projects, Sun Enterprise Java, and OpenOffice (possibly because it also originated from a Sun project, and it seems to have enjoyed some popularity at Sun). If I had to make a wild guess from that info, it would be that it's more complex to work with, as odd as that sounds given the current context (although I guess it's possible OpenSSL got more complex over time, and was much simpler a decade ago).
  - ibotty 9y ago
    For one, NSS is not the kitchen sync that is openssl. With openssl you can do anything with any file you can get from the anywhere. Secondly, when using openssl-based servers it's usually easier to specify certificates and keys. You don't have to import them into a database, you only configure the filesystem path.

bostik 9y ago

Ow. The memories. Back in 2004 I was writing a piece of networking code that had to do handshakes with parameters that were not exposed in OpenSSL API. After many days of code diving and mailing list digging, I came across an old thread. Some kind soul had written up the man pages for the family of low-level functions I needed to use. He sent the doc update as a patch to the mailing list, and the response from the devs has seared itself to my memory: "NAK. If you use these functions, you need to understand all the code around them anyway." That day I learned everything I needed to know about OpenSSL and its development.