I worked around that one (I think I fully checked it out to Termux's $HOME, then moved it to sdcard. If I recall correctly, adjusted mode failed with more permission issues. But direct mode works... (I don't have the device in front of me, but it may be an actual SD card, not the fake sdcard. Which of course doesn't support permissions either.)

I wonder if it'd be easy enough to do a LD_PRELOAD hack to "fix" chmod.

Just got bitten by this. I guess it is not a very rare situation, so I was wondering, are there any known workarounds?

As of that same commit (a14f6ce75), running git annex init in a fresh repository no longer creates uuid.log:

% cd $(mktemp -dt gx-XXXXXXX)            
% git init
Initialized empty Git repository in /tmp/gx-kpnGSjg/.git/
% git annex init
init  ok
% git ls-tree -r git-annex  ;# no output

All fixed now.

I've gotten secure ftp url downloading working now. Have not yet put back in the handling of http-to-ftp redirects.

Yet another problem: A ftp server might have both IPv4 and IPv6 addresses, and only one might work. So git-annex would need to run curl more than once if substituting in IP.

Hmm.. curl has a --resolve that could be used instead of git-annex replacing the server hostname with its IP. This allows passing both ipv6 and ipv4 addresses:

curl --resolve *:80:[::1],127.0.0.1 http://google.com/

And it does also work for ftp and other protocols, but the protocol port number has to be included and can't be wildcarded. In particular, if the ftp url is on a nonstandard port, that port has to be included, otherwise port 21.

In a PASV ftp connection, the server provides to the client an IP address and port to connect to. That is exploited by a ftp bounce attack. (Which I last thought about in like 1998? Why are we still using these bad old protocols?)

So it seems git-annex can't rely on checking the ftp server IP is not local, because the non-local ftp server could use that to get the client to connect to a local ftp server. After content from that gets added to the git annex, we're back to CVE-2018-10857.

curl defaults to PASV of course (active FTP is unlikely to work on the "modern" non-p2p internet). Seems curl does have a --ftp-skip-pasv-ip that makes it ignore whatever IP address the FTP server might present and just continue to use the same server IP.

Thank you for the great work done with git-annex!

I am not much familiar with how the Debian maintainers decide to address - or not - a bug/patch like this one. But if dropping a line to support the related Debian Bug Report or subscribing to it could help, I invite everyone to do it. In my case, I have a 6TB RAID1 ARM Debian box meant to be used with git-annex but without it...

The netrc(5) file does use the hostname of the ftp server, so if git-annex swapped in an IP address it resolved it would not match the netrc file. But curl only reads the file when --netrc is used.

If annex.web-options is set to --netrc (or anything), and annex.security.allowed-http-addresses=all, git-annex uses curl already and the security measures are disabled.

So, git-annex could replace the ftp server hostname with the IP address when not so configured, and nothing that currently works would break, and this problem would be solved without needing any new configuration.

Thanks for tracking down the ghc bug. The git-annex standalone build is built on Debian using its toolchain. So once that bug gets fixed, I will just need to make sure the builder is up-to-date to close this.