
How compatible is LibreSSL? - aksx
http://devsonacid.wordpress.com/2014/07/12/how-compatible-is-libressl/
======
currysausage
I'm more than surprised about the hostile tone some contributors seem to use
when they talk about LibreSSL lately.

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.

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.

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.

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?

~~~
ayrx
So in your view people with valid criticisms should just shut up and be
thankful?

All the points in the blog posts are real problems. Pointing them out just
means that fixes can be made and software can be improved.

~~~
currysausage
_> So in your view people with valid criticisms should just shut up and be
thankful?_

No, sober problem reports (preferably sent to bugs@openbsd.org or openbsd-
tech) are obviously exactly what the preview release is meant for.

As I wrote, I am surprised about the _tone._ Not of any particular comment or
blogpost, but there's a tendency that I perceive lately.

~~~
anon1385
You are upset that people are using the wrong _tone_ to make criticisms of
OpenBSD? The same OpenBSD run by Theo de Raadt?

You reap what you sow, as they say.

~~~
two_cents_4u
Where are your patches to improve OpenSSL? Put up or shut up, some may say...

~~~
commenttard
I know, some of the commentards here are so whiny!

------
gnuvince
> -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 happen, so they may as well be
considered bugs.

~~~
ploxiln
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 didn't intend.

As a trivial example, -Wunused will warn when a function has a parameter but
doesn't use it. But you do this whenever you need to provide a callback that
really doesn't care about one of the parameters. Still, -Wunused is helpful to
find errors elsewhere in the code, so in these cases you might do something
like

unused_param = unused_param;

just to make that one compiler warning go away. (That might work for one
version of a compiler, but not another!) In other cases, the error the warning
catches is so much more uncommon than the spurious warnings, you might disable
that one warning type for your project. The linux kernel does this for a
couple of them.

Anyway, the best way is to enable as many warnings as you can, and have the
discipline to fix the ones you see, without forcing yourself or anyone with
-Werror. In any non-trivial codebase, you guarantee that the next major
release of gcc will not be able to build your code if you use -Werror, due to
some truly spurious warnings. Again, this isn't because gcc sucks, just
because the problem of guessing where what you wanted is different from what
you did is extremely difficult in C.

~~~
throwaway125
While many of these warnings can be annoying during development they are also
very useful if the code is kept clean of them. In this case the __bounded__
attribute is a security feature their compiler version has. If another
platform can not support this feature then revoking this specific instance of
this warning is an active decision someone should make when writing the build
scripts. Just ignoring all warnings is certainly not the way to go.

The language often (always?) has facilities to remove those warnings on a case
by case basis. For example when you don't want to use a parameter you can
actively let the compiler know without assigning the variable to itself: you
can only include the type and not the name:

    
    
        int fn(int, void*);
        
        int fn(int num, void* /*extra*/) {
            // If the name extra is commented out the compiler will
            // not warn that you are not using it. Now it is very
            // clear that not using this variable was an active choice
            // and not a mistake.
            return num;
        }
    

edit: as pbsd pointed out commenting out extra is not portable C code, though
I believe the wider point still stands. These warnings can be very useful and
should be be reviewed before ignoring them.

~~~
pbsd
Omitting `extra` is only valid in C++, not C. In C you have to get by with
things like

    
    
        (void)extra;
    

to shut the compiler up.

------
tedunangst
_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._

/dev/urandom _is_ 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.

~~~
leni536
How is it a good thing to fall back to non sufficient security? The only good
fallback is falling back to crash and clean up. If libressl can't find enough
entropy then it should give up on it.

~~~
tedunangst
I won't argue that point since I generally agree, but ask yourself this:

0\. sshd will fork() and chroot() into /var/empty. After the fork(), you can't
use the entropy you have because it's shared with the parent (i.e., it's not
"entropic").

1\. Where should it get entropy from?

2\. Where does OpenSSL get entropy from in this case?

Anyway, I don't even work on portable libressl because I don't want to deal
with shit like this, but I think the quoted text erroneously gives the
impression that /dev/urandom isn't used. I wanted to correct that impression.

~~~
agwa
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's RAND_poll() should have similar behavior to
ensure maximum compatibility with OpenSSL and to provide a means to use
chroot() safely without the risk of falling back to the "bobo" code. (Also, a
means of safely reseeding after a fork on systems without
minherit(MAP_INHERIT_ZERO)).

(Incidentally, libsodium has a similar API: you can explicitly call
randombytes_stir() to cause the library to open (and keep open) a file
descriptor to /dev/urandom, so subsequent calls to the PRNG work in a chroot.)

~~~
tedunangst
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 inheritzero.)

~~~
agwa
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.

------
__alexs
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.

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.

~~~
currysausage
_> without providing some sort of complementary IS_LIBRESSL flag._

Seems like this is already fixed: [http://marc.info/?l=openbsd-
tech&m=140511451408331&w=2](http://marc.info/?l=openbsd-
tech&m=140511451408331&w=2)

------
pronoiac
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 _possible,_ as I thought it's kind of a preview release,
but I'm inclined to listen to the OpenBSD guys first.

------
pdkl95
re: 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.
    

Obviously you don't want the build in this case.

    
    
       1) Some new -W flag was added.
    

Broken build are important here. The GCC authors probably added that flag for
a reason, and you can't _guarantee_ [1] the warning is a false-positive.

    
    
       2) No flags have changed, but some other component has caused 
          a warning where there wasn't one previously.
    

This means something else changed:

    
    
          2a) A function prototype changed. (does it even compile properly?)
          2b) Some defined type or macro changed. (could easily be a new bug)
    

Yes, in many cases, these are probably trivial. The point is that for some
software, forcing someone to actually check is _the goal_. The problems with
openssl that were recently exposed by heartbleed was that _nobody was actually
checking_ security-critical components, and simply assuming those checks were
being done by somebody else.

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](https://news.ycombinator.com/item?id=8023812)

[3]
[http://ftp.belnet.be/FOSDEM/2014/Janson/Sunday/NSA_operation...](http://ftp.belnet.be/FOSDEM/2014/Janson/Sunday/NSA_operation_ORCHESTRA_Annual_Status_Report.webm)

------
stefantalpalaru
Here's the experience of a Gentoo developer:
[https://blog.hboeck.de/archives/851-LibreSSL-on-
Gentoo.html](https://blog.hboeck.de/archives/851-LibreSSL-on-Gentoo.html)

------
anaphor
"Werror is a guarantueed build break whenever the build is tried on a system
the original developer had no access to."

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.

~~~
wolf550e
gcc routinely introduced new warnings that break correctly working software's
build if they use -Werror. For example, Gentoo had a lot of problems with this
in the past, as do other packagers, it's just that Gentoo users are more
exposed to build failures (upgrade gcc, rebuild tree, watch the fun).

~~~
anaphor
I still don't see the problem, warnings usually indicate problems with the
code, even if that particular sort of warning was added in a new version of
the cc. If they don't indicate actual problems then the compiler is broken,
but I still don't think that's a problem since they can usually be silenced in
some non-intrusive way. Also you shouldn't be trying to build software if you
don't know how to report a bug or have a buggy toolchain (so maybe a lot of
Gentoo users shouldn't be using Gentoo).

~~~
keeperofdakeys
Compiler warnings can come down to things that are purely style, like unused
variables. It's more than likely that an unused variable could sneak itself
into a program, not be found for a few years, then suddenly trigger a warning
when a compiler added the check (of course, compilers have been checking for
this for a long time, but this is just an example).

In the case of Gentoo, this would manifest itself as packages compiling
cleanly with one compiler version, then suddenly lots of packages failing to
compile because the build processes were stopped due to the, now reported,
unused variable. If these were just warnings, then the packages would still
compile, someone would notice (or even the original dev), and the problem can
be fixed. Note that before the compiler upgrade, there was no bug - the
program worked fine.

Except for a case such as libressl (preview release so they can get comments),
having -Werror hardcoded in the build process clearly makes no sense.

~~~
anaphor
Sorry, I still don't believe that's a problem. Unused variable warnings can be
silenced easily if they aren't real bugs (for example an unused parameter in a
callback). Most people don't have to deal with this stuff because they use
precompiled binaries. The people that _do_ deal with this should know how to
fix it properly.

~~~
comex
It's already necessary far too much of the time to manually back and slash C
code to get it to build in an untested or newer environment, without adding
additional cases over purely stylistic compiler complaints. Precompiled
binaries aren't available for every system for which one might want to use
portable software.

