-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Easier credential caching #98
Comments
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 |
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 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 (sigstore/sigstore#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. |
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. |
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?
The text was updated successfully, but these errors were encountered: