3 ms·

They're building it first and foremost for OpenBSD. If anybody's interested in using their fork, they'll create a portable version, as they do for OpenSSH, Open

They're building it first and foremost for OpenBSD. If anybody's interested in using their fork, they'll create a portable version, as they do for OpenSSH, OpenSMTPD, &c. The act of stripping the library down is worthwhile though: OpenSSL has accumulated a lot of cruft over the years.

jmspring 13y ago
I think restructuring OpenSSL with better modularization could achieve / maintain more compatibility than just ripping things out.
- talideon 13y ago
  The OpenSSL codebase is already pretty modular, but it's not very clean, and that's its major issue. Needless to say, it could be made even more modular, with the crypo code, X.509 code, the SSL/TLS protocol implementation, &c., entirely separated from one another, but doing that will still benefit from pulling out as much cruft as possible. They're ripping out all that stuff because it's more hard to test stuff that can just go wrong, and when it comes to critical security infrastructure, that's a bad thing to have lying around. All they really need to do to maintain compatibility is maintain the same API. And they're doing just that. In fact, it's in their best interests to maintain the same API as deviating in any significant way is just going to complicate porting software that uses OpenSSL over to use their implementation. So long as they do that, there's little to worry about. And maybe some day their fork will end up becoming the dominant SSL/TLS implementation, much as OpenSSH became the dominant SSH implementation.
  - jmspring 13y ago
    Ripping out FIPS and Windows Support based on their use case isn't ripping out cruft. I think the codebase needs attention (I am personally way to comfortable with it), but a dramatic fork instead of collaboration isn't necessarily best for the open source community as a whole...
    - talideon 13y ago
      If they can't maintain it, then it certainly is cruft from their point of view. Keep in mind that first and foremost they're doing this for OpenBSD: all other platforms are secondary.

jmspring 13y ago

I think restructuring OpenSSL with better modularization could achieve / maintain more compatibility than just ripping things out.

talideon 13y ago
The OpenSSL codebase is already pretty modular, but it's not very clean, and that's its major issue. Needless to say, it could be made even more modular, with the crypo code, X.509 code, the SSL/TLS protocol implementation, &c., entirely separated from one another, but doing that will still benefit from pulling out as much cruft as possible. They're ripping out all that stuff because it's more hard to test stuff that can just go wrong, and when it comes to critical security infrastructure, that's a bad thing to have lying around. All they really need to do to maintain compatibility is maintain the same API. And they're doing just that. In fact, it's in their best interests to maintain the same API as deviating in any significant way is just going to complicate porting software that uses OpenSSL over to use their implementation. So long as they do that, there's little to worry about. And maybe some day their fork will end up becoming the dominant SSL/TLS implementation, much as OpenSSH became the dominant SSH implementation.
- jmspring 13y ago
  Ripping out FIPS and Windows Support based on their use case isn't ripping out cruft. I think the codebase needs attention (I am personally way to comfortable with it), but a dramatic fork instead of collaboration isn't necessarily best for the open source community as a whole...
  - talideon 13y ago
    If they can't maintain it, then it certainly is cruft from their point of view. Keep in mind that first and foremost they're doing this for OpenBSD: all other platforms are secondary.