Compatibility with GnuPG 1.x and 2.x, auto-detect GnuPG version

[smira]

Fixes #741
Fixes #699
Fixes #657

Requirements

aptly should support transparently GnuPG 1.x and 2.x via gpg PGP provider. Internal PGP provider only supports GnuPG 1.x keyring format (as openpgp Go library doesn't support GnuPG 2.1+ kerying format).

Description of the Change

• aptly can sign and verify without issues with GnuPG 1.x and 2.x
• aptly auto-detects GnuPG version and adapts accordingly
• aptly automatically finds suitable GnuPG version

Majority of the work was to get unit-tests which can work with GnuPG 1.x & 2.x. Locally I've verified that aptly supports GnuPG 1.4.x & 2.2.x. Travis CI environment is based on trusty, so it runs gpg2 tests with GnuPG 2.0.x.

Configuration parameter gpgProvider now supports three values for GnuPG:

• gpg (same as before, default): use GnuPG 1.x if available (checks gpg, gpg1), otherwise uses GnuPG 2.x; for aptly users who already have GnuPG 1.x environment (as it was the only supported version) nothing should change; new users might start with GnuPG 2.x if that's their installed version
• gpg1 looks for GnuPG 1.x only, fails otherwise
• gpg2 looks for GnuPG 2.x only, fails otherwise

Checklist

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

[codecov]

Codecov Report

Merging #779 into master will decrease coverage by 0.02%.
The diff coverage is 55.88%.

@@            Coverage Diff             @@
##           master     #779      +/-   ##
==========================================
- Coverage   64.08%   64.06%   -0.03%     
==========================================
  Files          50       51       +1     
  Lines        6446     6506      +60     
==========================================
+ Hits         4131     4168      +37     
- Misses       1810     1831      +21     
- Partials      505      507       +2

Impacted Files	Coverage Δ
context/context.go	11.5% <0%> (-0.62%)	⬇️
pgp/gnupg_finder.go	71.87% <71.87%> (ø)
pgp/gnupg.go	64.56% <73.33%> (-2.26%)	⬇️
pgp/internal.go	51.19% <0%> (+3.57%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 702c1ff...61e00b5. Read the comment docs.

[smira]

There are some code coverage issues in openpgp/internal.go, I will get them sorted out tomorrow

[sliverc]

Looks good code wise. Question is though shoudln't we not also run the system tests with gpg2 to be sure that it works?

[smira]

@sliverc good point, I will add detection of gpg1/2 to system tests and I will add tests on signing/verifying with gpg2

[smira]

@sliverc I've tried to address your feedback in 61e00b5

[sliverc]

LGTM.

[bersace]

Kudo. Can't wait for next aptly release :-)

[iliis]

Not sure where to post this, but it took me ages to figure out why gpg signing wouldn't work. I always got the following error when trying to publish via the API:

Signing file 'Release' with gpg, please enter your passphrase when prompted:
gpg: signing failed: Inappropriate ioctl for device
gpg: signing failed: Inappropriate ioctl for device
[GIN] 2021/12/28 - 11:53:14 | 500 |   72.174473ms |   192.168.64.39 |  POST     /api/publish
Error #01: unable to publish: unable to detached sign file: exit status 2

I tried all kinds of things with configuring gpg. In the end, it turns out I was just using the API wrongly.
I was calling it like this:

curl -X POST -H 'Content-Type: application/json' --data '{"SourceKind": "local", "Sources": [{"Name": "foobarrepo"}], "Architectures": ["amd64"], "Distribution": "wheezy", "GpgKey": "****", "Passphrase": "****", "Batch": true}' http://myserver/api/publish/foobar

when instead I should have put the GPG signing parameters into a sub-field:

curl -X POST -H 'Content-Type: application/json' --data '{"SourceKind": "local", "Sources": [{"Name": "foobarrepo"}], "Architectures": ["amd64"], "Distribution": "wheezy", "Signing": {"GpgKey": "****", "Passphrase": "****", "Batch": true}}' http://myserver/api/publish/foobar

It would be very nice if the API gave an error for unknown/unexpected parameters.