Live data from Hacker News

How compatible is LibreSSL?

devsonacid.wordpress.com

11–20 of 55 posts

Re: How compatible is LibreSSL?

#11
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.

Re: How compatible is LibreSSL?

#12
post #5

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 issu…

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.

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.

Re: How compatible is LibreSSL?

#13
post #5

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 issu…

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.

It does fail if there is not enough entropy.

> An error occurs if the PRNG has not been seeded with enough randomness to ensure an unpredictable byte sequence.

https://www.openssl.org/docs/crypto/RAND_bytes.html

But there is also this:

> Pseudo-random byte sequences generated by RAND_pseudo_bytes() will be unique if they are of sufficient length, but are not necessarily unpredictable.

Re: How compatible is LibreSSL?

#14
post #2

> -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…

I believe the team doing this believes those should be fixed when they happen and so they consider them bugs.

Re: How compatible is LibreSSL?

#15
post #7

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

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

Re: How compatible is LibreSSL?

#16
post #7

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

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

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

Re: How compatible is LibreSSL?

#17
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?

Re: How compatible is LibreSSL?

#18
post #16

Earlier quoted context omitted.

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

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 ha…

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.

Re: How compatible is LibreSSL?

#19

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 ben…

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.

Re: How compatible is LibreSSL?

#20
post #2

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

Post reply on HN