gitsign
gitsign copied to clipboard
sigstore
Easier credential caching
I've started using this recently and need to login to GitHub each time i try to push something to the origin using GitHub's desktop application which gets annoying when dealing with multiple PRs/repos. Is there a way cache or store the login creds for a time period instead?
There is some work in progress to cache and reuse certificates, here: https://github.com/sigstore/gitsign/tree/main/cmd/gitsign-credential-cache
There are some noteworthy caveats and limitations at this time, but it's actively being worked on by @eddiezane and @wlynch
If you try it out and let us know how it goes that would be helpful feedback!
Would be good to get the credential-cache binary into homebrew and allow it to be enabled with brew services rather than using gitsign-credential-cache &
An alternative route could be a Chrome Extension, which is a bit more multi-platform.
Then when we close the browser, we lose the cache.
A Chrome extension is an interesting approach. I'd have to think about how it would cache things in a place the gitsign (or cosign) executables could get to them, but it might work.
Now that I'm thinking of it, what I really want a Chrome extension for is closing the OAuth window after I've finished OAuthing (https://github.com/sigstore/sigstore/pull/484)
@imjasonh I'd be happy to give it a try and let you know the feedback. Please let me know what branch/tag version I should be using.
@imjasonh I'd be happy to give it a try and let you know the feedback. Please let me know what branch/tag version I should be using.
You can try it out now following instructions at https://github.com/sigstore/gitsign/tree/main/cmd/gitsign-credential-cache, just be aware that it might change or go away in the future, and that there are security implications to caching these credentials.
I started working on dropping the extra binary and using the OS keystore. If that winds up not working I wanted to bake everything into a single binary that forks the daemon like gopls does. Just need to get a chance to finish it.
It would be great to pass the number of hours for the credentials to be cached. In our case, we are OK for the credentials to be on a developer's system for at least half a day. The threat model of someone stealing that file in that time and using it is a very acceptable risk, a day would be OK.
Like that the workflow is such that a developer at their machine only needs to log in at the start of the day. The threat model around machine compromise is more that it gets lost or stolen as the device is moving (i.e. between the workplace and home).
Of course, saving the credentials in the machine's keystore is even better but not a must have requirement for us.
