What are the plans for native Windows support? I don't know what they mean by "The right Portability team in place", but it'd be a joke if the lib would require CygWin or some other external portability scaffolding. And without proper Windows support LibreSSL will simply fragment OpenSSL user base. I guess it's still better than nothing, but it definitely won't be an OpenSSL "replacement."
From the Pros & Cons table, it doesn't seem that NSS is obviously superior to OpenSSL. Both seem to suffer from focus on extra features instead of maintenance and reliability.
This might be fine if you're running a Nexus device that still gets updates to the latest Android (Nexus 4 and later?). But for everyone else, that's effectively forcing people to get a new Android phone if they don't want to get stuck with a horribly insecure phone.
Oh, I see the point already...
When powering WebView, Chromium on Android uses the Android system-provided OpenSSL library - something not available to applications building with the Android NDK (like Chrome for Android or other Chromium-based Android applications). This helps reduce memory usage by having a single shared library in memory. To accomplish this with NSS, NSS would have to be part of the Android base image - which would still increase memory usage, as most other Android (native) services would still use OpenSSL.
Unfortunately in the SSL/TLS world, true security is a product of both, as minor flaws in the actual protocol itself are a common enough discovery to make the introduction of new "features" often quite key to the security of the implementation.
If StartSSL manages to topple OpenSSL and to discourage any further OpenSSL development, then that'd be a very bad thing for a lot developers.
Windows will probably get a port some time later on. Remember that OpenSSH's libssh also has Windows support. It's just not something that fits in their current short term goals of fixing up OpenSSL (I like the term flensing they're using).
Indeed!
Can you elaborate on that? I thought StartSSL was a certification authority.
Some people write a lot of stuff plugged into Win32 without considering the CSPs and pull in OpenSSL without thought. Their funeral.
As my father said: "when in France, talk French or hire a translator".
We can debate finer nuances of proper abstraction to the death, but it doesn't move a needle for people who already have OpenSSL dependencies in their code.
In the future, you can expect the same deal as OpenSSH, OpenNTPD and all the other OpenBSD software that _eventually_ gets ported to other architectures when it reaches a point of stability and safety that it makes sense to do so.
I'm sure LibreSSL won't have that problem but I thought it worthwhile pointing out that support for other OSes is not guaranteed.
If you follow that through the series of links, you find that it is just an assumption based on one guy who didn't know the project existed thinking unchanged = unmaintained.
I followed the links a while ago after hitting an intialization failure bug that leaves Linux boxes with the incorrect date. I found that neither Arch Linux or Redhat consider OpenNTPD to be supported on Linux.
Edit: a better link https://bugzilla.redhat.com/show_bug.cgi?id=430143
Portable OpenNTPD 3.9p1 released May 14, 2006.
If windows (and any other non-OpenBSD OS to be honest) people just HAVE to have LibreSSL instead of OpenSSL on their OS then the donation link is at the bottom of the page.
The LibreSSL guys are not yanking anything out of Windows, they're just providing an alternative to OpenSSL, for all the world to use, for free.
They're not under any obligation to support Windows, no matter how bad you want them to.
The concern is that OpenBSD fellas are fragmenting the project and they are also asserting that OpenSSL team was doing things wrong for a long time. This is not a start of a beautiful friendship. Throw in a bit of crowd lynching (to the tune of "OpenBSD is showing OpenSSL how to do security right") and we can end up with OpenSSL devs showing a finger and throwing in a towel. At best, we'll have to related SSL implementations, devs of which don't really talk to each other. That's the issue.
[1] https://www.peereboom.us/assl/assl/html/openssl.html [2] http://www.ibm.com/developerworks/opensource/library/l-opens... [3] http://lists.randombit.net/pipermail/cryptography/2012-Octob...
Fragmenting? Aren't they making a separate, alternative implementation?
Either way, the whole open source field is chock-full of "fragmentation", with countless precious little snowflakes rushing to fork and re-implement anything and everything under the sun to get it just the way they want it. I doubt whatever fragmentation might happen with OpenSSL is a cause for concern, especially when the OpenSSL codebase is objectively bad.
And those projects can upgrade to the heartbleed-patched version of OpenSSL and keep going. If LibreSSL eventually makes it to Windows, they can switch.
OpenBSD can't do everything at once.
Yes, and most of it is awful because they shouldn't. I hate manually configuring SSL certificates for OpenSSL-using Windows software.
Write a socket transport portability layer. It's not that hard, and you almost certainly need one anyway.
I'm fine with them not supporting MSVC in the build, but is it really that much harder to support something like MinGW/MSYS? No need for Cygwin.
The whole point of OpenSSL was that it runs everywhere. If we're going to write a shiny new version, let's at least try to hit the major platforms.
Its just a fork.
Given how knarly build systems can be, then only supporting modern versions of the same could help remove a lot of cruft.
They should use the operating system-shipped APIs, along with the OS-shipped certificate stores.
That means SChannel and CryptoAPIs in native code.