While I really enjoy Theo's talks and writings, I wonder if the fact that the VCS is CVS ain't a security issue in itself?
It's been really a long time I haven't used CVS but I remember that attempt to introduce backdoors in projects using Git as a (D)VCS have been caught (it was in the Linux kernel I think). IIRC some attempts were caught precisely because it's hard to fake SHA hashes and so people can't really "mess" with the history of a DVCS like Git: too many people noticed a critical file having no business being modified being, well... Modified.
Once again, it was quite a while ago but I'm pretty certain that both the fact that Git was decentralized and that Git was using cryptographically secure hashes was touted as a "Good Thing" [TM] that helped catch the backdooring attempts.
Ain't using CVS potentially an issue here?
Git and CVS are both just tools. They each provide a server implementation, but it's uncommon to use either of these for write access in large projects. It's more common to wrap CVS or Git with a different frontend like HTTPS or SSH. My guess is that the OpenBSD guys use OpenSSH.
This team is fanatical about security and process. I am completely comfortable with them using whichever tools they want.
In other words, with fewer than
2 * * 80
trials, an attacker can generate two files that have the same SHA-1 hash. (In the case of C source files, this probably means embedding a nonsense comment in the middle of each file, probably several hundred to several thousand ASCII characters.) If an attacker can get the very carefully constructed benign file past code review and have the ability to modify the repository, they can substitute the very carefully crafted malicious file for the very carefully crafted benign file without changing the root of the Merkle tree.
Assuming that SHA-1 is still second-preimage resistant, it will take an attacker about
2 * * 159
attempts to come up with a file that has the same hash as a legitimate file not carefully constructed by the attacker.
So, the weaknesses in SHA-1 probably mean that exploiting those weaknesses in the context of git still requires a mole in the development team. Though, I wouldn't want to bet my life on nobody noticing a big nonsense comment in the middle of a C file or someone figuring out how to construct a reasonably reviewable C file as the carefully crafted benign file.
In any case, the weaknesses in SHA-1 still likely pose a significant difficulty in forging a git history without planting a mole in the dev team. It's much better than no cryptographic barriers to forgery.
Probably more importantly though, Git encourages everyone to have the full repository lying around. Even if you inserted a vulnerability in a master, there would still be thousands of copies of code which could be independently compared to find the exact changes which were made.
My reply was not intended as an attack on Git. I use it daily and would choose it 10 times out of 10 vs. CVS for a new project. I just think the assertion that Git 'saved' Linux from some backdooring attempts because it's decentralized and uses cryptographic hashes is wrong; it's not the tools that make this happen, it's the processes around the use of these tools which do that.
I don't know any OpenBSD developers nor do I have any inside knowledge of how their team works, but I know from observation that they are a small team with high standards for code style and quality. They don't just let anyone commit code and appear to be thorough with code review. When procedural/practice problems are identified in the industry, they are proactive about mitigating or fixing those. They have a demonstrated track record of good releases. Basically, I don't see any reason to question their use of CVS.
I found the story back and things are, IMHO, actually quite interesting... If only because the attempt was made after someone ill-intentioned gained access to Linux's CVS repository.
Back then Linux was still using BitKeeper (decentralized) for Linus hadn't created Git yet (so I was not remembering things correctly here). But apparently some people didn't like BitKeeper so there was a CVS clone of the BitKeeper version. And it's in the CVS repo that the attempt took place (after someone hacked his way into the server hosting the CVS repo).
Here's the story:
Now even though Linus didn't choose SHA-1 for its cryptographic properties and even if SHA-1 is not SHA-256 nor SHA-3, it still looks like an attacker gaining access to a CVS repo would have a much easier time inserting a backdoor than an attacker gaining access to DVCS using cryptographic hashes (which user KMag here explained nicely).
Why not ?
With CVS, the security rely on the security of a single server. Anybody with root access to the CVS server can modify history, and nobody would notice.
That a vast oversimplification. There are still no publicly-known preimage or second-preimage attacks against SHA-1. Even the collision attack in 2005 was limited insofar that it reduced the search from a brute-force 2^80 to 2^69.
Perhaps you're referring to a length extension attack, but I admit I don't know much about those in the context of Git's use of SHA-1.
Anyone care to chime in/experiment with ways to embed nulls in C files such that either GCC or Clang will continue compiling code after hitting a null byte in the middle of a file? (I'm not talking about an escaped null in a character or string literal, but actually a 00 showing up in hexdump -C of the source.)
EDIT: I think it's safe to assume people will notice someone trying to sneak a 64-petabyte C source file into the codebase. With apologies to Sweet Brown, aint nobody got time for [downloading] that.
Forgive me for saying so and I doubt you intend it so, but statements like this is what gets us into trouble. At a certain point we need to trust the people that build the foundation for us, but only once we've done our due diligence. Most people, maybe not you since you seem to know more about the team, have not yet.
- CVS is simple - it's small (fits on a floppy with bsd.rd) and easy to use on exotic/slow architectures
- CVS is preferable for their current contribution workflow (centralized)
- CVS is treated as a tool that, currently, just works (tm)
OpenBSD's system level support for exotic platforms has more to do with drivers, compiler & tool chain support, boot code, etcetra. These do not create a jungle of ifdefs and workarounds in userspace applications. And if these platforms are broken, they are fixed instead of worked around with more jungle and weed. So support for these things does not add bugs for others.
On the contrary -- getting your software to run on a SPARC64 is more likely to expose flaws in your code.
No, why would it? If you don't trust the openbsd developers, the don't use their code.
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
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.
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.
> 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!
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...
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.
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.
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.
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."
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.
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.
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).
Can you elaborate on that? I thought StartSSL was a certification authority.
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.
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.
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
Portable OpenNTPD 3.9p1 released May 14, 2006.
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.
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.
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.
Its just a fork.
Given how knarly build systems can be, then only supporting modern versions of the same could help remove a lot of cruft.
They should use the operating system-shipped APIs, along with the OS-shipped certificate stores.
That means SChannel and CryptoAPIs in native code.
This page scientifically designed to annoy web hipsters. Donate now to stop the Comic Sans and Blink Tags
brew tap caskroom/fonts
brew cask install font-comic-neue
Andreas-MacBook-Air:Source ajf$ brew tap caskroom/fonts && brew cask install font-comic-neue
Cloning into '/usr/local/Library/Taps/caskroom-fonts'...
remote: Reusing existing pack: 3465, done.
remote: Total 3465 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3465/3465), 496.33 KiB | 280.00 KiB/s, done.
Resolving deltas: 100% (1974/1974), done.
Checking connectivity... done.
Tapped 0 formula
Error: Unknown command: cask
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.
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.
The fact that are are true and opinionated and no bullshit. Real character is hard to find these days.
I'd always salute doing stuff vs being politically correct.
The real see site doesn't have those things, but a MITM'd unsecured version might.
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 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.
That's the way seL4 was written.
> Let's say we want to build the TCP/IP stack of an operating system. A traditional implementation might take 10,000 lines of code. What if you rethought the design from the ground up? What if you could make the IP packet handling code look almost identical to the RFC 791 diagram which defines IP?
If the industry as whole could agree on this approach in a move similar to the Dijkstra/structured programming move that happened a few decades back, the sort of verifiable interoperability + security that Meredith Patterson and Sergey Bratus (who you may recognize from Occupy Babel!) call for would be closer to reach.
1. Jeff Moser. Towards Moore's Law Software: Part 3 of 3. https://www.youtube.com/watch?v=UzjfeFJJseU
2. Occupy Babel!. http://www.cs.dartmouth.edu/~sergey/langsec/occupy/
3. Meredith Patterson. LANGSEC 2011–2016. https://www.youtube.com/watch?v=UzjfeFJJseU
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.
Very old indeed.
OK, do the codecs in C if it's the only way to meet performance requirements. But the rest must be written in a language that's reasonably analyzable statically, and with adequate abstractions. Seriously, have you looked at the filthy mess of leaky abstractions that OpenSSL's BIO system is? How many bugs could be found and/or planted by a 3-letters agency in that crap? Is there anyone who's comfortable with its #ifdef labyrinths?
Finally, I don't think you can retrofit clarity in OpenSSL any better than you could, say, retrofit virus-resilience in a Microsoft OS that hasn't been originally designed for hostile network environments. I used to believe OpenSSL was made messy in order to sell consulting hours, since Snowden I have a more paranoid hypothesis.
Whatever it is, it'll need to be very portable (well beyond just Linux, OS X and Windows), and it'll presumably need a free implementation on each of those platforms, and it'll need to be quite fast, and it'll need to support native compilation, and it'll need to support interoperability with existing code, and it'll need to be "safer" in some way.
At this time, there are very, very few languages that meet every one of those criteria sufficiently. We're looking at C, or C++. Maybe Ada. But that's about it. Rust doesn't cut it yet, and probably won't for some time. Other candidates are lacking severely in one or more of those important areas.
C++ using modern techniques appears to be the only feasible alternative to C today.
There are several alternatives to OpenSSL available and/or popping up right now. They might or might not be a better choice for new developments. But refactoring OpenSSL (where a lot of currently used software depends upon) is certainly not a dumb decision.
So it's not "dumb", but I expect the net result to be negative. At least a clean reimplementation featuring XXI-th century technologies would have a non-zero chance to produce something great.
There are no guarantees of anything working out or being great, regardless of technology. And whatever language/tech you use would require a couple of layers of control. For example, ensuring the low-level features of the language don't betray entropy to statistical analysis, or managing (and ensuring) the virtual memory used is cleaned up properly, or being as efficient as possible lest the crypto become a performance barrier to use.
It's not like high level languages can't implement crypto as well as lower level ones; they can. But it's a lot easier to ensure the various attack vectors are mitigated in a low-level language where there's no glue [outside of that included in your source] to get in the way, obscure, or otherwise subvert the security and performance of the applications using your code. The Heartbleed bug happened because the glue they chose to use was crappy; this was an implementation problem, not a low-level-language problem.
What I am seeing is that we have a ridiculously upside-down trust
model -- "Trust the developers".
We never asked for people to trust us. We might have "earned some" in
some people's eyes, but if so it has always been false, even before
this. People should trust what they test, but the world has become
We build this stuff by trusting each other as friends, and that is
done on an international level. If anything, the layers and volume of
trust involved in software development should decrease trust. Oh
right, let's hear some of that "many eyes" crap again. [..] All the
many eyes are apparently attached to a lot of hands that type lots of
words about many eyes, and never actually audit code.
If anything, the collaborative model we use should _decrease_ trust,
You can't blame the developers for everything, they have work on their hands and you are not entitled to anything more from them. You also can't trust developers. If there's sloppy code, someone has to notice it and point it out. Someone has to fix it. If there are sloppy development practices and it is evident that the upstream developers do not care, someone has to notice that and let the world know. Then maybe create a fork and try to do better.
So anyone capable of reviewing code and diffs: please try to do it if you haven't before. Try to do more if you're already doing it. And remeber, you do not have to be an expert programmer to notice a duplicated goto fail line.
Or if you can write tests, why don't you contribute?
In any case forking OpenSSL seems like a knee jerk reaction?
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?
After heartbleed everybody blamed OpenSSL's bloated code base and it became apparent that many contributions came from volunteers with very few financing.
By forking the project, LibreSSL will keep the problematic code legacy and split the community. Maybe I am missing something, but it looks like opportunism here...
And this is exactly what they are fixing.
OpenSSL's response was to fix heartbleed and move on, not fixing the more broad problem of to much code cruft that led to the bug. IMHO they are right to fork it, OpenSSL's lack of reaction to this is a raise for concern. I am sure Theo( de Raadt) and its team can tackle this, making the code base much much leaner, reducing the risks of bugs similar to heartbleed. And there is really no excuse for OpenSSL to deny that.
Also i think OpenSSL has to much technical debt to be efficient in tackling a cleanup like this.
It's funny that they do this "donate to stop blinking" thing again. They have been doing it for OpenSSH since 2000. cf. http://www.openssh.com/
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.
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.
I also suspect that part of the reason is because OpenBSD just doesn't work well with others.
"Suggesting to call the fork LibreSSL or LibreTLS just to offend everyone. trololo"
And it was so.
Attitude and font choice aside, I can't help somewhat feel that one could explore better ways to funnel interest, commitment and donations to a project such as this; especially since it sparked as a result of heartbleed.
Seems silly to turn away help.
I then thought to myself, that'd be going too far..and nobody is really going to try and make an alternative.
And the whole thread ... and problem doesn't exist.
Same thing was brought up in this HN thread: https://news.ycombinator.com/item?id=7604364
@MiodVallat @cwlcks Well then I withdraw my earlier comments. What happens in BSD when the system RNG lacks entropy? Does it block?
its just a bunch of html very simple 1990s tags and it still looks and works much better than any html5 css3 bootstrap fanboy page Ive ever seen.
The site is ugly and I'm sure they would agree. That clearly is not the focus of their work.
They know. I find simple HTML like http://cr.yp.to/ to be refreshing sometimes, albeit not "pretty." But with the font and blink tag (powered by CSS), they've gone out of their way to make it a bit ugly. At least they drew a line and don't have headache-inducing colors or animations.
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
Oh, and while we're at it, the OpenSSL page  isn't much better visually speaking. Would you donate to them to make OpenSSL better ?
It's not all just window dressing; a pleasant, professional website will help to attract more attention and resources.
> 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.
(Wonder if marquee still works. EDIT: yes, it does. Thank the lord for that.)