Original whining and use case is buried in the comments to CVE fix announcement. In summary: http_proxy
environment variable could point to some address within local network (e.g. 10.0.0.1/24
). security.allowed-ip-addresses
(or older annex.security.allowed-http-addresses
) seems to support only a whitespace separate list of addresses (too tedious to list for sizeable private networks) or "all" (too much) not support networks.
In case of http_proxy
it would also be valuable to be able to limit to specific (e.g. privileged) port(s) (thus kicking back to http
from a generic ip
), to avoid opening access to some malicious user providing URLs on the same private network on some other port. I think both address + port "wishlist" items are related thus filing in a single issue.
If the goal is just to allow the
http_proxy
to be used even though it points to a proxy on the local network, then it could be done with some "trustproxy" config, without needing to complicate annex.security.allowed-http-addresses.I am doubtful about the security of local http proxies though, in the threat model that git-annex needs to worry about. When
http_proxy
is set, urls get passed to it as-is; git-annex is not currently able to interpose any checking that the url is on an allowed IP address.(git-annex cannot send http://$ipaddr/ to the http proxy, because the http server may require a specific hostname. And if git-annex only resolved the hostname and rejected ones on invalid IPs, then the http proxy would again resolve the hostname, and might see a different IP address than git-annex did.)
So allowing a local http proxy seems just as insecure as annex.security.allowed-http-addresses=all.
As to ports, it seems reasonable to support eg security.allowed-ip-addresses=[127.0.0.1]:80 to make sure that the massive electron app I have running on some random other port doesn't get abused to exfiltrate the contents of my $HOME. As a non-random example.
Back to the proxy question, I suppose if you have multiple internal networks and the proxy can only access one of them (eg your DMZ), then allowing access to the proxy is not as bad as "all".
And then DMZ/24 makes explicit that git-annex can access everything in that network.
Nor am I opposed to that syntax generally (although as I user, I consider it pretty opaque TBH, not being in the habit of counting bits in my head). The only haskell implementation I can find is in the
ip
package, which would be a new dependency for git-annex.