Use secure enclave for ephemeral key storage

[jalseth]

Description

Where possible (depending on OS/platform) gitsign should use hardware backed secure enclaves for private key generation and/or storage. Where this is not possible, gitsign should use a software enclave which uses OS features to protect the memory for the private key from other processes such as https://github.com/awnumar/memguard. This should also be true for the gitsign-credential-cache binary.

I'm happy to work on this if this sounds reasonable.

[wlynch]

💯 All for this!

There's already been some work done on the cosign side for hardware tokens - https://docs.sigstore.dev/cosign/hardware-based-tokens it's likely that we'll be able to leverage this in gitsign as well, since there's already a good amount of overlap between the 2 tools.

[jalseth]

Sounds good, but I think we should create a central module to house this logic rather than having each project re-implement it. If that SGTY I can start a repo under my namespace and we can migrate to the sigstore project ownership.

[wlynch]

👍 https://github.com/sigstore/sigstore is probably the right place for any shared behavior between gitsign/cosign.

[iavael]

As for software enclaves: I think it's better to utilize OS-provided tools like keyrings in linux (kernel ones, not those like gnome-keyring), rather than yet another userspace in-memory storage. Because libraries like https://github.com/awnumar/memguard cannot help against elephant in the room: someone using debugger to dump secrets that in gitsign case would still be stored in userspace memory.