Re: Signature strength of .dsc
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
Reply to: