Recent comments posted to this site:

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.

Comment by anthony Mon Jun 10 16:52:23 2019
Just got bitten by this. I guess it is not a very rare situation, so I was wondering, are there any known workarounds?
Comment by kirelagin Sat Jun 8 13:03:49 2019

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
Comment by kyle Wed Jun 5 15:18:30 2019
All fixed now.
Comment by joey Thu May 30 20:03:28 2019

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

Comment by joey Thu May 30 18:50:18 2019

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.

Comment by joey Thu May 30 15:59:57 2019

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.

Comment by joey Thu May 30 15:53:26 2019

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...

Comment by emanuele.olivetti Wed May 29 17:36:06 2019

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.

Comment by joey Wed May 29 14:22:57 2019

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.

Comment by joey Wed May 29 13:58:43 2019