Use modern APT keyrings on Debian family; require puppetlabs/apt 9.2

[kenyon]

This makes use of puppetlabs/puppetlabs-apt#1128 to store the public key in /etc/apt/keyrings and add a signed-by option to the sources.list.d entry.

[ekohl]

How is the migration on this. Does it clean up the old entry? Mostly asking because I want to know if this is backwards incompatible or not.

[kenyon]

How is the migration on this. Does it clean up the old entry? Mostly asking because I want to know if this is backwards incompatible or not.

This change adds the file for the keyring (https://github.com/puppetlabs/puppetlabs-apt/blob/0871cadcdcbc5f0e6540298fa11e9a3ebe884735/manifests/keyring.pp#L54-L61) and changes the line in the file in sources.list.d to add signed-by (https://github.com/puppetlabs/puppetlabs-apt/blob/0871cadcdcbc5f0e6540298fa11e9a3ebe884735/manifests/source.pp#L219).

[kenyon]

Need someone to approve a workflow run. Unit tests pass locally for me.

[ekohl]

One consideration: this will reach out to the internet on every Puppet run while I think previously it didn't. That also means the content of the GPG key may change at random and you wouldn't know, while previously the key ID would change. That begs the question: what is GPG key signing adding then?

Don't get me wrong, I do like this but I'd suggest to include the GPG key in this module and provide a parameter for the source (which would default to puppet://${module_name}/some_file.asc). If the key changes, users can easily change the source to something else but by default you don't put additional load on www.postgresql.org and get better security out of it.

[kenyon]

@ekohl good idea, implemented. That also makes the APT code consistent with the yumrepo code which contains the key in the module.

[kenyon]

Forgot the parameter to be able to override it, I'll do that.

[kenyon]

Wellllll, this module is kind of crazy. The postgresql::repo::yum_postgresql_org class doesn't provide a way to override gpgkey, so I'm going to leave postgresql::repo::apt_postgresql_org as is. I think, if the user doesn't want to use the provided defaults for the package repo, they'll have to set $manage_package_repo = false and manage it themselves.

[ekohl]

I'll kick off ci, but looks good. Overall I think the GPG keys can use more parameters. That was already the case before this and it doesn't make it worse.

We can ensure the old way is ensured absent, but that can cause problems. Perhaps something for the release notes?

[kenyon]

We can ensure the old way is ensured absent, but that can cause problems. Perhaps something for the release notes?

Yeah, I don't think it's necessary to remove the key from /etc/apt/trusted.gpg because it won't be used (by this source anyway) when signed-by is added to the sources.list.d entry managed by this module.