Existing credentials used/updated! about git-credential-keepassxc HOT 9 CLOSED

https://github.com/Frederick888/git-credential-keepassxc#ignoring-certain-entries

from git-credential-keepassxc.

Tried also with Azure DevOps personal access token. Not sure what happens in the background but the authentication works (it somehow finds an existing entry by the URL or whatever), prompts if access should be allowed (I've turned on Desktop Notifications feature).
If I accept, it stores the url into the entry properties but also changes the password field!
I'm not sure where the new token values comes from and would very much prefer if it did not change these entries.

I'd rather create any entries by hand and have a read-only access to my password database.

from git-credential-keepassxc.

In the meantime, there are two entries created in the Git folder: one for dev.azure.com and one for gitlab.com. These contain the correct values BUT the entry for Gitlab web site also gets updated and this is why the website password gets overwritten.
If I restore the original password, then I get prompted again, every time.

from git-credential-keepassxc.

By the way you bumped into this issue probably because you were actually trying to clone a repo or something and used this project to provide password to Git.

If this is the case, please do confirm that SSH is out of the picture for you, cos the 'updating passwords' behaviour you saw was actually Git initiating password updating requests. I actually wrote this project to provide SMTP password to Git, and later extended it for shell scripts. Pulling/pushing repo should still somewhat work in a hacky way, but really it should be your last resort.

from git-credential-keepassxc.

Thank you. That resolves the issue somewhat.

Do note that this section seems relatively irrelevant at the first glance. Hiding certain entries implies (to me) that they will be served by KeePassXC to the git credentials helper. I'm fine with that, doesn't raise any eyebrows.

However, overwriting the original password entry for Gitlab with the token is of serious concern. This entry is outside the Git folder.
Here I notice that the web site password gets overwritten by the access token, which is a Password field in a separate entry.

But I also notice that the Azure token also gets overwritten with some value, for which I have no idea where the value is coming from. Perhaps there is some entry that gets identified as valid. There could be some old tokens in the Trash bin, who knows.

from git-credential-keepassxc.

please do confirm that SSH is out of the picture for you

Yes, correct. I am using HTTPS access exclusively, since SSH is blocked on the network.
My concrete scenario is - setting the credentials helper to keepassxc and then continuing to use existing repositories (already cloned). This involves mostly Fetch/Pull but also Push operations.

OK, I see your point. Do you plan to develop the plugin in the direction where it is a full-scale git credentials helper that uses KeePass database as a backend? I think this would be a worthy goal. In due time, of course. It would eliminate storing the credentials in the local git credentials helper and would make the credentials portable over different workstations by synchronizing the KeePass file.
Cheers and thanks for a great helper! It does appear to work ok at the moment. I'll be observing the behaviour closely in the near future.

from git-credential-keepassxc.

Do note that this section seems relatively irrelevant at the first glance. Hiding certain entries implies (to me) that they will be served by KeePassXC to the git credentials helper. I'm fine with that, doesn't raise any eyebrows.

Fair enough. #49 <- a doc touch-up?

Do you plan to develop the plugin in the direction where it is a full-scale git credentials helper that uses KeePass database as a backend?

I think except for erase, which I intentionally didn't implement for safety and isn't supported by keepassxc-protocol anyway either, get and store are basically what man 7 gitcredentials needs almost? There are some quirks and limitations on both Git's and KeePassXC's sides (or KeePass with browser host extension that I gather you are using), which makes some cases tricky though. I think there are some assumptions that git-credential-whatever should have its own dedicated store, but unfortunately this is not the typical case of a KeePass(XC) user.

Though they recently added group to get-logins response. They didn't update the docs and I also only just noticed. I can in the future implement some 'Git group only mode' CLI flag if that's helpful?

from git-credential-keepassxc.

a doc touch-up

Great, thanks! It should help any new users to not get unpleasant surprises. With a security tool like this I think it is better to be conservative.

Git group only mode

My assumption was that this was the default behaviour already. As an end-user I don't know which component exactly is creating the Git folder but the assumption was, since it is created, that the operation will be limited to that only. This would also imply that the other entries in the database are relatively safe from being modified.

I think that would also eliminate most cases for the use of the KPH: git flag.

I'll try to use this as the default credentials store on different operating systems and environments and see how it goes. If I do have any suggestions, I'll create separate issues and you see which of them make sense.
As mentioned earlier, everything seems to work at the moment and without any extra pop-ups. Will see what happens when the tokens change or when other online services are used.

And, yes, I'm using KeePassXC. It is actively used by browser extensions in different browsers and works great. I try to minimize write operations coming from the browser and did not experience any unpleasant overwrites so far.

It would be convenient if the Plugin Data records could be created manually so that a full read-only access is used by Git but that does not seem to be the case at the moment.

from git-credential-keepassxc.

My assumption was that this was the default behaviour already.

Tbh these days I use this project much, much more in general shell scripts instead of with Git, so personally I'm comfortable with this default. Changing it would be an unexpected breaking change for other existing users as well.

Though I can see if it's possible to check whether the caller is /usr/lib/git-core/git-remote-http, and turn on 'Git group only' automatically, as I don't think/know any popular Git hosting services allow using user passwords here.

I'll merge the doc change and close this ticket. Please open a new one if you have other specific issues.

from git-credential-keepassxc.