Bug 1008325 - Zypp fails to handle repositories signed with a GPG subkey
Summary: Zypp fails to handle repositories signed with a GPG subkey
Status: RESOLVED FIXED
: 1056923 (view as bug list)
Alias: None
Product: openSUSE Distribution
Classification: openSUSE
Component: libzypp (show other bugs)
Version: Leap 42.2
Hardware: Other Other
: P5 - None : Normal with 47 votes (vote)
Target Milestone: ---
Assignee: E-mail List
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-03 13:44 UTC by Michael Andres
Modified: 2018-05-16 19:07 UTC (History)
28 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
fredsie: needinfo?


Attachments
Google's repomd.xml (951 bytes, text/xml)
2017-07-29 10:10 UTC, Dave Corrie
Details
Google's Linux Packages Signing Authority Key (7.85 KB, application/vnd.ms-publisher)
2017-07-29 10:11 UTC, Dave Corrie
Details
Google's repomd.xml.asc (819 bytes, text/plain)
2017-07-29 14:22 UTC, Dave Corrie
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Andres 2016-11-03 13:44:52 UTC
[posted on zypp-devel]
> I was confused earlier today when trying to add a GPG-signed rpm-md
> type repository to my system. I noticed that zypper was listing the
> repository as not being signed. zypper refresh was telling me that the
> repository was signed with an unknown key and zypper lr was listing
> the repository as not supporting repo_gpgcheck.
>
> After some digging around the libzypper source (14.43.0) on my system
> (openSUSE 13.2) I believe I've tracked down the issue.
>
> The call to publicKeyExists in
> KeyRing::Impl::verifyFileSignatureWorkflow checks if the
> repomd.xml.asc signature's key ID is known. If the repomd.xml.asc was
> signed with a subkey of a GPG key (instead of a primary key), this
> check will fail even though the call to VerifyFile would succeed.

> Not sure what the best solution is for zypper, but one potential
> solution would be to simply ask GPG to verify the signature using the
> general keyring without first checking if a matching key id is in the
> keyring. The logic in verifyFileSignatureWorkflow can then be
> simplified as GPG would figure out if there's a matching key and this
> issue would be avoided.
Comment 1 Dave Corrie 2017-07-29 10:08:56 UTC
I have a feeling that this is currently affecting the google-chrome linux repostory at:
http://dl.google.com/linux/chrome/rpm/stable/x86_64

I saw a request for for some more info on the zypp-devel mailing list:
https://lists.opensuse.org/zypp-devel/2016-11/msg00000.html

I will attach copies of the following data, downloaded at 2017-07-29 10:03 UTC:
http://dl.google.com/linux/chrome/rpm/stable/x86_64/repodata/repomd.xml
https://dl.google.com/linux/linux_signing_key.pub
Comment 2 Dave Corrie 2017-07-29 10:10:35 UTC
Created attachment 734453 [details]
Google's repomd.xml
Comment 3 Dave Corrie 2017-07-29 10:11:48 UTC
Created attachment 734454 [details]
Google's  Linux Packages Signing Authority Key
Comment 4 Dave Corrie 2017-07-29 14:22:59 UTC
Created attachment 734455 [details]
Google's repomd.xml.asc
Comment 6 Marcus Rückert 2017-07-31 09:52:03 UTC
steps to reproduce:

```
$ zypper rr google-chrome-stable
$ zypper ar http://dl.google.com/linux/chrome/rpm/stable/x86_64 google-chrome-stable
$ zypper ref


File 'repomd.xml' from repository 'google-chrome-stable' is signed with an unknown key '1397BC53640DB551'. Continue? [yes/no] (no): yes
```
Comment 7 Marcus Rückert 2017-07-31 09:53:02 UTC
rpm -qp -vvv ./zypp/packages/google-chrome-stable/google-chrome-stable-60.0.3112.78-1.x86_64.rpm
ufdio:       1 reads,    18883 total bytes in 0.000017 secs
D: loading keyring from pubkeys in /var/lib/rpm/pubkeys/*.key
D: couldn't find any keys in /var/lib/rpm/pubkeys/*.key
D: loading keyring from rpmdb
D: opening  db environment /var/lib/rpm cdb:private:0x201
D: opening  db index       /var/lib/rpm/Packages 0x400 mode=0x0
D: locked   db index       /var/lib/rpm/Packages
D: opening  db index       /var/lib/rpm/Name nofsync:0x400 mode=0x0
D:  read h#       1 Header SHA1 digest: OK (85e0be52624ee727408da6a2af83070de7cbcf3a)
D: added key gpg-pubkey-307e3d54-4be01a65 to keyring
D:  read h#       2 Header SHA1 digest: OK (f7d156c09a491f6c2b96dcf50eeb8d67524cc86e)
D: added key gpg-pubkey-3dbdc284-53674dd4 to keyring
D:  read h#    1898 Header SHA1 digest: OK (e3682e90f16798cd0f5020640e004d116ab0cec5)
D: added key gpg-pubkey-39db7c82-5847eb1f to keyring
D:  read h#    1904 Header SHA1 digest: OK (43ba319f78f48a4c0228d25b726e884a35e612ce)
D: added key gpg-pubkey-7fac5991-4615767f to keyring
D:  read h#    1958 Header SHA1 digest: OK (c13facddf3ab56b981f53c472ce502a9933e4810)
D: added key gpg-pubkey-3f56078e-56c68abe to keyring
D:  read h#    2021 Header SHA1 digest: OK (2e782b8d5b8f5c99879cbec727de92d7fab7fb01)
D: added key gpg-pubkey-c8da93d2-56548fdc to keyring
D:  read h#    2158 Header SHA1 digest: OK (4fc01c0c3a44fcaa134974165134be3f9cac112c)
D: added key gpg-pubkey-ee3d166a-57d17fa1 to keyring
D:  read h#    2182 Header SHA1 digest: OK (9aba47f074e30f91db8a189f13d7a5630a4282f8)
D: added key gpg-pubkey-d38b4796-570c8cd3 to keyring
D: added subkey 0 of main key gpg-pubkey-d38b4796-570c8cd3 to keyring
D:  read h#    2183 Header SHA1 digest: OK (b32701469db4996b1e810b05b8736159d1d0f79e)
D: added key gpg-pubkey-0b245af7-56ddb23f to keyring
D:  read h#    2198 Header SHA1 digest: OK (6d3d617a1a09dfc514cd30201b5a9b70c1cd4beb)
D: added key gpg-pubkey-0e9af123-57ab041b to keyring
D:  read h#    2199 Header SHA1 digest: OK (d975ab01b13cc62ac68e368cd6323a91b12a9ab8)
D: added key gpg-pubkey-62bb747c-56f27867 to keyring
D:  read h#    2363 Header SHA1 digest: OK (72bad7c500e647d4e004ef17e12d7ac6b99a49a1)
D: added key gpg-pubkey-367fe7fc-588f5460 to keyring
D:  read h#    3268 Header SHA1 digest: OK (0a67807ed688950c10fd8d5cd91f018ef96c7f32)
D: added key gpg-pubkey-222d23d0-5910b0f0 to keyring
D: Using legacy gpg-pubkey(s) from rpmdb
D: Expected size:     61731326 = lead(96)+sigs(356)+pad(4)+data(61730870)
D:   Actual size:     61731326
D: ./zypp/packages/google-chrome-stable/google-chrome-stable-60.0.3112.78-1.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 7fac5991: OK
ufdio:       6 reads,    47798 total bytes in 0.000034 secs
google-chrome-stable-60.0.3112.78-1.x86_64
D: closed   db index       /var/lib/rpm/Packages
D: closed   db index       /var/lib/rpm/Name
D: closed   db environment /var/lib/rpm
Comment 8 Dave Corrie 2017-07-31 18:55:23 UTC
There's a chromium bug tracking this issue too:
https://bugs.chromium.org/p/chromium/issues/detail?id=750481#c9

Conclusion there at present is that it is caused by signing using a subkey and preferred resolution would be to address in zypper.
Comment 10 Aaron Digulla 2017-08-05 16:03:05 UTC
Everyone using the official Google repo to update Chrome is affected by this bug.

People in forums are already suggesting to ignore warnings about unknown keys, undermining the confidence in the system of many users. 

I feel this is a very bad situation since Chrome is a very popular application used by many people and zypper is giving a false warning because Google increased the security on their side ("We don't really want to go back to the ancient (weaker) signing key", last comment in https://bugs.chromium.org/p/chromium/issues/detail?id=750481).
Comment 11 Aaron Digulla 2017-08-05 16:07:17 UTC
I just noticed that my key is different: On my computer, it says: 

Datei 'repomd.xml' aus Repository 'google-chrome' ist mit einem unbekannten Schlüssel '6494C6D6997C215E' signiert. Weiter? [ja/nein] (nein):

zypper info show the version in the repo as "60.0.3112.90-1" which is the same as in comment #7, so I'm wondering why I'm getting a different key than comment #6.

Can anyone confirm?
Comment 12 Steven Karp 2017-08-06 20:51:37 UTC
I can confirm the changed information in comment 11.  I initially received the original unknown key "1397BC53640DB551", then a couple of days later I started receiving "6494C6D6997C215E".

I presume this means there are multiple subkeys in use at Google, and the message changes depending on which key is used to sign a particular package.
Comment 13 Marcus Rückert 2017-08-07 09:36:01 UTC
6494C6D6997C215E is the 2nd subkey of their key.
Comment 14 Michael Andres 2017-08-11 13:36:48 UTC
JFYI: Will be a somewhat bigger change. Not just because of the subkey that signes, but also due to the fact that the repomd.xml.key file actually contains multiple keys

> pub   1024D/7FAC5991 2007-03-08
> uid       [ unknown] Google, Inc. Linux Package Signing Key <linux-packages-keymaster@google.com>
> sig 3        7FAC5991 2007-04-05  Google, Inc. Linux Package Signing Key <linux-packages-keymaster@google.com>
> sub   2048g/C07CB649 2007-03-08
> sig          7FAC5991 2007-03-08  Google, Inc. Linux Package Signing Key <linux-packages-keymaster@google.com>
> 
> pub   4096R/D38B4796 2016-04-12
> uid       [ unknown] Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>
> sig 3        D38B4796 2016-04-12  Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>
> sig          7FAC5991 2016-04-13  Google, Inc. Linux Package Signing Key <linux-packages-keymaster@google.com>
> sig          31B7E803 2016-04-13  [User ID not found]
> sub   4096R/640DB551 2016-04-12 [expires: 2019-04-12]
> sig          D38B4796 2016-04-12  Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>
> sub   4096R/997C215E 2017-01-24 [expires: 2020-01-24]
> sig          D38B4796 2017-01-24  Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>

Zypper/yast need to be prepared to ask for multiple keys being imported into the rpm-DB.
Comment 15 kolA flash 2017-08-21 18:35:02 UTC
(In reply to Michael Andres from comment #14)
> JFYI: Will be a somewhat bigger change. Not just because of the subkey that
> signes, but also due to the fact that the repomd.xml.key file actually
> contains multiple keys

What about adding subkey support first and publishing that update before doing the complicated multiple keys stuff. So people can workaround the rest of the problem by manually adding the key via "rpm --import ...". (if I get this right)

Please fix this soon. It keeps people from regularly installing all the other updates by blocking the KDE updates widget.

By the way: A long forum discussion about this.
https://forums.opensuse.org/showthread.php/526158-sudden-google-chrome-is-signed-with-an-unknown-key-problem
Comment 16 Michael Andres 2017-08-22 09:52:44 UTC
libzypp 16.15.4. will fix it. It will be submitted to OBS on Thursday 24.08.

---------------------
> === /tmp/gpggoo/repodata/repomd.xml.key{- 0644 216/50 size 6293}
> [Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>]
>   fpr EB4C1BFD4F042F6DDDCCEC917721F63BD38B4796
>    id 7721F63BD38B4796
>   cre 1460440275 Tue Apr 12 07:51:15 2016
>   exp 0 (does not expire)
>   ttl 2147483647
>   rpm d38b4796-570c8cd3
> ]

The pseudo package for this key in the rpm database will be 'gpg-pubkey-d38b4796-570c8cd3'.

The version d38b4796 is the trailing part of the primary keys id.

The release (0x)570c8cd3 (=1460440275 = Tue Apr 12 07:51:15 2016) encodes the keys creation time.

If a primary key is about to expire and you extend the expiration date, this will also modify the primary keys creation date. So you can immediately recognize that the key in the repo is newer than the same key in the rpm database. The gpg-pubkey package will appear to have a new (higher) release.

> $ gpg /tmp/gpggoo/repodata/repomd.xml.key
> pub  4096R/D38B4796 2016-04-12
> uid  Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>
> sub  4096R/640DB551 2016-04-12 [expires: 2019-04-12]
> sub  4096R/997C215E 2017-01-24 [expires: 2020-01-24]

The Google primary key however does not expire. The subkeys used for signing do, but you can simply add new subkeys. This however does _not_ change the primary keys creation date (the gpg-pubkeys release). 


So by looking at your keys in the rpm database (rpm -q gpg-pubkey) you can not tell whether such a key was updated because it's release does not change when subkeys are added. This may also affect you if you try to import a newer google key while an older one is already in the rpm db. Both keys have the same 'release' so rpm might not update the key. You may need to delete the key from the database first, then import the new key.

The (sub)key IDs used for signing data (640DB551 or 997C215E) are also not visible in the rpm database. So you can't easily tell if the key verifying this signature is already in the rpm database. You see just the primary keys id (as version).
Comment 17 Michael Andres 2017-08-25 12:30:56 UTC
Fixed in libzypp-16.15.4 / zypper-1.13.32
Comment 18 Michael Andres 2017-08-28 14:43:36 UTC
.
Comment 19 Michael Andres 2017-09-04 07:43:06 UTC
*** Bug 1056923 has been marked as a duplicate of this bug. ***
Comment 20 Michael Andres 2017-09-04 09:55:04 UTC
fixed
 SLE-12-SP1      libzypp 15.25.2
 SLE-12          libzypp 14.45.6
Comment 21 Swamp Workflow Management 2017-09-04 19:42:47 UTC
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
Comment 22 Patrick Finie 2017-09-06 00:41:01 UTC
(In reply to Swamp Workflow Management from comment #21)
> 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

Thank you, just updated the libzypp packages on one of my machines and all is now working.
Comment 23 Swamp Workflow Management 2017-09-06 01:15:36 UTC
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
Comment 24 Fred Jones 2017-09-14 15:43:58 UTC
Hi all

Is this rolling out to 42.1 as well as 42.3?  No sign of it yet in the 42.2 repos.

Regards

Fred
Comment 25 Fred Jones 2017-09-14 15:46:31 UTC
Sorry for typo that should read 42.2
Comment 26 Swamp Workflow Management 2017-09-14 16:09:26 UTC
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
Comment 27 Michael Andres 2017-09-14 16:27:01 UTC
(In reply to Fred Jones from comment #24)
> Is this rolling out to 42.2 as well as 42.3?

Yes. Looks like it was just released for SLE12-SP2, so LEAP-42.2 should follow soon.
Comment 28 Swamp Workflow Management 2017-09-15 10:12:26 UTC
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
Comment 29 Swamp Workflow Management 2017-10-27 01:08:45 UTC
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
Comment 30 Peter Tselios 2018-01-04 13:45:28 UTC
This is marked as fixed. However, in Leap 42.3 I still have the same issue. 
My libzypp is: 
libzypp-16.17.4-15.1.x86_64

However:
zypper ref

Retrieving repository 'google-chrome' metadata ---------------------------------------------------------------------------------------------------------------[/]
Warning: File 'repomd.xml' from repository 'google-chrome' is signed with an unknown key '1397BC53640DB551'.

    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 'google-chrome' is signed with an unknown key '1397BC53640DB551'. Continue? [yes/no] (no): 

FYI, I had removed all Google keys and I added them manually:

wget https://dl-ssl.google.com/linux/linux_signing_key.pub
rpm --import linux_signing_key.pub
Comment 31 Swamp Workflow Management 2018-01-18 23:08:42 UTC
SUSE-RU-2018:0138-1: An update that has 7 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1008325,1036659,1043218,1064999,1068708,1071466,969569
CVE References: 
Sources used:
SUSE OpenStack Cloud 6 (src):    libzypp-15.25.6-46.9.1
SUSE Linux Enterprise Server for SAP 12-SP1 (src):    libzypp-15.25.6-46.9.1
SUSE Linux Enterprise Server 12-SP1-LTSS (src):    libzypp-15.25.6-46.9.1
Comment 32 Christos Varelas 2018-02-27 15:17:43 UTC
While working on SUSE:Maintenance:5553:155577 I discovered that the bug is not fixed -- please see this excerpt from the test-report:

BEFORE
~~~~~~
		rr5553:~ # zypper ar http://dl.google.com/linux/chrome/rpm/stable/x86_64 google-chrome-stable
		Adding repository 'google-chrome-stable' ................[done]
		Repository 'google-chrome-stable' successfully added
		Enabled     : Yes                                                
		Autorefresh : No                                                 
		GPG Check   : Yes                                                
		URI         : http://dl.google.com/linux/chrome/rpm/stable/x86_64

		rr5553:~ # zypper ref
		Retrieving repository 'google-chrome-stable' metadata ------[\]
		File 'repomd.xml' from repository 'google-chrome-stable' is signed with an unknown key '1397BC53640DB551'. Continue? [yes/no] (no): yes

		^^^^^ this is due to the bug

		Retrieving repository 'google-chrome-stable' metadata ...[done]
		Building repository 'google-chrome-stable' cache ........[done]
		[...]
		All repositories have been refreshed.

AFTER
~~~~~
		rr5553:~ # zypper ar http://dl.google.com/linux/chrome/rpm/stable/x86_64 google-chrome-stable
		Adding repository 'google-chrome-stable' ................[done]
		Repository 'google-chrome-stable' successfully added
		Enabled     : Yes                                                
		Autorefresh : No                                                 
		GPG Check   : Yes                                                
		URI         : http://dl.google.com/linux/chrome/rpm/stable/x86_64

		rr5553:~ # zypper ref
		Retrieving repository 'google-chrome-stable' metadata ------[\]
		File 'repomd.xml' from repository 'google-chrome-stable' is signed with an unknown key '1397BC53640DB551'. Continue? [yes/no] (no): yes

		^^^^^ this is due to the bug, looks like it is not fixed

		Retrieving repository 'google-chrome-stable' metadata ...[done]
		Building repository 'google-chrome-stable' cache ........[done]
		[...]
		All repositories have been refreshed.

=> Bug does NOT seem to fixed

Please, see also Peter's comment: https://bugzilla.suse.com/show_bug.cgi?id=1008325#c30
Comment 33 Michael Andres 2018-02-27 15:58:14 UTC
> root@fibonacci:~ (4) $ zypper -v ref google-chrome-stable
> Verbosity: 1
> ...
> Checking whether to refresh metadata for google-chrome-stable
> Retrieving: repomd.xml.asc ..................[done]
> Retrieving: repomd.xml.key .............[not found]
> Retrieving: repomd.xml ......................[done]
> Warning: File 'repomd.xml' from repository 'google-chrome-stable'
>          is signed with an unknown key '1397BC53640DB551'.

The repo provides no .key file, so the message is right.
Comment 34 Swamp Workflow Management 2018-05-16 19:07:27 UTC
SUSE-RU-2018:1307-1: An update that has 10 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1008325,1033236,1036659,1038132,1043218,1068708,1074687,1076415,1079334,637791
CVE References: 
Sources used:
SUSE Linux Enterprise Server 12-LTSS (src):    libzypp-14.45.10-2.73.1, zypper-1.11.66-2.64.1