apt-get error - E: Repository 'https://cdn-aws.deb.debian.org/debian buster InRelease' changed its 'Suite' value from 'testing' to 'stable'

[adrelanos]

Reading package lists... Done                                                        
N: Repository 'https://cdn-aws.deb.debian.org/debian buster InRelease' changed its 'Version' value from '' to '10.0'
E: Repository 'https://cdn-aws.deb.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.
E: Repository 'https://cdn-aws.deb.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.

Affects Debian buster and Whonix 15 templates.

Instructions for users (these work alike for any Debian buster and Whonix users):
https://forums.whonix.org/t/apt-get-error-e-repository-tor-https-cdn-aws-deb-debian-org-debian-security-buster-updates-inrelease-changed-its-suite-value-from-testing-to-stable/7704

Solution for upgrading through QVMM? Dunno.

This would likely be fixed in new template builds without code changes required.

[tasket]

FWIW, I fixed this in one template by changing 'buster' to 'stable' in sources.list, performed one update, then changed sources.list back to 'buster'. But adrelanos' workaround is easier and probably more correct.

[unman]

This really isn't a Qubes issue.

The "easier" way for end users updating manually is to use apt - that's what it's designed to do, get rid of the command line options.
A manual apt update will notice the change and prompt user to accept the change.

The only Qubes relevant part of this is the impact on the updater process, which reports success, but none the less fails. It should be possible to drop a config file in /etc/apt/apt.conf.d in an updated salt package, but that seems like overkill to me.

I'll add a note to the docs, and maybe the FAQ.

[andrewdavidwong]

The only Qubes relevant part of this is the impact on the updater process, which reports success, but none the less fails.

Shouldn't the Qubes updater be robust against this sort of thing, though?

[tasket]

Shouldn't the Qubes updater be robust against this sort of thing, though?

Yes, definitely. However, Qubes RPC uses apt-get as does my qubes-multi-update, so users are left with non-updating templates because of pre-release state in the template.

The template in testing is still from June, so I think the Qubes R4.2rc1 release could also have this problem.

The template should be rebuilt or at least updated and then re-issued.

[unman]

Shouldn't the Qubes updater be robust against this sort of thing, though?

No. It isn't a bug, and nor is it an error - neither in Debian nor in Qubes. It's a security mechanism.
We choose to use apt-secure for Debian templates. Apt-secure requires a user to manually accept changes in the repo status - my hope for a config file was misplaced.

The template should be rebuilt or at least updated and then re-issued.

Of course, there isn't a current template available as yet, only testing. And 4.2rc1 does have the testing template, so cant be updated without user intervention.

I've tried to rebuild, but the build server seems to be broken at the moment, which is why we dont have an updated template,( and some packages aren't being pushed from testing to current).
@marmarek knows

[h01ger]

On Wed, Jul 10, 2019 at 07:34:47AM -0700, unman wrote: > Shouldn't the Qubes updater be robust against this sort of thing, though? No. It isn't a bug, and nor is it an error - neither in Debian nor in Qubes. It's a security mechanism.

no, it's a bug in Debian. luckily the workaround is easy, the easiest is just to run 'apt update' and then resolve it manually as prompted. see https://bugs.debian.org/931566 'apt: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")'

…

-- tschau, Holger

------------------------------------------------------------------------------- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[unman]

@h01ger To be picky, that's a feature request isn't it?
The existing treatment is completely in line with the apt-secure documentation.

[h01ger]

On Wed, Jul 10, 2019 at 08:07:24AM -0700, unman wrote: @h01ger To be picky, that's a feature request isn't it? The existing treatment is completely in line with the apt-secure documentation.

well, that's the maintainers view. the release team considers it a serious bugs in buster they want to see fixed.

…

-- tschau, Holger

------------------------------------------------------------------------------- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C "... the premise [is] that privacy is about hiding a wrong. It's not. Privacy is an inherent human right, and a requirement for maintaining the human condition with dignity and respect." (Bruce Schneier)

[unman]

I think we can agree that if Debian introduces that feature we'd incorporate it in to Qubes updater.
Until then, some advice to users.

[tasket]

Regardless of how Debian devs feel about the severity of the bug, they have the luxury of saying "Well, you installed a pre-release version and have an extra step to get it functioning as a full release".

Qubes doesn't have that option, because it shouldn't be distributing templates that are in a pre-release state.... not unless they come from a testing repo. Qubes shouldn't be foisting an unnecessary transition from pre-release to release onto regular users.

[andrewdavidwong]

Ok, so there's some disagreement about whether this is a Debian bug and how we should handle it. @marmarek, I think we need a decision from you about how we'll proceed.

[adrelanos]

Andrew David Wong:

> The only Qubes relevant part of this is the impact on the updater process, which reports success, but none the less fails. Shouldn't the Qubes updater be robust against this sort of thing, though?

I wrote a parser for the "apt-get update" output since apt get has unreliable exit codes (Debian bug report exists) but unlikely to be actioned. https://github.com/Whonix/security-misc/blob/master/usr/lib/security-misc/apt-get-wrapper syntax: /usr/lib/security-misc/apt-get-wrapper update <args>

[marmarek]

I've created PR adding apt-get update --allow-releaseinfo-change call if any list file for buster still contains Suite: testing. It isn't ideal (that option doesn't specify what change exactly should be allowed), but I don't see a better option there.

The PR applies to salt file update, used by "qubes update" application. It doesn't apply to template update started from qubes-manager. Nor manual apt-get update calls.

[tasket]

@marmarek I recommend against any permanent disabling of apt integrity checks.

AFAICT simply re-uploading an updated template would have fixed this issue, at least for the next two years until Debian 11 is released.

[marmarek]

Updated debian-10 templates are already in testing repo. @adrelanos you may want to build new Whonix templates.

[marmarek]

@adrelanos do you want some automatic update method (like PR I created above)? Or just template rebuild? debian-10 templates are still in testing and already rebuilt. Whonix 15 templates are in stable, so this is more visible to the users.

[adrelanos]

Both ok for me. Debian/Qubes package updates are ok. No Whonix updates yet. These are still being tested.

[marmarek]

@adrelanos When would be a good time for new Whonix template builds?
I'd like to have https://github.com/Whonix/whonixsetup/commit/9c6ec0f503c1b381d0e7cd50e465eb491f58447e there, as it's require for automatic tests to work.

[adrelanos]

That change is not yet in stable-proposed or testers repository since some not so well tested changes in other packages are still being worked on in the developers repository. I am good for development, but don't have a good grip on stable/release management / backporting / Q/A. Due to missing https://phabricator.whonix.org/T709 (or similar) it's hard to keep track on singular changes and/or moving packages though suites faster. Specifically also tb-updater should have stable upgrades faster often.

[adrelanos]

@marmarek:

@adrelanos When would be a good time for new Whonix template builds?

Now would be a good time.

Since #4918 (comment) among other fixes and enhancements hit Whonix stable repository today.

[zaoqi]

This issue was fixed

[andrewdavidwong]

Closing this as resolved. If you believe the issue is not yet resolved, or if anyone is still affected by this issue, please leave a comment, and we'll be happy to reopen this. Thank you.

[qubesos-bot]

Automated announcement from builder-github

The component mgmt-salt-dom0-update (including package qubes-mgmt-salt-dom0-update-4.1.7-1.fc32) has been pushed to the r4.1 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component mgmt-salt-dom0-update (including package qubes-mgmt-salt-dom0-update-4.0.11-1.fc25) has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component mgmt-salt-dom0-update (including package qubes-mgmt-salt-dom0-update-4.1.7-1.fc32) has been pushed to the r4.1 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component mgmt-salt-dom0-update (including package qubes-mgmt-salt-dom0-update-4.0.12-1.fc25) has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update