41–50 of 58 posts
Earlier quoted context omitted.
This is why I would never use OpenBSD (but yeah, I use OpenSSH). Can't use an OS for people with this type of attitude.
Linus is generally not gentle when rejecting an idea either. You might run out of OSes pretty soon ;-)
Earlier quoted context omitted.
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.
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…
Those down voting, have you actually dealt with getting a product through government certification? Specifically in security would be more useful.
Somehow, I don't see removing FIPS or Windows support being in the best interest of the community as a whole. For startups wanting to have a product that requires some level of FIPS support, starting with a decent base makes things easier. Windows support? There are more than a couple of applications out there running on Windows that make use of OpenSSL. Theo's quote -- "99.99% of the community does not care for VMS…
He does.
OpenSSL is beyond repair. We need a new clean start, sane design and rock solid implementation with principles and following best practices.
So far, two of the clean starts (Apple's and GnuTLS) are known for the critical "goto fail" bugs. How would your clean start be different?
OpenSSL is beyond repair. We need a new clean start, sane design and rock solid implementation with principles and following best practices.
While I can agree with that, how do you get people to use your new awesome crypto library? LibreSSL (the name of the OpenBSD fork, it seems) API should stay OpenSSL-compatible, making it mostly a drop-in replacement. Also, I think that an OpenSSL cleanup is needed even if we get a new awesome library too. We can't drop OpenSSL overnight, and as you said it's bad. So this at least make it less bad, until there's somet…
Earlier quoted context omitted.
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…
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.
It's cool they're doing this cleanup, but overly self-righteous commit messages ( http://opensslrampage.org/ ) on patches like http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/cry... rub me the wrong way (I'm sure comparing a string pointer to '5' / decimal 53 is _exactly_ what the old, ridiculed code meant to do…)
That is pretty bad. I can't see how that wouldn't give a new compiler warning that would tell the dev that they probably shouldn't commit that patch.
That said, many opensource projects ignore the vast majority of compilation warnings. Many projects do the same.
OpenSSL is beyond repair. We need a new clean start, sane design and rock solid implementation with principles and following best practices.
Somehow, I don't see removing FIPS or Windows support being in the best interest of the community as a whole. For startups wanting to have a product that requires some level of FIPS support, starting with a decent base makes things easier. Windows support? There are more than a couple of applications out there running on Windows that make use of OpenSSL. Theo's quote -- "99.99% of the community does not care for VMS…
But right now OpenSSL is a VERY VERY messy and dangerous library.
The OpenBSD devs need to get a working implementation, that catches up on 15 years of refactoring and clarity in (optimistically) 2 months -- or risk the bulk of the world's sensitive information leaking yet again (perhaps even sooner, depending on what is discovered!)
It seems that with the kind of things they're finding, there are a lot lesser understood vulnerabilities in the code.
With the kind of standardization they're working on, a Windows port will be a LOT easier and a LOT simpler after they're finished. Best let them make haste, tear out everything that's leaky, unclear, or dangerous -- and with that will come a lot of simplification and fixes for the entire implementation.
Once it's clean, focus on a Ports. The code is too bloated to even consider ports right now. Quite frankly you might even be safer using Microsoft's SSL/TLS and other crypto implementation for the time being... (Only time will tell!)