In Snapcraft, we support using third-party apt repositories in plugins. apt-secure defaults to not verifying the repo certificates in Xenial, so Snapcraft doesn’t do anything with repo keys. To quote apt-secure's manpage:
In the future APT will refuse to work with unauthenticated repositories by default until support for them is removed entirely. Users have the option to opt-in to this behavior already by setting the configuration option Acquire::AllowInsecureRepositories to false.
As promised, in Yakkety this default changed, which means that any plugin that uses third-party repositories fails to update its index because its key public key isn’t on the system.
We’re currently working around that by making the behavior consistent, but that means the behavior is consistently bad: not verifying at all. We should discuss how we actually want to solve this problem, by adding the ability to ack repo keys.
My strawman to start the discussion:
We currently support a plugin declaring its repos via the PLUGIN_STAGE_SOURCES property. I suggest adding a new property called PLUGIN_STAGE_SOURCES_KEYS that returns a list of public key IDs which will be handed off to apt-key before attempting to communicate with the repo. They could also be a URL or path to a keyfile.
Yeah that would probably use the same code path (at least for apt repos), but note that this is specifically for sources set in the plugin itself, not in the YAML.
Well, things that use apt repo configurations internally will also need a way to be configured for non-Ubuntu targets too. But I agree something needs to be done about it.
Maybe it would make sense for the plugin to actually create its own appropriately configured Repo? In the case of catkin the plugin currently passes the sources via PLUGIN_STAGE_SOURCES and also uses its own repo.Ubuntu instance. Those could be re-used and we could have distro-specific APIs like sources and keys that may not make sense for all future backends.
I am not fond of having insecure repos by default everywhere. We should probably follow best practices and add some logic to add the keys when dealing with ros (surfaced at the plugin level, not the parts level, that is the other linked discussion).
