Comment 4 for bug 1930281

Hi Paride,

Thanks so much (to you and James) for putting in the effort.

I have just been through the source code to apt-add-repository (https://tracker.debian.org/pkg/software-properties) and from what I can tell, there's no reason why the code in that repo shouldn't extend the "software-properties" library to properly provide a home for gpg keys and I also believe that apt-add-repository should be appropriately modified to permit specifying keys. I believe this is the correct solution to the problem as I don't believe there should be hundreds of different implementations to adding and removing keys from the apt repos.

I've been in contact with the apt tools maintainers regarding the possibility of making an official patch to the apt tools to support key management. We discussed multiple different solutions. From what juliank in #debian-apt on irc.debian.org says :

- He thinks the best solution will eventually be to add keys directly to the source.d files in the /etc/apt configurations. This way, keys will be stored with the sources rather than being linked.

- He (who is Ubuntu's apt tool contributor it seems) will not have the time in his schedule in the near future.

- We agreed that making the CLI tools able to support this functionality would be a good thing. But would require someone to take the time to do it.

- He says that he thinks cloud-init should come up with their own solution to fit the cloud-init model to handle this. He wasn't being cocky or rude. He seems to just believe that this is something cloud-init should support through its own tools as well.

Based on the last point, I think that he means that it would make sense that when someone specifies a key within the user-data and ties it to a repo, then the key should be dearmored and stored in the correct location and the signed-by should be configured appropriately.

The main reason I'm on board with this solution is that the "software-properties" toolkit seems to be unmaintained at this time. And there's no official API for handling this. In theory it seems that the location for storing the keys is distribution specific and unless someone does start maintaining the software-properties tools again, it might be best to pretend like the only solution is to just write it yourself.

As I have a work-around at this time, I will ignore it for now. But since apt-key is scheduled to be yanked from distros in 2022, I'm sure this is a topic that will need to be revisited. This means either deprecating the key: tag from the cloud-init apt module side (and documenting that run-cmd is the proper solution)... or it would mean implementing the tools for replacing apt-key.

Anyway thank you so much for your support with this and I'll leave it up "to the experts" (meaning your group) to decide what is best to do.