I tend not to click on links advertising pages that are hacked. You know, not that many zero days on Chrome, but still seems like a risky click, as they say.
Yet another example of why to both sign release artifacts AND verify them is important.<p>Also, if you're running the public website for a security lib or core FOSS package, expect more attacks by kiddies trying to build rep... so very conservative tech choices (mostly static website served from a read-only fs) and defensive practices are de rigueur.
I said this in a lower thread but I figured it's better up here.<p>Why is there not a standard for links of this type in browsers. Eg <a href="url" sigurl="url to sig" sigalgo="algo to calculate signature">OpenSSL</a><p>That's a simple way to go but I really think it's as generally insecure as reading a signature form a url that is advertised by a website. It's also why I rarely bother.<p>But if browsers were good about this then it could be done in a much better way which is to sign the application with a real peer verifiable signing method. Such as the SSL cert that covers the site behind the open source project .<p>now this only works for projects that have SSL certs. Another method would be to have a clearing house that can do 1-1 with github et al and a re cert, like a oss cert organization. A final good way would be to use the beauty of git and use the source checksums and a repeatable build process (which is fricking hard) and come up with a way to give a signature for oss applications based on a git commit and check that back to the public git repository.<p>really I think knwon public keys for oss projects and branches would be the real answer. And the security gating for newbs would be like windows and linux which check the public signature of the application before they run them from the web and make the end user feel safe instead of doing nothing.<p>Browsers have a good share in this responsibility as well. Standard domain security should work well here as well. Better than what we have.<p>I leave this to more entreprenurial minds to make this work and I'd love some real telegraph style sinkers to point out the flaws. This is must me talking after a belated xmas dinner. but I think I'm kind of on course.
What is a good reason for openssl.org not to utilize HSTS[1]?<p><pre><code> $ curl -I https://www.openssl.org/
HTTP/1.1 200 OK
Date: Sun, 29 Dec 2013 03:57:54 GMT
Server: Apache/2.2.22 (Ubuntu)
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Length: 15686
Content-Type: text/html
</code></pre>
[1]: <a href="https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security" rel="nofollow">https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security</a>
Does anyone have any details about how this was done? Was it a compromised admin account, a local root exploit, social engineering, etc? I'm eagerly awaiting the post-mortem.
Other pages are still up (although I haven't checked that they're unmodified) - it does appear the attacker didn't bother to bring anything but the front page down.