Implement zypper refresh functionality (new signing key)
Closed this issue · 4 comments
After not having used a MicroOS VM for a long time, it didn't want to update anymore because of invalid repositories, repomd.xml couldn't be accessed. After some digging, it turned out that I had to run sudo transactional-update run zypper refresh to regain access to the Tumbleweed repositories. Running sudo zypper refresh revealed that a new key had to be imported, but of course I had to use transactional-update to actually do this.
It would be neat if this process could be automated so that transactional-update doesn't simply refuse to update the system. For example, if there's problems with accessing a repository, zypper refresh could be called. This way, users don't have to deal with finding out why the update process is not working as expected. MicroOS is intended to be reliable and self-updating after all.
I am not sure about the security implications of this though, it would be nice to have someone more knowledgable comment on this idea.
The issue came back, for some reason. Now I can provide logs.
admin@nitrogen:~> sudo transactional-update dup
Checking for newer version.
Repository 'openSUSE-Tumbleweed-Non-Oss' is invalid.
[repo-non-oss|http://download.opensuse.org/tumbleweed/repo/non-oss/] Valid metadata not found at specified URL
History:
- Signature verification failed for repomd.xml
- Can't provide /repodata/repomd.xml
Please check if the URIs defined for this repository are pointing to a valid repository.
Repository 'openSUSE-Tumbleweed-Oss' is invalid.
[repo-oss|http://download.opensuse.org/tumbleweed/repo/oss/] Valid metadata not found at specified URL
History:
- Signature verification failed for repomd.xml
- Can't provide /repodata/repomd.xml
Please check if the URIs defined for this repository are pointing to a valid repository.
Some of the repositories have not been refreshed because of an error.
transactional-update 4.3.0 started
Options: dup
Separate /var detected.
2023-07-18 18:12:07 tukit 4.3.0 started
2023-07-18 18:12:07 Options: -c79 open
2023-07-18 18:12:08 Using snapshot 79 as base for new snapshot 80.
2023-07-18 18:12:08 Syncing /etc of previous snapshot 78 as base into new snapshot "/.snapshots/80/snapshot"
2023-07-18 18:12:08 SELinux is enabled.
ID: 80
2023-07-18 18:12:10 Transaction completed.
Calling zypper --no-cd dup
zypper: nothing to update
Removing snapshot #80...
2023-07-18 18:12:16 tukit 4.3.0 started
2023-07-18 18:12:16 Options: abort 80
2023-07-18 18:12:19 Discarding snapshot 80.
2023-07-18 18:12:19 Transaction completed.
transactional-update finished
In case it's relevant:
admin@nitrogen:~> zypper repos
Die Repository-Prioritäten sind ohne Effekt. Alle aktivierten Repositorys teilen sich die gleiche Priorität.
# | Alias | Name | Enabled | GPG Check | Refresh
--+-----------------------------+-----------------------------+-----------+-----------------+---------------
1 | openSUSE-MicroOS-20220609-0 | openSUSE-MicroOS-20220609-0 | Ja | (r ) Ja | Nein
2 | repo-debug | openSUSE-Tumbleweed-Debug | Nein | ---- | ----
3 | repo-non-oss | openSUSE-Tumbleweed-Non-Oss | Ja | (r ) Ja | Ja
4 | repo-oss | openSUSE-Tumbleweed-Oss | Ja | (r ) Ja | Ja
5 | repo-source | openSUSE-Tumbleweed-Source | Nein | ---- | ----
6 | repo-update | openSUSE-Tumbleweed-Update | Ja | (r ) Ja | Ja
Running zypper refresh shows that a new signing key has to be imported:
admin@nitrogen:~> sudo zypper refresh
Repository 'openSUSE-MicroOS-20220609-0' ist aktuell.
Neuen Signierungsschlüssel für Repository oder Paket erhalten:
Repository: openSUSE-Tumbleweed-Non-Oss
Schlüssel-Fingerabdruck: AD48 5664 E901 B867 051A B15F 35A2 F86E 29B7 00A4
Name des Schlüssels: openSUSE Project Signing Key <opensuse@opensuse.org>
Schlüsselalgorithmus: RSA 4096
Schlüssel erstellt: Mo 20 Jun 2022 14:03:14 UTC
Ablauf des Schlüssels: Fr 19 Jun 2026 14:03:14 UTC
RPM-Name: gpg-pubkey-29b700a4-62b07e22
Hinweis: Das Signieren von Daten ermöglicht dem Empfänger die Überprüfung, ob nach dem Signieren
Änderungen an den Daten vorgenommen wurden. Das Akzeptieren von Paketen mit falscher Prüfsumme
kann zu einem beschädigten System führen und in Extremfällen auch zu einer Systemgefährdung.
Hinweis: Ein öffentlicher GPG-Schlüssel wird durch seinen Fingerabdruck eindeutig identifiziert.
Verlassen Sie sich nicht auf den Namen des Schlüssels. Wenn Sie nicht sicher sind, ob der
dargestellte Schlüssel authentisch ist, fragen Sie den Anbieter des Repositorys oder sehen Sie
auf seiner Website nach. Viele Anbieter besitzen eine Webseite, auf der die Fingerabdrücke der
von ihnen verwendeten GPG-Schlüssel angezeigt werden.
Wollen Sie den Schlüssel abweisen, ihm temporär oder immer vertrauen? [a/t/i/?] (a): ^C
admin@nitrogen:~> sudo transactional-update shell
Checking for newer version.
Repository 'openSUSE-Tumbleweed-Non-Oss' is invalid.
[repo-non-oss|http://download.opensuse.org/tumbleweed/repo/non-oss/] Valid metadata not found at specified URL
History:
- Signature verification failed for repomd.xml
- Can't provide /repodata/repomd.xml
Please check if the URIs defined for this repository are pointing to a valid repository.
Repository 'openSUSE-Tumbleweed-Oss' is invalid.
[repo-oss|http://download.opensuse.org/tumbleweed/repo/oss/] Valid metadata not found at specified URL
History:
- Signature verification failed for repomd.xml
- Can't provide /repodata/repomd.xml
Please check if the URIs defined for this repository are pointing to a valid repository.
Some of the repositories have not been refreshed because of an error.
transactional-update 4.3.0 started
Options: shell
Separate /var detected.
2023-07-18 18:16:37 tukit 4.3.0 started
2023-07-18 18:16:37 Options: -c79 open
2023-07-18 18:16:38 Using snapshot 79 as base for new snapshot 80.
2023-07-18 18:16:38 Syncing /etc of previous snapshot 78 as base into new snapshot "/.snapshots/80/snapshot"
2023-07-18 18:16:38 SELinux is enabled.
ID: 80
2023-07-18 18:16:40 Transaction completed.
Opening chroot in snapshot 80, continue with 'exit'
2023-07-18 18:16:40 tukit 4.3.0 started
2023-07-18 18:16:40 Options: call 80 bash
2023-07-18 18:16:42 Executing `bash`:
transactional update # zypper refresh
Repository 'openSUSE-MicroOS-20220609-0' is up to date.
New repository or package signing key received:
Repository: openSUSE-Tumbleweed-Non-Oss
Key Fingerprint: AD48 5664 E901 B867 051A B15F 35A2 F86E 29B7 00A4
Key Name: openSUSE Project Signing Key <opensuse@opensuse.org>
Key Algorithm: RSA 4096
Key Created: Mon Jun 20 14:03:14 2022
Key Expires: Fri Jun 19 14:03:14 2026
Rpm Name: gpg-pubkey-29b700a4-62b07e22
Note: Signing data enables the recipient to verify that no modifications occurred after the data
were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system
and in extreme cases even to a system compromise.
Note: A GPG pubkey is clearly identified by its fingerprint. Do not rely on the key's name. If
you are not sure whether the presented key is authentic, ask the repository provider or check
their web site. Many providers maintain a web page showing the fingerprints of the GPG keys they
are using.
Do you want to reject the key, trust temporarily, or trust always? [r/t/a/?] (r): a
Retrieving repository 'openSUSE-Tumbleweed-Non-Oss' metadata ............................................................................................................................................................................................[done]
Building repository 'openSUSE-Tumbleweed-Non-Oss' cache .................................................................................................................................................................................................[done]
Retrieving repository 'openSUSE-Tumbleweed-Oss' metadata ................................................................................................................................................................................................[done]
Building repository 'openSUSE-Tumbleweed-Oss' cache .....................................................................................................................................................................................................[done]
Repository 'openSUSE-Tumbleweed-Update' is up to date.
All repositories have been refreshed.
transactional update # exit
exit
2023-07-18 18:18:05 Application returned with exit status 0.
2023-07-18 18:18:05 Transaction completed.
2023-07-18 18:18:05 tukit 4.3.0 started
2023-07-18 18:18:05 Options: close 80
2023-07-18 18:18:08 New default snapshot is #80 (/.snapshots/80/snapshot).
2023-07-18 18:18:08 Transaction completed.
Please reboot your machine to activate the changes and avoid data loss.
New default snapshot is #80 (/.snapshots/80/snapshot).
transactional-update finished
This time, I used the shell to manually approve the new signing key. Just running the command via transactional-update run zypper refresh worked for one update, but then there were problems again. It works now and I don't see why it would stop working again soon.
Still, I would appreciate some kind of automation or at least a prompt for importing the new key as it wasn't obvious what was causing the problem of not being able to update.
In this case the reason may be: If the last time the VM was booted was before the new key was rolled out (which was probably end of last year), then the new key indeed has to be accepted manually because it is indeed an unknown key now.
In general it's also possible to auto-accept keys, but that would require setting https://kubic.opensuse.org/documentation/man-pages/transactional-update.conf.5.html#ZYPPER_AUTO_IMPORT_KEYS.
However we had another case on ARM where the automatic key update seems to have failed even though the machine was online during that timeframe. Investigating...
You're probably right. I didn't think of checking the man page, that's on me.
It's nice to know that the functionality is there and it makes sense that it would be turned off by default.
If this really just happens to installations that have been offline for a very long time, I think this behaviour is acceptable. A heads-up that a new key has to be imported in order to make updates work again instead of simply failing when running transactional-update dup would be nice though.
The issue on the ARM machine couldn't be reproduced any more either, closing...