current workaround, in my site_settings:

# https://github.com/facebook/chef-cookbooks/issues/63
node.default['fb_apt']['keyring'] = '/etc/apt/trusted.gpg.d/fb_keyring.gpg'
node.default['fb_apt']['keys'] = {}

from chef-cookbooks.

That didn't work... even with a fix I had to make, I had to make keyring be nil to avoid it touching keys at all.

from chef-cookbooks.

OK so it gets a bit worse:

• fb_apt isn't passing --keyring #{keyring} into apt-key add... but even if you do, it's totally ignored
• As such, specifying a key will always give you an asymmetric bug - so the only sane way to do things is to never specify a keyring. This means we will see all loaded keys, and never try to load a key that's loaded. But it ALSO means all keys we want to mess with are loaded into /etc/apt/trusted.gpg, which is probably fine.
• Debian has stopped putting any official keys in the main keyring - they are all in files in /etc/apt/trusted.gpg.d/, the keys I have on the main keyring are all from other repos I have - dropbox, bjn, etc.

So, I can see two paths forward:

Option 1

• Drop the node['fb_apt']['keyring'] option
• Pre-poluate the keys hash (at attribute time) with all keys from "official" files (/etc/apt/trusted.gpg.d/debian-archive-* and /etc/apt/trusted.gpg.d/ubuntu-keyring.*) so that we don't try to delete them (it won't work anyway, it'll try to delete them from the main keyring and fail).
• Then security-concious people could instead overwrite that as well as make their own rule to nuke /etc/apt/trusted.gpg.d/*, and put whatever keys they wanted trusted in node['fb_apt']['keys'], but for everyone else, everything would "just work" - new keys would get added properly, keys dropped would be removed properly, and "official" keys would stay out of the way.
• By default cleanup keyrings in /etc/trusted.gpg.d that are not owned by any rpm/deb. If we do this, keyids on files that aren't part of the OS but are part of a package ALSO need to be pre-populated.

Option 2

• Drop the node['fb_apt']['keyring'] option
• Not pre-populate keys, but instead have an option like preserve_pkg_owned_keyrings. It defaults to true
  • If it's true then in the provider, we build a hash like of file to keyids from the output of apt-key finger. Any file owned by a package, we preserve, any others we don't. We take the list of preserved keyids, along with any the user specified, and remove any keys still left over.
  • If it's false, we delete every single file in /etc/trusted.gpg.d/, and then hope the user has all necessary keyids in the keys hash. We can pre-populate some, but we're not going to always be on top of everytime debian or ubuntu adds a key (we're already missing ubuntu keys), so there should be big warnings to the user

Option 3

Stop trying to holistically manage keys altogether. Have a list of "keys" and "blacklisted_keys". We add keys if they're not there, and we remove blacklisted keys if they are there and on the main keyring (or if they're the only key on some other keyring).

My preference is option 1...

from chef-cookbooks.

Fixed in #66

from chef-cookbooks.