3 ms·
> 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
by 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.)