Hacker News Reader

Comment by notacoward | Hacker News Reader

The bit about code signing is really important. The people who wrote distro package managers recognized this years ago, and ever since have at least tried to do the right thing. That can make getting code into those repos a bit cumbersome, but that's kind of the price you pay.

Unfortunately, most of the language- and environment-specific package managers have pretty much ignored that issue. There's too often no way to verify that the code you just downloaded hasn't been tampered with. Heck, half the time you can't even be sure it's a version that's compatible with everything else you have. It's a total farce.

Software distribution is too important, security-wise and other-wise, to leave it to dilettantes as an afterthought to other things they were doing. Others should follow curl's example, instead of just dumping code into an insecure repo or (even worse) putting it on GitHub with a README that tells users to sudo the install script.

View on HN

I want to agree with you that it's important, but also I want to emphasize how hard it is to do any better than just HTTPS.

If I have distro maintainers sign the packages they build, then I can avoid keeping their private keys on the package servers. That's cool, and it can make it harder for an attacker to ship evil bits. But there's a bootstrapping problem: How did the user's machine originally learn the packagers' public keys, to know what signatures to look for? It got the public keys that were baked into the installation disk, and that disk was almost certainly downloaded from an HTTPS website, without checking any other signatures. (Or even _with_ extra signatures, if the key fingerprint for those was hosted on the same server.) Compromising the server still lets you own all the users.

At the end of the day, running a whole system of offline package signing and key distribution buys you a kind of subtle difference in security: If an attacker owns the package/image server, they can own machines that are set up after that point, but not machines that were set up before. Is that difference worth the effort of maintaining a system like that? Maybe! But it's not really the difference between "secure" and "insecure".

For me a big difference between package signing and HTTPS is that with HTTPS the private key has to be on the web server all the time, so is constantly exposed.

With a package signing key, it can be held on a more easily secured system, and is therefore less likely to be compromised.

> That can make getting code into those repos a bit cumbersome, but that's kind of the price you pay.

That's as clear a statement of security theater as I can think of.

If you make it cumbersome to build packages for a distro and get them accepted into that distro, your distro then ends up with language-level package managers doing an end-run around that "secure" package-managing apparatus.

Meanwhile, non-dilettante security experts are sandboxing the code that they aren't able to verify. Chrome/Chromium does that. Firefox is doing that more and more. What are the cumbersome-package-having distros doing?

> Unfortunately, most of the language- and environment-specific package managers have pretty much ignored that issue. There's too often no way to verify that the code you just downloaded hasn't been tampered with.

This is something Windows seems to have got right, with Authenticode and Catalog signatures - it's easy to verify who signed a file, and if it's been tampered with.

What options are there for this on Linux? File integrity monitoring (Tripwire, Ionx Verisys, whatever) will tell you when files change, but that doesn't help to know if a file is in a 'trusted' state.

> What options are there for this on Linux?

You have RPM signatures and the like to verify the authenticity of packages at the point of installation. If you mean detection of changes to files after the installation, then we need to talk about what it is you're trying to protect against.

If you want to detect accidental corruption (e.g. clobbering of distro-provided files through pip or 'make install'), the built-in verification functionality of RPM (rpm -V) or dpkg (dpkg -V) does a good job at that.

Malicious modification is something else entirely. Your system files are only modifiable by root. So if an attacker was able to mess with these files, any tool intended to detect that situation might've also been messed with so that it always gives the "everything is fine" assessment.

You can tackle this problem using special hardware. Or do the assessment on a different system using a disk snapshot.

The former can be done on Linux using a TPM and the trousers framework. If the protected set of software changes frequently, it's a pain in the ass to manage though.

Brooooken. No change installs. Build once ,install once, ro mounts, writes to tempdirs by application, build release audits before push..it's the only way.

Assuming one can trust git and GitHub (and CAs), is there a technical reason why you would consider distributing code via GitHub as unsafe?

Stolen GitHib credentials.

The code is what we are trying to verify, not that someone claiming to be user x published it.

That is basically the same as trusting `apt install`. We just hope apt repo maintainers have higher levels of opsec.

Most trust on a typical Ubuntu install, for example, is still chained back to an TLS download of an ISO (or maybe torrent file). That bootstraps your repo public keys.

You should always be verifying your downloads:

https://tutorials.ubuntu.com/tutorial/tutorial-how-to-verify...

I have done this before. But if you are actually MiTM downloading the GPG sums from the same source as your ISO is a little pointless. That is the problem, how do you bootstrap the trust? It all still just goes back to TLS and the CA.

You can check the sums over time and acquire them using multiple connections to verify they are all the same to gain a higher level of confidence, but this is actually annoying for someone with a high level of technical skill and basically impossible for most people. I only do this for things that require the highest levels of operational security, like, say, if I am setting up a system to sign certificates in a CA or something.

A slightly easier approach is to strip down your CAs to a bare minimum in your browser config, and double check the certificates being presented on TLS download sites. You can still be owned by a MiTM if the CAs actively collude with a nation state and have given them signing keys, but... there isn't much to do about that. The options really aren't that great in terms of really verifying things.

And the security of the developer who signed the package too?

And we are back to Thompson, basically. :)

> We just hope apt repo maintainers have higher levels of opsec.

They do.

In addition to account compromise, there's also the risk of bugs/compromise of GitHub itself:

https://github.com/blog/1068-public-key-security-vulnerabili...

Commit signing can help to mitigate that.[0] Note that GitHub now offers the ability to add your GPG public key to your profile and show whether a commit is signed with that key or not. I find this more dangerous than useful: if an attacker compromises the account and adds his/her key, and adds a malicious commit, GitHub would show it as verified.

[0]: https://mikegerwitz.com/papers/git-horror-story

Do you know how the signing requirements work on GitHub when accepting a pull request on a repo requiring signed commits, when the pull request is from a fork where someone is not signing their commits? Must the commit to the fork be signed in order for the pull request to be merged, or is it possible for the main repo to merge an unsigned commit while signing it themselves in the process?

I can see requiring every commit on the primary repo to be signed, but it's a larger nightmare to accept pull requests from forks if they are also forced to sign their commits.

I'm not all that familiar with GitHub.

What's ultimately important for trust is that the maintainers (or whomever you are to trust) sign commits. They may choose to pass this responsibility down the line a bit (e.g. how Linus has his "lieutenants"), but if some random contributor does or does not sign a commit, do we care? Are they in the maintainers' web of trust? What benefit does verifying their identity actually have with respect for the project?

So in that case, a maintainer may decide to just review the patches and sign the merge commit.

That contributor may want to _assert_ their identity---e.g. have their signed commit committed to the repository to show that they actually did that work---but that's a different issue.

There are several reasons, but not specifically to do with code signing. Code in a distro repo has been at least cursorily checked to make sure the install script (or "scriptlets" in something like an RPM specfile) doesn't do anything awful. Some of that's automated, some of it's manual, but at least it's there. An exploit would have to get past both the author and the distro gatekeepers to become operative. With code on GitHub, it only has to get past the committer - who might, unlike distro packagers, be totally clueless about security or even basic bash-scripting safety rules. That's just too easy IMO.

Reply on news.ycombinator.com