[buildd-tools-devel] Bug#801798: please support building package without generating a gpg key for sbuild

[Helmut Grohne]

Package: sbuild
Severity: wishlist

Dear sbuild maintainers,

I would like to be able to use sbuild without having to create a gpg key
for it. I understand that creating a key is required for operating as a
buildd, but sbuild can be used in other scenarios as well. This bug is
supposed to summarize a discussion I had with Johannes Schauer and
Wookey.

The key generated by sbuild is used in a number of places. For one
thing, sbuild's dependency packages (those that encode Build-Depends)
are installed from a signed repository, but the key is also used for
signing the resultant .changes. These uses are somewhat distinct and I
question whether the first use is a good one in the presence of more
recent apt features. In particular, apt understands a "trusted=yes"
option in its sources.list to allow unsigned repositories to be mixed
with signed ones. Since sbuild's repository lives on the local disk, it
should be relatively safe to trust it. In a future apt release, the
simpler "apt-get install somefile.deb" API can be used instead.

Assuming that the only remaining use of sbuilds key would be signing
.changes files, it would be nice if creating that key could be turned
optional as it is a separate setup step. It hinders automation and is
slow to execute on virtual machines.

A quick look indicates that the relevant source lives in
/usr/share/perl5/Sbuild/ResolverBase.pm. There a file:// repository is
added without the suggested "[ trusted=yes ]" annotation. Using this
feature, which was introduced in apt 0.8.16~exp3 in 2011 could even
simplify the code here. The signing certainly was a good solution at the
time it was implemented, but nowadays even wheezy supports
"trusted=yes".

Hope this helps

Helmut