Add support for multiple, named OpenPGP signatures per package

[pmatilai]

Add support for multiple, named signatures per package.
Named signatures are stored as a name:base64 encoded string array in
RPMTAG_OPENPGPHEADER, name is an arbitrary \0-terminated string
and is part of the signed data (appended after actual package data).

These are always header-only signatures, and can co-exist with
"traditional" signatures: if no name is specified when signing then
the new signature replaces any old traditional signature the package
may have. If name is specified then the signature is merely appended
to RPMTAG_OPENPGPHEADER.

Use:

rpmsign --addsign --name=<name> <package>

Not implemented yet:

• name sanity checks (limit to alphanumeric and punctuation?)
• named signatures are not checked for duplicates when signing
• there's no way to delete just one named signature
• ...

Misc notes:
We could trivially support signatures without names too in the same
tag, but the question then becomes what to do with "traditional"
signatures when name isn't specified - only putting named signatures
into the new tag makes that simple(r). People will still need those
legacy signatures for some time due to older versions not supporting
the new.

[lgtm-com]

This pull request introduces 1 alert when merging cb14ea4 into d937b04 - view on LGTM.com

new alerts:

• 1 for Local variable hides global variable

[mlschroe]

What's the purpose of the 'name' part? Is this about supporting signatures from multiple groups? Or is this about supporting new pubkey algorithms (e.g. ed22519)?

[pmatilai]

It could be multiple groups or whatever, but certainly not about new algorithms. It's kinda intentionally loosely defined to the point of being undefined to allow creative use.

The "name" part was called "role" in earlier versions, which might give different ideas about its usage, but decided against it because it might mix badly with some other, more defined concepts of roles and signatures.

For example, one could use it to "stamp" different stages of production pipeline, eg "build", "qe", "ship", or organizations could do similar things internally, eg stamped authorized for use in departments org.foo.X and org.foo.Y, or different distro versions, or ... I don't know 😄 The naming is both a clue to the user/usage, and allows (but doesn't require) using the same key for different purposes.

Ultimately you'd want some configurable signature policy thingie but that's beyond the initial scope.

[pmatilai]

Oh and to be clear, this is little more than a draft at this point and ideas + suggestions are very welcome.

I originally did this in spring of 2017 but got side-tracked with 4.14 release and RHEL 8 and whatnot, and the work very nearly got lost forever (it would have, if it wasn't for @ffesti's email archive) so figured I'll just post this here for comments to have a safer place than my laptop...

[pmatilai]

To clarify the new RPMTAG_OPENPGP tag a bit, the idea is that eventually all OpenPGP signatures would be stored there, regardless of the public key algorithm used. Having separate tags based on the underlying algorithm is nuts, they're still all OpenPGP signatures, so it's the first step towards eliminating these wacko queries (now imagine a few more supported algorithms that everybody needs to check...):

Signature : %|DSAHEADER?{%{DSAHEADER:pgpsig}}:{%|RSAHEADER?{%{RSAHEADER:pgpsig}}:{%|SIGGPG?{%{SIGGPG:pgpsig}}:{%|SIGPGP?{%{SIGPGP:pgpsig}}:{(none)}|}|}|}|\n\

I'm not sure if the "name" part really makes sense, or is it actually just something weird that turns people away? OpenPGP signatures have User ID fields including a "Signer's User ID" which can be used to state a signer role, so perhaps we shouldn't be duplicating this at rpm level at all, instead just actually implement this properly in the parser.

At which point the RPMTAG_OPENPGP would be just an array of base64-encoded OpenPGP signatures on the header, and we should probably merge any DSAHEADER/RSAHEADER tags into it when reading a package to unify it all.

So I'm starting to think I'll close this non-merged and go back to drawing board, unless people suddenly jump in with use-cases for the name part.

[pmatilai]

Okay no further comments / feedback, back to the drawing board for now.