LibreSSL at BSDCan | Hacker News Reader

LibreSSL at BSDCan

blather.michaelwlucas.com

88 pointskryptiskt29 comments

"If you want to use the forthcoming portable LibreSSL, you need: [...] modern C string capabilities (strlcat, strlcpy, asprintf, etc)"

This could lead to some fun arguments, since the Ulrich Drepper rejects the idea of strl{cat,cpy}: http://www.sourceware.org/ml/libc-alpha/2000-08/msg00053.htm...

That's 14 years ago. Is Drepper involved in anything anymore?

http://www.linkedin.com/in/ulrichdrepper not Red Hat anymore, apparently.

Well, it was WONTFIXed in 2004, which is just ten years ago: https://sourceware.org/bugzilla/show_bug.cgi?id=178

Maybe it's worth reheating the debate?

The new glibc maintainers have very different opinions, and have reversed many WONTFIXes

Or perhaps we ought to drop this junk already. Musl libc implements strlcpy while being a whole lot less bloaty than glibc.

In Linux you can find those functions in libbsd.

Which is more than a little ridiculous. I've written code for Arduino and even that has strlcat and strlcpy - in fact, I had to fill in replacements for them in order to port the code to run on Linux.

Drepper is consistently wrong.

At least he's consistent.

> socklen_t – if your OS doesn’t have socklen_t, it’s either int or size_t. But OpenSSL does horrible contortions to define its own. If the size of socklen_t changes while your program is running, openssl will cope.

This doesn't surprise me; I've had to do runtime detection of socklen_t before. There have been 64-bit platforms (old HP/UX I think?) where different versions of the system libraries had differing opinions about sizeof(socklen_t) when you called accept(). On a little-endian platform this would be ignorable (just always reserve 64 bits and pre-zero it) but on big endian you had to do something like:

  uint64_t addrlen = 0;
  rv = accept(sock, &addr, (socklen_t *) &addrlen);
  if ((addrlen & 0xFFFFFFFF) == 0)
    addrlen >>= 32;

...in order for your binary to run on all systems. Fun times.

Is this part accurate? (from page 8) : "The OpenSSL foundation appears to be a million dollar a year for-profit company doing FIPS consulting gigs. (Incorporated in Maryland)"

appears so, but we don't exactly have access to their books.

More or less. See http://veridicalsystems.com/blog/of-money-responsibility-and....

That's kind of one of the problems with OpenSSL: The paid work they do may help most of the OpenSSL developers pay their bills, but spending their time writing weird one-off features for enterprise clients is the opposite of conducive to doing important work to maintain the quality of the library.

It was interesting to hear how impenetrable the code for OpenSSL was even for experienced studs like the OpenBSD team that have handled openssh.

OpenSSL has been dragging around EBSDIC support that the killed off. 90% of people under 50 will never even have heard of it, and 99.9% of people would agree that support should have been dropped ages ago, once explained.

DOS support is another Bob mentioned.

DOS support for a program that all about TCP/IP. Y, for anyone that had to live through it DOS with a bunch of drives and HIMEM crap would get ping, telnet and a couple other TCP/IP programs.

Possibly somebody even wrote http server for DOS after it was already dead for 10 years.

There's a graphical web browser that runs on DOS, and some other platforms without needing a windowing system:

https://en.wikipedia.org/wiki/Arachne_%28web_browser%29

Not sure if it's for that, though. Maybe it's for a DOS port of Lynx, which actually supports SSL.

It's amazing that the OpenSSL Foundation seems to do so little work on their actual code base give that they actually seem to take donations and have developers.

OpenBSD by comparison gets things done with 10% of the OpenSSL budget?

The current maintainers of OpenSSL have been doing a shitty job. It's not that heartbleed itself was the problem.

OpenSSL scares people away, the code is such a mess. I've looked at it for 5 minutes years ago. You hope to compile it, let alone understand it.

Finally people had to take a look at it, and what they found was a scary unmaintained mess vs other open source projects.

Specifically considering the importance of OpenSSL the maintainers seem to do a terrible job.

As people have mentioned. OpenSSL is basically a "FIPS" consultancy.

http://en.wikipedia.org/wiki/Federal_Information_Processing_...

FIPS is real world useless to 99% of the population that doesn;t live in the US and do business with the US govt.

They are worried more about maintaining the FIPS then patching or improving the code base for something that has become so universal.

That's fine for them, but a couple million a year in consulting fee's is messing with a much larger audience.

OpenSSL will be able to keep its outdated code base and FIPS, while the rest of the world moves on.

Key takeaway from Bob, is they need to raise money to pay some super knowledgable developers to get some of the more lengthly parts done.

I recently (2011ish) got SSH installed and working on DOS. I was writing a DOS utility for a client (who makes high end network cards)—all their manufacturing is done via DOS. I got frustrated at the slow turn around time of sneakernetting my code to the test machine via USB thumb drives and managed to get SSH up enough so that could scp from the network.

You might think DOS is dead (I did), but it still exists (thrives?) at certain places.

On FIPS, this claims it is possible to fix Heartbleed without invalidating FIPS certification because the TLS code is separate from the actual crypto implementation: http://lwn.net/Articles/596102/

That says a lot about how meaningless FIPS actually is...

Slides in the other front page submission: https://news.ycombinator.com/item?id=7761041

Asking the Linux foundation for support is interesting. I'm sure that will in itself cause a few problems.

Good work though all round.

Can you expand on this? Do they have a past history of conflicts?

If not, this project would certainly benefit both *BSD and the Linux community. Although the LibreSSL team is currently concentrated on just targetting OpenBSD, the cleaner code base should make porting easy enough that the work in exchange for a cleaner, more secure and easier to debug code base will be worth it.

It would serve the Linux foundation to keep with a more secure implementation than OpenSSL.

> It would serve the Linux foundation to keep with a more secure implementation than OpenSSL.

The Linux Foundation is supporting the OpenSSL project with funding.

Hm.... I see. I do not know if things often get political with the Linux Foundation.

If they do, then this could definitely be an issue.

If they don't then I can see there benefit for the Linux Foundation in funding both. LibreSSL has the benefits I previously mentioned, and OpenSSL benefits from having all the features that are being cut out by LibreSSL (FIPS probably being the biggest one).

But I can see where the possible conflict could occur. Thanks for clearing things up.

> Asking the Linux foundation for support is interesting. I'm sure that will in itself cause a few problems.

Why? Are we kids?

Is there a video of this talk?

There must be. I just watched his talk and they a video capture device setup on it.

Perhaps you have to wait a couple days for it be processed and uploaded.

Good talk Bob.

It should be available from https://www.youtube.com/user/osbootcamp/videos at some point in the next few days.

Thanks!

Yep, it is here https://www.youtube.com/watch?v=GnBbhXBDmwU

Reply on news.ycombinator.com