-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keys listed in gpgkey= not used for repo metadata signature verification #528
Comments
I have this problem in zypper 1.14.71 but do not have it in 1.14.68. zypper 1.14.68 # cat /etc/zypp/repos.d/nginx.repo && zypper --version && zypper refs && zypper --gpg-auto-import-keys refresh -r nginx-stable
[nginx]
name=nginx-stable
enabled=1
autorefresh=1
baseurl=https://nginx.org/packages/sles/15/
gpgcheck=1
gpgkey=https://nginx.org/keys/nginx_signing.key
path=/
type=yum
keeppackages=0
zypper 1.14.68
All services have been refreshed.
Looking for gpg key ID 7BD9BF62 in cache /var/cache/zypp/pubkeys.
Looking for gpg key ID 7BD9BF62 in repository nginx-stable.
gpgkey=https://nginx.org/keys/nginx_signing.key
Automatically importing the following key:
Repository: nginx-stable
Key Fingerprint: 573B FD6B 3D8F BC64 1079 A6AB ABF5 BD82 7BD9 BF62
Key Name: nginx signing key <[email protected]>
Key Algorithm: RSA 2048
Key Created: Sat May 25 00:31:01 2024
Key Expires: Tue May 25 00:31:01 2027
Rpm Name: gpg-pubkey-7bd9bf62-6650b2b5
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.
Retrieving repository 'nginx-stable' metadata ...............................................................................[done]
Building repository 'nginx-stable' cache ....................................................................................[done]
Specified repositories have been refreshed. zypper 1.14.71 # cat /etc/zypp/repos.d/nginx.repo && zypper --version && zypper refs && zypper --gpg-auto-import-keys refresh -r nginx-stable
[nginx]
name=nginx-stable
enabled=1
autorefresh=1
baseurl=https://nginx.org/packages/sles/15/
gpgcheck=1
gpgkey=https://nginx.org/keys/nginx_signing.key
path=/
type=yum
keeppackages=0
zypper 1.14.71
All services have been refreshed.
Looking for gpg key ID 7BD9BF62 in cache /var/cache/zypp/pubkeys.
Looking for gpg key ID 7BD9BF62 in repository nginx-stable.
gpgkey=https://nginx.org/keys/nginx_signing.key
Warning: File 'repomd.xml' from repository 'nginx-stable' is signed with an unknown key 'ABF5BD827BD9BF62'.
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: File 'repomd.xml' is the repositories master index file. It ensures the integrity of the
whole repo.
Warning: We can't verify that no one meddled with this file, so it might not be trustworthy
anymore! You should not continue unless you know it's safe.
File 'repomd.xml' from repository 'nginx-stable' is signed with an unknown key 'ABF5BD827BD9BF62'.
Continue? [yes/no] (no):
Retrieving repository 'nginx-stable' metadata ..............................................................................[error]
Repository 'nginx-stable' is invalid.
[nginx|https://nginx.org/packages/sles/15/] Valid metadata not found at specified URL
History:
- Signature verification failed for repomd.xml
Please check if the URIs defined for this repository are pointing to a valid repository.
Skipping repository 'nginx-stable' because of the above error.
Could not refresh the repositories because of errors. |
@jswolf19 to me it looks like the repo is signed with
|
We'll add a message telling why |
@mlandres I'll have to check once I'm in front of a computer, but I think the file has 3 keys. The one used for signing is the second one. Update: yes, ABF5BD827BD9BF62 is the second key in the file. $ curl https://nginx.org/keys/nginx_signing.key | gpg --show-keys --with-fingerprint
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 11809 100 11809 0 0 4438 0 0:00:02 0:00:02 --:--:-- 4437pub rsa4096 2024-05-29 [SC]
8540 A6F1 8833 A80E 9C16 53A4 2FD2 1310 B49F 6B46
uid nginx signing key <[email protected]>
pub rsa2048 2011-08-19 [SC] [expires: 2027-05-24]
573B FD6B 3D8F BC64 1079 A6AB ABF5 BD82 7BD9 BF62
uid nginx signing key <[email protected]>
pub rsa4096 2024-05-29 [SC]
9E9B E90E ACBC DE69 FE9B 204C BCDC D8A3 8D88 A2B3
uid nginx signing key <[email protected]> |
@jswolf19 Sorry, then I'll have to check my script. In any case, there's been an issue with the gpgkey url, but is meanwhile fixed: Please check your libzypp version. If it's older and 17.32.6 fixes it, we can close this as duplicate of #546 |
I'll check tomorrow and get back to you. |
@mlandres Upgrading to libzypp-17.32.6 solves my problem. If it's a url issue, I'm not sure if it solves the original issue, though. The 15.5 repos currently only includes up to libzypp-17.32.5, so I made a temporary repo providing 17.32.6. Any idea if/when that version will be added to the 15.5 update repo? |
@mlandres The issue is not fixed for me, see logs and information below:
|
@jswolf19 it's in the maintenance QA queue for a while now. I can't tell how long it will take. We hat a bunch of submissions lately - up to 17.34.1 yesterday. Maybe they head for one of the newer versions. |
@DaanDeMeyer sorry, but I don't understand the issue. Apparently the repo metadata are signed with 35A2F86E29B700A4. The gpgkey=URL is one of the locations where (the fixed) libzypp tries to find a missing key. But the key was found. You got the message:
But you decided to (r)eject the key. That's why the repo is discarded. The URL just tells where we can find a key, but it's always up to the user to decide whether the key is trustwothy. Either interactively (trust temporarily, or trust always) or via --gpg-auto-import-keys. |
@mlandres I expect zypper to trust keys from There's no point in asking users to trust keys defined with So I would like to be able to tell zypper to only use the local gpg keys defined in |
@DaanDeMeyer No, /etc/zypp/repos.d is IMO not a 'trusted location'. You can add repos by just downloading the .repo file a repository provides. Just like If you have all the keys locally and want to trust just them, you could import them into the rpmdb ( |
Ok, thanks for your help. I'll use my temporary repo for now, then. |
@mlandres Is there a way to tell zypper to not try to read public keys from |
No, but may I ask why not? We know the keyid from the repomd.xml's signature. The keyfiles we find ( repomd.xml.asc or gpgkey= or files in /var/cache/zypp/pubkeys) are imported into a temporary keyring. If the needed key is in the keyring, only this key is exported into the rpm database. We will never import all keys contained in a file. |
@mlandres I have users that have concerns about downloading keys remotely and which would much rather that the key is provided out of band (see systemd/mkosi#757 for the full discussion). They would much rather see mkosi (which uses zypper internally for opensuse) use a model where the keys are installed beforehand and out of band rather than the package manager downloading the keys itself. I'm inclined to agree with them and given that https://pkgs.org/download/distribution-gpg-keys is already somewhat widely packaged, I have an easy way to retrieve the opensuse GPG keys without needing zypper to download them for me from the repository. So it would be great to have a mechanism available where I can tell zypper to only use the keys that I already provide locally and to not download keys itself. |
For your usecase, this would be a new feature. By manually importing these keys into the rpmdb you basically trust them, but nevertheless zypper will download available repomd.xml.key files and import them IF the key is already trusted, but was re-signed to extend the expiry date. Also may a repomd.xml signed by a trusted key define additional key ids which should be imported together with the main key. OpenSUSE Leap AFAIK uses this because at least 2 keys are used to sign the the distribution packages (it's a mix of Leap and SLES packages). Your usecase probably does not want to allow this as well. |
Maybe this is OK in some cases but I would still prefer to be able to block all key downloads completely and to solely rely on local keys |
When I run zypper with gpgkeys listed in gpgkey= in the individual repo files, zypper fails with an error saying it can't verify the repo metadata signature, even though the key that the repository metadata is signed with is listed in gpgkey=.
Version: 1.14.59
Repo file:
Log: https://gist.github.com/DaanDeMeyer/7babbb3adb9464d2ce964a569ed92cde
The text was updated successfully, but these errors were encountered: