Systems that pin to commit hashes (e.g. Go module proxies,
Nix flake locks, Github Actions references, Dockerfiles naming a specific commit, etc) rely on the assumption that a hash is a unique handle for content under a given signer.
I don’t think this is true on either count: systems that pin to commits frequently don’t look at commit signatures at all, and there is no particular assumption of uniqueness between object IDs and contents (given that object IDs can point to each other across namespaces, e.g. a tag reference that peels to a commit).
(I also agree with the points below about this probably not being a useful form of malleability: there are a nearly infinite number of ways to “malleate” janky encodings like GPG packets and CMS. The much more interesting malleability is when an attacker forges a signature over contents the victim did not intend to sign, which is not demonstrated.)
Comments
I don’t think this is true on either count: systems that pin to commits frequently don’t look at commit signatures at all, and there is no particular assumption of uniqueness between object IDs and contents (given that object IDs can point to each other across namespaces, e.g. a tag reference that peels to a commit).
(I also agree with the points below about this probably not being a useful form of malleability: there are a nearly infinite number of ways to “malleate” janky encodings like GPG packets and CMS. The much more interesting malleability is when an attacker forges a signature over contents the victim did not intend to sign, which is not demonstrated.)