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

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

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               <none>

-- no debconf information
Reply | Threaded
Open this post in threaded view
|

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

David Kalnischkies-4
Hi,

On Sun, May 19, 2019 at 11:37:57PM +0200, Thorsten Glaser wrote:
> 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:

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.


> … 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.


> 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

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

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

Thorsten Glaser
David Kalnischkies dixit:

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

>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
--
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
                                         -- Henry Nelson, March 1999

Reply | Threaded
Open this post in threaded view
|

Bug#929248: changed its 'Suite' value from 'buster' to 'testing' ...

Osamu Aoki
In reply to this post by Thorsten Glaser
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

Reply | Threaded
Open this post in threaded view
|

Bug#929248: changed its 'Suite' value from 'buster' to 'testing' ...

Adam Borowski-3
On Sun, Jul 07, 2019 at 10:34:49PM +0900, Osamu Aoki wrote:
> 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.

> 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".

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...
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ According to recent spams, "all my email accounts are owned
⢿⡄⠘⠷⠚⠋  by a hacker".  So what's the problem?
⠈⠳⣄⠀⠀⠀⠀

Reply | Threaded
Open this post in threaded view
|

Bug#929248: changed its 'Suite' value from 'buster' to 'testing' ...

Julian Andres Klode-4
On Sun, Jul 07, 2019 at 05:26:27PM +0200, Adam Borowski wrote:

> On Sun, Jul 07, 2019 at 10:34:49PM +0900, Osamu Aoki wrote:
> > 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".

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.

>
> 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).

>
> > 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".

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.

--
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
|

Bug#929248: apt: Information hidden how to confirm buster

Helge Kreutzmann-2
In reply to this post by Thorsten Glaser
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:
root@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

--
      Dr. Helge Kreutzmann                     [hidden email]
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

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

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

Julian Andres Klode-4
In reply to this post by Thorsten Glaser
Control: forcemerge 879786 -1

On Sun, May 19, 2019 at 11:37:57PM +0200, Thorsten Glaser wrote:

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

Merging this into the other bug
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en