tonyespy
commented
2 days ago As I pointed out in an out-of-band conversation, moving private keys around like this implies multiple copies of these keys exist, which isn't a great idea from a security perspective, especially if these are Brand keys. Let's see what the snapcraft developers have to say, but IMHOP this isn't something we should officially support.
What needs to get done
See https://forum.snapcraft.io/t/how-to-import-snapcraft-keys-without-logging-in/43716
It is possible to export private snapcraft keys through accessing gpg directly. However, when trying to import the private key on a "clean" system things fail, because snapcraft has not initialized gpg on install. You can "work" around this issue by logging into snapcraft with a "dummy" account and doing any random key-action (such as list-keys), but this doesn't feel like the prettiest solution.
It would be nice if snapcraft supported exporting and importing private keys from its own UI.
Another option would be to extend snap itself to be able to receive a private-key file to sign things rather than just a key name. This might even be better as it would improve clarity on the meaning of the private key; you should be able to use it independent of anything else to sign things.
Why it needs to get done
Our usecase: We sign our models etc. from a machine running in CI. We have the private key in a keyvault; in CI the job retrieves this key and imports it into snapcraft before it runs
snap sign .... This is our usual workflow; we create "empty" runners that only have publically available packages installed, and all secrets are injected before doing any signing actions. Because the runners are initialized on the spot, the gpg keychain is always empty.In addition, I feel like the lack for a clear pathway to use snap keys without logging in creates a false impression that the login and keys are somehow linked.