CVE-2019-13050

Note

this is a weakness in the PGP keyserver design.
gnupg upstream has 2 mitigations for this - firstly, don't import key signatures by default anymore, and to fallback to only import self-signatures on very large keyblocks
as of 2020-01-06, there is no ideal fix for this issue
marking this CVE as deferred until a complete fix is available
gnupg mitigations landed in upstream in 2.2.17 with important
fixes in 2.2.18
2.2.19-3ubuntu1 introduced a debian/ubuntu specific change to
use keys.openpgp.org as the default keyserver
any backports to address this issue will be complex and
introduce changes in behavior
sks in debian introduced very basic filtering in
1.1.6+git20210302.c3ba6d5a-1
as of 2022-03-22, there is no upstream backport for
gnupg 1.4 series. Backporting from 2.2 is too risky.

Package	Release	Status
gnupg Launchpad, Ubuntu, Debian	bionic	Does not exist
	disco	Does not exist
	eoan	Does not exist
	focal	Does not exist
	groovy	Does not exist
	hirsute	Does not exist
	impish	Does not exist
	jammy	Does not exist
	kinetic	Does not exist
	precise	Ignored (end of ESM support, was deferred [2020-01-06])
	trusty	Deferred (2022-03-22)
	upstream	Needs triage
	xenial	Deferred (2022-03-22)
gnupg2 Launchpad, Ubuntu, Debian	bionic	Released (2.2.4-1ubuntu1.5)
	disco	Ignored (reached end-of-life)
	eoan	Ignored (reached end-of-life)
	focal	Not vulnerable (2.2.19-3ubuntu1)
	groovy	Not vulnerable (2.2.19-3ubuntu1)
	hirsute	Not vulnerable (2.2.19-3ubuntu1)
	impish	Not vulnerable (2.2.19-3ubuntu1)
	jammy	Not vulnerable (2.2.19-3ubuntu1)
	kinetic	Not vulnerable (2.2.19-3ubuntu1)
	precise	Does not exist
	trusty	Does not exist
	upstream	Released (2.2.17-3)
	xenial	Ignored (change too intrusive)
	Patches: upstream: https://dev.gnupg.org/rG15a425a1dfe60bd976b17671aa8e3d9aed12e1c0 upstream: https://dev.gnupg.org/rGadb120e663fc5e78f714976c6e42ae233c1990b0 upstream: https://dev.gnupg.org/rGa1f2f38dfb2ba5ed66d3aef66fc3be9b67f9b800 upstream: https://dev.gnupg.org/rG2b7151b0a57f5fe7d67fd76dfa1ba7a8731642c6 (possibly problematic) upstream: https://dev.gnupg.org/rGb6effaf4669b2c3707932e3c5f2f57df886d759e upstream: https://dev.gnupg.org/rG3c2cf5ea952015a441ee5701c41dadc63be60d87
sks Launchpad, Ubuntu, Debian	bionic	Deferred (2020-01-06)
	cosmic	Ignored (reached end-of-life)
	disco	Ignored (reached end-of-life)
	eoan	Ignored (reached end-of-life)
	focal	Deferred (2020-01-06)
	groovy	Does not exist
	hirsute	Not vulnerable (1.1.6+git20210302.c3ba6d5a-1)
	impish	Not vulnerable (1.1.6+git20210302.c3ba6d5a-1)
	jammy	Not vulnerable (1.1.6+git20210302.c3ba6d5a-1)
	kinetic	Not vulnerable (1.1.6+git20210302.c3ba6d5a-1)
	precise	Does not exist
	trusty	Does not exist
	upstream	Released (1.1.6+git20210302.c3ba6d5a-1)
	xenial	Ignored (end of standard support, was deferred [2020-01-06])

Security

CVE-2019-13050

Notes

Low

Status

References

Bugs

Join the discussion

Canonical is offering Expanded Security Maintenance

Further reading

Author	Note
mdeslaur	this is a weakness in the PGP keyserver design.
amurray	gnupg upstream has 2 mitigations for this - firstly, don't import key signatures by default anymore, and to fallback to only import self-signatures on very large keyblocks
mdeslaur	as of 2020-01-06, there is no ideal fix for this issue marking this CVE as deferred until a complete fix is available
sbeattie	gnupg mitigations landed in upstream in 2.2.17 with important fixes in 2.2.18 2.2.19-3ubuntu1 introduced a debian/ubuntu specific change to use keys.openpgp.org as the default keyserver any backports to address this issue will be complex and introduce changes in behavior sks in debian introduced very basic filtering in 1.1.6+git20210302.c3ba6d5a-1
rodrigo-zaiden	as of 2022-03-22, there is no upstream backport for gnupg 1.4 series. Backporting from 2.2 is too risky.