Bug#790565: pbuilder: support https in MIRRORSITE detection

Mattia Rizzolo mattia at mapreri.org
Fri Jul 3 09:12:46 UTC 2015


On Fri, Jul 03, 2015 at 10:39:52AM +0200, Michael Prokop wrote:
> * Mattia Rizzolo [Fri Jul 03, 2015 at 07:44:19AM +0000]:
> > On Tue, Jun 30, 2015 at 10:54:18AM +0200, Michael Prokop wrote:
> 
> > > pbuilder fails to detect MIRRORSITE if /etc/apt/sources.list
> > > includes only https entries.
> > > Patch attached.
> 
> > Well, that's not enough.
> > I haven't tried, by I'd say having https lines in /etc/apt/sources.list
> > requires apt-transport-https.
> 
> Yes, apt-transport-https is indeed needed and that's what I'm doing
> to set up the build envs:
> 
> | /usr/sbin/cowbuilder --create [,,,] --debootstrapopts --include=apt-transport-https,ca-certificates
> 
> ca-certificates isn't explicitely needed because it seems to be
> pulled in anyway, but maybe we should add it explicitely as well,
> what do you think?

ca-certificates is a recommends of libcurl3-gnutls which is in turn a
dependency of apt-transport-https. the chroots created by pbuilder disable the
automatic installation of recommends, so you explicitly need it, yes.

I'm not super happy about having ca-certificates (and that means openssl) in
chroots, though I guess nobody is going to manually install single certificates
for every host he's going to connect to, and ssl without trusting certs is
useless. What a pain.
Until this is not the default I'm ok, though.

> > so if you really want https being automatically detected and used
> > then you also want to add some conditional things that install
> > apt-transport-https if needed.
> 
> Would it be an option to check for usage of https in $MIRRORSITE
> in /usr/lib/pbuilder/pbuilder-createbuildenv and then extend the
> --include=apt option with apt-transport-https accordingly?

not only -createbuildenv, but also -updatebuildenv. There are already a couple
of cases where the installed packages are extended.
And I think we also want to check for https in the chroot's
/etc/apt/sources.list in -updatebuildenv, since a user might have add entries
by hand and now he wants to use them.

But, umh, this is going to be a bit tricky because the first `apt-get update`
is going to fail due to the missing apt-transport-https, and the EXTRAPACKAGES
check is done after that.

Only now I see that you're explicitely installing them in the debootstrap
phase, and not after, e.g. adding them to the EXTRAPACKAGES conf entry. umh.
And as you can read in the comment above the debootstrap invocation (even if
that would mean ignoring the --update use case), adding packages with --include
is not safe from our pov, so that's not really as easy as I first thought.


Please have a look at those two scripts and try to see if you can think of a
clean solution for this :)


-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540         .''`.
more about me:  http://mapreri.org                                 : :'  :
Launchpad user: https://launchpad.net/~mapreri                     `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia     `-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pbuilder-maint/attachments/20150703/47b2b46b/attachment-0001.sig>


More information about the Pbuilder-maint mailing list