Dear Maintainer,

What led up to the situation? Normal upgrading of system

What exactly did you do (or not do) that was effective (or ineffective)? Unsure
these messages started appearing.

What was the outcome of this action? I now receive multiple lines of: gpgv:
Signature made Fri 24 Oct 2014 06:23:17 PM CDT
gpgv:                using RSA key F664D256B4691A7D
gpgv: Can't check signature: No public key
dpkg-source: warning: cannot verify signature
/var/cache/apt/sources/libtrio_1.16+dfsg1-3.dsc
gpgv: Signature made Tue 03 May 2022 09:04:38 PM CDT
gpgv:                using RSA key A1489FE2AB99A21A
gpgv: Note: signatures using the SHA1 algorithm are rejected
gpgv: Can't check signature: Bad public key
dpkg-source: warning: cannot verify signature /var/cache/apt/sources/r-cran-
quantreg_5.93-1.dsc
gpgv: Signature made Wed 20 Jul 2022 05:25:03 AM CDT
gpgv:                using RSA key A1489FE2AB99A21A
gpgv: Note: signatures using the SHA1 algorithm are rejected
gpgv: Can't check signature: Bad public key
dpkg-source: warning: cannot verify signature /var/cache/apt/sources/r-cran-
quantreg_5.94-1.dsc
apt-listdifferences: removing old src:r-cran-quantreg 5.93-1
gpgv: Signature made Fri 27 May 2022 04:42:52 AM CDT
gpgv:                using RSA key 5F2A9FB82FA6C1E1077007072D191C8843B13F4D
gpgv: Note: signatures using the SHA1 algorithm are rejected
gpgv: Can't check signature: Bad public key
dpkg-source: warning: cannot verify signature
/var/cache/apt/sources/kconfig_5.94.0-3.dsc
gpgv: Signature made Sat 23 Jul 2022 05:20:34 AM CDT
gpgv:                using RSA key 5F2A9FB82FA6C1E1077007072D191C8843B13F4D
gpgv: Note: signatures using the SHA1 algorithm are rejected
gpgv: Can't check signature: Bad public key
dpkg-source: warning: cannot verify signature
/var/cache/apt/sources/kconfig_5.94.0-4.dsc

When running this command `apt-get dist-upgrade -y -m`

What outcome did you expect instead? To be sure I'm getting packages from an
uncompromised repo.

Hi!

I assume you have something installed that downloads source packages
(and perhaps builds them) as part of the upgrade? Otherwise that seems
uncommon. In any case…

… assuming you are getting the source packages from a Debian
repository, those should have the repository mataindices signed by the
archive keys, which get rotated and updated when necessary, in contrast
to the source package signatures which are created by the person uploading
the source package (and never updated anymore). As such those latter
signatures (when later verified after the archive did the initial
verification on upload) can very easily come from now revoked or expired
keys or from keys for people that are no longer members of the project
and are thus not present in the keyrings, the signatures can be expired
themselves, they might come from keys or signatures which are now
considered weak, which is what happens to be the case here. These
signatures use SHA1 as a hashing algorithm which is no longer considered
secure and get rejected.

For the above reasons apt passes --no-check to dpkg-source, and
dpkg-source does not default to erroring out (unless passing to it
--require-valid-signature), as can be seen from the warnings (not
errors) shown above. So I see no dpkg bug here, perhaps whatever is
calling dpkg-source should also be passing --no-check (if it can
guarantee the source came from a verified repo). Otherwise I'll be
closing this in a bit.

Thanks,
Guillem

Hi Guillem,
Gnome Software and I left sources.list pretty much as it came from the
net install CD.
So I'm getting this because some packages no longer have a maintainer,
that sucks, hope you guys get some more maintainers for those projects.
Either way, thanks for the clear explanation of why it's happening and
where the warnings are coming from. 
If it's not really a bug I guess it's okay to close it and sorry for
wasting your time. 
Have a great day! 

Hmm, I've checked gnome-software and I don't see anything obvious there
that would cause sources to be downloaded. After looking for something
using the /var/cache/apt/sources/ pathname, I've found
apt-listdifferences which seems like a matching culprit. Do you happen
to have that installed? If so, the problem is that it calls debdiff,
which always verifies signatures, even though apt-listdifferences
downloaded it from the archive, so there should be no need for that.
Then I'd reassign to apt-listdifferences which would need a new option
in debdiff to be able to request passing --no-check to dpkg-source.

Not necessarily, it might well be that these packages did not get
uploaded after these maintainers updated their OpenPGP keys, and have
remained with weak signatures. We should probably add some QA check
(if there's none yet in place), to catch that, I'll check that out
too.

Thanks,
Guillem

[ Replying to the initial report for some context. ]

Hi!

The problem here in the end was (confirmed off-BTS) that
apt-listdifferences is installed on the system, which downloads the
source packages for binary packages being upgraded to debdiff them.
But those source packages had been signed with a weak algorithm, which
is rejected by dpkg-source (even though that command defaults to
warning only).

Because when downloading the source packages from the archive, they
have switched their trust anchor from the uploader to the archive,
which takes care of key (re)signing, expiration and rotation, checking
the signatures in the .dsc can be more confusing than helpful. (This
would be a different matter if the .dsc reached the system through
some other means such as scp or sneaker net or whatever).

So, ideally apt-listdifferences would call debdiff and request for it
to pass --no-check to dpkg-source. But there is currently no such
option. I'll file another report, and block this one with that other
one.

Thanks,
Guillem

Hi!

The recently uploaded devscripts now includes support for --no-check
in debdiff. So we can use that to fix this report.

Thanks,
Guillem

Hi!

Sorry, and then forgot to attach the actual patch. :/

Thanks,
Guillem