3 ms·
Exactly this. The flow should be: * Look up keys that I trust * Check if the signature verifies against any of those keys Key hints can aid in selection here
by dlor 5y ago
Exactly this. The flow should be:
* Look up keys that I trust
* Check if the signature verifies against any of those keys
Key hints can aid in selection here if you have many trusted keys, but you can also just loop through.
Not:
* verify the signature
* check if the key matches one I trust
The second is much more dangerous, a "valid" signature from an untrusted key is just as bad as an "invalid" signature from a trusted key. There's no reason to treat these states as different.
- julian-klode 5y agogpg precisely has valid signature and good signature to distinguish signatures that are technically valid from good signatures. e.g. a valid signature can be expired, so it's not good or shit like that. So, the argument is flawed.
- julian-klode 5y agoThe point is not about valid signatures from untrusted keys, it's about invalid signatures from untrusted keys. Some repositories are signed with multiple keys. People building the repositories might only have one key T as trusted, and then mess up signing with the other key U (imagine that one is an offline key - this is how debian stable releases are signed). By verifying all signatures and rejecting any invalid one, it will be immediately obvious if the signature by U is wrong. Also, as mentioned before, the scheme allows for rapid subkey replacement in case of potentially compromised subkey.