Hi, with my sbuild-maintainer-hat on I would also like to vehemently argue against apt dropping support for unsigned repositories.
Quoting Simon McVittie (2019-07-29 09:01:47) > On Mon, 29 Jul 2019 at 00:17:17 +0000, Thorsten Glaser wrote: > > echo "deb [trusted=yes] file://$base ./" > > >"/etc/apt/sources.list.d/$this.list" > > sbuild and autopkgtest (and probably other build/CI tools) also rely on > being able to inject local packages into a build/test environment using a > [trusted=yes] apt repository. > > Older versions of both sbuild and autopkgtest set up a temporary GPG key, > signed the repository and marked the GPG key as trusted, but this was slow > (particularly because it consumed entropy from /dev/random) and not very > robust. Newer versions mark an unsigned repository as [trusted=yes] instead > and are faster and more reliable as a result. I agree with Simon on all accounts. Having to sign gpg archive caused multiple problems for sbuild. Grep [1] for "gpg" for evidence. After LTS support for squeeze ended, we finally were able to remove a few hundred lines of code from sbuild that was dealing with gpg and the pesky agent that needed to be killed plus all the workarounds for supporting gpg2. I would love to keep the current simplicity without having to deal with multiple gpg versions on the host and inside the chroot across multiple Debian releases. There is also the senseless waste of CPU cycles to generate the key (please lets try not to waste energy) and the required entropy which is problematic for containers or other systems with low entropy (raspberry pi). See bugs #801798 and #607945. Lastly, sbuild now finally supports building packages in a chroot that only has Essential:yes packages and apt installed in it. If we need to sign repositories again, then we either have to drop this feature or add more complexity again to handle the signing outside the chroot. > Both sbuild and autopkgtest are designed to target multiple Debian releases > including the oldest release that still attracts uploads (currently jessie, > for LTS), so relying on "apt-get install --with-source" is undesirable. > sbuild also uses aptitude instead of apt (for its more-backports-friendly > resolver) in some configurations, and that doesn't have --with-source. Yes. In sbuild we also cannot use other apt features like "apt-get build-dep" because sbuild allows one to mangle the build dependencies, so it works with dummy packages. So sbuild will have to keep creating its own repository. Thanks! cheers, josch [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;src=sbuild
signature.asc
Description: signature
