Live data from Hacker News

OpenBSD forks, prunes, fixes OpenSSL

zdnet.com

21–30 of 58 posts

Re: OpenBSD forks, prunes, fixes OpenSSL

#21
post #9

OpenSSL is beyond repair. We need a new clean start, sane design and rock solid implementation with principles and following best practices.

"We need a new clean start, sane design and rock solid implementation with principles and following best practices."

We need everything after the comma, sure, but there's no particular logical connection with the bit before your comma. A drop-in, API-compatible replacement (or at least one where the bits of the API thrown out are carefully chosen and generally unused) with OpenSSL that isn't scary and has been vetted is by far the fastest way to get to the second bit. This is probably the best thing that could have happened to OpenSSL, and I predict a decent chance this will be the dominant branch in under a year.

Re: OpenBSD forks, prunes, fixes OpenSSL

#22
post #10

It's cool they're doing this cleanup, but overly self-righteous commit messages ( http://opensslrampage.org/ ) on patches like http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/cry... rub me the wrong way (I'm sure comparing a string pointer to '5' / decimal 53 is _exactly_ what the old, ridiculed code meant to do…)

That is pretty bad. I can't see how that wouldn't give a new compiler warning that would tell the dev that they probably shouldn't commit that patch.

Re: OpenBSD forks, prunes, fixes OpenSSL

#23
post #10

It's cool they're doing this cleanup, but overly self-righteous commit messages ( http://opensslrampage.org/ ) on patches like http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/cry... rub me the wrong way (I'm sure comparing a string pointer to '5' / decimal 53 is _exactly_ what the old, ridiculed code meant to do…)

This is why I would never use OpenBSD (but yeah, I use OpenSSH). Can't use an OS for people with this type of attitude.

Re: OpenBSD forks, prunes, fixes OpenSSL

#24
post #19

A quote in there says that customers don't care for FIPS support. I hope OpenBSD is not planning on dropping FIPS support from LibreSSL -- it seems like that would be a huge mistake. Government agencies are among the many that are open to SSL vulnerabilities. Our tax, financial, SSN, and healthcare information are all open to vulnerabilities in buggy code. Dropping FIPS support means that government agencies whose se…

It appears doubtful that FIPS will be restored. See the commit: http://marc.info/?l=openbsd-cvs&m=139775148919571&w=2

"Forcible certification conflicts with the goals of a free software project."

Re: OpenBSD forks, prunes, fixes OpenSSL

#25
post #19

A quote in there says that customers don't care for FIPS support. I hope OpenBSD is not planning on dropping FIPS support from LibreSSL -- it seems like that would be a huge mistake. Government agencies are among the many that are open to SSL vulnerabilities. Our tax, financial, SSN, and healthcare information are all open to vulnerabilities in buggy code. Dropping FIPS support means that government agencies whose se…

Even if OpenBSD did not drop the FIPS code, LibreSSL would not be FIPS compliant because that involves paying large amounts of money for certification, which with their limited resources, and the way FIPS nessisarily constrains development, they would be unwilling to do.

Re: OpenBSD forks, prunes, fixes OpenSSL

#26
Somehow, I don't see removing FIPS or Windows support being in the best interest of the community as a whole. For startups wanting to have a product that requires some level of FIPS support, starting with a decent base makes things easier.

Windows support? There are more than a couple of applications out there running on Windows that make use of OpenSSL.

Theo's quote -- "99.99% of the community does not care for VMS support, and 98% do not care for Windows support." -- is, at least to me, narrow minded in the scope of what he defines as "community" -- unless he specifically means the OpenBSD community.

Re: OpenBSD forks, prunes, fixes OpenSSL

#27
post #18

> Some of that is indentation, because we are trying to make the code more comprehensible. 99.99% of the community does not care for VMS support, and 98% do not care for Windows support. They care for POSIX support, so that the Unix and Unix derivatives can run. Do they not realize that clients also need SSL support? Servers that don't have anyone to talk to them are kind of useless, so at best this is half of soluti…

They're building it first and foremost for OpenBSD. If anybody's interested in using their fork, they'll create a portable version, as they do for OpenSSH, OpenSMTPD, &c.

The act of stripping the library down is worthwhile though: OpenSSL has accumulated a lot of cruft over the years.

Re: OpenBSD forks, prunes, fixes OpenSSL

#28
post #18

> Some of that is indentation, because we are trying to make the code more comprehensible. 99.99% of the community does not care for VMS support, and 98% do not care for Windows support. They care for POSIX support, so that the Unix and Unix derivatives can run. Do they not realize that clients also need SSL support? Servers that don't have anyone to talk to them are kind of useless, so at best this is half of soluti…

Ack - looks like I posted something quite similar.

Maybe Theo is thinking only about the "OpenBSD community".

Re: OpenBSD forks, prunes, fixes OpenSSL

#30
post #18

> Some of that is indentation, because we are trying to make the code more comprehensible. 99.99% of the community does not care for VMS support, and 98% do not care for Windows support. They care for POSIX support, so that the Unix and Unix derivatives can run. Do they not realize that clients also need SSL support? Servers that don't have anyone to talk to them are kind of useless, so at best this is half of soluti…

They're building it first and foremost for OpenBSD. If anybody's interested in using their fork, they'll create a portable version, as they do for OpenSSH, OpenSMTPD, &c. The act of stripping the library down is worthwhile though: OpenSSL has accumulated a lot of cruft over the years.

I think restructuring OpenSSL with better modularization could achieve / maintain more compatibility than just ripping things out.
Post reply on HN