A Carnegie Mellon preprint shows that an attacker without the signing key can turn any signed commit into a second, content-identical commit that still earns a "Verified" badge and a different hash. The author says Git and GitHub have not fixed it.
I don’t understand. Why does having two commit IDs with the exact same code cause problems.
A green “Verified” badge on GitHub is supposed to mean that a trusted author signed it
The author did sign it. It is the exact same code.
An attacker can reissue the same signed code under a fresh ID that’s still verified to slip past.
To split past what? At best it seems that they would be able to have a different ID for the exact same code, which seems harmless? Slightly confusing at worst.
Nix also doesn’t use PGP signatures, it requires a separate hash of the resulting commit (the files with the .git directory stripped by default).
sounds like the author thinks because their purist definition is violated its a problem vs it actually being a problem. im in the same boat as you. I dont see the issue with the commit hash changing long as the code doesnt change.
I don’t understand. Why does having two commit IDs with the exact same code cause problems.
The author did sign it. It is the exact same code.
To split past what? At best it seems that they would be able to have a different ID for the exact same code, which seems harmless? Slightly confusing at worst.
Nix also doesn’t use PGP signatures, it requires a separate hash of the resulting commit (the files with the .git directory stripped by default).
Right, it’s not a serious exploit which would allow changing code, but it does allow compromising integrity because changing the id mutates history.
sounds like the author thinks because their purist definition is violated its a problem vs it actually being a problem. im in the same boat as you. I dont see the issue with the commit hash changing long as the code doesnt change.