Re: Dropping Release and Release.gpg support from APT
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
unsigned repositories (was: Re: Dropping Release and Release.gpg support from APT)
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
Re: Dropping Release and Release.gpg support from APT
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
Description: This is a digitally signed message part
Re: Dropping Release and Release.gpg support from APT
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 Description: signature
Re: Dropping Release and Release.gpg support from APT
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
Re: Dropping Release and Release.gpg support from APT
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
Re: Dropping Release and Release.gpg support from APT
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
Re: Dropping Release and Release.gpg support from APT
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
Re: Dropping Release and Release.gpg support from APT
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
Re: Dropping Release and Release.gpg support from APT
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.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt
Dropping Release and Release.gpg support from APT
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
Re: dists/etch/Release.gpg missing from DVD images
Hi Is it still the case that one needs to manually add an (gpg checking) exception for DVD images for upgrades from etch to lenny? If so, can someone please provide a text (license: GPL v2) for inclusion in the release notes? Thanks already. Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dists/etch/Release.gpg missing from DVD images
On Sat, Oct 04, 2008 at 05:53:22PM +0200, Luk Claes wrote: Is it still the case that one needs to manually add an (gpg checking) exception for DVD images for upgrades from etch to lenny? If so, can someone please provide a text (license: GPL v2) for inclusion in the release notes? Yes, I think so. You need the APT option APT::Authentication::TrustCDROM true; Debian Installer adds this since Sarge in /etc/apt/apt.conf.d/00trustcdrom IIRC. Nevertheless there is no way I know to have this working also with CD/DVD image files instead of using CD/DVDs registered with apt-cdrom. And I also noticed during my last upgrade that unsigned packages provided via loopback devices are ignored if another APT source with signed packages (even from a very slow network mirror) are available. Jens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dists/etch/Release.gpg missing from DVD images
Jens Seidel wrote: On Sat, Oct 04, 2008 at 05:53:22PM +0200, Luk Claes wrote: Is it still the case that one needs to manually add an (gpg checking) exception for DVD images for upgrades from etch to lenny? If so, can someone please provide a text (license: GPL v2) for inclusion in the release notes? Yes, I think so. You need the APT option APT::Authentication::TrustCDROM true; Debian Installer adds this since Sarge in /etc/apt/apt.conf.d/00trustcdrom IIRC. Nevertheless there is no way I know to have this working also with CD/DVD image files instead of using CD/DVDs registered with apt-cdrom. And I also noticed during my last upgrade that unsigned packages provided via loopback devices are ignored if another APT source with signed packages (even from a very slow network mirror) are available. Does apt-cdrom take care of setting that option? Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Problems verifying release.gpg
Hi, I'm having trouble verifying release.gpg for Unstable. Has the release key been changed to 30B34DD5, am I doing something wrong or what's up? After apt-secure failed to apt-get update today... Err http://ftp.fi.debian.org unstable Release The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 2DB1C72530B34DD5 ...I tried to verify the signature myself. However, it failed as well: supertiger:~/test$ wget http://ftp.fi.debian.org/debian/dists/unstable/Release --17:48:00-- http://ftp.fi.debian.org/debian/dists/unstable/Release = `Release' Resolving ftp.fi.debian.org... 130.230.54.99 Connecting to ftp.fi.debian.org[130.230.54.99]:80... connected. HTTP request sent, awaiting response... 200 OK Length: 34,068 [text/plain] 100%[] 34,068--.--K/s 17:48:00 (303.83 KB/s) - `Release' saved [34068/34068] supertiger:~/test$ wget http://ftp.fi.debian.org/debian/dists/unstable/ Release.gpg --17:48:06-- http://ftp.fi.debian.org/debian/dists/unstable/Release.gpg = `Release.gpg' Resolving ftp.fi.debian.org... 130.230.54.99 Connecting to ftp.fi.debian.org[130.230.54.99]:80... connected. HTTP request sent, awaiting response... 200 OK Length: 197 [text/plain] 100%[] 197 --.--K/s 17:48:06 (1.88 MB/s) - `Release.gpg' saved [197/197] supertiger:~/test$ mv Release.gpg Release.asc supertiger:~/test$ gpg --no-default-keyring --keyring=./test-ring.gpg --keyserver the.earth.li --recv-keys 38C6029A gpg: keyring `./test-ring.gpg' created gpg: key 38C6029A: public key Debian Archive Automatic Signing Key (2003) [EMAIL PROTECTED] imported gpg: Total number processed: 1 gpg: imported: 1 supertiger:~/test$ gpg --keyring=./test-ring.gpg --verify Release.asc gpg: Signature made Fri Dec 5 22:42:16 2003 EET using DSA key ID 30B34DD5 gpg: Can't check signature: public key not found
Re: Problems verifying release.gpg
I'm having trouble verifying release.gpg for Unstable. Has the release key been changed to 30B34DD5 Ah, so it has. I just found the announcement which had been filtered to a wrong mail folder by accident. Sorry. - Jarno
Release.gpg
Hi! Is there a reason why the Release.gpg files for testing and unstable are empty? I'm using the Wichert's script to check the integrity of the local mirror, but at the moment this is not possible because auf the missing signature. Jan
Re: Release.gpg
Previously Jan Niehusmann wrote: I'm using the Wichert's script to check the integrity of the local mirror, but at the moment this is not possible because auf the missing signature. I never wrote such a script as far as I know :) Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: Release.gpg
On Mon, Jan 14, 2002 at 03:30:45PM +0100, Jan Niehusmann wrote: I'm using the Wichert's script to check the integrity of the local Sorry, wrong attribution - of course, the script is written by Anthony Towns.
Re: Release.gpg
Jan Niehusmann wrote: Hi! Is there a reason why the Release.gpg files for testing and unstable are empty? A bug on your end of the pipe? auric!joey(pts/0):/org/ftp.debian.org/incoming l `locate Release.gpg` -rw-r--r--1 ajt Debian240 Dec 17 21:11 /home/ajt/bleh/Release.gpg -rw-r--r--1 ajt debadmin 480 Jan 14 10:28 /org/ftp.debian.org/ftp/dists/potato-proposed-updates/Release.gpg -rw-rw-r--1 ajt debadmin 480 Jan 12 12:08 /org/ftp.debian.org/ftp/dists/potato/Release.gpg -rw-r--r--1 ajt debadmin 480 Jan 14 10:28 /org/ftp.debian.org/ftp/dists/sid/Release.gpg -rw-r--r--1 ajt debadmin 480 Jan 14 10:28 /org/ftp.debian.org/ftp/dists/woody-proposed-updates/Release.gpg -rw-r--r--1 ajt debadmin 480 Jan 14 10:28 /org/ftp.debian.org/ftp/dists/woody/Release.gpg -rw-r--r--1 ajt debadmin 480 Jan 14 10:28 /org/ftp.debian.org/ftp/project/experimental/Release.gpg These files don't look too empty to me... Regards, Joey PS: could you send me the script via private mail? Would save me some research time. Thanks. -- The only stupid question is the unasked one. Please always Cc to me when replying to me on the lists.
Re: Release.gpg
On Mon, Jan 14, 2002 at 05:51:39PM +0100, Martin Schulze wrote: Jan Niehusmann wrote: Is there a reason why the Release.gpg files for testing and unstable are empty? A bug on your end of the pipe? auric!joey(pts/0):/org/ftp.debian.org/incoming l `locate Release.gpg` [...] -rw-r--r--1 ajt debadmin 480 Jan 14 10:28 /org/ftp.debian.org/ftp/dists/woody/Release.gpg [...] But: bash-2.05a$ ncftp ftp.debian.org NcFTP 3.1.1 (Dec 23, 2001) by Mike Gleason ([EMAIL PROTECTED]). Connecting to 128.101.36.192... saens.debian.org FTP server (vsftpd) Logging in... Login successful. Have fun. Sorry, I don't do help. Logged in to ftp.debian.org. Current remote directory is /debian/dists/testing. ncftp /debian/dists/testing ls -l *.gpg -rw-r--r-- 77 1176 11760 Jan 13 22:53 Release.gpg This does look empty... but perhaps the problem has already been fixed and the files only needs to propagate to the mirrors. Jan
Re: Release.gpg
On Mon, Jan 14, 2002 at 03:30:45PM +0100, Jan Niehusmann wrote: Is there a reason why the Release.gpg files for testing and unstable are empty? Yes, 'twas a bug on ftp-master. I created and added the 2002 key the other day, and tested it, but neglected to ensure the permissions were correct so that the daily dinstall cronjob could use the keys (apparently gpg likes removing group read access to secret keyrings...). It should be fixed in today's mirror run, depending on when that is for you. Note that the 2001 key expires in a day or two. The 2002 key is available from http://ftp-master.debian.org/ziyi_key_2002.asc and should be signed by both me and the 2001 key. Its key id is 1024D/722F1AED (and 4096g/D9A900D4), and the fingerprint is 8FD4 7FF1 AA93 72C3 7043 DC28 AA7D EB7B 722F 1AED. It expires mid January in 2003. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. The daffodils are coming. Are you? linux.conf.au, February 2002, Brisbane, Australia --- http://linux.conf.au/ pgp8pIt7j2EQ2.pgp Description: PGP signature
