4 ms·

> Some of that is indentation, because we are trying to make the code more comprehensible. 99.99% of the community does not care for VMS support, and 98% do not

by tedivm 13y ago

> Some of that is indentation, because we are trying to make the code more comprehensible. 99.99% of the community does not care for VMS support, and 98% do not care for Windows support. They care for POSIX support, so that the Unix and Unix derivatives can run. Do they not realize that clients also need SSL support? Servers that don't have anyone to talk to them are kind of useless, so at best this is half of solution (unless it really is the year of the linux desktop, of course). There are a ton of applications out there that run on Windows and use OpenSSL for handling SSL connections. That being said this may be a great replacement for servers, and there really isn't a requirement for there to be "one library to rule them all". This may be a great step towards diversifying the encryption-library ecosystem a bit.

talideon 13y ago
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
Ack - looks like I posted something quite similar. Maybe Theo is thinking only about the "OpenBSD community".
- ahknight 13y ago
  Yes. This is an OpenBSD fork. It will run on OpenBSD. That said, later on folks can create compatibility layers (like OpenSSH) to make it work elsewhere. It's better to keep that code outside the core anyway.
  - jmspring 13y ago
    I don't necessarily disagree with the changes, overall. I think there would be a benefit from both companies and projects that leverage OpenSSL to have contributed back to it both in terms of $ as well as change sets to make it better instead of another fork of a library. (I realize the issues previously expressed about the state of change within the OpenSSL project, as well as the lack of general give back from the many people that use it).
    - jmspring 13y ago
      I'm finding the unjustified down voting of the benefits of a FIPS compliant mode interesting. I, personally, don't really care. So open question - Those down voting, have you actually dealt with getting a product through government certification? Specifically in security would be more useful.
      - leccine 13y ago
        Don't worry HN turned into this down voting community where if your opinion does not meet with what people want to see you get down voted. It is the best way to get rid of different views so after a while just those guys hang around who's view is the same. RIP HN
stiff 13y ago
It may still run on Windows, just on top of a POSIX compatibility layer, no?

by tedivm 13y ago

talideon 13y ago

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

Ack - looks like I posted something quite similar. Maybe Theo is thinking only about the "OpenBSD community".

ahknight 13y ago
Yes. This is an OpenBSD fork. It will run on OpenBSD. That said, later on folks can create compatibility layers (like OpenSSH) to make it work elsewhere. It's better to keep that code outside the core anyway.
- jmspring 13y ago
  I don't necessarily disagree with the changes, overall. I think there would be a benefit from both companies and projects that leverage OpenSSL to have contributed back to it both in terms of $ as well as change sets to make it better instead of another fork of a library. (I realize the issues previously expressed about the state of change within the OpenSSL project, as well as the lack of general give back from the many people that use it).
  - jmspring 13y ago
    I'm finding the unjustified down voting of the benefits of a FIPS compliant mode interesting. I, personally, don't really care. So open question - Those down voting, have you actually dealt with getting a product through government certification? Specifically in security would be more useful.
    - leccine 13y ago
      Don't worry HN turned into this down voting community where if your opinion does not meet with what people want to see you get down voted. It is the best way to get rid of different views so after a while just those guys hang around who's view is the same. RIP HN

stiff 13y ago

It may still run on Windows, just on top of a POSIX compatibility layer, no?