Please describe the problem.
git annex push does not trigger git credential retrieval reliably, but forces manual credential entry.
What steps will reproduce the problem?
I have the following git-credential setup
[credential]
helper = cache --timeout 21600
helper = oauth
Most of my remotes are on some forgejo-aneksajo site. This setup makes git perform an oauth2 workflow against forgejo, and then use the cached credential for a couple of hours. I find this convenient.
git-annex usage also benefits from this setup, as it appears to be able to use a cached credential fine.
But when a credential is not yet cached, the oauth workflow is not triggered when git-annex needs a credential. Instead, it causes a prompt:
❯ git annex push
copy vid/trr379-metadata-website-update.mp4 (to origin...) Password for 'https://oauth2@<host>':
When I ctrl-c that and immediately afterwards run git-push, this is happening:
❯ git push
Please complete authentication in your browser...
https://<host>/login/oauth/authorize?client_id=a4792ccc-...&code_challenge=mHvQCJU...&code_challenge_method=S256&redirect_uri=http%3A%2F%2F127.0.0.1%3A43407&response_type=code&state=QTFf...
...
To https://<host>/<repo>.git
0ee8c89..4977dac main -> main
Afterwards, git-annex-push runs fine too.
❯ git annex push
copy vid/trr379-metadata-website-update.mp4 (to origin...)
ok
(recording state in git...)
push origin
Everything up-to-date
...
remote:
remote: Create a new pull request for 'synced/git-annex':
remote: https://<host>/<repo>/compare/main...synced/git-annex
remote:
remote:
remote: Create a new pull request for 'synced/main':
remote: https://<host>/<repo>/compare/main...synced/main
remote:
To https://<host>/<repo>.git
aec36a7..18aa9ab git-annex -> synced/git-annex
0ee8c89..4977dac main -> synced/main
ok
My expectation would be that a git-annex push would be able to trigger the oauth workflow in the same way that Git does.
What version of git-annex are you using? On what operating system?
git-annex version: 10.20260316-gf01ba218ffb36e8607516d9895dfaeaeaf101a05 on Debian forky/sid
I am now seeing the "same" problem in a different context, where no 3rd-party credential helper is involved.
Concretely, I have a Forgejo actions workflow that manually pre-fills a credential via
This appears to be working, as confirmed by
which returns
However, running
git annex pushimmediately afterwards has the git-push parts working, but the internalcredential fillfail withfatal: could not read Username for 'https://hub.psychoinformatics.de': No such device or address(full log below).I wanted to investigate further and added a credential "helper" that documents what was queried
I also switched from
annex pushtoannex copy(because this is the aspect that failed). I now see (what I could have seen in the log above already). The issue is not that the credential isn't retrieved properly. It is actually rejected, and the superficial/original error is the result of prompting for another valid credential. Here is the log of a copy call:At the risk of introducing a second red herring, this seems similar to git annex checkpresentkey removes git credentials. But I don't think the same, because here
git-annex pushworks aftergit pushhas cached a credential, so git-annex is apparently not removing the cached credential.Could you link to the forgejo-aneksajo issue that is/was being dealt with?
The "Password for" prompt comes from git-credential, not git-annex.
I was able to reproduce that behavior using a
git-credential-foo"helper" which just exits successfully but does not output any credentials. With the git config adjusted to use that (as well as cache), git runs it but then falls back to the password prompt:So it seems likely that
git-credential-oauthis just choosing not to do anything when git-annex runs it, and then git is falling back like that.Why it would choose to do that I don't know, but I suppose it could be a difference in that is sent to it on stdin when called by git-annex vs by git.
In your bug report I noticed that the password prompt is for
"https://oauth2@<host>"but when you git push it's to"https://<host>/<repo>.git". I'm not clear on if these were really different urls or if it was a mistake in your sanitization.If there are different urls,
git-credential-oauthcould have acted on one and not on the other. Although I don't understand why runninggit pullwould then cache a credential that would be used on a different url.Assuming you're using
git-credential-oauthfrom eg the Debian package of that name, here's an example of it not acting on an url:Running it the same way with github.com doesn't behave that way:
This behavior is not network dependent. In fact,
git-credential-oauthhas a pile of special casing for different hosts and different servers, including a looksLikeForgejo case. If it does not recognize the server name, it doesn't do anything without further configuration.@mih told me the url privately. (There is only 1.)
It is indeed a host which when passed to
git-credential-oauth getit decides not to do anything.But,
git pushto the same url usesgit-credential-oauth getand it does do oauth.Dumping what git sends to it, there are additional fields beyond what git-annex sends:
The wwwauth field is the relevant one.
There was a past bug about a very similar problem: https://git-annex.branchable.com/bugs/__96__git_annex_push__96___does_not_use_git-credential-oauth/
32fac0b103db1982b748f15def825e1490d34f50 was supposed to fix that, by passing the www-authenticate http header in to git credential.
This bug must be a case where that doesn't happen.
git-annex pushis talking togit-annex p2phttpwhich is on aForgejo-aneksajoserver.In this case, the server responds with HTTP 401, and I have verified that response does not include the
www-authenticateheader.So, git-annex's code to send that header on to
git-credentialseems fine, and this needs to be fixed in either p2phttp or Forgejo-aneksajo to make the header be sent. I suspect it will need to be done in Forgejo-aneksajo.git-annex pushwon't always trigger this problem because often it has things togit pushto the server before sending content. A more reliable way is to usegit-annex copy --to.