Hacker News Reader

Comment by agwa | Hacker News Reader

Source is served from a HTTP website with no PGP signature in sight. :-( Critical software like this should really be distributed more securely.

View on HN

It's a bit early to rely on as critical - this is serious work-in-progress. I'm not sure I'd use it yet, and I'm not sure you should either, but then, I suppose I could say that equally well about the OpenSSL library it's forked from.

It is nevertheless a bit weird to see test sourcecode for TLS support on a site that does not support HTTPS!

Maybe when the cleanup is complete and it's shored up, they might actually use it? :)

Yeah, a LibreSSL dev has replied saying as much. I did not realize this was meant to be a preview release, or I would not have been so critical. (But I do think they could have made this more clear in their announcement and/or version scheme.)

Interesting to compare and contrast the approach taken by libreSSL and agl's BoringSSL (my own private fork is in the process of being replaced by BoringSSL, because it's not as hacky as my solutions).

I think I prefer BoringSSL's cmake/make process, because OpenSSL's build system is simply horrible, I've never liked it. But it doesn't do shared libraries yet, so I'm having to take the .a files and link them by hand (well, by script anyway). Not optimal, but better than having to rebase my own patches so frequently, and it's only a test box.

I love the sheer amount of renovation-via-demolition libreSSL's doing. OpenSSL really does have a terrifying amount of #if 0, crufty ciphers and code no-one ever wants to use.

By the way, you may as well take RC4 out: it's about to get another significant result...

fwiw, the current policy is that mere availability of crapto algorithms isn't the end of the world. This is clearly debatable (I'm not entirely happy with it myself), but the reality is that many people using crapto are stuck with it, and if one library doesn't offer it, they'll use another that does.

Like if no RC4 meant no youtube, I don't think we're quite popular enough to demand that youtube change ciphers.

Cryptography software is in itself cryptic. Does that increase encryption strength?

Taking out of defaults maybe, but people still need to be able to access old/broken ciphers to do work. Maybe I'm mis-interrupting your meaning.

Indeed. Consider it a preview. :)

I am considering it a preview of how releases of important security software are handled by the developers.

I'm also horrified to see that the OpenBSD songs are still without proper PGP signatures. How can I be sure Richard Stallman and Bill Gates didn't tamper with the lyrics?

Btw, did you have a look into ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/ ?

Working out the details of who signed what and when for OpenBSD took several weeks. After months of people asking when a portable release would be made (and critics slagging us and saying it would/could never happen), we could have held back the release for another month while we sorted that out. Or we could cut a release right now, while all the people working on portable are sitting in the same room and are well positioned to resolve build issues. Apparently we chose wrong. Next time we'll maintain radio silence until everything is just perfect.

I appreciate the clarification; had the announcement contained something to that effect ("We realize that production releases need GPG signatures and secure distribution channels, but we want to get this build out for early testing by devs and we're still ironing out the aforementioned distribution procedures"), I'd not have had any complaint at all.

Unfortunately, without that notice, my first thought was "why is it linking me to an HTTP site". The notice prevents visitors like me from guessing as to why that is by setting the appropriate context and letting us know you're aware of the right steps but they aren't feasible right now.

It's the first release. Of course it's not production ready. But fair enough. The web site will tell you when it's ready to use. :)

It's not the state of the software itself that's being questioned here. It's how security wasn't put first and foremost in this case. Putting an extraordinarily high degree of emphasis on security is something a lot of us have come to expect from OpenBSD and related projects. Security comes first, even if that means waiting a bit longer for an official release, or something like that.

While LibreSSL does appear to be going in the right direction, especially after the disastrous few months that OpenSSL has had, the community at large does want to be reassured that the LibreSSL project truly does revere security. A more security-conscious release in this case would have helped with that.

I respect the work you're doing on LibreSSL and OpenBSD. The release of this portable LibreSSL arrived much sooner than anyone expected and that's commendable. I think pretty much everyone expected it to be released in OpenBSD first and later as a portable version.

However, I really like to download code related to cryptography securely. Perhaps you didn't have the resources or the time to do this.

There were a few easy to do things: posting the hashes of the downloads in various places like GitHub, mailing lists, this HN thread and a few others. GitHub is useful for serving source releases, as long as you post the hashes in more places.

OpenSSL has been heavily criticized. That has been debated ad nauseam in countless places. The one thing I like about OpenSSL is that they're providing secure downloads. Their code might be bad, but at least you can download it from them via HTTPS.

Many would like to contribute, but the OpenBSD project isn't the friendliest (that's a mild way to put it).

This is not a release for anyone's production system. It's to review on test systems, or to audit.

Reply on news.ycombinator.com