First release of LibreSSL portable is available(marc.info)
marc.info
First release of LibreSSL portable is available
http://marc.info/?l=openbsd-tech&m=140510291304119&w=2
72 comments
> an audited port of openssl comes out and the discussion centers around:
Exactly what kind of discussion were you hoping for here? We have a number of individuals frequenting this site with the skills to comment on this at a technical level, but they probably have other things to do then to show up for every story that hits the frontpage of HN and requires someone of their skillset to have a competent discussion of the technical details...
> they can use git like all the cool ruby hackers.
Though git has become widely accepted by the Ruby community, it was created by kernel hackers. Is Linus Torvalds now a 'hipster Ruby hacker' or can we elevate the level of discussion here above name-calling?
It also seems like you've missed comments like this: https://news.ycombinator.com/item?id=8021965
Exactly what kind of discussion were you hoping for here? We have a number of individuals frequenting this site with the skills to comment on this at a technical level, but they probably have other things to do then to show up for every story that hits the frontpage of HN and requires someone of their skillset to have a competent discussion of the technical details...
> they can use git like all the cool ruby hackers.
Though git has become widely accepted by the Ruby community, it was created by kernel hackers. Is Linus Torvalds now a 'hipster Ruby hacker' or can we elevate the level of discussion here above name-calling?
It also seems like you've missed comments like this: https://news.ycombinator.com/item?id=8021965
There's a difference between the creator of a software system and who actually adopts it and advocates it in practice.
Yes, git did originally come from Linus and the Linux kernel development community. But since then, their original use of it has been eclipsed by the larger and more vocal GitHub/Ruby on Rails/JavaScript segment of software developers. The fact that both groups use git does not mean that they're otherwise connected in any way. Traits (such as the propensity to be a hipster) specific to one of the groups very likely do not apply to the other.
Many of these GitHub/Ruby on Rails/JavaScript people do advocate very loudly for git's use everywhere, even in situations where it is not the best choice, or even where it's obviously a bad choice. Some of them have elevated git from being a tool to a quasi-religion. They've done this with some of their other "chosen" tools, too, so it's not just limited to git.
They do make the git community as a whole look quite bad. But they're obviously very distinct and separate from the Linux kernel developers who created git. The two distinct groups should obviously not be confused.
Yes, git did originally come from Linus and the Linux kernel development community. But since then, their original use of it has been eclipsed by the larger and more vocal GitHub/Ruby on Rails/JavaScript segment of software developers. The fact that both groups use git does not mean that they're otherwise connected in any way. Traits (such as the propensity to be a hipster) specific to one of the groups very likely do not apply to the other.
Many of these GitHub/Ruby on Rails/JavaScript people do advocate very loudly for git's use everywhere, even in situations where it is not the best choice, or even where it's obviously a bad choice. Some of them have elevated git from being a tool to a quasi-religion. They've done this with some of their other "chosen" tools, too, so it's not just limited to git.
They do make the git community as a whole look quite bad. But they're obviously very distinct and separate from the Linux kernel developers who created git. The two distinct groups should obviously not be confused.
This is called "bikeshedding" and it's inevitable.
http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality
http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality
Or perhaps like dogs peeing on lampposts - just leaving their mark. Most of these people are incapable of comprehending the internals of SSL or contributing to it, so they comment on trivialities (which they do not understand either). Dragging things down to their own level is another way of putting it.
You've just described bike shedding.
I am surprised that we haven't gotten discussion around point 4 ("Theo is an asshole, so is Linus, but Theo is worse"). These seem to be always present when anything related to OpenBSD is discussed. It's disappointing.
that's because CVS is shit and they should use git or mercurial.
and why should we trust an SSL tool that uses COMIC SANS on thier website. these LibReSSL dudes sound like idiot hipsters
and why should we trust an SSL tool that uses COMIC SANS on thier website. these LibReSSL dudes sound like idiot hipsters
"these LibReSSL dudes sound like idiot hipsters"
No, they're just poking fun at people like you :D
No, they're just poking fun at people like you :D
"This page scientifically designed to annoy web hipsters."
Hint: they are mocking you.
Source is served from a HTTP website with no PGP signature in sight. :-( Critical software like this should really be distributed more securely.
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? :)
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...
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...
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.
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.
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?
Indeed. Consider it a preview. :)
I am considering it a preview of how releases of important security software are handled by the developers.
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.
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.
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).
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.
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/ ?
Btw, did you have a look into ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/ ?
Where should bugs be reported?
It doesn't build on Debian:
md5/md5_dgst.c: In function 'md5_block_data_order':
md5/md5_dgst.c:107:49: error: right-hand operand of comma expression has no effect [-Werror=unused-value]
HOST_c2l(data,l); X( 0)=l; HOST_c2l(data,l); X( 1)=l;
^Perhaps try #openbsd on Freenode.
definitely not. mail to [email protected]
The github repo: https://github.com/libressl-portable
From the README:
Development is done in the upstream OpenBSD codebase. A github clone of the official repositories is kept at: https://github.com/libressl-portable We update this repository from the OpenBSD respositories semi-frequently, so changes may not show up in GitHub immediately. The GitHub repository should be used for informational purposes only.
Development is done in the upstream OpenBSD codebase. A github clone of the official repositories is kept at: https://github.com/libressl-portable We update this repository from the OpenBSD respositories semi-frequently, so changes may not show up in GitHub immediately. The GitHub repository should be used for informational purposes only.
Makes me wonder why is OpenBSD still using CVS for their things.
Really, not having atomic commits is a pain
Really, not having atomic commits is a pain
Works for them so who cares? No reason to bikeshed tools of a project you're not sending patches to anyway.
Windows XP works for some people. There are legitimate costs to operating in the past, moreso when it's a project other people rely on.
-2 for an absolutely true fact? Wow. I'm not normally one to complain about downvotes but.. seriously.
-2 for an absolutely true fact? Wow. I'm not normally one to complain about downvotes but.. seriously.
There are also significant migration costs.
They likely have a toolchain built around CVS that would have a very challenging time being migrated to git.
They also have a workflow that involves tracking file IDs as the import/export files from other projects. Git doesn't do this well.
They likely have a toolchain built around CVS that would have a very challenging time being migrated to git.
They also have a workflow that involves tracking file IDs as the import/export files from other projects. Git doesn't do this well.
Every change (for significant values of, err.. significant) breaks someone's workflow.
Again, XP works for many. That doesn't mean there aren't vanishingly few reasons to use it anymore. For CVS, there's the whole non-atomic changes thing, the whole no renaming files thing, no binary file support, no amending commits, no bisect (a feature which I believe sells the software even if everything else sucked), it's harder to collaborate with other users..
Holding onto objectively inferior tools due to a lack of desire to migrate because "it works for me!" is a huge plague on technology.
Again, XP works for many. That doesn't mean there aren't vanishingly few reasons to use it anymore. For CVS, there's the whole non-atomic changes thing, the whole no renaming files thing, no binary file support, no amending commits, no bisect (a feature which I believe sells the software even if everything else sucked), it's harder to collaborate with other users..
Holding onto objectively inferior tools due to a lack of desire to migrate because "it works for me!" is a huge plague on technology.
Perhaps "workflow" was the wrong word. What I am talking about is fundamental to how the project manages sources.
And again, they likely also have tools built around CVS. From my understanding of OpenBSD's build system, it would ALSO require significant effort to divorce it from CVS and marry it to git.
Similarly, Arch Linux switching from SVN to git for the packages repositories is very unlikely to happen. They've discussed it a number of times, but besides all the tooling that has been written around the SVN setup, it isn't well-suited to their use case. That isn't to say that switching to git wouldn't have benefits, or that SVN is perfect, but: It would take substantial development and testing effort to make it happen, as well as ALL contributors having to change how they work (not "learn git" (all of the other repositories for Arch are git anyway), but "re-learn all the Arch-specific tools that were built around SVN, but are now built around git").
> Holding onto objectively inferior tools due to a lack of > desire to migrate because "it works for me!" is a huge > plague on technology.
That's a broken argument.
Sure, it is in the case where an organization is hanging onto SVN because none of the developers want to take the effort to switch, and that is a drag on development. But, at the same time, if it is what the developers actually chose; it's not a drag. (The "users refusing to upgrade" is also a drag on technology because of support costs; that is irrelevant here, but is a cause of much of the "must upgrade" feelings among developers)
But the opposite is also true, switching to the latest thing without actually evaluating why is also a HUGE plague on technology. Git in most aspects is a far better tool than CVS. But, there are still things that CVS and SVN are better at (managing subprojects is the biggest one). These are things that I know in Arch mostly outweigh git's benefits, and I presume the same is true of OpenBSD.
And again, they likely also have tools built around CVS. From my understanding of OpenBSD's build system, it would ALSO require significant effort to divorce it from CVS and marry it to git.
Similarly, Arch Linux switching from SVN to git for the packages repositories is very unlikely to happen. They've discussed it a number of times, but besides all the tooling that has been written around the SVN setup, it isn't well-suited to their use case. That isn't to say that switching to git wouldn't have benefits, or that SVN is perfect, but: It would take substantial development and testing effort to make it happen, as well as ALL contributors having to change how they work (not "learn git" (all of the other repositories for Arch are git anyway), but "re-learn all the Arch-specific tools that were built around SVN, but are now built around git").
> Holding onto objectively inferior tools due to a lack of > desire to migrate because "it works for me!" is a huge > plague on technology.
That's a broken argument.
Sure, it is in the case where an organization is hanging onto SVN because none of the developers want to take the effort to switch, and that is a drag on development. But, at the same time, if it is what the developers actually chose; it's not a drag. (The "users refusing to upgrade" is also a drag on technology because of support costs; that is irrelevant here, but is a cause of much of the "must upgrade" feelings among developers)
But the opposite is also true, switching to the latest thing without actually evaluating why is also a HUGE plague on technology. Git in most aspects is a far better tool than CVS. But, there are still things that CVS and SVN are better at (managing subprojects is the biggest one). These are things that I know in Arch mostly outweigh git's benefits, and I presume the same is true of OpenBSD.
You can't really compare Windows XP and CVS. It's disingenuous.
CVS isn't deprecated. You can't say that it's fundamentally obsolete, either. It's just really primitive, compared to modern DVCS like Git and Mercurial.
But if the primitive functionality fulfills their use case, why should they switch?
CVS isn't deprecated. You can't say that it's fundamentally obsolete, either. It's just really primitive, compared to modern DVCS like Git and Mercurial.
But if the primitive functionality fulfills their use case, why should they switch?
Why not?
* Both are perfectly working versions of software
* Both have been obsoleted by newer, more fully featured, and more secure replacements (git cryptographically hashes its commits, cvs does not)
* Both have users that refuse to migrate from them because "it works for them", despite the benefits and impact on everyone else.
* Both are perfectly working versions of software
* Both have been obsoleted by newer, more fully featured, and more secure replacements (git cryptographically hashes its commits, cvs does not)
* Both have users that refuse to migrate from them because "it works for them", despite the benefits and impact on everyone else.
CVS still has its uses.
http://stackoverflow.com/a/7871646/827263
http://stackoverflow.com/a/7871646/827263
Humm, let's see
"Unlike Git, you can check out only a subset of the repository."
Maybe useful, you can do that in SVN, also checkouts in GIT are very fast, the point may be moot.
"So I find CVS (and sometimes even RCS) convenient when the repository is a collection of largely unrelated files, and I'm more interested in tracking changes on individual files"
Ok, I guess it makes sense in this strict case (for example, a collection of config files). Apart from that, if you're wondering with version of file A works with which version of file B you lost.
"At least once, I've had to manually reconstruct a saved CVS file that had become corrupted. I'm not sure how I could have done that with SVN or Git."
They wouldn't have corrupted the file in the first place more likely... And yes there are ways to recover it.
"Unlike Git, you can check out only a subset of the repository."
Maybe useful, you can do that in SVN, also checkouts in GIT are very fast, the point may be moot.
"So I find CVS (and sometimes even RCS) convenient when the repository is a collection of largely unrelated files, and I'm more interested in tracking changes on individual files"
Ok, I guess it makes sense in this strict case (for example, a collection of config files). Apart from that, if you're wondering with version of file A works with which version of file B you lost.
"At least once, I've had to manually reconstruct a saved CVS file that had become corrupted. I'm not sure how I could have done that with SVN or Git."
They wouldn't have corrupted the file in the first place more likely... And yes there are ways to recover it.
Valid points; I never claimed that CVS is better than Git in general. I still use it for some things mostly out of habit and the fact that it's not really worth the effort of migrating (again, this is mostly for collections of files that don't depend on each other).
As for the (rare) corrupted files, I don't know what caused that. They were single-bit errors that I could correct by manually editing the *,v files. I know of no reason to assume that such errors are more or less likely with Git vs. CVS.
As for the (rare) corrupted files, I don't know what caused that. They were single-bit errors that I could correct by manually editing the *,v files. I know of no reason to assume that such errors are more or less likely with Git vs. CVS.
I seems almost like the bsd people prefer minimalist tooling.
> CVS isn't deprecated.
Isn't it? I thought SVN was designed to be a similar but better system? Also cvs(the gpl one, not opencvs) seems to not have had any commits for several years.
Isn't it? I thought SVN was designed to be a similar but better system? Also cvs(the gpl one, not opencvs) seems to not have had any commits for several years.
I think there is a much more important feature in git for OpenBSD: cryptographic hashes of all commits that depend on the parent commit (=> cryptographically hashed history). Combine that with commit signing and detecting tampering gets easy. There are reported cases where this helped the Linux kernel project detect tampering.
Or have they implemented something like this on top of CVS?
Or have they implemented something like this on top of CVS?
OpenBSD combines two seldom used techniques. First, not having millions of lines of code written by random untrusted people. This allows them to use the second technique, which is to actually read their code.
Well, that is not good enough. How can you proof that already read (audited) code wasn't tampered afterwards by a hacker? If you don't use cryptographic hashes you can't.
-2 for an absolutely true fact?
It's probably because, true or not, not the best argument. Other than the fact Microsoft ended support Windows XP is fine. It does the job. It's not the latest and greatest, but right to the end it was better than acceptable or tolerable, it was downright decent.
A hardware refresh at work gave me a 7 box, but I've still got my old XP box in a corner somehwere, heavily firewalled ofc now that support has ended, I remote desktop into it 5-10 times a month now for the few straglers I haven't migrated off, and its fine.
Yeah legacy does have support costs, but as I said, you're not building openbsd from source nor would you be if they were on a trendy vcs. That's why they mirror libressl on github, this is a case where they know outsiders might care. And one vcs or another you're going to the mailing list to submit a patch to them, so until you're in it, don't really matter.
It's probably because, true or not, not the best argument. Other than the fact Microsoft ended support Windows XP is fine. It does the job. It's not the latest and greatest, but right to the end it was better than acceptable or tolerable, it was downright decent.
A hardware refresh at work gave me a 7 box, but I've still got my old XP box in a corner somehwere, heavily firewalled ofc now that support has ended, I remote desktop into it 5-10 times a month now for the few straglers I haven't migrated off, and its fine.
Yeah legacy does have support costs, but as I said, you're not building openbsd from source nor would you be if they were on a trendy vcs. That's why they mirror libressl on github, this is a case where they know outsiders might care. And one vcs or another you're going to the mailing list to submit a patch to them, so until you're in it, don't really matter.
I'm all for migrating to git, but at least one aspect of the OpenBSD workflow would take some serious thought to migrate: CVS supports having one giant repository containing everything (at least, as well as it supports anything else), even including project source code, whereas git really wants smaller per-project repositories that share common history with the corresponding upstreams. In light of that, migrating to git would require some non-trivial workflow changes, making it understandable that it hasn't happened in a hurry.
It depends how you work and how stable your product is. I think they are patch heavy i.e the CVS tree is used to apply patches to and that is that. CVS has some advantages then as you can pin individual file versions on a tag rather than having to fuck around merging things. Individual files might be ethernet drivers, scheduler etc because TBH the BSD codebase is a hell of a lot better decoupled and modular than most things out there.
CVS works because they didn't fuck it up.
CVS works because they didn't fuck it up.
License is one of the reasons. OpenBSD uses the BSD license, and has a strong preference for it when it comes to the base system, base tools, etc. There's no chance they'll move something so critical to GPL-licensed software.
$ uname
OpenBSD
$ cvs -v
Concurrent Versions System (CVS) 1.11.1p1 (client/server)
Copyright (c) 1989-2001 Brian Berliner, david d `zoo' zuhn,
Jeff Polk, and other authors
CVS may be copied only under the terms of the GNU General Public License,
a copy of which can be found with the CVS distribution kit.
Specify the --help option for further information about CVS
My understanding is that it's BSD licensed, and works well enough.
No, it's GNU CVS, but it does work well enoughish...
Just curious, but why don't you use git?
they use a shitty BSD clone called Open CVS
Or not.
yes they do
You do realize who Ted Unangst is, right?
If he says "we use GNU CVS" you might consider believing him.
If he says "we use GNU CVS" you might consider believing him.
You might consider cross-referencing the authors of commits to the LibreSSL project with the authors of comments in this thread. You might be surprised.
humor/irony or not, I'll never take a project seriously that has such ridiculous typography for the project home page.
Sure you will. It'll be bundled with your OS, or your browser, or just used by web sites you visit that have "https://" at the beginnings of their URLs, and you'll take it seriously because you take those thing seriously.
By the same token, you're trusting OpenSSL unless you go to great pains not to.
By the same token, you're trusting OpenSSL unless you go to great pains not to.
Mission accomplished.
Maybe they could switch to a hip, cool font when everything's finished. Right now, it's in Comic Sans territory, because it's really not done.
I guess that makes OpenSSL crayon, I don't know... :) (Kidding!)
Maybe they could switch to a hip, cool font when everything's finished. Right now, it's in Comic Sans territory, because it's really not done.
I guess that makes OpenSSL crayon, I don't know... :) (Kidding!)
agreed
1. why CVS sucks and the openbsd team should spend 3 months doing nothing but reworking their development processes so they can use git like all the cool ruby hackers.
2. Lack of formality in the release announcement
3. Choice of font
wow.