I’m not quite sure where this topic should go, since both snapcraft is the user-facing key handler, but it just shells out to snapd, and then snapd uses it with snap sign… so this really applies to both snapcraft and snapd.
Say I’m making a custom image, using a custom model assertion. I’m following this tutorial (ish, I’m using the snapcraft commands to generate and list the keys). I need to sign the model definition, and thus need a key to do it. We have snapcraft as an opaque wrapper around snapd, which, judging from the contents of ~/.snap/ is an opaque wrapper around gnupg.
Is there any way I can use my own already-existing key for this? Or must I generate a new one just for signing assertions?
Alright, thanks for the response. Are those constraints documented anywhere? I agree that having more key management (import/export) functionality would be nice.
I need to recollect the details, there’s no official doc except in code comments I think and an internal doc ATM. The issue is mostly that the view on how to identify the key from snapd POV vs PGP will differ unless the key respects the constraints very precisely. The main reason for this situation is while the signing, packet format is fine for us, we didn’t want to trust, especially going forward, the ways PGP identifies keys and matches signature packets back to keys.
