Bugzilla – Bug 1045735
VUL-0: CVE-2017-9269: libzypp: Missing key pinning allows mirrors to exchange content undetected
Last modified: 2020-06-27 19:39:11 UTC
Reported by Moritz Duge and Till Doerges from PRESENSE === (3) spoofing (replacing signed with unsigned repo) === You can probably also do this by modifying your /etc/hosts or adding IP routes. I did it by setting up an own mirror server. After successfully setting up a mirror server for http://download.opensuse.org/update/leap/42.2/oss/ I changed my YaST/Zypper to use my mirror instead. Installing packages from my mirror worked fine. No manipulations until now! Maybe this is of no importance, but I used /update/leap/42.2/oss/ because it has a directory structure like what comes out of "createrepo". The structure of the distribution-oss repo is slightly different. http://download.opensuse.org/distribution/leap/42.2/repo/oss/ Then I replaced the mirror directory on the mirror with the repository from step (2). After this YaST didn't refreshed the repository by itself. It still showed the old package list. I'm not sure if that would have happened automatically after a few hours or if there's any way to enforce a refresh by the server. So I had to run this on my client: zypper clean -a (again: no warning) Afterwards installing "vim" got me that modified package from the mirror server. No warnings! ================= The repository in step 2 was created like this: mkdir -p ~/testrepo/repodata/ mkdir -p ~/testrepo/rpm/ Then a unsigned, self generated rpm was place in ~/testrepo/rpm createrepo ~/testrepo/ We need to ensure that signed repos can't be "downgraded" to unsigned repos. So this allows any mirror to change the content and potentially infecting users of these repos with arbitrary code.
CRD still under discussion.
Credit: Discovered by Till Dörges and Moritz Duge of PRESENSE Technologies CRD: 2017-07-20 14:00 UTC
While we're at changing how zypper handles things another report by them: > Bottom line (AFAICT): zypper accepts unsigned packages in its cache. > > I haven't gotten around to creating a (simple) reproducer. And perhaps this will also > be fixed by the fixes for issues #2 and #3 from above. Here's a relatively simple way (even though it requires kiwi) to reproduce what I tried to describe above. Following these steps, you can make zypper accept a package into its cache even though the GPG signature check of the package failed. All tests were done on this system with all the latests patches installed: --- snip --- $ lsb-release -a LSB Version: n/a Distributor ID: openSUSE project Description: openSUSE Leap 42.2 Release: 42.2 Codename: n/a $ uname -a Linux loderunner 4.4.72-18.12-default #1 SMP Mon Jun 19 14:11:41 UTC 2017 (9c03296) x86_64 x86_64 x86_64 GNU/Linux --- snap --- Prerequisites (install latest kiwi etc., execute kiwi 1st stage): --- snip --- zypper ar http://download.opensuse.org/repositories/Virtualization:/Appliances:/Builder/openSUSE_Leap_42.2/Virtualization:Appliances:Builder.repo zypper in python3-kiwi kiwi-tools git git clone https://github.com/SUSE/kiwi-descriptions # sigs are not checked (yet) grep rpm-check ./kiwi-descriptions/suse/x86_64/suse-leap-42.2-JeOS/config.xml # make sure we actually check signatures sed -i.orig \ -e 's;<rpm-check-signatures>.*</rpm-check-signatures>;<rpm-check-signatures>true</rpm-check-signatures>;' \ ./kiwi-descriptions/suse/x86_64/suse-leap-42.2-JeOS/config.xml # sigs are checked now grep rpm-check ./kiwi-descriptions/suse/x86_64/suse-leap-42.2-JeOS/config.xml rm -rf --one-file-system kiwisharedcache kiwidestdir mkdir {kiwisharedcache,kiwidestdir} rm -rf --one-file-system kiwirootdir kiwi --debug --logfile ./kiwi.1.log --shared-cache-dir=kiwisharedcache system prepare --description=./kiwi-descriptions/suse/x86_64/suse-leap-42.2-JeOS --root=kiwirootdir --signing-key=/usr/lib/rpm/gnupg/keys/gpg-pubkey-3dbdc284-53674dd4.asc --- snap --- Up to here everything behaves as expected. And if you called the 2nd kiwi stage like this, everything would still be fine: --- snip --- kiwi --debug --logfile=./kiwi.2.log --shared-cache-dir=kiwisharedcache --type=iso system create --root=kiwirootdir --target-dir=kiwidestdir --signing-key=/usr/lib/rpm/gnupg/keys/gpg-pubkey-3dbdc284-53674dd4.asc --- snap --- However, if you omit the --signing-key option and call kiwi like this: --- snip --- kiwi --debug --logfile=./kiwi.2.log --shared-cache-dir=kiwisharedcache --type=iso system create --root=kiwirootdir --target-dir=kiwidestdir --- snap --- you'll get an error (still everything's fine): --- snip --- [ DEBUG ]: 22:30:02 | bootstrap: Retrieving: adaptec-firmware-1.35-25.2.noarch.rpm [done] [ DEBUG ]: 22:30:02 | bootstrap: adaptec-firmware-1.35-25.2.noarch.rpm: [ DEBUG ]: 22:30:02 | bootstrap: Header V3 RSA/SHA256 Signature, key ID 3dbdc284: NOKEY [ DEBUG ]: 22:30:02 | bootstrap: V3 RSA/SHA256 Signature, key ID 3dbdc284: NOKEY [ DEBUG ]: 22:30:02 | bootstrap: Abort, retry, ignore? [a/r/i] (a): a [ INFO ]: Processing: [########################################] 100% [ ERROR ]: 22:30:02 | KiwiBootStrapPhaseFailed: Bootstrap package installation failed: adaptec-firmware-1.35-25.2.noarch (de36b9be105dc4782ce19db6c895bded): Signature verification failed [4-Signatures public key is not available] --- snap --- *but* now adaptec-firmware-1.35-25.2.noarch.rpm has been placed in the cache (this is where things break): --- snip --- find . -iname adaptec-firmware-1.35-25.2.noarch.rpm ./kiwisharedcache/packages/de36b9be105dc4782ce19db6c895bded/suse/noarch/adaptec-firmware-1.35-25.2.noarch.rpm --- snap --- If you call the kiwi 2nd stage again: --- snip --- kiwi --debug --logfile=./kiwi.2.log --shared-cache-dir=kiwisharedcache --type=iso system create --root=kiwirootdir --target-dir=kiwidestdir --- snip --- zypper will happily install adaptec-firmware, because it considers the cache as trusted - even though the signature was never successfully verified: --- snip --- [ DEBUG ]: 22:36:11 | bootstrap: ( 1/248) Installing: adaptec-firmware-1.35-25.2.noarch [....done] [ INFO ]: Processing: [# ] 2%[ DEBUG ]: 22:36:11 | bootstrap: Additional rpm output: [ DEBUG ]: 22:36:11 | bootstrap: warning: /home/doerges/tmp/kiwidestdir/kiwi_boot_root.0nq6k4ig/home/doerges/tmp/kiwisharedcache/packages/de36b9be105dc4782ce19db6c895bded/suse/noarch/adaptec-firmware-1.35-25.2.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID 3dbdc284: NOKEY --- snip --- And instead the build fails because the next package fails to pass the signature check: --- snip --- [ DEBUG ]: 22:36:12 | bootstrap: Retrieving: sysfsutils-2.1.0-154.4.x86_64.rpm [done] [ DEBUG ]: 22:36:12 | bootstrap: sysfsutils-2.1.0-154.4.x86_64.rpm: [ DEBUG ]: 22:36:12 | bootstrap: Header V3 RSA/SHA256 Signature, key ID 3dbdc284: NOKEY [ DEBUG ]: 22:36:12 | bootstrap: V3 RSA/SHA256 Signature, key ID 3dbdc284: NOKEY [ DEBUG ]: 22:36:12 | bootstrap: Abort, retry, ignore? [a/r/i] (a): a [ INFO ]: Processing: [########################################] 100% [ ERROR ]: 22:36:12 | KiwiBootStrapPhaseFailed: Bootstrap package installation failed: sysfsutils-2.1.0-154.4.x86_64 (de36b9be105dc4782ce19db6c895bded): Signature verification failed [4-Signatures public key is not available] --- snap --- For the 2nd call of the kiwi 2nd stage the expected behavior would have been to fail at exactly the same package, i.e. adaptec-firmware-1.35-25.2.noarch.rpm. IOW it should not have ended up in the cache in the first place. I'm not sure how to extract meaningful zypper logs, but the kiwi output should give enough information to narrow this down.
Do you have zypp packages with the fix available for SLES? Then we could check if SCC activation still works without issues. We should especially test the external repositories (AMD/IBM) that get delivered with SLES.
(In reply to Thomas Schmidt from comment #7) We had to reject our first attempt, but I will have something later today. I'll update here once it's available.
Till kindly agreed to extending the CRD. We currently aim for CRD: 2017-08-03 14:00 UTC
(In reply to Thomas Schmidt from comment #7) Binaries are now available in SUSE:Maintenance:5191
Hello, everyone. I've looked into how the patch will affect registering against SCC and SMT. Registering against SCC shouldn't be affected, as all the repos are properly signed. Registering against SMT will cause errors in the following scenarios: 1. If the customer has patch filtering enabled for a module on their SMT, and GPG re-signing is not enabled, then activating this module is broken. 2. If the customer has added unsigned custom repos to a module on their SMT, then activating this module is broken. Both errors are caused by SUSEConnect trying to install product RPM in non-interactive mode, while patched zypper is asking to confirm trusting an unsigned repo. The proposed solution would be to issue a TID for the affected customers. The proposed ways to fix the issue for them would be to: 1. Either use their own GPG key for signing their repos/re-signing our repos in case of patch filtering; 2. Or relax global zypper settings on client machines to allow unsigned repos without zypper asking. Thanks, Ivan.
(In reply to Ivan Kapelyukhin from comment #12) > [...] > 2. Or relax global zypper settings on client machines to allow unsigned > repos without zypper asking. Sorry, but that sounds like restoring the original vulnerable behavior!? In the end, rpm's should never be downloaded from remote without any signature check. Either on the repo or on each single rpm. Else that's always an open door for attackers.
(In reply to Moritz Duge from comment #13) > Sorry, but that sounds like restoring the original vulnerable behavior!? Well, if the customer wants to install unsigned repos of their own -- they'll have to do it somehow. But I see your point -- OK, rather then relaxing the settings globally we can advise the customers to trust the repos on per-repository basis.
(In reply to Ivan Kapelyukhin from comment #14) yes, please use this solution
(In reply to Ivan Kapelyukhin from comment #14) > But I see your point -- OK, rather then relaxing the settings globally we > can advise the customers to trust the repos on per-repository basis. JFYI: zypper-1.13.31 will provide new options to add-repo/modify-repo, to allow setting the options according to your needs: --gpgcheck (default: requires either signed repo or signed package) gpgcheck = 1 (repo_gpgcheck/pkg_gpgcheck unset: follow zypp.conf) --gpgcheck-strikt (requires signed package even for signed repos) gpgcheck = 1 repo_gpgcheck = 1 pkg_gpgcheck = 1 --gpgcheck-allow-unsigned (allow repo and package to be unsigned) gpgcheck = 1 repo_gpgcheck = 0 pkg_gpgcheck = 0 --gpgcheck-allow-unsigned-repo (allow repo to be unsigned) gpgcheck = 1 repo_gpgcheck = 0 (pkg_gpgcheck unset: follow zypp.conf) --gpgcheck-allow-unsigned-package (allow package to be unsigned) gpgcheck = 1 (repo_gpgcheck unset: follow zypp.conf) pkg_gpgcheck = 0
I'm just reviewing the QA report for this update (http://qam.suse.de/testreports/SUSE:Maintenance:5191:136224/log). The behavior change is fine, but I think we could make the warning a bit more drastic: Current: File 'repomd.xml' from repository 'slesup' is unsigned, continue? [yes/no] (no): I would prefer something along the line of: File 'repomd.xml' from repository 'slesup' is unsigned. This could mean that someone meddled with this repository and it might not be trustworthy anymore. Do you want to continue (it is safer not to)? [yes/no] (no): or something shorter that still conveys that this is bad. No need to resubmit for that though, we could take it in the next update
(In reply to Johannes Segitz from comment #17) > I'm just reviewing the QA report for this update > (http://qam.suse.de/testreports/SUSE:Maintenance:5191:136224/log). The > behavior change is fine, but I think we could make the warning a bit more > drastic: > Current: > File 'repomd.xml' from repository 'slesup' is unsigned, continue? [yes/no] > (no): Yes! And even an experienced user might not recognize, that the 'repomod.xml' ensures the integrity of the whole repo. So an unsigned 'repomod.xml' means the whole content of the repo isn't safe. So that should be mentioned too.
I'll fix this in zypper-1.13.31
SUSE-SU-2017:2040-1: An update that solves three vulnerabilities and has 6 fixes is now available. Category: security (important) Bug References: 1009745,1031756,1033236,1038132,1038984,1043218,1045735,1047785,1048315 CVE References: CVE-2017-7435,CVE-2017-7436,CVE-2017-9269 Sources used: SUSE Linux Enterprise Software Development Kit 12-SP2 (src): libzypp-16.15.2-27.21.1 SUSE Linux Enterprise Server for Raspberry Pi 12-SP2 (src): libzypp-16.15.2-27.21.1, zypper-1.13.30-18.13.3 SUSE Linux Enterprise Server 12-SP2 (src): libzypp-16.15.2-27.21.1, zypper-1.13.30-18.13.3 SUSE Linux Enterprise Desktop 12-SP2 (src): libzypp-16.15.2-27.21.1, zypper-1.13.30-18.13.3 OpenStack Cloud Magnum Orchestration 7 (src): libzypp-16.15.2-27.21.1, zypper-1.13.30-18.13.3
public
openSUSE-SU-2017:2111-1: An update that solves three vulnerabilities and has 6 fixes is now available. Category: security (important) Bug References: 1009745,1031756,1033236,1038132,1038984,1043218,1045735,1047785,1048315 CVE References: CVE-2017-7435,CVE-2017-7436,CVE-2017-9269 Sources used: openSUSE Leap 42.2 (src): libzypp-16.15.2-5.9.1, zypper-1.13.30-5.9.1
It will look like this in case of an unsigned repo (accordingly if missing key): > Retrieving repository 'xxx' metadata --------------------------------------------------------------[\] > Warning: File 'repomd.xml' from repository 'xxx' is unsigned. > > 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 'xxx' is unsigned, continue? [yes/no] (no): In case of a failed signature verification: > > Warning: This file was modified after it has been signed. This may have been a malicious change, > so it might not be trustworthy anymore! You should not continue unless you know it's safe.
Fixed in zypper-1.13.31
(In reply to Michael Andres from comment #23) Very nice, thank you
Submitted for SLES12-SP2/3 (Leap-42.2/3) and Tumbleweed
please let the bug open. The security team will close it as soon it is released to all products. thank you!
SUSE-SU-2017:2264-1: An update that solves three vulnerabilities and has 5 fixes is now available. Category: security (important) Bug References: 1009745,1036659,1038984,1043218,1045735,1046417,1047785,1048315 CVE References: CVE-2017-7435,CVE-2017-7436,CVE-2017-9269 Sources used: SUSE Linux Enterprise Software Development Kit 12-SP3 (src): libzypp-16.15.3-2.3.1, yast2-pkg-bindings-devel-doc-3.2.4-2.3.1 SUSE Linux Enterprise Server 12-SP3 (src): libzypp-16.15.3-2.3.1, yast2-pkg-bindings-3.2.4-2.3.1 SUSE Linux Enterprise Desktop 12-SP3 (src): libzypp-16.15.3-2.3.1, yast2-pkg-bindings-3.2.4-2.3.1
openSUSE-SU-2017:2335-1: An update that solves three vulnerabilities and has 5 fixes is now available. Category: security (important) Bug References: 1009745,1036659,1038984,1043218,1045735,1046417,1047785,1048315 CVE References: CVE-2017-7435,CVE-2017-7436,CVE-2017-9269 Sources used: openSUSE Leap 42.3 (src): libzypp-16.15.3-9.1, yast2-pkg-bindings-3.2.4-4.1, yast2-pkg-bindings-devel-doc-3.2.4-4.1
SUSE-SU-2017:2344-1: An update that solves one vulnerability and has 6 fixes is now available. Category: security (important) Bug References: 1008325,1038984,1045735,1047785,1054088,1054671,1055920 CVE References: CVE-2017-7436 Sources used: SUSE Linux Enterprise Software Development Kit 12-SP3 (src): libzypp-16.15.6-2.8.1 SUSE Linux Enterprise Server 12-SP3 (src): libzypp-16.15.6-2.8.1, zypper-1.13.32-21.3.2 SUSE Linux Enterprise Desktop 12-SP3 (src): libzypp-16.15.6-2.8.1, zypper-1.13.32-21.3.2
openSUSE-SU-2017:2370-1: An update that solves one vulnerability and has 6 fixes is now available. Category: security (important) Bug References: 1008325,1038984,1045735,1047785,1054088,1054671,1055920 CVE References: CVE-2017-7436 Sources used: openSUSE Leap 42.3 (src): libzypp-16.15.6-12.1, zypper-1.13.32-8.1
SUSE-RU-2017:2462-1: An update that has 5 recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1008325,1045735,1054088,1054671,1055920 CVE References: Sources used: SUSE Linux Enterprise Software Development Kit 12-SP2 (src): libzypp-16.15.6-27.28.2 SUSE Linux Enterprise Server for Raspberry Pi 12-SP2 (src): libzypp-16.15.6-27.28.2, zypper-1.13.32-18.16.3 SUSE Linux Enterprise Server 12-SP2 (src): libzypp-16.15.6-27.28.2, zypper-1.13.32-18.16.3 SUSE Linux Enterprise Desktop 12-SP2 (src): libzypp-16.15.6-27.28.2, zypper-1.13.32-18.16.3 SUSE Container as a Service Platform ALL (src): libzypp-16.15.6-27.28.2, zypper-1.13.32-18.16.3 OpenStack Cloud Magnum Orchestration 7 (src): libzypp-16.15.6-27.28.2, zypper-1.13.32-18.16.3
SUSE-SU-2017:2470-1: An update that solves 18 vulnerabilities and has 46 fixes is now available. Category: security (important) Bug References: 1004995,1009745,1014471,1017420,1019637,1026825,1027079,1027688,1027908,1028281,1028723,1029523,1031756,1032706,1033236,1035062,1036659,1038132,1038444,1038984,1042392,1043218,1043333,1044095,1044107,1044175,1044840,1045384,1045735,1045987,1046268,1046417,1046659,1046853,1046858,1047008,1047236,1047240,1047310,1047379,1047785,1047964,1047965,1048315,1048483,1048605,1048679,1048715,1049344,1050396,1050484,1051626,1051643,1051644,1052030,1052759,1053409,874665,902364,938657,944903,954661,960820,963041 CVE References: CVE-2013-7459,CVE-2016-9063,CVE-2017-1000100,CVE-2017-1000101,CVE-2017-10684,CVE-2017-10685,CVE-2017-11112,CVE-2017-11113,CVE-2017-3308,CVE-2017-3309,CVE-2017-3453,CVE-2017-3456,CVE-2017-3464,CVE-2017-7435,CVE-2017-7436,CVE-2017-8872,CVE-2017-9233,CVE-2017-9269 Sources used: SUSE Container as a Service Platform ALL (src): caasp-container-manifests-0.0.0+git_r155_93e40ab-2.3.3, container-feeder-0.0.0+20170901.git_r55_17ecbd3-2.3.3, sles12-mariadb-docker-image-1.1.0-2.3.10, sles12-pause-docker-image-1.1.0-2.3.11, sles12-pv-recycler-node-docker-image-1.1.0-2.3.10, sles12-salt-api-docker-image-1.1.0-2.3.9, sles12-salt-master-docker-image-1.1.0-4.3.10, sles12-salt-minion-docker-image-1.1.0-2.3.8, sles12-velum-docker-image-1.1.0-4.3.9
should be done
openSUSE-RU-2017:2484-1: An update that has 5 recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1008325,1045735,1054088,1054671,1055920 CVE References: Sources used: openSUSE Leap 42.2 (src): libzypp-16.15.6-5.12.1, zypper-1.13.32-5.12.1
SUSE-SU-2017:2861-1: An update that solves three vulnerabilities and has 22 fixes is now available. Category: security (moderate) Bug References: 1005063,1008325,1009269,1012523,1025176,1028485,1032680,1036659,1042781,1045628,1045735,1050767,1050943,1054028,1054088,1054671,1055920,1056995,1060653,1061876,1063824,903543,978055,998893,999878 CVE References: CVE-2017-1000254,CVE-2017-1000257,CVE-2017-11462 Sources used: SUSE Container as a Service Platform ALL (src): sles12-mariadb-docker-image-1.1.0-2.5.19, sles12-pause-docker-image-1.1.0-2.5.21, sles12-pv-recycler-node-docker-image-1.1.0-2.5.19, sles12-salt-api-docker-image-1.1.0-2.5.19, sles12-salt-master-docker-image-1.1.0-4.5.18, sles12-salt-minion-docker-image-1.1.0-2.5.18, sles12-velum-docker-image-1.1.0-4.5.18
I just had another look at this with $ zypper --version zypper 1.13.40 $ lsb-release -d Description: openSUSE Leap 42.3 and the default settings for zypper/libzypp. This means an unmodified /etc/zypp/zypp.conf in particular. Throughout the ticket you mention that the integrity of repomd.xml is checked. But this does not (always) seem to be the case. In my setup only the file content was checked. Not sure this is important but I took me a moment to chase. Details follow below. repomd.xml ---------- user@reposrv:~> gpg .../distribution/leap/42.3/repo/oss/suse/repodata/repomd.xml.asc gpg: Signatur vom Mi 19 Jul 2017 20:57:50 CEST mittels RSA-Schlüssel ID 3DBDC284 gpg: Korrekte Signatur von "openSUSE Project Signing Key <opensuse@opensuse.org>" [unbekannt] gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur! gpg: Es gibt keinen Hinweis, daß die Signatur wirklich dem vorgeblichen Besitzer gehört. Haupt-Fingerabdruck = 22C0 7BA5 3417 8CD0 2EFE 22AA B88B 2FD4 3DBD C284 reposrv:.../distribution/leap/42.3/repo/oss/suse/repodata # joe repomd.xml reposrv:.../distribution/leap/42.3/repo/oss/suse/repodata # diff repomd.xml.orig repomd.xml 3c3 < <revision>1500484332</revision> --- > <revision>1500484333</revision> user@reposrv:~> gpg .../distribution/leap/42.3/repo/oss/suse/repodata/repomd.xml.asc gpg: Signatur vom Mi 19 Jul 2017 20:57:50 CEST mittels RSA-Schlüssel ID 3DBDC284 gpg: FALSCHE Signatur von "openSUSE Project Signing Key <opensuse@opensuse.org>" [unbekannt] client:~ # zypper cc -a All repositories have been cleaned up. client:~ # zypper ref --repo reposrv_oss Retrieving repository 'Reposrv Oss' metadata ...............................[done] Building repository 'Reposrv Oss' cache ....................................[done] Specified repositories have been refreshed. content ------- reposrv:.../latest/distribution/leap/42.3/repo/oss # diff content.orig content 1c1 < CONTENTSTYLE 11 --- > CONTENTSTYLE 11 user@reposrv:~> gpg .../latest/distribution/leap/42.3/repo/oss/content.asc gpg: Signatur vom Mi 19 Jul 2017 20:57:50 CEST mittels RSA-Schlüssel ID 3DBDC284 gpg: FALSCHE Signatur von "openSUSE Project Signing Key <opensuse@opensuse.org>" [unbekannt] client:~ # zypper cc -a All repositories have been cleaned up. client:~ # zypper ref --repo reposrv_oss Retrieving repository 'Reposrv Oss' metadata ---------------------------------------[\] Signature verification failed for file 'content' from repository 'Reposrv Oss'. 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 'content' is the repositories master index file. It ensures the integrity of the whole repo. Warning: This file was modified after it has been signed. This may have been a malicious change, so it might not be trustworthy anymore! You should not continue unless you know it's safe. Signature verification failed for file 'content' from repository 'Reposrv Oss'. Continue? [yes/no] (no):
@Till: I guess the behavior is ok, because repomd.xml is most probably not used: This is how your repo on the server looks like? > reposrv:.../distribution/leap/42.3/repo/oss/ > content > content.asc > content.key > suse/ > /repodata/ > /repomd.xml > /repomd.xml.asc > /repomd.xml.key This layout actually contains 2 repositories. One in SUSETAGS fomat (content as master index), one in RPMMD (repomd.xml as master index). But you don't use both at the same time. On a client: When probing the repositories URL to figure out the repositories type, ZYPP recognizes > <URL>/content > <URL>/repodata/repomd.xml So if your URL is ...leap/42.3/repo/oss, ZYPP will probe it as type SUSETAGS and use content as master index. It the URL is ...leap/42.3/repo/oss/suse, ZYPP wouLd probe it as RPMMD and use repomd.xml as master index. Your comment does not tell how the repository URL in the 'repomd.xml' case looked like. You can call 'zypper -v ref' to see which index files are actually downloaded.
(In reply to Michael Andres from comment #44) > This is how your repo on the server looks like? Yes. > So if your URL is ...leap/42.3/repo/oss, ZYPP will probe it as type SUSETAGS > and use content as master index. > > It the URL is ...leap/42.3/repo/oss/suse, ZYPP wouLd probe it as RPMMD and > use repomd.xml as master index. client:~ # tail -1 /etc/zypp/repos.d/reposrv_oss.repo type=yast2 client:~ # zypper -v ref --repo reposrv_oss [...] Retrieving: content....................................................[done] Retrieving: media......................................................[done] Repository 'Reposrv Oss' is up to date. Specified repositories have been refreshed. Thank you very much for the explanation. Now I understand, why only 1 master index is used.
Fixes submitted for SLES12-SP1 libzypp 15.25.16 zypper 1.12.58 (MR#170535)
Amended the fix for SP1; included updated translations and rephrased some libzypp code, so swig understands it. SLE12* swig does not fully understand C++11. Without this libzypp-bindings won't build. SLES12-SP1 libzypp 15.25.16 zypper 1.12.58 (MR#170947) SLES12 libzypp 14.45.16 zypper 1.11.70 (MR#170948)
SUSE-SU-2018:2555-1: An update that solves four vulnerabilities and has 10 fixes is now available. Category: security (important) Bug References: 1037210,1038984,1045735,1048315,1054088,1070851,1076192,1088705,1091624,1092413,1096803,1100028,1101349,1102429 CVE References: CVE-2017-7435,CVE-2017-7436,CVE-2017-9269,CVE-2018-7685 Sources used: SUSE Linux Enterprise Server for SAP 12-SP1 (src): libzypp-15.25.17-46.22.1, zypper-1.12.59-46.10.1 SUSE Linux Enterprise Server 12-SP1-LTSS (src): libzypp-15.25.17-46.22.1, zypper-1.12.59-46.10.1
SUSE-SU-2018:2688-1: An update that solves four vulnerabilities and has 13 fixes is now available. Category: security (important) Bug References: 1036304,1037210,1038984,1045735,1048315,1054088,1070851,1076192,1079334,1088705,1091624,1092413,1096803,1099847,1100028,1101349,1102429 CVE References: CVE-2017-7435,CVE-2017-7436,CVE-2017-9269,CVE-2018-7685 Sources used: SUSE Linux Enterprise Server 12-LTSS (src): libzypp-14.45.17-2.82.1, zypper-1.11.70-2.69.2
SUSE-SU-2018:2690-1: An update that solves two vulnerabilities and has 26 fixes is now available. Category: security (important) Bug References: 1036304,1041178,1043166,1045735,1058515,1066215,1070770,1070851,1082318,1084525,1088037,1088705,1091624,1092413,1093103,1096217,1096617,1096803,1099847,1100028,1100095,1100427,1101349,1102019,1102429,408814,428822,907538 CVE References: CVE-2017-9269,CVE-2018-7685 Sources used: SUSE Linux Enterprise Module for Development Tools 15 (src): libsolv-0.6.35-3.5.2 SUSE Linux Enterprise Module for Basesystem 15 (src): libsolv-0.6.35-3.5.2, libzypp-17.6.4-3.10.1, zypper-1.14.10-3.7.1
SUSE-SU-2018:2716-1: An update that solves two vulnerabilities and has 12 fixes is now available. Category: security (important) Bug References: 1036304,1045735,1049825,1070851,1076192,1079334,1088705,1091624,1092413,1096803,1099847,1100028,1101349,1102429 CVE References: CVE-2017-9269,CVE-2018-7685 Sources used: SUSE OpenStack Cloud 7 (src): libzypp-16.17.20-27.52.1, zypper-1.13.45-18.33.1 SUSE Linux Enterprise Server for SAP 12-SP2 (src): libzypp-16.17.20-27.52.1, zypper-1.13.45-18.33.1 SUSE Linux Enterprise Server 12-SP2-LTSS (src): libzypp-16.17.20-27.52.1, zypper-1.13.45-18.33.1 SUSE Enterprise Storage 4 (src): libzypp-16.17.20-27.52.1, zypper-1.13.45-18.33.1 OpenStack Cloud Magnum Orchestration 7 (src): libzypp-16.17.20-27.52.1, zypper-1.13.45-18.33.1
openSUSE-SU-2018:2739-1: An update that solves two vulnerabilities and has 26 fixes is now available. Category: security (important) Bug References: 1036304,1041178,1043166,1045735,1058515,1066215,1070770,1070851,1082318,1084525,1088037,1088705,1091624,1092413,1093103,1096217,1096617,1096803,1099847,1100028,1100095,1100427,1101349,1102019,1102429,408814,428822,907538 CVE References: CVE-2017-9269,CVE-2018-7685 Sources used: openSUSE Leap 15.0 (src): libsolv-0.6.35-lp150.2.3.1, libzypp-17.6.4-lp150.2.3.1, zypper-1.14.10-lp150.2.3.1
SUSE-SU-2018:2814-1: An update that solves two vulnerabilities and has 11 fixes is now available. Category: security (important) Bug References: 1036304,1045735,1049825,1070851,1076192,1088705,1091624,1092413,1096803,1099847,1100028,1101349,1102429 CVE References: CVE-2017-9269,CVE-2018-7685 Sources used: SUSE Linux Enterprise Software Development Kit 12-SP3 (src): libzypp-16.17.20-2.33.2 SUSE Linux Enterprise Server 12-SP3 (src): libzypp-16.17.20-2.33.2, zypper-1.13.45-21.21.2 SUSE Linux Enterprise Desktop 12-SP3 (src): libzypp-16.17.20-2.33.2, zypper-1.13.45-21.21.2 SUSE CaaS Platform ALL (src): libzypp-16.17.20-2.33.2, zypper-1.13.45-21.21.2 SUSE CaaS Platform 3.0 (src): libzypp-16.17.20-2.33.2, zypper-1.13.45-21.21.2
SUSE-SU-2018:2716-2: An update that solves two vulnerabilities and has 12 fixes is now available. Category: security (important) Bug References: 1036304,1045735,1049825,1070851,1076192,1079334,1088705,1091624,1092413,1096803,1099847,1100028,1101349,1102429 CVE References: CVE-2017-9269,CVE-2018-7685 Sources used: SUSE Linux Enterprise Server 12-SP2-BCL (src): libzypp-16.17.20-27.52.1, zypper-1.13.45-18.33.1
Guess we forgot to close it.