Hacker News Reader

Comment by ivoras | Hacker News Reader

You'd be supried how few people actually work on issues such as security in FreeBSD. Unfortunately, instead of using existing solutions to reduce their workload, there's a lot of NIH-ism.

Like writing freebsd-update in POSIX shell, or using a home-made public key signature format instead of PGP, or not using signatures at all for package files, or refusing to use CDNs to deliver packages until very recently.

It's not that those things are inherently bad, it's that the bus factor ("what stops working when a developer is hit by a bus - or goes on a vacation") is very, very high.

View on HN

Vulnerabilities don't bother me! All code has vulnerabilities. Meanwhile, the opportunity to use code built around a different (BSD-like) mindset is why you'd use FreeBSD instead of Linux in the first place.

What freaks me out is simple problems of principle, like, "we won't disclose this vulnerability because we don't have a patch, even though we know there's an exploit available". Even if the exploit wasn't public, as long as you know it's out there, people need to know about it!

       we won't disclose this vulnerability because we 
       don't have a patch, even though we know there's an
       exploit available.

This is some 1984 shit. It's a horrible policy. While yes it'll make it easier for bad actors to write exploits, it'll also allow for sys-admins to possibly mitigate those exploits, or add extra logging to make it easier to catch exploits.

Not admitting your software has flaws until you fix them is beyond irresponsible.

Did you miss the directly following sentence?

> We are reviewing this policy for cases where a proof-of-concept or working exploit is already public.

The existing policy is flawed and they intend to fix it. It just hadn't been a problem before now.

No, it was that sentence that moved me to comment! They're "reviewing this policy"? They were bound by the policy in this case? That's crazy. There's an exploit. They didn't write it. Nobody should have to wonder if they're going to disclose.

Ultimately I just care about this as an object lesson for how to handle security incidents.

a home-made public key signature format instead of PGP

How is 'openssl rsautl -sign' a "home-made" signature format?

As for using GPG... given its security track record, that's one of the last things I'd want to consider using for verifying signatures on binary updates.

or not using signatures at all for package files

The pkg repository is signed.

>> a home-made public key signature format instead of PGP

> How is 'openssl rsautl -sign' a "home-made" signature format?

It's RAW RSA DATA. You could argue it's more pure that way but if that were the case, noone would ask for more metadata-rich signatures.

> As for using GPG... given its security track record, that's one of the last things I'd want to consider using for verifying signatures on binary updates.

If you don't see the NIH-ism in that sentence, then I'm sorry, neither I nor nobody else can help you.

> The pkg repository is signed.

Can individual package files be verified off-line?

Is it not possible for cperciva's assessment of GPG to be accurate regardless of where it was invented?

Whether code is crap is a completely separate question from where it was invented.

Putting signatures onto the individual package files could expose users to mismatch attacks, and would also make it harder to defend against build-trojan theft of signing keys.

I think Colin has the better argument here. You were hyperbolic when you called rsautl a "home-made format".

Packages are not meant to be distributed ad-hoc. You're meant to host a repo and sign it.

I find it amusing that the line before your statement of distrust around GPG refers to using that bastion of solid, dependable crypto code that ships with OpenSSL.

OpenSSL's crypto code isn't all that bad as long as you're not worried about side channel attacks. Most of their remote code execution bugs have been in protocol code.

> OpenSSL's crypto code isn't all that bad as long as you're not worried about side channel attacks.

I consider "horrible API that makes it basically impossible to write safe code" to be a security vulnerability. Not to mention that OpenSSL's example code actually had security vulnerabilities (they didn't check the return value from one of the IV routines, whish means that you could end up using a shorter key than you expected).

That was pretty funny. Gets better with the Snowden slides where mighty NSA basically says they can't break it in basic, use case. At Princeton, Snowden even said analysts got failure notices even for requests to decrypt GPG w/ 1,024-bit RSA at a time when paranoids wondered how long 4,096-bit might last. Haha.

Next I'm going to hear that using TAIL's increases your risk of damning evidence found during a disk audit by a forensics team.

The packages don't need signing! The repo database is signed and the package checksums are inside. If the checksum doesn't match, the package is refused to be installed. This is vastly simpler than signing every package.

> Like writing freebsd-update in POSIX shell

How is this a bad thing? It is part of the base system, so it's either /bin/sh or C.

Reply on news.ycombinator.com