Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How compatible is LibreSSL?

devsonacid.wordpress.com

Post reply on HN
Print view View original

41–50 of 55 posts

Re: How compatible is LibreSSL?

#41

Post by agwa »

tedunangst wrote: post #12
leni536 wrote: post #5

Earlier quoted context omitted.

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

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

Re: How compatible is LibreSSL?

#42

Post by robryk »

tedunangst wrote: post #12
leni536 wrote: post #5

Earlier quoted context omitted.

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

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

What's wrong with generating some random numbers using the parent's entropy pool before fork and using that as the child's entropy pool?

Re: How compatible is LibreSSL?

#43

Post by oldmanjay »

currysausage wrote: post #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 ben…

I honestly didn't pick up on any hostility in the tone of this article. There was no insulting, for instance. It was a simple one-by-one listing of (seemingly minor) mistakes along with corrections for those mistakes.

I think, in order to find hostility in that, you'd have to be looking for it.

Re: How compatible is LibreSSL?

#44

Post by clarry »

ploxiln wrote: post #20
gnuvince wrote: 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 d…

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

Seeing as how easy it is to zap the -Werror from the configure script, I don't think that anyone is being forced to use it. However, making it the default helps avoid the opposite scenario where a growing amount of warnings (some potentially critical!) whizz past and nobody gives a shit.

So, the fact that warnings are enabled, they break built for some people, these people fix the issue and/or shout about it on the Internet (preferrably bugs@), it all is exactly what needs to happen. The problems get noticed and fixed this way. They don't just pile up. Yes it can be annoying, yes there are some stupid warnings -- ideally there'd be a flag -Wuseful-warnings. Yes people are free to zap the -Werror if they don't care about these warnings. Hopefully they know what they are doing because it really is possible that a bug in LibreSSL or in their system headers for example is calling for attention.

Consider how much discussion there was around goto fail and the like -- about the fact that static analysis (or smart compilers) would've caught these things. Why didn't they listen to the compiler?! So passing -Werror is one way towards making sure people look at the issues.

Re: How compatible is LibreSSL?

#45

Post by joshbaptiste »

pygy_ wrote: post #23
currysausage wrote: post #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 ben…

The OpenBSD folks have set the tone. They are arrogant and dismissive, it's not surprising other people respond in kind.

There's a social policy that one must adhere to when interacting with groups within certain "geekdom" domains. I learned it while idling on IRC EFNet in #Linux, #LinuxHelp in the early 2000's. To an outsider it comes off as harsh and dismissive but It really does weed out the random noobs/script kiddies who refuse to read a man page or put any effort into solving a problem themselves. I learned how to exhaust all possible search options before posting and how to formulate a question properly, by providing clear and concise examples of the problem resulting in less followup questions and quick solutions to my issues.

Re: How compatible is LibreSSL?

#46

Post by clarry »

agrover wrote: post #38
clarry wrote: post #27

Earlier quoted context omitted.

If you don't try to cope with the lack of a /dev/random, you get shit from people. If you try to cope with it, you get shit from people. While I would agree that the fallback entropy gathering is very very hacky and ugly, the difference is that it sure as hell tries harder than OpenSSL ever did. I'm not qualified to say whether the things it uses for entropy are truly any good for it, but it sure looks like it wouldn…

I thought the libressl devs thought it was a mistake to even try to fall back -- the code should use OS-provided random numbers, and if they're not there, give up. If so, I'm a little surprised to hear libressl is trying harder than openssl.

Ideally, that's how it handled. In fact that's how it's handled on OpenBSD. Getentropy either works or you're screwed. As it turns out, there are other systems (hello Linux, etc.) where you don't have such a reliable way to source entropy. I don't know how common it is to encounter this in reality but sadly it looks like it might be quite common indeed, though I hope I'm wrong. See the point about daemons chrooting into /var/empty for example.

You can disable the fallback code with a define, so if your distributors are sure your system should always be able to provide a good entropy source in normal use, they'll flip that switch.

Re: How compatible is LibreSSL?

#47

Post by currysausage »

wyager wrote: post #39
pygy_ wrote: post #23

Earlier quoted context omitted.

The OpenBSD folks have set the tone. They are arrogant and dismissive, it's not surprising other people respond in kind.

>They are arrogant and dismissive, I think they've earned that right, and this attitude may be necessary to scare away the kind of developers who might (with perfectly good intentions) end up making the job of the OpenBSD developers a lot harder. OpenBSD is amazing software. By far the best OS I've ever used in my life. If the cost of that is a bad attitude, so be it. Whatever they're doing, it's working.

> OpenBSD is amazing software. By far the best OS I've ever used in my life. If the cost of that is a bad attitude, so be it.

I like to judge a developer's attitude by reading the manpage that he or she kindly wrote for me. OpenBSD manpages are comprehensive and still concise. So the devs respect my time. I really appreciate that. (Actually, I want to throw money at them just for providing such excellent Unix documentation.)

Yes, they tend to be brusque when you mail them about some issue and obviously didn't RTFM before. They are right: You show them that you don't respect their time. Why should they be nice to you?

Re: How compatible is LibreSSL?

#48

Post by oskdfjgfgg »

ayrx wrote: post #19
currysausage wrote: post #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 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.

No, they aren't real problems. And he would know that if he were trying to be constructive, as he would have then posted it to tech. The fact that it is a snotty and incorrect blog post indicates that he is not trying to be constructive.

Re: How compatible is LibreSSL?

#49

Post by oskdfjgfgg »

ploxiln wrote: post #20
gnuvince wrote: 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 d…

This is a preview specifically intended to find problems. Hence -Werror should be on. It is supposed to be off for a production release.

Re: How compatible is LibreSSL?

#50

Post by tedunangst »

agwa wrote: post #41
tedunangst wrote: post #12

Earlier quoted context omitted.

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

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

Post reply on HN