Reprepro will handle signing if an individual key is specified or if the default gpg can be used, but signing a release with multiple keys requires the use of a handler script.
The handler script is added as a static script which relies on a new shell configuration file to set variables dictating the keys used via adding them to KEY_OPTS.
Additional GPG options can also be set in the GPG_OPTS variable although this is currently unused.
The config file is intended to be used as a chef template which will incorporate the keys to be used.
Caveats
I actually wrote this on an omnibus branch that included #136 and #135 because the pulp removal simplifies a lot of the GPG configuration. I'm not sure if this branch rebased onto latest will build.
Unsupported as of now is the ability to use multiple signatures on the rpm repositories.
For the time being they are only signed with the key designated "default".
It would be nice to try and resurrect the gpg-vault setup from #55, reverted in #82 because of consistency issues. I don't want to block on that but I would like to port the GPG vault approach forward and see if we have the same issues on a test farm in a future PR.
Reprepro will handle signing if an individual key is specified or if the default gpg can be used, but signing a release with multiple keys requires the use of a handler script.
The handler script is added as a static script which relies on a new shell configuration file to set variables dictating the keys used via adding them to KEY_OPTS.
Additional GPG options can also be set in the GPG_OPTS variable although this is currently unused.
The config file is intended to be used as a chef template which will incorporate the keys to be used.
Caveats
I actually wrote this on an omnibus branch that included #136 and #135 because the pulp removal simplifies a lot of the GPG configuration. I'm not sure if this branch rebased onto latest will build.
Unsupported as of now is the ability to use multiple signatures on the rpm repositories. For the time being they are only signed with the key designated "default".
It would be nice to try and resurrect the gpg-vault setup from #55, reverted in #82 because of consistency issues. I don't want to block on that but I would like to port the GPG vault approach forward and see if we have the same issues on a test farm in a future PR.