I'm more than surprised about the hostile tone some contributors seem to use when they talk about LibreSSL lately.<p>LibreSSL is an OpenSSL fork done by the OpenBSD team primarily because they don't think OpenSSL is the right software to include in their OS. That's their decision, if you don't use OpenBSD, you don't have to care. They have done an insane amout of work in pretty short time, and since that work might benefit the larger OS community, they kindly decided to start work on a portable version, which you don't have to use.<p>Even if you don't use LibreSSL, you might still benefit from their work as there is a healthy collaboration between OpenBSD/LibreSSL and Google/Adam Langley/BoringSSL.<p>Now, there's a first preview release of portable LibreSSL, and nitpicks are used to demonstrate how supposedly incapable the OpenBSD team must be. They hardcode -Werror, they obviously don't know how to write a configure script. They don't provide a PGP signature for the preview release, they obviously don't know how to distribute software securely. They use Comic Sans, they can't be taken seriously at all.<p>If you think LibreSSL will benefit you personally, you might consider showing a little gratitude. If you don't think LibreSSL is of any use to you, why do you even bother to write about it?
> -Werror is hardcoded in the configure script, which is a very bad idea, and the opposite of portable.
using -Werror is a guarantueed build break whenever the build is tried on a system the original developer had no access to.<p>I think that is <i>exactly</i> the point; if the thing does not build, people are going to complain loudly and things are going to get fixed. Warnings are usually just run-time problems waiting to happen, so they may as well be considered bugs.
<i>so if the libressl developers rip out all their dubious entropy generation methods in favor of /dev/urandom on linux it might be well worth switching to it.</i><p>/dev/urandom <i>is</i> the favored entropy gathering method. But if you can't open it (not there, rlimit restriction, etc.) it falls back to the bobo code. If the linux kernel provided a random number source that was reliable and could not fail, this wouldn't be an issue.
LibreSSL is lacking features such as ALPN and they've removed many constants, changed function definitions in subtle ways and modified header include dependencies. The result of this is that it definitely isn't a drop in replacement for OpenSSL. Then again OpenSSL usually isn't a drop in replacement for OpenSSL between versions either so they aren't doing a terrible job.<p>Most of these could be easily worked around with a few #ifdefs but they've also managed to make that a bit problematic by reusing the OPENSSL_VERSION_NUMBER macro without providing some sort of complementary IS_LIBRESSL flag. Fortunately OpenSSL hasn't hit version 2 yet so the version numbers don't overlap at all.
The author tried building the first release on Sabotage Linux, an experimental distro, and reported on what broke. That may be valid; I hadn't heard of the distro before. They also talked about how entropy was being gathered incorrectly; this is <i>possible,</i> as I thought it's kind of a preview release, but I'm inclined to listen to the OpenBSD guys first.
re: hard-coding -Werror into the build process<p>Yes, -Werror is normally going to break things badly and cause far too much unnecessary work... <i>for most projects</i>. There are a handful of projects, on the other hand, that I would argue -Werror is absolutely necessary. Crypto libraries such as openssl/libressl/gnutls and tools like gnupg are at the top of that list. This list <i>might</i> also include key-handling utils such as {gpg,ssh}-agent and maybe pinentry.<p>Breaking on new GCC features is a good thing, because for these important packages you <i>shouldn't ever</i> be guessing about the programmer intention or <i>assuming</i> that some new warning is safe.<p>Several people brought up -Wunused. We already know about that warning, and so libressl should expect it and compile cleanly. Yes, this might be annoying at times, but cleaning up the code was the goal anyway. What about future versions of GCC? There are only a few possibilities:<p><pre><code> 0) The warning actually is about an important bug.
</code></pre>
Obviously you don't want the build in this case.<p><pre><code> 1) Some new -W flag was added.
</code></pre>
Broken build are important here. The GCC authors probably added that flag for a reason, and you can't <i>guarantee</i>[1] the warning is a false-positive.<p><pre><code> 2) No flags have changed, but some other component has caused
a warning where there wasn't one previously.
</code></pre>
This means something else changed:<p><pre><code> 2a) A function prototype changed. (does it even compile properly?)
2b) Some defined type or macro changed. (could easily be a new bug)
</code></pre>
Yes, in many cases, these are probably trivial. The point is that for some software, forcing someone to actually check is <i>the goal</i>. The problems with openssl that were recently exposed by heartbleed was that <i>nobody was actually checking</i> security-critical components, and simply assuming those checks were being done by somebody else.<p>With -Werror, the fact that it doesn't compile will force someone to either fix some bug or silence the warning by adding the necessary cast or #ifdef or whatever. Really, I have to wonder about anybody who advocates for allowing unchecked builds: why are you ok with the kind of unchecked code that lead to heartbleed and many other security problems? As DJB[2] and PHK[3] both warned: are you <i>trying</i> to prevent a high-security environment?<p>[1] Why can't we guarantee such things? Because answering that would req1uire solving the Halting Problem.<p>[2] <a href="https://news.ycombinator.com/item?id=8023812" rel="nofollow">https://news.ycombinator.com/item?id=8023812</a><p>[3] <a href="http://ftp.belnet.be/FOSDEM/2014/Janson/Sunday/NSA_operation_ORCHESTRA_Annual_Status_Report.webm" rel="nofollow">http://ftp.belnet.be/FOSDEM/2014/Janson/Sunday/NSA_operation...</a>
Here's the experience of a Gentoo developer: <a href="https://blog.hboeck.de/archives/851-LibreSSL-on-Gentoo.html" rel="nofollow">https://blog.hboeck.de/archives/851-LibreSSL-on-Gentoo.html</a>
"Werror is a guarantueed build break whenever the build is tried on a system the original developer had no access to."<p>Yeah, if your program uses undefined behaviour or your cc is crazy. I think the point is to catch undefined behaviour and make sure it isn't ignored.