Here's the experience of a Gentoo developer: https://blog.hboeck.de/archives/851-LibreSSL-on-Gentoo.html
How compatible is LibreSSL?
51–55 of 55 posts
Re: How compatible is LibreSSL?
#52> -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. I think that is exactly 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 ha…
C is not the same as other languages. Many possible errors reported by the compiler really are not bugs. You've probably heard of "-Wall" and "-Wextra". Why does -Wextra include even more warnings than -Wall? Because they're more likely to include truly spurious warnings. C is both more simple and more flexible than other languages, and it's very hard for the compiler to tell when the code does something the writer d…
"Still, -Wunused is helpful to find errors elsewhere in the code, so in these cases you might do something like
unused_param = unused_param;"
It is better to comment out the name of the argument in the function header:
void foo( int x, int /* unused */)
{
…
}
Re: How compatible is LibreSSL?
#53Earlier quoted context omitted.
C is not the same as other languages. Many possible errors reported by the compiler really are not bugs. You've probably heard of "-Wall" and "-Wextra". Why does -Wextra include even more warnings than -Wall? Because they're more likely to include truly spurious warnings. C is both more simple and more flexible than other languages, and it's very hard for the compiler to tell when the code does something the writer d…
"Still, -Wunused is helpful to find errors elsewhere in the code, so in these cases you might do something like unused_param = unused_param;" It is better to comment out the name of the argument in the function header: void foo( int x, int /* unused */) { … } C compilers know not to complain about that second argument ( http://stackoverflow.com/questions/1486904/how-do-i-best-sil... )
That's C++, not C. In C, the parameter name must be specified in a definition. I tried with 7 compilers, and none of them allow it as an extension, either, as they all consider it a fatal error.
Re: How compatible is LibreSSL?
#54Earlier quoted context omitted.
With OpenSSL, if you know you're going be chrooting, you can explicitly seed the internal PRNG with a call to RAND_poll() before you chroot, avoiding the need to open /dev/urandom once you've chrooted. (Similarly, you're supposed to call RAND_poll() to re-seed after forking because there's no safe way to detect that you've forked. Of course, if you fork while in a chroot you're screwed.) I really think that LibreSSL'…
Yes, that's what you're supposed to do, and it sucks. A good library should provide you with more than a box full of hammers and thumbs; it should actually help you and not just punt whenever a hard decision shows up. The RAND interface was one of the first things gutted. The presence or need for a stir() function should be considered a serious design flaw. (forks are detected by calling getpid() if you don't have in…
Agreed, but the lack of a random syscall on Linux makes an API like stir necessary.
Also, getpid() isn't airtight - if you fork and fork again there's a risk of PID wraparound.
Re: How compatible is LibreSSL?
#55re: hard-coding -Werror into the build process
Yes, -Werror is normally going to break things badly and cause far too much unnecessary work... for most projects. 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 might also include key-handling utils such as {gpg,ssh}-agent and maybe pinentry.
Breaking on new GCC features is a good thing, because for these important packages you shouldn't ever be guessing about the programmer intention or assuming that some new warning is safe.
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:
0) The warning actually is about an important bug.
1) Some new -W flag was added.
2) No flags have changed, but some other component has caused
a warning where there wasn't one previously.
2a) A function prototype changed. (does it even compile properly?)
2b) Some defined type or macro changed. (could easily be a new bug)
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 trying to prevent a high-security environment?
[1] Why can't we guarantee such things? Because answering that would req1uire solving the Halting Problem.
[2] https://news.ycombinator.com/item?id=8023812
[3] http://ftp.belnet.be/FOSDEM/2014/Janson/Sunday/NSA_operation...