Bug#929248: apt: E: Repository # changed its 'Suite' value from 'buster' to 'testing'; but how to accept?

[Thorsten Glaser]

Package: apt
Version: 1.8.0
Severity: normal

(but ought to be release-critical, see last paragraph)


E: Repository 'http://debs.tarent.de buster InRelease' changed its 'Suite' value from 'buster' to 'testing'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

Sure, but the apt-secure(8) manpage is 8 screen pages, and while
I eventually (took me some time) found the right section, it does
not document *how* one would accept this change:

INFORMATION CHANGES
A Release file contains beside the checksums for the files in the
repository also general information about the repository like the
origin, codename or version number of the release.

This information is shown in various places so a repository owner
should always ensure correctness. Further more user configuration like
apt_preferences(5) can depend and make use of this information. Since
version 1.5 the user must therefore explicitly confirm changes to
signal that the user is sufficiently prepared e.g. for the new major
release of the distribution shipped in the repository (as e.g.
indicated by the codename).

Nothing in here shows the correct way, so people will duckduckgo for
answers and likely find things like “sudo chmod 777 somefile” on
ask*buntu, or something…

… for the record, I *believe* that adding --allow-releaseinfo-change
to apt-get update is right, but this appears only in the apt-get(8)
manpage, not in apt(8) which some people believe is the new tool, and
especially not in apt-secure(8) where the user is directed to.

As such, this is a rather severe documentation bug that I believe
ought to be fixed before buster.

-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (/etc/apt/preferences.d/dash-mksh.pref present, but not submitted) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (no /etc/apt/sources.list.d/* present) --


-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages apt depends on:
ii adduser 3.118
ii debian-archive-keyring 2018.1
ii gpgv 2.2.12-1
ii libapt-pkg5.0 1.8.0
ii libc6 2.28-8
ii libgcc1 1:8.3.0-6
ii libgnutls30 3.6.6-2
ii libseccomp2 2.3.3-4
ii libstdc++6 8.3.0-6

Versions of packages apt recommends:
ii ca-bundle [ca-certificates] 20181220tarent1

Versions of packages apt suggests:
pn apt-doc <none>
pn aptitude | synaptic | wajig <none>
ii dpkg-dev 1.19.6
ii gnupg 2.2.12-1
ii gnupg1 1.4.23-1
pn powermgmt-base

[David Kalnischkies]

Hi,

Post by Thorsten Glaser
Sure, but the apt-secure(8) manpage is 8 screen pages, and while
I eventually (took me some time) found the right section, it does

Well, apt-secure manpage is supposed to be generic information for all
APT-based clients. I really don't look forward to describing which
buttons must be clicked to perform this magic in e.g. synaptics and the
gazillion other clients apt and apt-get are just the most prominent of.

Post by Thorsten Glaser

 for the record, I *believe* that adding --allow-releaseinfo-change
to apt-get update is right, but this appears only in the apt-get(8)
manpage, not in apt(8) which some people believe is the new tool, and
especially not in apt-secure(8) where the user is directed to.

1. apt(8) is documented to not document every nook and cranny.
2. "apt" asks an interactive question in this situation,
for "apt-get" this is disabled by default, because, I am told,
people hate changes.
3. the user is directed to "apt-secure" for details on the why,
how to use the client in question is a matter of client manpages
4. The client manpage apt-get(8) indeed mentions the option framed by
the other security related options.

Post by Thorsten Glaser
As such, this is a rather severe documentation bug that I believe
ought to be fixed before buster.

While I might agree the behaviour of apt-get could be more revealing,
I don't think this would belong in apt-secure. I guess we could add
another N: for apt-get, but I haven't looked at where to add that it is
generated only for apt-get not for other clients where that hint would
make no sense as a graphical software center likely doesn't accept that
flag


Or we could babble about the underlying config options like in the
insecure repository case as it would effect all clients then, but that
feels a bit dirty and wrong.


On a sidenote: The Release file can include a "Release-Notes" field
which is then displayed as "More information about this can be found
online in the Release notes at: %s" so that a repository owner can
provide an explanation for this change.


In summary, I don't believe in this being a severe problem. Legit
changes of these fields should be really really rare given we teach
users to use Codename in configuration rather than Suite.


Best regards

David Kalnischkies

[Thorsten Glaser]

Post by David Kalnischkies
While I might agree the behaviour of apt-get could be more revealing,
I don't think this would belong in apt-secure. I guess we could add
another N: for apt-get, but I haven't looked at where to add that it is

That sounds agreeable as well.

Post by David Kalnischkies
On a sidenote: The Release file can include a "Release-Notes" field
which is then displayed as "More information about this can be found
online in the Release notes at: %s" so that a repository owner can
provide an explanation for this change.

Oh, interesting. I may have a look into that.

bye,
//mirabilos

[Osamu Aoki]

Hi,

So I am not the only one ;-)

But why we point people to apt-secure manpage? It was cryptic for me.

Why not simply say:

Probably, a new Debian Stable release has happened as you tried to
update your system. If this is the case, please update "Release-Notes"
field by executing "sudo apt-get --allow-releaseinfo-change update".

Osamu

[Adam Borowski]

Post by Osamu Aoki
But why we point people to apt-secure manpage? It was cryptic for me.

I did not manage to find the information there either. At this moment, I
did intentionally stop -- while I might be not the brightest bulb in the
knife drawer, I believe my ability to read man pages is a wee bit better
than that of an average user. And _those_ will not manage futher research.

My particular question was:
Given a pipeline that's basically:
for x in `lxc-ls --running`;do echo ...;lxc-attach -n "$x" -- apt-get update;done
have apt do its job.

None of the containers in question refer to any codenames that have changed,
thus apt's reluctance to continue is irrelevant or harmful. All of these
referred to either "unstable", "buster" or "stretch". I would understand
your reasoning if I had referred to "stable".

But, it's worse than merely annoying users of unstable and testing. Two
years from now, millions of boxes will have "buster" change to "oldstable",
and, with cron mails currently being null-routed by default, no one will see
that[1]. Thus, a significant part of users will have security updates
suddenly stopped despite nothing relevant to them happening.

And this particular piece deserves a high severity.

Post by Osamu Aoki
Probably, a new Debian Stable release has happened as you tried to
update your system. If this is the case, please update "Release-Notes"
field by executing "sudo apt-get --allow-releaseinfo-change update".

Yes, thank you! This particular bit is what I was looking for in this case.

But, I'm afraid that a documentation change is nowhere near enough.


Meow!

[1]. How many times have you been called to recover a server whose mail
spool has a couple of years of notifications about degraded RAID -- which
then worked until the second disk failed? And so on...

[Julian Andres Klode]

Post by Adam Borowski

Post by Osamu Aoki
But why we point people to apt-secure manpage? It was cryptic for me.

I did not manage to find the information there either. At this moment, I
did intentionally stop -- while I might be not the brightest bulb in the
knife drawer, I believe my ability to read man pages is a wee bit better
than that of an average user. And _those_ will not manage futher research.
for x in `lxc-ls --running`;do echo ...;lxc-attach -n "$x" -- apt-get update;done
have apt do its job.
None of the containers in question refer to any codenames that have changed,
thus apt's reluctance to continue is irrelevant or harmful. All of these
referred to either "unstable", "buster" or "stretch". I would understand
your reasoning if I had referred to "stable".

There are two reasons for these checks:

(1) Your pinning can break (or -t switches in your script)
(2) Your system can accidentally upgrade to a new stable release

In your case, (1) applies.

Post by Adam Borowski
But, it's worse than merely annoying users of unstable and testing. Two
years from now, millions of boxes will have "buster" change to "oldstable",
and, with cron mails currently being null-routed by default, no one will see
that[1]. Thus, a significant part of users will have security updates
suddenly stopped despite nothing relevant to them happening.
And this particular piece deserves a high severity.

Luckily we have about two years to deal with this (well, let's say 18
months or so, gotta give people time to update before the new stable).

Post by Adam Borowski

Post by Osamu Aoki
Probably, a new Debian Stable release has happened as you tried to
update your system. If this is the case, please update "Release-Notes"
field by executing "sudo apt-get --allow-releaseinfo-change update".

You're not supposed to be using apt-get, use apt. We can't tell people to
use that flag or apt-get as they might be using a different frontend -
refering them to the manpage is the best we can do if they insist on
using the apt-get frontend.

[Csillag Tamas]

Hi,

Post by Julian Andres Klode

Post by Adam Borowski
But, it's worse than merely annoying users of unstable and testing. Two
years from now, millions of boxes will have "buster" change to "oldstable",
and, with cron mails currently being null-routed by default, no one will see
that[1]. Thus, a significant part of users will have security updates
suddenly stopped despite nothing relevant to them happening.
And this particular piece deserves a high severity.

Luckily we have about two years to deal with this (well, let's say 18
months or so, gotta give people time to update before the new stable).

fwiw. what Adam predicted is exactly what happened today:

# apt-get update
Get:1 http://security.debian.org buster/updates InRelease [65.4 kB]
Get:2 http://deb.debian.org/debian buster InRelease [122 kB]
Get:3 http://ftp.de.debian.org/debian buster InRelease [122 kB]
Reading package lists... Done
E: Repository 'http://security.debian.org buster/updates InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
E: Repository 'http://deb.debian.org/debian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
E: Repository 'http://ftp.de.debian.org/debian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

100 # cat /etc/debian_version
10.9

why I use apt-get instead of apt you ask?
Because that is what ansible does.

I can solve this for myself, but everyone needs to deal with it on its own.
(I have no idea if other cfg management systems deal with this any better or not)
Looking at the manpages to check if apt-get is deprecated I found that apt-get
is still preferred for scripting in general.

I usually run an ad-hoc command on all hosts with: "apt-get --allow-releaseinfo-change update".
What should ansible do? What is a better solution than running this after every release?

Regards,
cstamas
--

[Adam D. Barratt]

Post by Csillag Tamas
Hi,

Post by Julian Andres Klode

Post by Adam Borowski
But, it's worse than merely annoying users of unstable and
testing. Two
years from now, millions of boxes will have "buster" change to "oldstable",
and, with cron mails currently being null-routed by default, no one will see
that[1]. Thus, a significant part of users will have security updates
suddenly stopped despite nothing relevant to them happening.
And this particular piece deserves a high severity.

Luckily we have about two years to deal with this (well, let's say 18
months or so, gotta give people time to update before the new stable).

# apt-get update
Get:1 http://security.debian.org buster/updates InRelease [65.4 kB]
Get:2 http://deb.debian.org/debian buster InRelease [122 kB]
Get:3 http://ftp.de.debian.org/debian buster InRelease [122 kB]
Reading package lists... Done
E: Repository 'http://security.debian.org buster/updates InRelease'
changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this
repository can be applied. See apt-secure(8) manpage for details.
E: Repository 'http://deb.debian.org/debian buster InRelease' changed
its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this
repository can be applied. See apt-secure(8) manpage for details.
E: Repository 'http://ftp.de.debian.org/debian buster InRelease'
changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this
repository can be applied. See apt-secure(8) manpage for details.
100 # cat /etc/debian_version
10.9

At the risk of asking a possibly silly question, why are you not
running 10.*10*, which was released in June and contained an APT
package that downgraded that particular change to a notice?

Regards,

Adam

[Csillag Tamas]

[...]

Post by Adam D. Barratt

Post by Csillag Tamas
E: Repository 'http://security.debian.org buster/updates InRelease'
changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this
repository can be applied. See apt-secure(8) manpage for details.
E: Repository 'http://deb.debian.org/debian buster InRelease' changed
its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this
repository can be applied. See apt-secure(8) manpage for details.
E: Repository 'http://ftp.de.debian.org/debian buster InRelease'
changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this
repository can be applied. See apt-secure(8) manpage for details.
100 # cat /etc/debian_version
10.9

At the risk of asking a possibly silly question, why are you not
running 10.*10*, which was released in June and contained an APT
package that downgraded that particular change to a notice?

That is a fair question and the reason is:
I have machines auto upgrading and rebooting when they have their uptime over 30
days however this automation was temporary disabled for a few weeks because
I had my wedding.
(It is staggered and made with some ansible and a cronjob.)

If 10.10 fixes apt-get that explains why I see this only on a handful of machines (most are on 10.10).
This also means that indeed the ad-hoc fix should be only needed once and last,
but not for future releases. This is good.

Thanks,
cstamas
--

[Helge Kreutzmann]

Package: apt
Version: 1.8.2
Severity: normal

I added buster a few days ago in my sources.list. Now I get the
following error:
***@samd:~# LC_ALL=C apt-get update
Get:1 http://security.debian.org/debian-security buster/updates InRelease [39.1 kB]
Get:2 http://172.16.18.51:9999/ftp.de.debian.org/debian buster InRelease [118 kB]
Reading package lists... Done
N: Repository 'http://security.debian.org/debian-security buster/updates InRelease' changed its 'Version' value from '' to '10'
E: Repository 'http://security.debian.org/debian-security buster/updates InRelease' changed its 'Suite' value from 'testing' to 'stable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
N: Repository 'http://172.16.18.51:9999/ftp.de.debian.org/debian buster InRelease' changed its 'Version' value from '' to '10.0'
E: Repository 'http://172.16.18.51:9999/ftp.de.debian.org/debian buster InRelease' changed its 'Suite' value from 'testing' to 'stable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

I read apt-secure(8), but it does not say how to accept explcitly
to use buster, i.e. the new stable. It only tells me how to turn the
error in a warning (which I don't want, I want to use this properly).

Now off duckduckgo'ing, what I need to do 


Ok, I found this bug and I belive it is severe.
a) On purpose I did not use "stable" but "buster", so the meaning is clear
b) I explicitly chose to use "buster" before the relase, so that I
would no longer keep tracking "testing" by accident
c) It does not matter, if apt-get is deprecated or not, it only
changes the error.
So either: "This cannot be done with apt-get, use 
"
or explain where the information can befound, actually for apt-get.

The fix described in this bug (apt-get --allow-releaseinfo-change
update) worked for me as well.

-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.1.15 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt depends on:
ii adduser 3.118
ii debian-archive-keyring 2019.1
ii gpgv 2.2.12-1
ii libapt-pkg5.0 1.8.2
ii libc6 2.28-10
ii libgcc1 1:8.3.0-6
ii libgnutls30 3.6.7-4
ii libseccomp2 2.3.3-4
ii libstdc++6 8.3.0-6

Versions of packages apt recommends:
ii ca-certificates 20190110

Versions of packages apt suggests:
ii apt-doc 1.8.2
pn aptitude | synaptic | wajig <none>
ii dpkg-dev 1.19.7
ii gnupg 2.2.12-1
ii gnupg2 2.2.12-1
pn powermgmt-base <none>

-- no debconf information

[Julian Andres Klode]

Control: forcemerge 879786 -1

Post by Thorsten Glaser
Package: apt
Version: 1.8.0
Severity: normal
(but ought to be release-critical, see last paragraph)
E: Repository 'http://debs.tarent.de buster InRelease' changed its 'Suite' value from 'buster' to 'testing'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
Sure, but the apt-secure(8) manpage is 8 screen pages, and while
I eventually (took me some time) found the right section, it does
INFORMATION CHANGES
A Release file contains beside the checksums for the files in the
repository also general information about the repository like the
origin, codename or version number of the release.
This information is shown in various places so a repository owner
should always ensure correctness. Further more user configuration like
apt_preferences(5) can depend and make use of this information. Since
version 1.5 the user must therefore explicitly confirm changes to
signal that the user is sufficiently prepared e.g. for the new major
release of the distribution shipped in the repository (as e.g.
indicated by the codename).
Nothing in here shows the correct way, so people will duckduckgo for
answers and likely find things like “sudo chmod 777 somefile” on
ask*buntu, or something…
… for the record, I *believe* that adding --allow-releaseinfo-change
to apt-get update is right, but this appears only in the apt-get(8)
manpage, not in apt(8) which some people believe is the new tool, and
especially not in apt-secure(8) where the user is directed to.
As such, this is a rather severe documentation bug that I believe
ought to be fixed before buster.

Merging this into the other bug