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