Bug#1092131: python-debian: Better gpg verification needed (and test updates) for gpgv/gpgv-sq

[Stuart Prescott]

Source: python-debian
Version: 0.1.49
Severity: important
X-Debbugs-Cc: stuart at debian.org

With multiple gpg signature verification tools in the archive the test
suite has become more fragile - the tests pass with gpgv while they fail
with gpgv-sq. As gpgv-from-sq was being pulled into the experimental chroots,
this incompatibility caused the FTBFS of version 0.1.50 which is worked
around for the time being with a Build-Conflicts: gpgv-from-sq.

For the purposes of the test_gpg_info test, the differences are:
- gpgv only tests that the cryptographic signature checks out.
- gpgv-from-sq does not consider the SHA1 that the test key uses.
- gpgv-from-sq tests that the metadata in the key makes sense too, as I
  understand it, the exported test key does not have self-sigs that
  indicate that it was valid at the time the signature was made and so
  gpgv-from-sq rejects the signature.

Fixing the tests is, in a way, easy enough.
- export the test key to have all self-sigs, and configure gpgv-from-sq
  to accept sha1, or
- create new data for the gpg tests
- create a key-pair within the test suite and use them for the signing
  tests.

sq upstream recommends the last of these, but in doing so, one loses the
ability to test that you can operate on old data - which brings us to
a design decisions:

For python-debian, is it important to be able to check the gpg signature on
random old .dsc or .changes files?

The relative prioritisation of old data vs new standards/good-practice will
influence the solution. While apt has moved to the sq stack, I'm not
aware of dak making similar changes at this stage.

If we choose to support gpgv-from-sq (or follow apt to support sqv) then an
API change is likely necessary to control how picky it is about
signatures; that might also be the time to look at fixing other bugs
around multiple signatures.