Edit: To those downvoting, yes, I saw the footer. This doesn't excuse their childish behavior. I will not be donating to this project if this is the level of seriousness they have for it.
Ask yourself which hipster start-up is going to do a comprehensive rewrite job on OpenSSL - or, for that matter, which SV VC is going to bung a few million green sheets into something like this (which, if we're honest, we could all do with happening, rather than the next DOA social media start up with a -ly/-able/-r suffix).
If these people are prepared to take this on, then they can use whatever fonts they bloody well like. As a web hipster, I will pay them for punishing my hubris.
Having said that, I can't seem to find a browser in which the blink tags actually, er, blink. Did all the vendors shitcan it on the quiet? I think we should be told.
You know, what you really care about is them spending time on writing good software, not writing good websites. They don't have time for this, they don't have money for this, and they don't want to spend human CPU on this.
Oh, and while we're at it, the OpenSSL page [0] isn't much better visually speaking. Would you donate to them to make OpenSSL better ?
It seems that is is indeed the official site (as linked-to on http://www.openbsdfoundation.org/), just in case there are any doubts…for no reason whatsoever.
How can they know that they have not broken something in their flensing without any automated testing since no tests is one of the big problems with OpenSSL?
Believe it or not, there are other ways to spot problems besides automated testing, which wouldn't catch every problem anyway (that's why we need human audits like the one OpenBSD is doing).
Yes, software existed before TDD and ADHD.
That's not to say tests don't help. If you are interested, why don't you contribute?
Not really considering you have to buy certs if you want people to use your site, it doesn't have any sensitive data on it (not even source code or binaries), and they haven't finished cleaning it up to their standards yet.
StartCom/StartSSL [1] and, to my knowledge, Comodo [2] do offer free (and widely supported) SSL certs. Charges may apply to revoke certificates if a private key is leaked ($25 at StartSSL, IIRC).
As for why SSL should be used everywhere: It improves security and makes eavesdropping more expensive. For the first point, see the BEAST and CRIME attacks. On vulnerable systems, a single unencrypted connection may be used to reveal data from other, encrypted streams. As for the second: if only sensitive data is encrypted, all encrypted streams automatically become "interesting" to a potential eavesdropper. If, however, everything is encrypted, all streams become equal again. The cost of storing all communications becomes much higher, and the ratio of cost and reward of decrypting a single captured stream worsens (as you may either reveal sensitive or non-sensitive data).
If you have to pay for revocation, then it is not free certificate. It is just certificate with fees postponed. It is not the same thing. Not sure how you, but when I buy things I do not consider only initial price, but also additional fees.
If we want SSL used everywhere, browsers need accept self signed certificates in less obtuse way or there need to be other way to get really free ones.
It should rename to LibibreSSL instead, so that one can link the library with `-libressl`. Other than that, I appreciate this effort (no pun intended).
Why wouldn't they just make it available for linking as "ibressl" rather than naming the project that? LibibreSSL is unwieldy to put it mildly, and meaningless without the context of the original name.
I understand the point but this comes across as immature. OpenSSL has provided years of free software, supporting thousands of sites and applications.
Of course it has its problems, and there is nothing wrong with adding more competition in this space.
But what this space needs now, more than ever, is professionalism and pride in craft (by which I mean demonstrable unit test coverage, regression testing, fuzz testing and documentation) not silly music video jabs.
They've already done massive amounts of work already - adding missing checks, documenting a metric ton of magic numbers, removing VMS support, fixing year 2038 bugs, removing insecure cypher support, removing less secure replacements for secure OS inbuilts, unused code, and more, see http://opensslrampage.org.
On a side note, I was really hoping for the name to be OpenTLS (consistent with OpenBSD and OpenSSH, which are also OpenBSD maintained projects) or ValhallaTLS
Agreed. This is a bit scary. I feel the resources would be better off focusing on merging with the official OpenSSL project rather than forking and _then_ asking for funding, essentially taking any potential funding from the official OpenSSL project.
Count the number of vulnerabilities in OpenSSL over the last few years, relative to the size of its code base. A single vulnerability, albeit bad this year, results in a fork and the attitude of "it had its chance."
LibreSSL inherits all of the undiscovered vulnerabilities in its huge code base. I hope your harsh criticism carries over to its code base once these flaws are discovered here too. That's the beauty of open source.
The problem is that a security software brick is not satisfactory when it works, but when you can be sure there are no problems.
Given the very low quality of the code and the high amount of bloat, few people actually trust it. They have to trust third-parties and external certifications and the word on the street, and this is not enough for that kind of dependency.
Quite frankly unless LibreSSL manages to raise more than 2000$ a year (what the OpenSSL fundation makes, apparently) I fail to see how they hope to avoid encountering the same kind of problems OpenSSL did (and still does). And given that the OpenBSD projects had to beg for donations to reach a 150k$ goal, if memory serves, I doubt they'll be able to sink a tremendous amount of money into LibreSSL.
If you can't pay people to work on the project full time, properly test and audit the code, sooner or later something will go wrong. And then we'll see people over here commenting along the lines of "my god those people are incompetent/irresponsible, they hope to get a free pass because it's free and open source, etc..."
Also, until I see a first release of the lib it's just marketing as far as I'm concerned, after all the OpenBSD foundation announced OpenCVS in 2004...
Well sure, OpenSSH is probably one of the most useful and versatile tools out there, there's no denying that it's a huge achievement.
That being said it's a program with mostly well defined use cases while OpenSSL is a library used in thousands of programs (including OpenSSH) on a variety of hardware and operating systems. The OpenBSD project naturally mostly cares about OpenBSD first and the rest second, which might be a bad thing if we end up with a multitude of forks each supporting a particular OS/architecture, increasing the chances of messing things up. After all, the latest big OpenSSH vulnerability was due to debian-specific patches...
Also, for what it's worth, sloccount tells me the latest snapshot of OpenSSH has about 90 thousand lines of code while OpenSSL has more than 360 thousand. It's a huge, huge library, forking and maintaining it is a tremendous undertaking, even compared to OpenSSH.
I get your point, but let's face it, the OpenBSD developers have done more to fix OpenSSL in the last two weeks that the OpenSSL developers done the last two years.
Some of the bug fixes have been pull from OpenSSLs bugtracker, they've just sat there for one or two years. This should make you think about what motivates the OpenSSL developers, my guess would be new crypto algorithms and the math, rather than maintaining a modern and secure crypto library.
Honestly the better solution might be to have the OpenSSL developers commit new code to the OpenBSD fork. For my understanding no one doubts that the OpenSSL developer understand the math and crypto in SSL and TLS, but they aren't the sharpest C programmers. There's no point in ostracising the OpenSSL developers, but maybe they should just focus on the parts that they do really well and let others, like the OpenBSD developer, productize their work.
Which goes to show that you're not the intended end-consumer of this product and don't know their credentials. They are not newcomers to this space. If their tone is off-putting, maybe you should stop relying on OpenSSH too.
The tone and the footer encouraged me to actually donate even what little I have to this project.
The footer is a smack in the face to all those responsive bootstrap modern crap marketing websites - while this, table based layout, single page html provides more information and works in every device, with every resolution. Everything just included. As it should be.
This page probably took as much time to write as the sentences in the page - instead of fucking around with html initializr responsive themes, colors and oh god make it stop.
I still can't believe such a fundamental backbone of the web runs on $2000/year. This is a -worldwide- service, and it runs on peanuts. It's flabbergasting. Please donate today if you can.
No. It needs corporate involvement, from Google, Red Hat, Amazon, Verisign etc. Lend minds, not money. By all means fund people to write it, but like it's not you who should be contributing, it's the corporations who rely on it.
Google and Amazon should be donating to LibreSSL, too. They may have no intention of using it in the next few years, but I'm sure they'd like for a solid alternative to be out there, so they can use it just in case they do change their minds, just like Google recently did with the switch from NSS to OpenSSL, just before Heartbleed happened.
It would've been smart of them to donate to OpenSSL starting a few years back, so that by the time they decided to quit NSS, they would've been sure OpenSSL is pretty solid, and would've also discovered the Heartbleed bug much earlier. They could not repeat the same mistake twice by donating to LibreSSL right now.
>OpenSSL has provided years of free software, supporting thousands of sites and applications.
And has done it so poorly that it has been a security nightmare the whole time. Just because something is given away, doesn't mean the world is obligated to be thankful for it. Giving away crap doesn't make it not stink.
It's indeed a great effort. Lets just hope that it delivers what is promising and doesn't bring other sorts of vulnerabilities due to the new implementation/code.
Mine doesn't show up in comic sans. However, the link to OpenSSL is to We're Not Gonna Take It (http://www.youtube.com/watch?v=mRCGDUsdRDU)... This all seems like a joke to me.
While it is funny, I think using Comic Sans is actually more hipstery than ranting against it, which is too mainstream today (the same goes for blink tags).
Ah yes, the kind of professionalism I've come to expect from OpenBSD. They make decent software, but boy could they use some work in the PR department.
libressl.org is the most professional landing page a project could ever have, what more do you want blink tags hero unigs, marketing spots, slideshows??
Every sentence and paragraph on that page is meaningful, unlike _any_ modern web crap app/mvp where visitor has to click and mock about just to find what the hell the page/project is about. Here its in the first sentence and you cant miss it.
And they could make it look decent by replacing Comic Sans with Arial, Times or something similarly simple. You can't tell me they used Comic for any reason but to annoy people.
May be you missed to read the footer of the page.. the last line, Infact they are also trying to make the same point as you said (why not use Arial or Times and get rid of comic sans)
>You can have great software without insulting half the internet
You overestimate how many web hipsters there are. And annoying them is not "being an immature brat". It is precisely to discourage their involvement. Because the mentality behind the web fads are precisely why the entire world of software is layers upon layers of shit stacked on top of each other.
With a PhD in architecture, design and branding, there's something about the extreme simplicity of OpenBSD's web pages that I find really attractive. "Perfection is achieved, not when there's nothing left to add, but when there's nothing left to take away".
I am not sure if anyone noticed the footer of the page. It not the PR's fault or anything to blame PR. Its just a link for donation :).. they are trying to improve the standards of the web by wanting/helping to get rid of comic sans font
I'm curious what they mean by "free", they put it in bold caps. Since it's a fork of OpenSSL that probably implies that the OpenSSL license remains attached to the code at least until all of the relevant code has either been rewritten or removed.
I can't speak for them, but I think if you're not sold on git/mercurial then you have CVS and SVN as obvious choices. And those two aren't that different (pros/cons explained: http://www.pushok.com/software/svn-vscvs.html ... edit: that's a very old link)
How so? CVS do make branching and merging rather annoying, but I don't see how reviewing changes becomes difficult. It's a lot easier to track the changes to the entire OpenBSD source three, compared to the Linux kernel.
Git and Mercurial are extremely nice tools, but the flow of patches and branches quickly become rather hard to follow. CVS doesn't have most of the features that newer tools have, so there's stuff you simply can't do, but it is extremely easy to follow the code.
There's many problems that makes it very annoying to review their changes:
- CVS commits are per file. You can't see changes made by a single commit to multiple files.
- CVS cannot rename files. You have to create a new file and remove the old one. So you cannot follow history of the changes.
- CVS is really slow. You cannot clone the repository locally, so it takes a few seconds to show any change, whereas git shows you any commit and logs instantly. And you can't do it offline (for instance if you need to spend a few hours in a train).
- git log / show / diff is so much better than cvs log / diff.
- you can't use things like git blame
- they've lost all openssl.org history. If they were using git, they could have cloned the openssl git repository, and add their commits on top, keeping all history (which is often very useful when you're trying to understand why something has been done like this, or who introduced some change).
I'm not an openssl expert, so I didn't plan to review their changes anyway. But if I had to, using CVS would be the most annoying thing.
> I'm not an openssl expert, so I didn't plan to review their changes anyway
Bad excuse. Now if you said you don't know C at all, that'd be reasonable.
> But if I had to, using CVS would be the most annoying thing.
There's freshbsd, cgit on anoncvs, probably a git repo or two on github. You don't need to touch CVS to view the code and diffs. Blaming the VCS that much is a bunch of lazy excuses. Yes, CVS has its shortcomings. No it doesn't make code review difficult.
Lets assume somehow you as attacker got access to the box where their CVS process is running.
Now you can edit a file, insert a line or change a "uid != 0" to "uid = 0", you also edit the history of the CVS repistory to make it seem that this change was introduced with some patch 3 years ago by Theo. Because its CVS or SVN the history is in the server, and not on every developers computers. Next time the devs build the tar.gz for distribution your bug is in it.
This wont be allowed with Git or Mercurial, because if you try to rewrite the history, well good luck making a SHA-1 collision on source files. That stops it.
I imagine supporting non-POSIX operating systems, or not exactly conforming ones, to have its challenges, but is it really hard to make this stuff working in Linux and Open/NET/Free BSD from day one? It seems to me a better approach to start this way, without to mention that the potential developers base you get if you support Linux ASAP can be larger.
OpenSSH also deliberately trashed cross-platform compatability. This makes it amusing whenever someone flounces off to OpenBSD because they think systemd should have been written portably.
OpenBSD cares about their own first and foremost. OpenSSH has a similar porting team, and has since the beginning, and there have been no problems there.
"OpenBSD cares about their own first and foremost.".
This is their choice, but their impact in the security of IT is much smaller this way because most servers are running Linux. It is surely a great result to have an operating system like OpenBSD that can be proud of the security level reached and the small amount of vulnerabilities over the years, however if you analyze the computer security problem from a vendor-neutral standpoint, there is more at it than the availability of niche secure systems.
I'd disagree. As I wrote in the second half of my post, they do the same thing for OpenSSH, and I don't think anyone will say OpenSSH has had a minimal impact on IT security. One of the reasons they develop this way is that they can work with a known set of functions, etc, which may not be available on other platforms, and then have people who grok portability handle that part of the puzzle. Additionally, functions and libraries that are not used in the OpenBSD world, like PAM integration, can be maintained by people who understand all the security implications of those libraries.
I don't use OpenBSD for my own environments, but at the same time, I can understand why they code the way they do. Everyone ends up a biased toward their platform of choice in how they code, what functions they use, etc, it's just that the OpenBSD team is militantly upfront and open in their biases. Given their track record in creating secure software, and in auditing others' software, I'd argue their end result is appreciable, even if I'm not directly using those results.
I'm sure that portability is a major goal, but "from day one" isn't. Better to focus on correct, high quality, readable code first and then deal with a portable version. And OpenBSD C code tends more toward generic UNIX than some others, so shimming is less painful than it could be.
There really are a lot of parallels with OpenSSH's history. There were the "Oh, God! Theo forked SSH!", "It's just OpenBSD, who uses that?", and all the rest. Now everyone uses it, and it's a good thing. The wait time for it to be ready and available to all platforms was a small price to pay, well worth it, and quite small in retrospect.
> removed MacOS, Netware, OS/2, VMS and Windows build machinery
What are the plans for native Windows support? I don't know what they mean by "The right Portability team in place", but it'd be a joke if the lib would require CygWin or some other external portability scaffolding. And without proper Windows support LibreSSL will simply fragment OpenSSL user base. I guess it's still better than nothing, but it definitely won't be an OpenSSL "replacement."
Probably none. Windows has its own CSP library which is a little more convenient in a win32 context than OpenSSL or anything POSIX TBH. I think they're doing the right thing here.
There's a ton of Windows software that uses OpenSSL as their security library. Moreover, there is a lot of Windows projects that are written in inherently portable way and using OpenSSL API is the most natural choice for them.
If StartSSL manages to topple OpenSSL and to discourage any further OpenSSL development, then that'd be a very bad thing for a lot developers.
Well I disagree. Whilst it's a natural choice for portability, when you port to a proprietary platform such as windows you lose a lot of the support and portability guarantees that POSIX gives you and the calling conventions and standards of many libraries. At this point it's advisable to pick a holistic 3rd party abstraction over this such as something right from APR to Qt that will abstract the platform specific implementation away.
Some people write a lot of stuff plugged into Win32 without considering the CSPs and pull in OpenSSL without thought. Their funeral.
As my father said: "when in France, talk French or hire a translator".
This is all great, but the fact remains that OpenSSL is very widely used on Windows and yanking it out without providing a drop-in replacement option is a bad idea.
We can debate finer nuances of proper abstraction to the death, but it doesn't move a needle for people who already have OpenSSL dependencies in their code.
I don't expect them to support Windows, you misunderstand the whole concern.
The concern is that OpenBSD fellas are fragmenting the project and they are also asserting that OpenSSL team was doing things wrong for a long time. This is not a start of a beautiful friendship. Throw in a bit of crowd lynching (to the tune of "OpenBSD is showing OpenSSL how to do security right") and we can end up with OpenSSL devs showing a finger and throwing in a towel. At best, we'll have to related SSL implementations, devs of which don't really talk to each other. That's the issue.
People have been saying that OpenSSL has been of poor quality [1], that the documentation is bad [2], and the developers don't really listen [3] for years. Heartbleed was just the straw that broke the camel's back. OpenSSL really was one of those pieces of software that was Just Good Enough that people tolerated it, but at the same time, filled them with a desire to punch kittens whenever they had to code with it.
The devs can probably at least be mature enough to use each others code where it is compatible. More to the point, there's really only a couple of full time OpenSSL devs, and the others are more contributors, for whom I'd imagine switching to a better laid out, less buggy, less spaghetti-codey, more practical implementation would be an advantage.
> The concern is that OpenBSD fellas are fragmenting the project and they are also asserting that OpenSSL team was doing things wrong for a long time.
Fragmenting? Aren't they making a separate, alternative implementation?
Either way, the whole open source field is chock-full of "fragmentation", with countless precious little snowflakes rushing to fork and re-implement anything and everything under the sun to get it just the way they want it. I doubt whatever fragmentation might happen with OpenSSL is a cause for concern, especially when the OpenSSL codebase is objectively bad.
For right now, it does not matter. Their goal is to fix the project from a security point of view, and it would be impossible if they tied their hands with that during the course of development.
In the future, you can expect the same deal as OpenSSH, OpenNTPD and all the other OpenBSD software that _eventually_ gets ported to other architectures when it reaches a point of stability and safety that it makes sense to do so.
If you follow that through the series of links, you find that it is just an assumption based on one guy who didn't know the project existed thinking unchanged = unmaintained.
Are you sure? There hasn't been a release for 8 years.
I followed the links a while ago after hitting an intialization failure bug that leaves Linux boxes with the incorrect date. I found that neither Arch Linux or Redhat consider OpenNTPD to be supported on Linux.
It would be good if you could explain what I am missing. If there are more recent Linux releases and the information on the Redhat bug tracker is incorrect I would like to know. I'd rather be running OpenNTPD than ntpd.
No one is yanking OpenSSL, this is a fork. OpenSSL is still available and developed and windows apps can continue using it.
If windows (and any other non-OpenBSD OS to be honest) people just HAVE to have LibreSSL instead of OpenSSL on their OS then the donation link is at the bottom of the page.
Windows is just a little too different for them to make a proper purge of the project right now. Having Windows support is just a much larger cross-cutting concern than a Unix-like OS, which appears to be the only category of operating system they're currently supporting.
Windows will probably get a port some time later on. Remember that OpenSSH's libssh also has Windows support. It's just not something that fits in their current short term goals of fixing up OpenSSL (I like the term flensing they're using).
> There's a ton of Windows software that uses OpenSSL
And those projects can upgrade to the heartbleed-patched version of OpenSSL and keep going. If LibreSSL eventually makes it to Windows, they can switch.
Ehh, I maintain a few libs that rely on the OpenSSL Windows ports. I'm not too keen on writing a compatibility layer that says "if windows, use the MS version, else use libreSSL!"
I'm fine with them not supporting MSVC in the build, but is it really that much harder to support something like MinGW/MSYS? No need for Cygwin.
The whole point of OpenSSL was that it runs everywhere. If we're going to write a shiny new version, let's at least try to hit the major platforms.
I imagine that's what the supported option is going to be. Given that the OpenSSH documentation explicitly lists Cygwin as the way to run it for windows, similar will probably happen for LibreSSL. The OpenBSD team has always had another team handle porting of their libraries, and they do a pretty good job of it.
Its not a replacement for OpenSSL, OpenSSL will continue to exists as it is, but in a while when libressl is stable enough you can choose on or the other.
maybe it's better to switch to NSS, the original SSL library developed by Netscape (now by Mozilla, Google, etc.), that is available under better open source licenses, is used in Firefox, (Chrome), OpenOffice, etc. and has an optional compatible API to OpenSSL: http://en.wikipedia.org/wiki/Network_Security_Services
From the Pros & Cons table, it doesn't seem that NSS is obviously superior to OpenSSL. Both seem to suffer from focus on extra features instead of maintenance and reliability.
The reasoning there is, certainly post-Heartbleed, very scary. Their conclusion boils down to that they want to use the system-provided OpenSSL on Android, rather than shipping NSS.
This might be fine if you're running a Nexus device that still gets updates to the latest Android (Nexus 4 and later?). But for everyone else, that's effectively forcing people to get a new Android phone if they don't want to get stuck with a horribly insecure phone.
In the doc, Google says NSS would need to be added to the base Android image.. so it's not going to be updated any faster than openSSL.
When powering WebView, Chromium on Android uses the Android system-provided OpenSSL library - something not available to applications building with the Android NDK (like Chrome for Android or other Chromium-based Android applications). This helps reduce memory usage by having a single shared library in memory. To accomplish this with NSS, NSS would have to be part of the Android base image - which would still increase memory usage, as most other Android (native) services would still use OpenSSL.
It says "On Android, Chromium uses OpenSSL." in the background section. The question is whether they want to switch other platforms to OpenSSL (or Android to NSS, or keep using both).
"Both seem to suffer from focus on extra features instead of maintenance and reliability."
Unfortunately in the SSL/TLS world, true security is a product of both, as minor flaws in the actual protocol itself are a common enough discovery to make the introduction of new "features" often quite key to the security of the implementation.
I don't see why this product would have a different porting strategy to the usual way OpenBSD projects (such as OpenSSH) handle it - target OpenBSD exclusively in the core project, and support other platforms with ports. Presumably that's what they are going to do here.
FWIW the usual OpenBSD story is "get it working, reliable and simple, on (Open)BSD, then add porting shims" (they'll have to add shims for linux anyway if they start using strlcpy)
While most of us just talk, this guys actually did something of great importance. Hell yeah they have all the rights to step on some toes and make fun as they see fit.
I'd always salute doing stuff vs being politically correct.
One annoying thing about OpenSSL is its license. I hope The Better Replacement™ fixes that as well (especially if its name gets to contain the string "Libre"), and it is not going to happen by forking OpenSSL.
This is the problem with any sort of viral license in Free/Open/Libre software. Different people have different notions as to the best way of distributing it. An advertising clause is pretty minor compared to the rights you have to give away to use certain other "Libre" software.
They are already placing completely rewritten files under ‘better’ licenses, so the license switch might happen file-by-file over a long period of time.
Is that strategy possible at all? Are there cases tested in courts (both US and EU) that assert that the file-by-file licence replacement really works?
Why wouldn't it? The author of the file will be the copyright holder by the virtue of authoring it. If she does not get rid of it, she still remains the copyright holder. Copyright does not switch owners purely by the virtue of distribution with another piece of work.
The copyright holders can later on relicense the work under something else. Licensing a work under some non-exclusive license does not restrict you from licensing it again in the future under other terms.
I was going to ASK HN, when are we going to see a replacement for OpenSSL; you know, the company that has much more field experience, or even understanding of how SSL operates.
I then thought to myself, that'd be going too far..and nobody is really going to try and make an alternative.
Before you guys get too high and mighty. Refactoring openSSL is pretty fucking trivial. Fixing these bugs is also massively fucking trivial.
Whats not trivial is that we as a community are using bug-ridden zero day software all the time, and we dont know because our profession is essentially a joke.
Before you write the next clever comment think about that.
You and by extension, I and by extension WE, are a total fucking joke.
261 comments
[ 1.1 ms ] story [ 146 ms ] threadhttp://openbsd.com/lyrics.html
Edit: To those downvoting, yes, I saw the footer. This doesn't excuse their childish behavior. I will not be donating to this project if this is the level of seriousness they have for it.
A) In the smallprint: "This page scientifically designed to annoy web hipsters." (Mission accomplished)
B) Make it obvious that this is a temporary site (In case the disclaimer wasn't enough)
And if you really want to see the lengths they went to to annoy web people, look at the source
> This page scientifically designed to annoy web hipsters. Donate now to stop the Comic Sans and Blink Tags
And if that's supposed to promote donations... (?!)
Ask yourself if a founder dresses as a clown to get funding.
If these people are prepared to take this on, then they can use whatever fonts they bloody well like. As a web hipster, I will pay them for punishing my hubris.
Having said that, I can't seem to find a browser in which the blink tags actually, er, blink. Did all the vendors shitcan it on the quiet? I think we should be told.
[1] https://www.mozilla.org/en-US/firefox/23.0/releasenotes/
[2] http://www.jwz.org/blog/2013/08/a-light-has-gone-out-on-the-...
(Wonder if marquee still works. EDIT: yes, it does. Thank the lord for that.)
Oh, and while we're at it, the OpenSSL page [0] isn't much better visually speaking. Would you donate to them to make OpenSSL better ?
[0] https://www.openssl.org/
It's not all just window dressing; a pleasant, professional website will help to attract more attention and resources.
How can they know that they have not broken something in their flensing without any automated testing since no tests is one of the big problems with OpenSSL?
Sort-of-integration testing. Gotchya
Yes, software existed before TDD and ADHD.
That's not to say tests don't help. If you are interested, why don't you contribute?
As for why SSL should be used everywhere: It improves security and makes eavesdropping more expensive. For the first point, see the BEAST and CRIME attacks. On vulnerable systems, a single unencrypted connection may be used to reveal data from other, encrypted streams. As for the second: if only sensitive data is encrypted, all encrypted streams automatically become "interesting" to a potential eavesdropper. If, however, everything is encrypted, all streams become equal again. The cost of storing all communications becomes much higher, and the ratio of cost and reward of decrypting a single captured stream worsens (as you may either reveal sensitive or non-sensitive data).
[1] https://www.startssl.com/
[2] http://www.instantssl.com/ssl-certificate-products/free-ssl-...
If we want SSL used everywhere, browsers need accept self signed certificates in less obtuse way or there need to be other way to get really free ones.
The real see site doesn't have those things, but a MITM'd unsecured version might.
Of course it has its problems, and there is nothing wrong with adding more competition in this space.
But what this space needs now, more than ever, is professionalism and pride in craft (by which I mean demonstrable unit test coverage, regression testing, fuzz testing and documentation) not silly music video jabs.
On a side note, I was really hoping for the name to be OpenTLS (consistent with OpenBSD and OpenSSH, which are also OpenBSD maintained projects) or ValhallaTLS
This is the beauty of open source, nothing more. We can take this and make it better.
LibreSSL inherits all of the undiscovered vulnerabilities in its huge code base. I hope your harsh criticism carries over to its code base once these flaws are discovered here too. That's the beauty of open source.
The problem is that a security software brick is not satisfactory when it works, but when you can be sure there are no problems.
Given the very low quality of the code and the high amount of bloat, few people actually trust it. They have to trust third-parties and external certifications and the word on the street, and this is not enough for that kind of dependency.
You might want to take your own advice. There have been tons of vulnerabilities in openssl, not one.
>LibreSSL inherits all of the undiscovered vulnerabilities in its huge code base.
That would be why it is being gutted and audited. That's the whole point.
If you can't pay people to work on the project full time, properly test and audit the code, sooner or later something will go wrong. And then we'll see people over here commenting along the lines of "my god those people are incompetent/irresponsible, they hope to get a free pass because it's free and open source, etc..."
Also, until I see a first release of the lib it's just marketing as far as I'm concerned, after all the OpenBSD foundation announced OpenCVS in 2004...
That being said it's a program with mostly well defined use cases while OpenSSL is a library used in thousands of programs (including OpenSSH) on a variety of hardware and operating systems. The OpenBSD project naturally mostly cares about OpenBSD first and the rest second, which might be a bad thing if we end up with a multitude of forks each supporting a particular OS/architecture, increasing the chances of messing things up. After all, the latest big OpenSSH vulnerability was due to debian-specific patches...
Also, for what it's worth, sloccount tells me the latest snapshot of OpenSSH has about 90 thousand lines of code while OpenSSL has more than 360 thousand. It's a huge, huge library, forking and maintaining it is a tremendous undertaking, even compared to OpenSSH.
Well, true, but I don't think that anyone know how badly they needed the money and the $150.000 was collected in three month.
OpenSSH have been around for a long time, without much funding really. OpenCVS was a bit of a dud though.
Some of the bug fixes have been pull from OpenSSLs bugtracker, they've just sat there for one or two years. This should make you think about what motivates the OpenSSL developers, my guess would be new crypto algorithms and the math, rather than maintaining a modern and secure crypto library.
Honestly the better solution might be to have the OpenSSL developers commit new code to the OpenBSD fork. For my understanding no one doubts that the OpenSSL developer understand the math and crypto in SSL and TLS, but they aren't the sharpest C programmers. There's no point in ostracising the OpenSSL developers, but maybe they should just focus on the parts that they do really well and let others, like the OpenBSD developer, productize their work.
Which is exactly what the entire "community" has been doing for the past few weeks.
Disappointing.
> one doubts that the OpenSSL developer understand the math and crypto in SSL and TLS, but they aren't the sharpest C programmers
I think you're selling them way too short!
The footer is a smack in the face to all those responsive bootstrap modern crap marketing websites - while this, table based layout, single page html provides more information and works in every device, with every resolution. Everything just included. As it should be.
This page probably took as much time to write as the sentences in the page - instead of fucking around with html initializr responsive themes, colors and oh god make it stop.
https://www.openssl.org/support/donations.html
It would've been smart of them to donate to OpenSSL starting a few years back, so that by the time they decided to quit NSS, they would've been sure OpenSSL is pretty solid, and would've also discovered the Heartbleed bug much earlier. They could not repeat the same mistake twice by donating to LibreSSL right now.
And has done it so poorly that it has been a security nightmare the whole time. Just because something is given away, doesn't mean the world is obligated to be thankful for it. Giving away crap doesn't make it not stink.
This page scientifically designed to annoy web hipsters. Donate now to stop the Comic Sans and Blink Tags
https://github.com/caskroom/homebrew-fonts
Every sentence and paragraph on that page is meaningful, unlike _any_ modern web crap app/mvp where visitor has to click and mock about just to find what the hell the page/project is about. Here its in the first sentence and you cant miss it.
You overestimate how many web hipsters there are. And annoying them is not "being an immature brat". It is precisely to discourage their involvement. Because the mentality behind the web fads are precisely why the entire world of software is layers upon layers of shit stacked on top of each other.
The fact that are are true and opinionated and no bullshit. Real character is hard to find these days.
Very old indeed.
Git and Mercurial are extremely nice tools, but the flow of patches and branches quickly become rather hard to follow. CVS doesn't have most of the features that newer tools have, so there's stuff you simply can't do, but it is extremely easy to follow the code.
- CVS commits are per file. You can't see changes made by a single commit to multiple files.
- CVS cannot rename files. You have to create a new file and remove the old one. So you cannot follow history of the changes.
- CVS is really slow. You cannot clone the repository locally, so it takes a few seconds to show any change, whereas git shows you any commit and logs instantly. And you can't do it offline (for instance if you need to spend a few hours in a train).
- git log / show / diff is so much better than cvs log / diff.
- you can't use things like git blame
- they've lost all openssl.org history. If they were using git, they could have cloned the openssl git repository, and add their commits on top, keeping all history (which is often very useful when you're trying to understand why something has been done like this, or who introduced some change).
I'm not an openssl expert, so I didn't plan to review their changes anyway. But if I had to, using CVS would be the most annoying thing.
Bad excuse. Now if you said you don't know C at all, that'd be reasonable.
> But if I had to, using CVS would be the most annoying thing.
There's freshbsd, cgit on anoncvs, probably a git repo or two on github. You don't need to touch CVS to view the code and diffs. Blaming the VCS that much is a bunch of lazy excuses. Yes, CVS has its shortcomings. No it doesn't make code review difficult.
I'm not blaming CVS as an excuse, because as I said, I didn't plan to review it anyway.
> No it doesn't make code review difficult.
It does make code review difficult, for all the reasons I gave. And I've seen several people who try review it complain about that too.
It is possible with CVS and even SVN to insert bad code on their repository server - but with git thats a much harder if not impossible to do.
Now you can edit a file, insert a line or change a "uid != 0" to "uid = 0", you also edit the history of the CVS repistory to make it seem that this change was introduced with some patch 3 years ago by Theo. Because its CVS or SVN the history is in the server, and not on every developers computers. Next time the devs build the tar.gz for distribution your bug is in it.
This wont be allowed with Git or Mercurial, because if you try to rewrite the history, well good luck making a SHA-1 collision on source files. That stops it.
This is their choice, but their impact in the security of IT is much smaller this way because most servers are running Linux. It is surely a great result to have an operating system like OpenBSD that can be proud of the security level reached and the small amount of vulnerabilities over the years, however if you analyze the computer security problem from a vendor-neutral standpoint, there is more at it than the availability of niche secure systems.
I don't use OpenBSD for my own environments, but at the same time, I can understand why they code the way they do. Everyone ends up a biased toward their platform of choice in how they code, what functions they use, etc, it's just that the OpenBSD team is militantly upfront and open in their biases. Given their track record in creating secure software, and in auditing others' software, I'd argue their end result is appreciable, even if I'm not directly using those results.
There really are a lot of parallels with OpenSSH's history. There were the "Oh, God! Theo forked SSH!", "It's just OpenBSD, who uses that?", and all the rest. Now everyone uses it, and it's a good thing. The wait time for it to be ready and available to all platforms was a small price to pay, well worth it, and quite small in retrospect.
What are the plans for native Windows support? I don't know what they mean by "The right Portability team in place", but it'd be a joke if the lib would require CygWin or some other external portability scaffolding. And without proper Windows support LibreSSL will simply fragment OpenSSL user base. I guess it's still better than nothing, but it definitely won't be an OpenSSL "replacement."
If StartSSL manages to topple OpenSSL and to discourage any further OpenSSL development, then that'd be a very bad thing for a lot developers.
Some people write a lot of stuff plugged into Win32 without considering the CSPs and pull in OpenSSL without thought. Their funeral.
As my father said: "when in France, talk French or hire a translator".
We can debate finer nuances of proper abstraction to the death, but it doesn't move a needle for people who already have OpenSSL dependencies in their code.
The LibreSSL guys are not yanking anything out of Windows, they're just providing an alternative to OpenSSL, for all the world to use, for free.
They're not under any obligation to support Windows, no matter how bad you want them to.
The concern is that OpenBSD fellas are fragmenting the project and they are also asserting that OpenSSL team was doing things wrong for a long time. This is not a start of a beautiful friendship. Throw in a bit of crowd lynching (to the tune of "OpenBSD is showing OpenSSL how to do security right") and we can end up with OpenSSL devs showing a finger and throwing in a towel. At best, we'll have to related SSL implementations, devs of which don't really talk to each other. That's the issue.
[1] https://www.peereboom.us/assl/assl/html/openssl.html [2] http://www.ibm.com/developerworks/opensource/library/l-opens... [3] http://lists.randombit.net/pipermail/cryptography/2012-Octob...
Fragmenting? Aren't they making a separate, alternative implementation?
Either way, the whole open source field is chock-full of "fragmentation", with countless precious little snowflakes rushing to fork and re-implement anything and everything under the sun to get it just the way they want it. I doubt whatever fragmentation might happen with OpenSSL is a cause for concern, especially when the OpenSSL codebase is objectively bad.
In the future, you can expect the same deal as OpenSSH, OpenNTPD and all the other OpenBSD software that _eventually_ gets ported to other architectures when it reaches a point of stability and safety that it makes sense to do so.
I'm sure LibreSSL won't have that problem but I thought it worthwhile pointing out that support for other OSes is not guaranteed.
If you follow that through the series of links, you find that it is just an assumption based on one guy who didn't know the project existed thinking unchanged = unmaintained.
I followed the links a while ago after hitting an intialization failure bug that leaves Linux boxes with the incorrect date. I found that neither Arch Linux or Redhat consider OpenNTPD to be supported on Linux.
Edit: a better link https://bugzilla.redhat.com/show_bug.cgi?id=430143
If windows (and any other non-OpenBSD OS to be honest) people just HAVE to have LibreSSL instead of OpenSSL on their OS then the donation link is at the bottom of the page.
Windows will probably get a port some time later on. Remember that OpenSSH's libssh also has Windows support. It's just not something that fits in their current short term goals of fixing up OpenSSL (I like the term flensing they're using).
Indeed!
Can you elaborate on that? I thought StartSSL was a certification authority.
And those projects can upgrade to the heartbleed-patched version of OpenSSL and keep going. If LibreSSL eventually makes it to Windows, they can switch.
OpenBSD can't do everything at once.
Yes, and most of it is awful because they shouldn't. I hate manually configuring SSL certificates for OpenSSL-using Windows software.
Write a socket transport portability layer. It's not that hard, and you almost certainly need one anyway.
I'm fine with them not supporting MSVC in the build, but is it really that much harder to support something like MinGW/MSYS? No need for Cygwin.
The whole point of OpenSSL was that it runs everywhere. If we're going to write a shiny new version, let's at least try to hit the major platforms.
Given how knarly build systems can be, then only supporting modern versions of the same could help remove a lot of cruft.
Its just a fork.
From the Pros & Cons table, it doesn't seem that NSS is obviously superior to OpenSSL. Both seem to suffer from focus on extra features instead of maintenance and reliability.
This might be fine if you're running a Nexus device that still gets updates to the latest Android (Nexus 4 and later?). But for everyone else, that's effectively forcing people to get a new Android phone if they don't want to get stuck with a horribly insecure phone.
Oh, I see the point already...
When powering WebView, Chromium on Android uses the Android system-provided OpenSSL library - something not available to applications building with the Android NDK (like Chrome for Android or other Chromium-based Android applications). This helps reduce memory usage by having a single shared library in memory. To accomplish this with NSS, NSS would have to be part of the Android base image - which would still increase memory usage, as most other Android (native) services would still use OpenSSL.
Unfortunately in the SSL/TLS world, true security is a product of both, as minor flaws in the actual protocol itself are a common enough discovery to make the introduction of new "features" often quite key to the security of the implementation.
They should use the operating system-shipped APIs, along with the OS-shipped certificate stores.
That means SChannel and CryptoAPIs in native code.
I'd always salute doing stuff vs being politically correct.
IANAL.
I then thought to myself, that'd be going too far..and nobody is really going to try and make an alternative.
Oh boy..
Whats not trivial is that we as a community are using bug-ridden zero day software all the time, and we dont know because our profession is essentially a joke.
Before you write the next clever comment think about that. You and by extension, I and by extension WE, are a total fucking joke.