Live data from Hacker News

LibreSSL

libressl.org

211–220 of 262 posts

Re: LibreSSL

#212
post #192

Earlier quoted context omitted.

There is a pro-type / mordern-type version of comic sans http://comicneue.com/ :)

I added it to homebrew-cask :) https://github.com/caskroom/homebrew-fonts brew tap caskroom/fonts brew cask install font-comic-neue

nice! :)

Re: LibreSSL

#213

"No we don't want help making web pages, thank you." Seems silly to turn away help.

Managing a flock of web devs and telling them all they're doing it wrong would eat up time that could've been spent on the actual code. So it's not actually help.

Re: LibreSSL

#214
post #155

Earlier quoted context omitted.

At least they succeeded in their goal of annoying web hipsters. Why don't you sell your fixie on craigslist and donate some money anyway, please?

Do you think your tone will encourage anyone to donate?

Well, I donated because I was glad it annoyed him, so I assume other people might, too. ;)

Re: LibreSSL

#215
post #67

Comic sans?? lol! This page scientifically designed to annoy web hipsters. Donate now to stop the Comic Sans and Blink Tags

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

The correct word for "mainstream" is "surface". "Mainstream" is far too surface of a word.

Re: LibreSSL

#216
post #183

I've been thinking recently about Heartbleed, and I was wondering if by writing C code to implement various network and cryptographic protocols, we're acting as human compilers for something that might be better represented in a more abstract format. I know there's some research on this already (the Austin Protocol Compiler), but does anyone here know of any other serious efforts to take the human out of the equation…

The most viable option today seems to be writing code in some language with strong formal guarantees (Agda, Coq) with extracting to Haskell/OCaml for generating C code from there.

That's the way seL4 was written.

Re: LibreSSL

#217
post #161

I may have a stupid question but... 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 ha…

Git uses SHA-1 hashes, which have not been considered cryptographically secure since 2005. 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 proces…

> Git uses SHA-1 hashes, which have not been considered cryptographically secure since 2005.

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.

Re: LibreSSL

#218
post #183

I've been thinking recently about Heartbleed, and I was wondering if by writing C code to implement various network and cryptographic protocols, we're acting as human compilers for something that might be better represented in a more abstract format. I know there's some research on this already (the Austin Protocol Compiler), but does anyone here know of any other serious efforts to take the human out of the equation…

Rust ( http://www.rust-lang.org/ ) is a serious effort to build a language that's close to metal like C but safe.

Rust (http://playrust.com/) is a serious effort to build an envrionment that's about survival and gratuitous male nudity.

Re: LibreSSL

#219
post #174
post #126

With close to years of C under my belt, I believe it's a major error, today, to write a critical cryptographic library in C. 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…

People might disagree, but why is this downvoted so much?

https://news.ycombinator.com/item?id=7619287

Re: LibreSSL

#220
Some of the commit comments are entertaining: "Fix some serious pointer-arithmatic-magic-number-unchecked-return eyebleed that I stumbled into here and got stuck with. If modern society can get past selling daughters for cows, surely we can decide to write modern C code in an "application" that is probably 3 lines of shell/python/cgi away from talking to the internet in a lot of places.. (This file still needs a lot more love though) "oh god yuck" deraadt@ ok tedu@"

http://freshbsd.org/commit/openbsd/fc55d7f9ab6fcadd0ca2f8231...

Post reply on HN