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

Johannes Schauer josch at debian.org
Mon Dec 7 20:13:10 UTC 2015


Hi all,

Quoting Benjamin Drung (2015-12-07 12:37:01)
> Am Donnerstag, den 15.10.2015, 23:54 +0200 schrieb Helmut Grohne:
> > On Wed, Oct 14, 2015 at 06:53:56PM +0200, Helmut Grohne wrote:
> > > 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.
> > 
> > Johannes Schauer asked me to clarify why this change is useful.
> > Currently, every setup of sbuild requires running sbuild-update
> > --keygen. This step is not done from a maintainer script and thus prone
> > to be forgotten. It also takes up to an hour to execute on virtual
> > machines that lack proper random sources.
> > 
> > I am attaching a basic and untested patch that implements the following
> > change: If sbuild fails to find the keys (for instance because
> > sbuild-update --keygen has not been run), it no longer errors out, but
> > adds "[ trusted=yes ]" to the generated sources.list. Thus existing
> > installations (with existing keys) will keep operating like they did and
> > new installations may skip the key generation step. The patch is meant
> > to sketch the desired behaviour.
> 
> Adding cases complicates the code. So why not just change the behavior to
> always use "[ trusted=yes ]"?

with apt's support for [trusted=yes] lines in sources.list I cannot think of a
reason why one would want to sign the internal repository.

Is anybody able to come up with a reason?

Otherwise it might indeed make sense to just never sign that repository. It's a
local file:// repository so there should not be any security problems.

Maybe the signing of the internal repository came from a time where apt didn't
have the trusted=yes option?

It seems that apt has support for trusted=yes since 0.8.16~exp3, so since
wheezy.

Is there any reason to keep support for squeeze?

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20151207/6b1b5db3/attachment.sig>


More information about the Buildd-tools-devel mailing list