Source: python-debian Version: 0.1.49 Severity: important X-Debbugs-Cc: [email protected]
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. -- https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-python-debian-maint
