> Linux package managers really verify the signature of the hash
> Code signing is the real root of trust here, not hashing.
Hashing is the root of that specific trust which says "this is the same thing it was 17 months ago when we first fetched it".
(It is not deductively implied; it is predicated on the difficulty of producing a rogue file that has the same hash.)
Maybe it was a fake then, loaded with malware; that's a related, though different concern.
The fact is that I can inspect something, like a module of shell script code, to my satisfaction to be free of problems, and debug all my stuff with it. The hash then gives a lot of assurance that it's the same thing I validated before.
> You can't escape the total insecurity of git cloning because a malicious actor will just create a branch with the name of the desired hash and every client will happily clone it
If a branch or tag can be created that has a name indistinguishable from the syntax of a hash, that's a disturbing ambiguity in git that should be arguably patched away. It is tangential to this topic.
I believe, perhaps mistakenly, that after the repository is cloned and checked out (by any means: hash or branch/release tag), a validation can be made that HEAD points to the expected commit, e.g. using
git rev-parse --verify HEAD^{commit}
That should defeat the ruse.
Language managers are based on a vested interest in popularizing a language, by maximizing the amount of activity occurring in its "ecosystem". If every dependency were pinned down by a hash, such that the upstream developers have to beg everyone to update to a new hash every time they want to publish some change, that would put a huge a damper on the party. Language package managers are not motivated by stability, reliability and security. I'm not in favor of language package managers, and none of my work or side projects depend on them.
> Code signing is the real root of trust here, not hashing.
Hashing is the root of that specific trust which says "this is the same thing it was 17 months ago when we first fetched it".
(It is not deductively implied; it is predicated on the difficulty of producing a rogue file that has the same hash.)
Maybe it was a fake then, loaded with malware; that's a related, though different concern.
The fact is that I can inspect something, like a module of shell script code, to my satisfaction to be free of problems, and debug all my stuff with it. The hash then gives a lot of assurance that it's the same thing I validated before.
> You can't escape the total insecurity of git cloning because a malicious actor will just create a branch with the name of the desired hash and every client will happily clone it
If a branch or tag can be created that has a name indistinguishable from the syntax of a hash, that's a disturbing ambiguity in git that should be arguably patched away. It is tangential to this topic.
I believe, perhaps mistakenly, that after the repository is cloned and checked out (by any means: hash or branch/release tag), a validation can be made that HEAD points to the expected commit, e.g. using
That should defeat the ruse.Language managers are based on a vested interest in popularizing a language, by maximizing the amount of activity occurring in its "ecosystem". If every dependency were pinned down by a hash, such that the upstream developers have to beg everyone to update to a new hash every time they want to publish some change, that would put a huge a damper on the party. Language package managers are not motivated by stability, reliability and security. I'm not in favor of language package managers, and none of my work or side projects depend on them.