@mih told me the url privately. (There is only 1.)

It is indeed a host which when passed to git-credential-oauth get it decides not to do anything.

But, git push to the same url uses git-credential-oauth get and it does do oauth.

Dumping what git sends to it, there are additional fields beyond what git-annex sends:

capability[]=authtype
capability[]=state
protocol=https
host=<obscured>
wwwauth[]=Basic realm="Gitea"

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-oauth could have acted on one and not on the other. Although I don't understand why running git pull would then cache a credential that would be used on a different url.

Assuming you're using git-credential-oauth from eg the Debian package of that name, here's an example of it not acting on an url:

joey@darkstar:~/tmp/x>(echo 'protocol=https'; echo 'host=example.com'; echo 'username=oauth2') | git-credential-oauth get
joey@darkstar:~/tmp/x>

Running it the same way with github.com doesn't behave that way:

joey@darkstar:~/tmp/x>(echo 'protocol=https'; echo 'host=github.com'; echo 'username=oauth2') | git-credential-oauth get
Please complete authentication in your browser...

This behavior is not network dependent. In fact, git-credential-oauth has 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.

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:

joey@darkstar:~/tmp/a1>GIT_TRACE=2 git push foo
12:08:19.869469 git.c:502               trace: built-in: git push foo
12:08:19.869942 run-command.c:673       trace: run_command: GIT_DIR=.git git remote-https foo https://github.com/joeyh/gitannexbuilder
12:08:19.869965 run-command.c:765       trace: start_command: /usr/lib/git-core/git remote-https foo https://github.com/joeyh/gitannexbuilder
12:08:19.873067 git.c:808               trace: exec: git-remote-https foo https://github.com/joeyh/gitannexbuilder
12:08:19.873107 run-command.c:673       trace: run_command: git-remote-https foo https://github.com/joeyh/gitannexbuilder
12:08:19.873121 run-command.c:765       trace: start_command: /usr/lib/git-core/git-remote-https foo https://github.com/joeyh/gitannexbuilder
12:08:20.549858 run-command.c:673       trace: run_command: 'git credential-cache get'
12:08:20.549927 run-command.c:765       trace: start_command: /bin/sh -c 'git credential-cache get' 'git credential-cache get'
12:08:20.555753 git.c:502               trace: built-in: git credential-cache get
12:08:20.556612 run-command.c:673       trace: run_command: 'git credential-foo get'
12:08:20.556635 run-command.c:765       trace: start_command: /bin/sh -c 'git credential-foo get' 'git credential-foo get'
12:08:20.561465 git.c:808               trace: exec: git-credential-foo get
12:08:20.561506 run-command.c:673       trace: run_command: git-credential-foo get
12:08:20.561530 run-command.c:765       trace: start_command: /home/joey/bin/git-credential-foo get
Username for 'https://github.com':

So it seems likely that git-credential-oauth is 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.

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 push works after git push has 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?

This would still be worth doing despite git-annex supporting BLAKE3 now. XXHASH is even faster, due to not needing to do the work to be cryptographically secure.

It lowers the probability to only files that happen to start with the same prefix. There are many cases where 2 versions of a file start with the same data and diverge later, think eg a filesystem image where one file has been changed.

So I think this would give a false sense of protection, kind of like wearing a steel toed boot but with a gun still pointed at your foot.

It's better to just not use WORM. Modern computers can hash really fast, especially if you use BLAKE3.

It would be possible to add other blake3 hash lengths, but I have not investigated if there is any benefit (eg performance or security) in using anything other than BLAKE3_256. Will wait to see if anyone comes up with a use case for them.

I don't think it will be a problem to adapt the existing code to use them.

The above patches did have a memory leak.

I've fixed that, and merged to master.

Updated to blake3-0.3 and it is indeed even faster: 6.80s

Impressive, that's twice as fast as botan's sha256.

blake3 does outperform botan's sha256. I benchmarked it at 8.30s vs 0:14.36s adding a 4 gb file. That's with blake3-0.2. Newer versions of the blake3 library may be faster yet.

Since the above patches no longer cleanly apply, I have committed my update of them to the blake3 branch. My above review items are not addressed yet in that branch. I did add Blake3 to BuildFlags.hs though, which was a problem I missed in my earlier review.

Also, the haskell blake3 library has gotten a 0.3 release, which the code needs to be updated to build with. (I see no need to retain support for 0.2.)