fb_apt update

[adsr]

Hello, we've written a version of fb_apt that replaces use of apt-key and /etc/apt/trusted.gpg.d¹ with per-repo keyrings managed by gpg and specified via Signed-By. It also uses the newer DEB822 format which we find easier to read and more concise in some cases. The cookbook API is similar except for the repos and keys attributes which are replaced with a sources hash:

node.default['etsy_apt']['sources']['repo_name'] = {
  'URIs' => 'https://repo.url.here',
  'Suites' => 'noble',
  'Components' => 'main',
  '_public_key' => read_file('repo_name-signing-key'),
}
# or `_fingerprint` instead of `_public_key` to fetch from a keyserver

Presently it doesn't try to manage anything in /etc/apt/trusted* nor accommodate older versions of Debian/Ubuntu or Chef.

We figure other users may want this functionality so contributing it back to this repo came up. Curious if the maintainers have a minimum level of back-compatibility they'd want before considering merging something like this, or if they'd be open to an fb_apt2 or something.

Happy to share code of course.

Footnotes

1. "The certificate MUST NOT be placed in /etc/apt/trusted.gpg.d or loaded by apt-key add." https://wiki.debian.org/DebianRepository/UseThirdParty ↩

[dafyddcrosby]

I think that as long as the existing attribute keys aren't clobbered, it might be better to put it into the existing fb_apt, since it's an easier runway to adoption from a cookbook metadata approach. If you wouldn't mind pushing a branch I can take a look at, I should be able to speak a little more to integrating that in :-)
As far as minimum levels of backwards compatibility, for distros it's (generally speaking) "support non-EOL and don't break older than that unless there's a compelling reason." For Chef versions, the current policy is "oldest supported major Chef version - 1," which means that we aim for Chef 16 support currently. The reasons for the "- 1" there are several, but it boils down to focusing on stable functionality in the client, not arbitrarily breaking open-source users who sync the cookbooks from this repo infrequently, and gives a bit of wiggle room when major version releases come out. That backwards-compatibility is best-effort, but if you see something violating it, please do point it out :-D

[taylorific]

Very, very nice with this folks! Backwards-compatible with a way to gradually transition to the new. Bravo!