Repository navigation
bridges: better credentials management #327
Description
Excerpt of the discussion:
Nice find, I had no idea it existed. Using real secret store instead of the git config is definitely a nice thing to have.
Toying a bit with that thing, I found that:
- it's a way to interact with user-specified secret storage
- if no credential helper is configured (virtually 100% of users) it default to a one off prompt. Nothing is stored, even between git invocation.
- a cache system exist (need to be configured) to store credential in memory in between git invocation
- a storage system exist (need to be configured) to store credential in a clear-text file
- the expressiveness of this credential system is highly coupled with what git know: URLs, login, password. Storing tokens or metadata is kinda hacky.
So, what I derive from that is:
- this system is deeply tied to what git understand but could be abused for our needs. A standardized way to talk to a secret store is neat, especially as it could require no git-bug specific configuration.
- instead of being a new kind of credential (token, password, login/password), this would really be a new way to store credentials for the credential system
- credential's metadata can keep being stored in the git config. Shoehorning those into the git credential system seems a bit too much
- in term of UX, an explicit choice between the git config and this more secure system is not required each time a credential is stored. It seems ok to me to use that better system if available and default to the git config if not. It may cause problems though if this system become unavailable and credentials are left in an incoherent state.
Does that sounds reasonable to you ? If so I'll merge my branch and we can add this feature later as it's orthogonal to everything else. Only the storage functions will be impacted.
Originally posted by @MichaelMure in #324 (comment)
Activity
Julian commentedon May 22, 2020
Not sure if here's the right place to add this comment, but even beyond
git-credential, isn't using the git config a bit surprising? It surprised me certainly -- I have my configuration itself tracked in git, and seeing secret credentials pop up in the file breaks being able to do that (of course I noticed, but yeah I definitely didn't expect secrets to be added to the global git config as part of setting up git-bug with a bridge)karlicoss commentedon May 23, 2020
Agree that adding directly to git config is a bit extreme (because people usually expect this file to be public). Perhaps an easy fix without changing the model would be using an
includesection in git config instead:and git-bug keeps its token sections
.config/git-bug/token.MichaelMure commentedon May 23, 2020
Using the git config is not perfect but it has a very nice property: it works cross platform and across repository very easily. I'm open to suggestion and help to change that though.
Julian commentedon May 23, 2020
Cool! Glad to hear.
In Python-land if it were me I may be considering something like the keyring module.
Maybe there's something similar for go (OS-agnostic access to the operating system's credentials keychain)
But can have a think or look around.
sudoforge commentedon Jun 17, 2020
Just a note: using the
includesection won't work, becausegit-bugcurrently uses the--globaland--localflags respectively, which do not follow includes. If specifying a file is desired, includes can be followed by also using--include.Since this is off-topic for this issue, it's probably best to continue the discussion in #406.
MichaelMure commentedon Jul 29, 2020
Closing as the likely path forward is to not use the git global config anymore but not the git credential thing either.
What is being cooked in #412 is to use the user system keyring (accessed through https://github.com/99designs/keyring) with a simple file in the user config dir as a fallback.
mpldr commentedon Mar 1, 2023
Storing the Secrets in a freedesktop.org Secret Service would probably be the best way to solve this on Linux.
sudoforge commentedon Mar 1, 2023
my vote would be for a systemd-creds entry for linux. unless that
keyringlib already supports that.mpldr commentedon Mar 1, 2023
Would that even be applicable for git-bug? If memory serves me well systemd-creds is intended to be used for credentials used by units.
sudoforge commentedon Mar 1, 2023
it's a generic tool for encrypting and decrypting things. yes, it's built into systemd and available to units, but there's nothing stopping anyone from using
systemd-credsdirectly.mpldr commentedon Mar 1, 2023
Then I would suggest to instead opt for the system-independent standard already implemented by various password (and other secrets) managers.
sudoforge commentedon Mar 2, 2023
If we're looking for a cross-platform solution, letting the user pick how their credentials are stored and using
git-credentialis actually what I'd argue for, since that is a) available in Git, requiring no additional user-managed dependency, and b) not limiting the user to supported secret backends (e.g. a particular keyring).I do not have
gnome-keyringinstalled, and have no desire to install it just so I can use it for managing mygit-bugcredentials -- I'd much prefer to use my existing password store.7 remaining items
sudoforge commentedon Mar 4, 2023
Of course; DIYing this would be a non-optimal solution.
A simpler implementation of "cascading support" is simply:
because
git-credentialscan be configured (by the user) to proxy out to whatever other solution they want.[-]bridges: support user secret storage through git-credential[/-][+]bridges: better credentials management[/+]smoyer64 commentedon Mar 5, 2023
sudoforge commentedon Mar 6, 2023
I don't see how using another application to abstract the storage mechanism away is any different from using some command specified in gitconfig (which is what
git-credentialsdoes with thecredential.helperparameter), which, as I've detailed in other comments in this thread, avoids requiring the user to install a new dependency, and avoids any sort of limitation on how the user wants to provide credentials togit-bug.In fact, I think referencing
git-credentialhere has added confusion around what we need to do. Let's scratch that topic.Piping out to a user-defined command to fetch credentials, securely storing that input somewhere, and going about our business seems to be the most straightforward way to accomplish this without much complexity.
We then get the value for this, perform whatever validation we need to (e.g. does the program exist in
PATH?), execute it, report back and short circuit if it fails, else take thestdoutas input, store it securely (memguard?), and use it as the credential when authenticating.smoyer64 commentedon Mar 6, 2023
I didn't mean we should use
chezmoi... I meant we should pick an abstraction that ultimately allows the user to choose. I'm actually in agreement with you WRT using something like thecredential.helper.github-actions commentedon Jul 23, 2024
This bot triages untriaged issues and PRs according to the following rules:
lifecycle/stalelabel is appliedlifecycle/stalewas applied, the issue is closedTo remove the stale status, you can:
lifecycle/stalelabel