
First release of LibreSSL portable is available - klapinat0r
http://marc.info/?l=openbsd-tech&m=140510291304119&w=2
======
erobbins
So, an audited port of openssl comes out and the discussion centers around:

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.

~~~
stal
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

~~~
hobarrera
Honestly, if you're using windows (which, AFAIK, is the only OS that includes
Comic Sans), why the are you complaining about being unable to trust security
software from a certain provider?

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

~~~
AlyssaRowan
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? :)

~~~
agwa
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.)

~~~
AlyssaRowan
Interesting to compare and contrast the approach taken by lib _re_ SSL 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 lib _re_ SSL'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...

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

------
edwintorok
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;
                                                     ^

~~~
pyroh
Perhaps try #openbsd on Freenode.

~~~
tedunangst
definitely not. mail to bugs@openbsd.org

~~~
mey
That is a little confusing to have on end point for openbsd, openssh and
Montreal.

~~~
gnuvince
And Montreal...

~~~
mey
Sorry that was a phone auto-correction. I typed in LibreSSL...

------
nayden
The github repo: [https://github.com/libressl-
portable](https://github.com/libressl-portable)

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

~~~
raverbashing
Makes me wonder why is OpenBSD still using CVS for their things.

Really, not having atomic commits is a pain

~~~
forgottenpass
Works for them so who cares? No reason to bikeshed tools of a project you're
not sending patches to anyway.

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

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

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

~~~
vezzy-fnord
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?

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

~~~
_kst_
CVS still has its uses.

[http://stackoverflow.com/a/7871646/827263](http://stackoverflow.com/a/7871646/827263)

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

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

------
strict9
humor/irony or not, I'll never take a project seriously that has such
ridiculous typography for the project home page.

~~~
pjscott
Sure you will. It'll be bundled with your OS, or your browser, or just used by
web sites you visit that have "[https://"](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.

