Add support for multiple signatures per package, aka v6 signatures #3439
Conversation
The function comments are several generations old plain wrong. No functional changes.
No functional changes, just a tiny refactoring bit for the next steps.
Pass the flags down to the function that needs to do stuff. No functional changes.
Add support for multiple OpenPGP header signatures per package, base64 encoded in a string array, also known as rpm v6 signatures. --addsign no longer deletes any signatures, it only creates and adds a new signature if possible. --delete and --resign behave as before: they delete ALL signatures on the package, and the latter then creates and adds a new one. For v6 packages this is the default signature type, but if requested, one v4 compat signature can be created for compatible algorithms. v6 signatures on v4 packages are also supported, but have to be explicitly requested. In that case, v3/v4 signatures are only added if none already exist and a v4 compatible algorithm is used. v3 signatures on v6 packages are not supported (out of principle, not a technical limitation) On verification, if RPMTAG_OPENPGP exists then other signature tags are ignored because they're expected to only contain compat copies of the same content. As of now, all existing signatures must validate for signature checking of a package to pass, further policies are to be added later. Fixes: rpm-software-management#3385
Add a tag extension for RPMTAG_OPENPGP (on top of the concrete tag) to handle compatibility with v3/v4 signatures: the extension collects all legacy signatures under the same umbrella so users don't need to query multiple different tags, you just query for RPMTAG_OPENPGP to get all them at once. Extend :pgpsig tag format to handle the new string array/base64 variant. Update --info/-i query to use the extension and output all existing signatures, one per line. The no-signature case of "Signature : (none)" is preserved as-is to help backwards compatibility with scripts parsing the output. Related: rpm-software-management#3385
|
The main commit split into two due to popular demand 😄 |
|
Some other notes:
|
For some reason this feels very wrong to me. I can't conjure up am attack vector for this. But it makes me uneasy. |
|
Well, the only thing somebody can achieve by messing with the signatures is not achieving a positive verification really. In my initial version it read all the tags but then you'd need to weed out exact duplicates and somehow manage the resulting NOTFOUND spew. It gets ugly and complicated for no gain at all. |
|
May be just elaborating a bit more in the commit message makes this less scary. The current sentences is totally not something I want to read in some publication about rpm's signature handling. |
|
Uh, I don't really know what else to put there. The thing you need to remember is that NOTHING in rpm's signature handling makes sense or stands public scrutiny before enforcing signature checking is enabled. |
|
For example: without the enforcing mode, you just strip the signature from the package and modify it all you like. And rpm will merrily install the unsigned messed with thing with zero complaints. That is the wacko and scary present of the last 25 years. |
|
Mind, that's not to slight your intuition. I know I'm really hard-pressed to hit merge when something has a sense of "not right". Intuition is a powerful thing, but it's not always right. So maybe try pinpointing what exactly it is that's bothering you there - if your intuition is onto something and there's a problem with the current logic then it's rather important that we discover it. And in the other case, it's useful to yourself to understand why. |
|
I guess this is twofold: First we assume they are the same when there really is no reason an attacker would do so. So we can end up with different signatures depending on the rpm version being used. Then there's this "the newer rpm could check this but we leave that to the older version that has less of a chance to figure things out". Not sure if this really is realistic this "use rpm V6 to check signatures and then hand the packages down to an older rpm version". Otoh there is this post quantum talk. As soon as we do have policies requiring specific signatures may be there is a way to sneak in weak signatures this way. May be this is just fine for now and we need to look at this later on when we get into policy based verification. |
I don't see what there is to gain for an attacker in that situation. It's pretty much by design that newer and older rpm's can see different signatures.
There's no scenario where v6 would be used to check for signatures and then hand to v4. That compat stuff is about letting packages signed by rpm v6 be verified by older versions, to the best of their abilities. Those abilities do not include these newer signatures, whatever they are. The policy stuff is something that could use some further elaboration in the commit message actually. In the current implementation you can put 100 signatures in there, and somebody strips 99 of them out and nothing will notice, but in the future, the user will be able to specify which signatures and signature types are required in order to pass verification. |
|
Otherwise this is pretty straight forward. I am not a fan of the longer and long list of |
There are a handful of refactoring commits, da bomb is the last one. It should be as per the specification in ticket #3385, so not going to repeat all that here.