Hi! On Fri, 2023-12-01 at 00:20:16 +0000, Dimitri John Ledkov wrote: > Currently dak requires signatures on .changes & .dsc uploads. .changes with > signatures are publicly announced and then .dsc are published in the > archive with signatures. .changes references .dsc. > > All .dsc have Checksums-Sha256 for the files they reference, .dsc itself > can be verified through strong checksum in Sources metadata, chained via > InRelease to the strong debian archive key signature.
Yes, the maintainer and uploader signatures (which can be different, .dsc vs .changes) are most useful during the upload process, and are part of the trust anchor handover. So that an archive can take over, and then can implement certificate policies, such as certificate rotation or handle expirations, revocations, etc. Performing such actions on all .dsc would be not only infeasible as their checksums would change, but I guess also rather costly. > The same is not true for signatures on .dsc themselves. Majority of .dsc > use at least sha256 and can be successfully verified. Sure, and that's why for example dpkg-source by default does not enforce --require-valid-signature by default. > But some use weak hash: > 5 dsc signed using Hash: RIPEMD160 > 152 dsc signed using Hash: SHA1 Although dpkg-source considers RIPEMD160 and SHA1 to be weak algorithms, and when using its GnuPG OpenPGP backend will configure it explicitly to that effect (given that by default it does not do so), for other OpenPGP backends (such as SOP or Sequoia) this should already be the tools builtin default. > And many of them cannot be verified using debian-keyring: > 2,455 no public key > 3 wrong key usage Did you use all keyrings like dpkg-source or dscverify do? For example one of the first entries in the list, 7zip has a certificate in the debian-maintainers.gpg, I assume many others do too (or the nonupload one). > Lists of affected .dsc are published at > https://people.canonical.com/~xnox/dsc-analysis/ due to size. > > This makes me wonder if signatures on uploaded or published .dsc have any > value at all. > Ultimately one should use apt secure to retrieve both .deb and .dsc; and > verify .changes signature if one wants to figure out authorship. Yes, for the users of an archive, the trust anchor is the archive. And checking the signatures from the .changes file should in general give no better results than the ones from the .dsc. But because the .changes files are not generally published alongside in the archive they are way more cumbersome to obtain (for example who-uploads needs to scrape HTML…). Having signatures in .dsc, even if some might end up expiring, their certificates revoked, or removed from the keyrings, it seems better than not having them at all. > Should we upload sourceful NMU to eliminate SHA1, RIPEMD160, > wrong-key-usage signatures in .dsc? In the end in most cases this will probably just be an indicator that these packages have not been uploaded in a very long time. Having lintian classify them or error or warn would seem appropriate, I could even see a release criteria where source packages that are to be part of a supported release need to have a valid and strong signature, for example. But just uploading to refresh the sigs right now (w/o such criteria) seems a bit pointless, perhaps they should be uploaded as part of a process to get them orphaned instead? > Should we stop requiring signed .dsc on uploads? I think they do have value. You can provides signed .dsc to someone else before an upload (even people that have no certificates in the archive, knowing they cannot upload these), and then the same files will appear on the archive. It is an easy way to check for provenance, and to link the uploader to the archive, even on mirrors, in the same way as upstreams provide signatures for source tarballs, for example, which can also suffer from the same fate. I don't see a strong reason why we'd want to drop them TBH. Thanks, Guillem
