

LibreSSL at BSDCan - kryptiskt
http://blather.michaelwlucas.com/archives/2071?

======
beefhash
"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...](http://www.sourceware.org/ml/libc-
alpha/2000-08/msg00053.html)

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

[http://www.linkedin.com/in/ulrichdrepper](http://www.linkedin.com/in/ulrichdrepper)
not Red Hat anymore, apparently.

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

Maybe it's worth reheating the debate?

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

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

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

~~~
mnordhoff
More or less. See [http://veridicalsystems.com/blog/of-money-responsibility-
and...](http://veridicalsystems.com/blog/of-money-responsibility-and-pride/).

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.

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

~~~
TazeTSchnitzel
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](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.

~~~
stormqloud
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_...](http://en.wikipedia.org/wiki/Federal_Information_Processing_Standards)

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.

------
yuhong
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/](http://lwn.net/Articles/596102/)

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

------
TazeTSchnitzel
Slides in the other front page submission:
[https://news.ycombinator.com/item?id=7761041](https://news.ycombinator.com/item?id=7761041)

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

Good work though all round.

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

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

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

------
ehPReth
Is there a video of this talk?

~~~
bremac
It should be available from
[https://www.youtube.com/user/osbootcamp/videos](https://www.youtube.com/user/osbootcamp/videos)
at some point in the next few days.

~~~
ehPReth
Thanks!

