From c32ee94e47be1acf7f782b1baa2bdd24049c56a9 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Antoine=20Beaupr=C3=A9?= Date: Mon, 11 Mar 2019 14:38:40 -0400 Subject: [PATCH] don't hardcode an old key from official mirrors for Debian backports MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553 is really this key, on any modern Debian system: /etc/apt/trusted.gpg.d/debian-archive-wheezy-automatic.gpg ---------------------------------------------------------- pub rsa4096 2012-04-27 [SC] [expire : 2020-04-25] A1BD 8E9D 78F7 FE5C 3E65 D8AF 8B48 AD62 4692 5553 uid [ inconnue] Debian Archive Automatic Signing Key (7.0/wheezy) It expires in about a year, and is shipped by default in Debian: $ dpkg -S /etc/apt/trusted.gpg.d/debian-archive-wheezy-automatic.gpg debian-archive-keyring: /etc/apt/trusted.gpg.d/debian-archive-wheezy-automatic.gpg With the current configuration, it might attempt to download the key from the network, which could then be hijacked by a MITM and break the entire trust chain built by AptSecure. If the key was used in the sources.list template to pin the repository, that would be one thing (it's not). But then it would fail every time that key gets rotated on the Debian server (that is: at every major release). So just remove the key: it serves no purpose than enable a possible MITM attack and creates an additional maintenance burden. (OpenPGP crypto-geeks will surely point out that the full fingerprint is used in the specification, and that this is normally not considered breakable the same way short key IDs are currently known to be easily breakable. I would counter that a fingerprint is still a checksum of the original keypair and could *eventually* be found to be vulnerable to certain attacks. OpenPGP as an ecosystem would likely fall apart at that point as self-signatures are also using fingerprints (if not long key IDs) but I'm disgressing: we do not rely on those for Secure Apt so let's just do the right thing.) Note that the `Ubuntu` section might be similarly affected, but I do not have an Ubuntu system to test this with right now. Finally, it should be noted that running apt-key the way the puppetlabs module does is completely unsafe. Keys should *NEVER* be added to the global trust ring in /etc/apt/trusted.gpg.d. Instead, they should be deployed in /usr/share/keyrings and mapped in the `sources.list` with an entry like: deb [signed-by=/usr/share/keyrings/example-archive-keyring.gpg] https://example.net/debian/ main That conventions are also documented in the Debian wiki here: https://wiki.debian.org/DebianRepository/UseThirdParty --- manifests/params.pp | 1 - 1 file changed, 1 deletion(-) diff --git a/manifests/params.pp b/manifests/params.pp index e7bcb33..76f06b9 100644 --- a/manifests/params.pp +++ b/manifests/params.pp @@ -82,7 +82,6 @@ class apt::params { 'Debian': { $backports = { 'location' => 'http://deb.debian.org/debian', - 'key' => 'A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553', 'repos' => 'main contrib non-free', } $ppa_options = undef -- 2.32.3