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

31–40 of 55 posts

Re: How compatible is LibreSSL?

#31

Post by two_cents_4u »

anon1385 wrote: post #25
currysausage wrote: post #22

Earlier quoted context omitted.

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

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.

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

Re: How compatible is LibreSSL?

#32

Post by wbl »

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.

They aren't: -Werror is doing exactly what it is supposed to, keeping a tacit assumption from subtly causing bugs. sysctl is necessary because there is no randomness system call, and in chroots /dev/random is not available.

Re: How compatible is LibreSSL?

#33

Post by throwaway125 »

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…

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.

Re: How compatible is LibreSSL?

#34

Post by dobbsbob »

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…

OpenBSD can handle the hostile tone, they aren't fragile feels about criticism. The whole point is to release this early so they (and other contributors, like Adam from Google) can get feedback so it's good people are trying to port it and offering opinions however if anybody wants to constructively criticize the project or make recommendations they have to post on the mailing list because I doubt any of them will respond to some random guy's wordpress site. If you just throw up a site and blast them you're accomplishing nothing except link bait. They have a good reason to use -Werror and would explain why if this was posted to openbsd-tech

Re: How compatible is LibreSSL?

#35

Post by commenttard »

two_cents_4u wrote: post #31
anon1385 wrote: post #25

Earlier quoted context omitted.

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.

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

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

Re: How compatible is LibreSSL?

#36

Post by pbsd »

throwaway125 wrote: post #33
ploxiln wrote: post #20

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

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…

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.

Re: How compatible is LibreSSL?

#37

Post by robryk »

__alexs wrote: post #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 wi…

> changed function definitions in subtle ways

This is surprising for me. Can you provide an example?

Re: How compatible is LibreSSL?

#38

Post by agrover »

clarry wrote: post #27
throwaway2048 wrote: post #10

Earlier quoted context omitted.

Was this not one of the things you critisized openssl for? ie falling back on braindead methods when sane ones failed.

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.

Re: How compatible is LibreSSL?

#39

Post by wyager »

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.

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

Re: How compatible is LibreSSL?

#40

Post by currysausage »

__alexs wrote: post #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 wi…

> 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

Post reply on HN