Dropping Release and Release.gpg support from APT

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Dropping Release and Release.gpg support from APT

Julian Andres Klode-4
So,

we currently have code dealing with falling back from InRelease
to Release{,.gpg} and it's all a bit much IMO. Now that buster
has been released with an InRelease file, the time has IMO come for
us to drop support for the old stuff from APT!

Timeline suggestion
-------------------
now         add a warning to apt 1.9.x for repositories w/o InRelease, but Release{,.gpg}
Aug/Sep     turn the warning into an error, overridable with an option (?)
Q1 2020     remove the code

My idea being that we give this a cycle in the Ubuntu 18.10 stable
release before we drop it, so people are ready for it.

Why remove it?
--------------
* It's annoying UX to have repositories with Release files and the "Ign" lines
* Handling the fallback from InRelease to Release{,.gpg} involves some abstractions
  and logic and the less logic we have in security-relevant file fetching, the better

--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

Reply | Threaded
Open this post in threaded view
|

Re: Dropping Release and Release.gpg support from APT

Steve McIntyre
On Tue, Jul 09, 2019 at 08:53:04PM +0200, Julian Andres Klode wrote:

>So,
>
>we currently have code dealing with falling back from InRelease
>to Release{,.gpg} and it's all a bit much IMO. Now that buster
>has been released with an InRelease file, the time has IMO come for
>us to drop support for the old stuff from APT!
>
>Timeline suggestion
>-------------------
>now         add a warning to apt 1.9.x for repositories w/o InRelease, but Release{,.gpg}
>Aug/Sep     turn the warning into an error, overridable with an option (?)
>Q1 2020     remove the code
>
>My idea being that we give this a cycle in the Ubuntu 18.10 stable
>release before we drop it, so people are ready for it.
>
>Why remove it?
>--------------
>* It's annoying UX to have repositories with Release files and the "Ign" lines
>* Handling the fallback from InRelease to Release{,.gpg} involves some abstractions
>  and logic and the less logic we have in security-relevant file fetching, the better

Can we please slow this kind of change down? We normally look for a
full cycle in Debian stable before making breaking changes. Your
proposed schedule will potentially bite people using stable -
the deprecation warnings will have come and gone.

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"Because heaters aren't purple!" -- Catherine Pitt

Reply | Threaded
Open this post in threaded view
|

Re: Dropping Release and Release.gpg support from APT

Paul Wise via nm
In reply to this post by Julian Andres Klode-4
On Wed, Jul 10, 2019 at 2:53 AM Julian Andres Klode wrote:

> Timeline suggestion
> -------------------
> now         add a warning to apt 1.9.x for repositories w/o InRelease, but Release{,.gpg}
> Aug/Sep     turn the warning into an error, overridable with an option (?)
> Q1 2020     remove the code

I think this timeline is missing a few items:

File bugs/patches on dak, launchpad, reprepro and other repository
creation tools to drop producing Release{,.gpg} (including all the
ones used by derivatives and by prominent external apt repositories
and apt repository services).

Wait for all of those to be fixed.

Add the warnings.

Wait one Debian release cycle.

Change the warnings to errors.

Wait a bit more.

Remove the code.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: Dropping Release and Release.gpg support from APT

Julian Andres Klode-4

On Wed, Jul 10, 2019 at 10:35:25AM +0800, Paul Wise wrote:

> On Wed, Jul 10, 2019 at 2:53 AM Julian Andres Klode wrote:
>
> > Timeline suggestion
> > -------------------
> > now         add a warning to apt 1.9.x for repositories w/o InRelease, but Release{,.gpg}
> > Aug/Sep     turn the warning into an error, overridable with an option (?)
> > Q1 2020     remove the code
>
> I think this timeline is missing a few items:
>
> File bugs/patches on dak, launchpad, reprepro and other repository
> creation tools to drop producing Release{,.gpg} (including all the
> ones used by derivatives and by prominent external apt repositories
> and apt repository services).
>
> Wait for all of those to be fixed.

We don't need them to do that. Repositories can still ship the old
files :)

We do need them to ship InRelease files. I just filed an issue for OBS
to do that. Given how long we had InRelease file, and how confusing it
is to not provide InRelease files (not to mention that it doubles the
traffic for no-change cases), I'm surprised they aren't using InRelease
files yet.

Also like we've been talking about dropping Release.gpg support
and listing the InRelease file as mandatory in the repository format
spec for ages, so this should hardly come as a surprise to anyone.

>
> Add the warnings.
>
> Wait one Debian release cycle.

I don't think it provides a significant benefit - we'll have plenty
of other breakage in 2 years time. Like we started APT 2.0 development,
there is probably quite some more stuff that's going to break. Like
package names might suddenly have a different meaning when we get
patterns or stuff like that (something we do really have to fix, currently
apt install g++7 would install a ton of packages involving gs and a
7 somewhere in their name if there is no g++7). I think InRelease is
the least of our worries.

Basically we have three types of users:

1. The average user, using the debian repo and a bunch of popular
   third-party ones (e.g. spotify, chrome)
2. The power user who builds their own repository
3. Organizations building their own repositories

Let's see how this affects them when they upgrade to bullseye:

1. The average user mostly uses the same third-party repositories
   as an Ubuntu user. Those will be fixed because they've already
   been causing warnings/errors in an Ubuntu stable release.
2. The power user will likely be running testing/unstable and have
   already fixed their repository, or at the very least do so now.
3. The organization will run upgrade tests prior to upgrading, note
   their repositories stopped working, and fix them before rolling
   out the update.

In summary, I do not expect Debian users to be really negatively
impacted by that change.

In any case, we'll see what breaks when we add that in 1.9.x, and
if there's still significant damage left we can potentially extend
the grace period for periods of 3 months or so, but I definitely want
this to be over when bullseye releases.

--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

Reply | Threaded
Open this post in threaded view
|

Re: Dropping Release and Release.gpg support from APT

Philipp Kern-2
On 2019-07-10 10:04, Julian Andres Klode wrote:
> On Wed, Jul 10, 2019 at 10:35:25AM +0800, Paul Wise wrote:
>> On Wed, Jul 10, 2019 at 2:53 AM Julian Andres Klode wrote:
>>
>> > Timeline suggestion
>> > -------------------
>> > now         add a warning to apt 1.9.x for repositories w/o InRelease, but Release{,.gpg}
>> > Aug/Sep     turn the warning into an error, overridable with an option (?)
>> > Q1 2020     remove the code
[...]
> We do need them to ship InRelease files. I just filed an issue for OBS
> to do that. Given how long we had InRelease file, and how confusing it
> is to not provide InRelease files (not to mention that it doubles the
> traffic for no-change cases), I'm surprised they aren't using InRelease
> files yet.

Given the timeline, shouldn't we also get oldstable to ship an InRelease
file?

Kind regards
Philipp Kern

Reply | Threaded
Open this post in threaded view
|

Re: Dropping Release and Release.gpg support from APT

Julian Andres Klode-4
On Wed, Jul 10, 2019 at 10:10:41AM +0200, Philipp Kern wrote:

> On 2019-07-10 10:04, Julian Andres Klode wrote:
> > On Wed, Jul 10, 2019 at 10:35:25AM +0800, Paul Wise wrote:
> > > On Wed, Jul 10, 2019 at 2:53 AM Julian Andres Klode wrote:
> > >
> > > > Timeline suggestion
> > > > -------------------
> > > > now         add a warning to apt 1.9.x for repositories w/o InRelease, but Release{,.gpg}
> > > > Aug/Sep     turn the warning into an error, overridable with an option (?)
> > > > Q1 2020     remove the code
> [...]
> > We do need them to ship InRelease files. I just filed an issue for OBS
> > to do that. Given how long we had InRelease file, and how confusing it
> > is to not provide InRelease files (not to mention that it doubles the
> > traffic for no-change cases), I'm surprised they aren't using InRelease
> > files yet.
>
> Given the timeline, shouldn't we also get oldstable to ship an InRelease
> file?

What's the use case for having oldstable in your sources.list on
unstable/testing machines?

But yes, I think it would make sense to ship an InRelease file
with 9.10 now that we are capable of having those.

--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

Reply | Threaded
Open this post in threaded view
|

Re: Dropping Release and Release.gpg support from APT

Paul Wise via nm
On Wed, Jul 10, 2019 at 4:18 PM Julian Andres Klode wrote:

> What's the use case for having oldstable in your sources.list on
> unstable/testing machines?

I have it in a chdist so that I can look up package versions in old releases.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: Dropping Release and Release.gpg support from APT

Johannes Schauer-3
In reply to this post by Julian Andres Klode-4
Quoting Julian Andres Klode (2019-07-10 10:17:51)
> On Wed, Jul 10, 2019 at 10:10:41AM +0200, Philipp Kern wrote:
> > Given the timeline, shouldn't we also get oldstable to ship an InRelease
> > file?
> What's the use case for having oldstable in your sources.list on
> unstable/testing machines?

If apt in unstable cannot understand oldstable repos anymore, then this will
also mean that unstable systems cannot create oldstable chroots using
multistrap or mmdebstrap anymore.

Thanks!

cheers, josch

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dropping Release and Release.gpg support from APT

Ben Hutchings-3
In reply to this post by Julian Andres Klode-4
On Wed, 2019-07-10 at 10:17 +0200, Julian Andres Klode wrote:

> On Wed, Jul 10, 2019 at 10:10:41AM +0200, Philipp Kern wrote:
> > On 2019-07-10 10:04, Julian Andres Klode wrote:
> > > On Wed, Jul 10, 2019 at 10:35:25AM +0800, Paul Wise wrote:
> > > > On Wed, Jul 10, 2019 at 2:53 AM Julian Andres Klode wrote:
> > > >
> > > > > Timeline suggestion
> > > > > -------------------
> > > > > now         add a warning to apt 1.9.x for repositories w/o InRelease, but Release{,.gpg}
> > > > > Aug/Sep     turn the warning into an error, overridable with an option (?)
> > > > > Q1 2020     remove the code
> > [...]
> > > We do need them to ship InRelease files. I just filed an issue for OBS
> > > to do that. Given how long we had InRelease file, and how confusing it
> > > is to not provide InRelease files (not to mention that it doubles the
> > > traffic for no-change cases), I'm surprised they aren't using InRelease
> > > files yet.
> >
> > Given the timeline, shouldn't we also get oldstable to ship an InRelease
> > file?
>
> What's the use case for having oldstable in your sources.list on
> unstable/testing machines?
I currently have "deb-src ... jessie main" in my sources.list so I can
fetch packages that (might) need a security update.

Obviously I build them in a jessie chroot, but it seems like overkill
to do that for the initial source download too.  And back when I was
doing triage for Debian LTS I wouldn't build at all - I would only look
at the source to see if a bug was present in the old version.

Ben.

> But yes, I think it would make sense to ship an InRelease file
> with 9.10 now that we are capable of having those.
>
--
Ben Hutchings
One of the nice things about standards is that
there are so many of them.



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

unsigned repositories (was: Re: Dropping Release and Release.gpg support from APT)

Julian Andres Klode-4
In reply to this post by Julian Andres Klode-4
On Tue, Jul 09, 2019 at 08:53:04PM +0200, Julian Andres Klode wrote:
> So,
>
> we currently have code dealing with falling back from InRelease
> to Release{,.gpg} and it's all a bit much IMO. Now that buster
> has been released with an InRelease file, the time has IMO come for
> us to drop support for the old stuff from APT!

One thing also forgotten in all that excitement is unsigned
repositories and repositories without a *Release file.

Now, I'd argue that having support for these repositories, while
convenient, is wrong: I think it makes a lot more sense for people
to "needlessly" sign repositories and not have those code paths in
apt. Because if we have a mistake in these code paths and accidentally
don't verify a signature, that's really bad; but if you needlessly
sign a repository, it's hardly much effort.

We can maybe significantly reduce that risk by just providing a
fake gpgv that successfully verifies any file passed and using
that for unsigned repositories instead, and just you know, fake-sign
the repository (like serve an InRelease file without an actual
signature).

I mean, I don't really know, but I always feel a bit scared by
how complex the verification stuff is.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

Reply | Threaded
Open this post in threaded view
|

Re: unsigned repositories

Sam Hartman-3
>>>>> "Julian" == Julian Andres Klode <[hidden email]> writes:

Please carefully consider uses of apt besides the system level apt
running as root installing packages on the system.

What about when I use the apt libraries to explore some repository and
parse its packages files etc.
Asking people to go set up the keys for some of these use cases seems
like a lot of work.

Reply | Threaded
Open this post in threaded view
|

Re: unsigned repositories

Eduard Bloch
Hallo,
* Sam Hartman [Sun, Jul 14 2019, 08:46:18AM]:
> >>>>> "Julian" == Julian Andres Klode <[hidden email]> writes:
>
> Please carefully consider uses of apt besides the system level apt
> running as root installing packages on the system.
>
> What about when I use the apt libraries to explore some repository and
> parse its packages files etc.
> Asking people to go set up the keys for some of these use cases seems
> like a lot of work.

IMHO this could and should be mitigated. I.e. give people a tool they
can work with without studying rocket science, following the spirit of
letsencrypt etc., which handles the snakeoil key handling in a lazy way.

<brainstorming>Something like:

apt-ftparchive ... --auto-sig
(create a new PGP key OR load and use the PGP key with identity of the current
InRelease file; auto-generated key is stored in user's private keyring
and can be extracted with ...)

</>

Best regards,
Eduard.

--
Angela Merkel zitiere ich ja am liebsten wörtlich. Ich hab noch keine
bessere Möglichkeit gefunden, diese Frau zu beleidigen.
                                                    -- Volker Pispers

Reply | Threaded
Open this post in threaded view
|

Re: unsigned repositories

Sam Hartman-3
>>>>> "Eduard" == Eduard Bloch <[hidden email]> writes:

    Eduard> Hallo, * Sam Hartman [Sun, Jul 14 2019, 08:46:18AM]:
    >> >>>>> "Julian" == Julian Andres Klode <[hidden email]> writes:
    >>
    >> Please carefully consider uses of apt besides the system level
    >> apt running as root installing packages on the system.
    >>
    >> What about when I use the apt libraries to explore some
    >> repository and parse its packages files etc.  Asking people to go
    >> set up the keys for some of these use cases seems like a lot of
    >> work.

    Eduard> IMHO this could and should be mitigated. I.e. give people a
    Eduard> tool they can work with without studying rocket science,
    Eduard> following the spirit of letsencrypt etc., which handles the
    Eduard> snakeoil key handling in a lazy way.

Most of the repository generation tools these days do a fairly good job
of signing the release file.
What I'm more worried about is configuring the client apt library in
cases where you are using it for things other than the main apt instance
on the system.

Reply | Threaded
Open this post in threaded view
|

Re: unsigned repositories

Eduard Bloch
Hallo,
* Sam Hartman [Sun, Jul 14 2019, 02:07:55PM]:

> >>>>> "Eduard" == Eduard Bloch <[hidden email]> writes:
>
>     Eduard> Hallo, * Sam Hartman [Sun, Jul 14 2019, 08:46:18AM]:
>     >> >>>>> "Julian" == Julian Andres Klode <[hidden email]> writes:
>     >>
>     >> Please carefully consider uses of apt besides the system level
>     >> apt running as root installing packages on the system.
>     >>
>     >> What about when I use the apt libraries to explore some
>     >> repository and parse its packages files etc.  Asking people to go
>     >> set up the keys for some of these use cases seems like a lot of
>     >> work.
>
>     Eduard> IMHO this could and should be mitigated. I.e. give people a
>     Eduard> tool they can work with without studying rocket science,
>     Eduard> following the spirit of letsencrypt etc., which handles the
>     Eduard> snakeoil key handling in a lazy way.
>
> Most of the repository generation tools these days do a fairly good job
> of signing the release file.

I am looking at this from the POV of a regular/lazy user. The next best
tool here is apt-ftparchive. Does it help you with signing? No. Does its
manpage even mention InRelease signing in any way? Not really.

Therefore, the critical voices in this thread are right - too early to
enforce strict signing.

> What I'm more worried about is configuring the client apt library in
> cases where you are using it for things other than the main apt instance
> on the system.

Understood, but what's the plan? Shouldn't this be another part of the
apt-secure manpage? Showing the user configuration examples for the few
main usecases?

Best regards,
Eduard.

Reply | Threaded
Open this post in threaded view
|

Re: unsigned repositories

Russ Allbery-2
Eduard Bloch <[hidden email]> writes:

> I am looking at this from the POV of a regular/lazy user. The next best
> tool here is apt-ftparchive. Does it help you with signing? No. Does its
> manpage even mention InRelease signing in any way? Not really.

For what it's worth, if I were setting up a small personal repository and
didn't want to deal with configuring reprepro (which I thought was
best-in-class here the last time I surveyed the field), I'd use aptly,
which will do the signing for you and has a pretty simple interface for
adding a new package to the repository.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

Re: unsigned repositories

Jeremy Stanley
In reply to this post by Eduard Bloch
On 2019-07-14 21:23:57 +0200 (+0200), Eduard Bloch wrote:
[...]
> I am looking at this from the POV of a regular/lazy user. The next best
> tool here is apt-ftparchive. Does it help you with signing? No. Does its
> manpage even mention InRelease signing in any way? Not really.
[...]

On that note, I just do:

apt-ftparchive release . | gpg2 --clear-sign --output InRelease

Works great. Would simply adding that to the EXAMPLES section of
apt-ftparchive(1) suffice? It's right in line with the existing
example of a compressed Packages.gz file.
--
Jeremy Stanley

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dropping Release and Release.gpg support from APT

Philipp Kern-2
In reply to this post by Julian Andres Klode-4
On 2019-07-09 20:53, Julian Andres Klode wrote:

> we currently have code dealing with falling back from InRelease
> to Release{,.gpg} and it's all a bit much IMO. Now that buster
> has been released with an InRelease file, the time has IMO come for
> us to drop support for the old stuff from APT!
>
> Timeline suggestion
> -------------------
> now         add a warning to apt 1.9.x for repositories w/o InRelease,
> but Release{,.gpg}
> Aug/Sep     turn the warning into an error, overridable with an option
> (?)
> Q1 2020     remove the code
>
> My idea being that we give this a cycle in the Ubuntu 18.10 stable
> release before we drop it, so people are ready for it.
>
> Why remove it?
> --------------
> * It's annoying UX to have repositories with Release files and the
> "Ign" lines
> * Handling the fallback from InRelease to Release{,.gpg} involves some
> abstractions
>   and logic and the less logic we have in security-relevant file
> fetching, the better

One thing worth noting in case we drop support for generating the files:
It looks like choose-mirror (no bug found) and net-retriever (bug in
[1]) in d-i still use Release and not InRelease. Found by investigating
annoying file races internally that would have been solved by
InRelease...

Kind regards
Philipp Kern

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926035

Reply | Threaded
Open this post in threaded view
|

Re: unsigned repositories

Thorsten Glaser-7
In reply to this post by Julian Andres Klode-4
I actually have a use case: injecting packages from
/var/cache/pbuilder/base.cow-somedist/repo/ into APT
from an optional cowbuilder hook script that I can
enable (chmod +x) when needed.

The hook script has the interesting constraint that
it adds a repository to APT with*out* running apt-get
update, i.e. ceteris paribus, keeping the *other*
repositories’ state as-is and NOT updating them from
the network. I sometimes rely on this.

-----BEGIN cutting here may damage your screen surface-----
#!/bin/bash
# $MirOS: contrib/hosted/tg/deb/hookdir/D01slashrepo,v 1.3 2019/02/24 03:34:00 tg Exp $
#-
# Copyright © 2014, 2018, 2019
# mirabilos <[hidden email]>
#
# Provided that these terms and disclaimer and all copyright notices
# are retained or reproduced in an accompanying document, permission
# is granted to deal in this work without restriction, including un‐
# limited rights to use, publicly perform, distribute, sell, modify,
# merge, give away, or sublicence.
#
# This work is provided “AS IS” and WITHOUT WARRANTY of any kind, to
# the utmost extent permitted by applicable law, neither express nor
# implied; without malicious intent or gross negligence. In no event
# may a licensor, author or contributor be held liable for indirect,
# direct, other damage, loss, or other issues arising in any way out
# of dealing in the work, even if advised of the possibility of such
# damage or existence of a defect, except proven that it results out
# of said person’s immediate fault when using the work as intended.
#-
# Configure $base and $this at the beginning of the file. Do ensure:
# • base must be URI safe since we do not encode it for sources.list
# • this must be a valid basename for sources.list.d: [A-Za-z0-9._-]

base=/repo
this=D01slashrepo


unset LANGUAGE
LC_ALL=C; export LC_ALL

test -d "$base/." || {
        echo >&2 "E: D01slashrepo: base '$base' does not exist"
        exit 1
}

shopt -s extglob
base=${base%%*(/)}
pstr=${base//\//_}_._Packages

echo >&2 "I: creating Packages file for local APT cache in $base"
rm -f "$base/Packages"
(cd "$base"
#dpkg-scanpackages -h md5 -m . >Packages 2>/dev/null || \
    dpkg-scanpackages -m . >Packages 2>/dev/null || \
    dpkg-scanpackages . /dev/null >Packages)
paste -d_ <(sed -n '/^Package: /s///p' "$base/Packages") \
    <(sed -n '/^Version: /s///p' "$base/Packages") \
    <(sed -n '/^Architecture: /s///p' "$base/Packages") | \
    sed 's/^/N: /' >&2
echo >&2 "I: updating APT repository information"
cp "$base/Packages" "/var/lib/apt/lists/$pstr"
if test -d /etc/apt/sources.list.d/.; then
        echo "deb [trusted=yes] file://$base ./" >"/etc/apt/sources.list.d/$this.list"
else
        echo "deb file://$base ./" >>"/etc/apt/sources.list"
fi
apt-cache gencaches
echo >&2 "I: made $(grep -c '^Package: ' "$base/Packages") packages available from $base"
exit 0
-----END cutting here may damage your screen surface-----


It’s also much more convenient for quickly testing the
built packages: having the following snippet…
-----BEGIN cutting here may damage your screen surface-----
#!/bin/sh
cd "$(dirname "$0")"
rm -f Packages* en.gz
#dpkg-scanpackages -h md5 -m . >Packages 2>/dev/null || \
    dpkg-scanpackages -m . >Packages
gzip -n9 <Packages >Packages.gz
(: | gzip -n9 >en.gz)
-----END cutting here may damage your screen surface-----
… in /var/cache/pbuilder/result/0 (for quickly running
it from mc) and the sources.list snippet…
        deb [trusted=yes] file:///var/cache/pbuilder/result ./
… I can test-install stuff just built with an easy
        sudo apt-get update
        sudo apt-get install foo
or even
        sudo apt-get update
        sudo apt-get upgrade
instead of having to do
        sudo apt install /var/cache/pbuilder/result/{pkg1,pkg2,pkg-common}_*.deb
        sudo apt-mark auto pkg2 pkg-common
because installing .deb via apt doesn’t search the rest of
the directory for dependencies and disturbs the auto/manually
installed flag.


Please keep the code and support in APT.

Thanks,
//mirabilos
--
22:20⎜<asarch> The crazy that persists in his craziness becomes a master
22:21⎜<asarch> And the distance between the craziness and geniality is
only measured by the success 18:35⎜<asarch> "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Reply | Threaded
Open this post in threaded view
|

Re: unsigned repositories

Simon McVittie-7
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.

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.

    smcv

Reply | Threaded
Open this post in threaded view
|

Re: unsigned repositories

Johannes Schauer-3
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 (849 bytes) Download Attachment
12