3 ms·

The tarball, with its signed hash, is the authoritative source with immutable ID. Not every project uses git. Not every project uses a public VCS. Git history

by bregma 3y ago

The tarball, with its signed hash, is the authoritative source with immutable ID. Not every project uses git. Not every project uses a public VCS. Git history can be changed with a simple command and is unreliable. The point of a tarball is that it is the distribution medium of a source release. The developer generates the generated code (where required), runs all tests (eg. `make distcheck`), then when satisfied it's good, signs it and releases it. If you can't trust the developer's signed tarball you can't trust their git repo either, since it's the developer you can't trust. A downstream, such as a Linux distro, uses the release tarball because it's the single, verifiable, published source of truth. They should be able to do reproduceable builds from the tarball (not being able to do so should be filed upstream as a bug), and for licensing reasons (eg. GPL) need to keep the tarball and make it available to anyone to whom the software is distributed.

gunapologist99 3y ago
The parent referred to "questionable" (i.e., unsigned) tarballs. Your answer, while excellent, is answering a question that wasn't asked.
- AshamedCaptain 3y ago
  No distribution I know of uses "unsigned" tarballs. Most of them hardcode the hash of the expected tarball anyway.
  - gunapologist99 3y ago
    Hashes and cryptographic signatures are not the same thing.
kijin 3y ago
> Git history can be changed with a simple command and is unreliable. Not if other people have cloned your repo. That's the whole point of having a distributed VCS. Your repo is no longer the single source of truth because other repos remember what truth looked like 3 days, 3 months, 3 years ago. You renounce the right to dictate truth as you wish, and gain trust in exchange. I don't understand why this idea comes up again and again: "You trust the developer, you might as well trust the code they distribute." That makes no sense. Why do you trust them in the first place? Do you know them? Have you met them in person, had a few beers with them? Or is your trust merely based on their past performance as an open-source developer? If it's the latter, whether they have been willing to work in a way that facilitates independent inspection and verification of their output should be a very important factor in whether you should trust them at all. Hardware vendors who dump opaque binary blobs at the kernel's doorstep tend not to receive much respect, after all.
- bregma 3y ago
  > "I trust the developer, so I trust the code they distribute." I said "If you can't trust the developer's signed tarball you can't trust their git repo". That's absolutely not the same thing. In fact it's sort of the opposite. Distributed cloned repos are not a single source of truth. If they differ, which one is the actual source of truth? Was the post-release changed history propagated? A signed tarball means the signing key you use to verify the tarball has been verified by a web of trust. The web of trust requires the physical confirmation of identity of the private key holder. Yes, it's possible to subvert the web of trust by playing the long game, complete with falsified (or even real) national ID documents, active participation in social networks, and other life activities. This, though, is true of all espionage and no amount of technical measures or randos ranting on social media on the internet will prevent it.
  - kijin 3y ago
    > Distributed cloned repos are not a single source of truth. That's the point. No person should be trusted to be a single source of truth. If there are multiple sources of truth and they don't agree, it's a red flag. A highly useful flag, in fact. The situation must be resolved before truth can be established again, and all that commotion in the bazaar will make it more likely that a maintainer gone rogue will be caught. A signed tarball by the same rogue maintainer, on the other hand, will probably pass unnoticed until it's too late. At the end of the day, it's neither people nor any specific chunk of code that I'd like to trust. It's the system -- a system that incentivizes accountable behavior, and blocks releases if there are any red flags, so that you don't really need to trust any single person.
  - jcranmer 3y ago
    > A signed tarball means the signing key you use to verify the tarball has been verified by a web of trust. The web of trust requires the physical confirmation of identity of the private key holder. Hasn't the web of trust collapsed due to an unfixable hole in keyservers? PGP keys in practice have almost always amounted to checking a hardcoded list of acceptable keys that is periodically updated, not unlike a list of trusted CAs. (In any case, the attack we're talking about here--a rogue maintainer creating a backdoor in their project--won't be caught by any amount of advanced signing infrastructure. Somebody was elevated to a position of trust and any reason not to elevate them wasn't discovered until after the damage was done.)
Ajedi32 3y ago
> If you can't trust the developer's signed tarball you can't trust their git repo either The public git repo has a lot more eyes on it. You don't necessarily have to trust the developer if 1) you trust at least one of the people who reviewed the code, and 2) you have a way to verify that the code you're running is the same as the code that person reviewed Trusted builds based on the public git repo rather than an unrelated tarball solves part 2 of that problem.

by bregma 3y ago

gunapologist99 3y ago

The parent referred to "questionable" (i.e., unsigned) tarballs. Your answer, while excellent, is answering a question that wasn't asked.

AshamedCaptain 3y ago
No distribution I know of uses "unsigned" tarballs. Most of them hardcode the hash of the expected tarball anyway.
- gunapologist99 3y ago
  Hashes and cryptographic signatures are not the same thing.

kijin 3y ago

> Git history can be changed with a simple command and is unreliable. Not if other people have cloned your repo. That's the whole point of having a distributed VCS. Your repo is no longer the single source of truth because other repos remember what truth looked like 3 days, 3 months, 3 years ago. You renounce the right to dictate truth as you wish, and gain trust in exchange. I don't understand why this idea comes up again and again: "You trust the developer, you might as well trust the code they distribute." That makes no sense. Why do you trust them in the first place? Do you know them? Have you met them in person, had a few beers with them? Or is your trust merely based on their past performance as an open-source developer? If it's the latter, whether they have been willing to work in a way that facilitates independent inspection and verification of their output should be a very important factor in whether you should trust them at all. Hardware vendors who dump opaque binary blobs at the kernel's doorstep tend not to receive much respect, after all.

bregma 3y ago
> "I trust the developer, so I trust the code they distribute." I said "If you can't trust the developer's signed tarball you can't trust their git repo". That's absolutely not the same thing. In fact it's sort of the opposite. Distributed cloned repos are not a single source of truth. If they differ, which one is the actual source of truth? Was the post-release changed history propagated? A signed tarball means the signing key you use to verify the tarball has been verified by a web of trust. The web of trust requires the physical confirmation of identity of the private key holder. Yes, it's possible to subvert the web of trust by playing the long game, complete with falsified (or even real) national ID documents, active participation in social networks, and other life activities. This, though, is true of all espionage and no amount of technical measures or randos ranting on social media on the internet will prevent it.
- kijin 3y ago
  > Distributed cloned repos are not a single source of truth. That's the point. No person should be trusted to be a single source of truth. If there are multiple sources of truth and they don't agree, it's a red flag. A highly useful flag, in fact. The situation must be resolved before truth can be established again, and all that commotion in the bazaar will make it more likely that a maintainer gone rogue will be caught. A signed tarball by the same rogue maintainer, on the other hand, will probably pass unnoticed until it's too late. At the end of the day, it's neither people nor any specific chunk of code that I'd like to trust. It's the system -- a system that incentivizes accountable behavior, and blocks releases if there are any red flags, so that you don't really need to trust any single person.
- jcranmer 3y ago
  > A signed tarball means the signing key you use to verify the tarball has been verified by a web of trust. The web of trust requires the physical confirmation of identity of the private key holder. Hasn't the web of trust collapsed due to an unfixable hole in keyservers? PGP keys in practice have almost always amounted to checking a hardcoded list of acceptable keys that is periodically updated, not unlike a list of trusted CAs. (In any case, the attack we're talking about here--a rogue maintainer creating a backdoor in their project--won't be caught by any amount of advanced signing infrastructure. Somebody was elevated to a position of trust and any reason not to elevate them wasn't discovered until after the damage was done.)

Ajedi32 3y ago

> If you can't trust the developer's signed tarball you can't trust their git repo either The public git repo has a lot more eyes on it. You don't necessarily have to trust the developer if 1) you trust at least one of the people who reviewed the code, and 2) you have a way to verify that the code you're running is the same as the code that person reviewed Trusted builds based on the public git repo rather than an unrelated tarball solves part 2 of that problem.