don't hardcode an old key from official mirrors for Debian backports

[anarcat]

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) <[email protected]>

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

PS: I tried to file an issue for this in JIRA, but the password reset form is failing for me. It seems I have been away for too long or something:

The password could not be changed by the credentials provider. org.springframework.ldap.NoPermissionException: [LDAP: error code 50 - Insufficient Access Rights]; nested exception is javax.naming.NoPermissionException: [LDAP: error code 50 - Insufficient Access Rights]; remaining name 'uid=anarcat,ou=community,ou=users,dc=puppetlabs,dc=com'

[anarcat]

ping?

[lionce]

Hello @anarcat ,

Thank you for your contribution to improve this module. :) Looking good to me.

Cheers!