Add config key for 'gpgKeys' and allow multiple keyRefs when signing with gpg, fixing Issues #309 and #691

[abregar]

Fixes #309 and #691

Requirements

All new code should be covered with tests, documentation should be updated. CI should pass.

Description of the Change

This PR introduces support for multiple GPG signing keys in aptly, addressing longstanding requests for multi-signature support in published repositories. The change was motivated by Debian repository guidelines and our internal requirement to rotate signing keys without interrupting package consumers.

• Implements repeatable --gpg-key CLI flag.
• Adds gpgKeys array to aptly.conf for configuration-based multi-key support.
• CLI arguments take precedence over configuration file values.
• Both clearsign and detach-sign operations now sign with all provided keys.
• updated some unit tests

Checklist

• [x] unit-test updated (if change is algorithm)
• [ ] functional test added/updated (if change is functional)
• [ ] man page updated (if applicable)
• [ ] bash completion updated (if applicable)
• [x] documentation updated
• [x] author name in AUTHORS

[abregar]

Hey @neolynx , two quick questions:

• Since the only check currently failing is the build for Debian Buster — which has been EOL for some time — would you consider removing it from the build, or is there a specific reason to keep it?
• Could you briefly assess the solution in this PR to see if it’s good enough for me to start using from my current branch, without waiting for your official aptly tag?

[neolynx]

Hey @abregar !

thanks for the PR, great work gentlemen :+1:

Since the only check currently failing is the build for Debian Buster — which has been EOL for some time — would you consider > removing it from the build, or is there a specific reason to keep it?

you are right, the pipeline also fails because buster is not installable anymore. it will be removed!

Could you briefly assess the solution in this PR to see if it’s good enough for me to start using from my current branch, without waiting for your official aptly tag?

looks good to me !

the command is backward compatible this way, no problems there.

however, we should probably allow the same via API calls, also specify one or more keys there. hope this can be done in a backward compatible way as well (maybe separate by comma/space?).

please go on, looking forward to merge this !

[abregar]

Hey @neolynx, with the non-breaking-change requirement for the REST API in mind, I think the only option is to keep the current key name gpg-key but allow CSV values. I’ve made this change in the latest commit, and after rebasing with your pipeline changes, all checks have passed—yay!

[neolynx]

looks good otherwise ! :+1:

[codecov[bot]]

Codecov Report

:x: Patch coverage is 63.82979% with 17 lines in your changes missing coverage. Please review. :white_check_mark: Project coverage is 74.49%. Comparing base (231039e) to head (e4f35c4). :warning: Report is 2 commits behind head on master.

Files with missing lines	Patch %	Lines
api/publish.go	21.42%	8 Missing and 3 partials :warning:
cmd/publish.go	85.00%	2 Missing and 1 partial :warning:
pgp/gnupg.go	66.66%	2 Missing and 1 partial :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1479      +/-   ##
==========================================
- Coverage   74.86%   74.49%   -0.37%     
==========================================
  Files         159      159              
  Lines       18438    18476      +38     
==========================================
- Hits        13803    13764      -39     
- Misses       3489     3565      +76     
- Partials     1146     1147       +1     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.