update status

This commit is contained in:
Joey Hess 2018-06-21 13:45:07 -04:00
parent b657242f5d
commit 838b65bd6b
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38

View file

@ -119,10 +119,6 @@ CLAIMURL and CHECKURL, and then themselves download the content of urls
in response to a TRANSFER RETRIEVE will have the same problems as
git-annex's url downloading.
> Checked all known external special remotes
> to see if they used GETURLS. ipfs did, but not in an exploitable way.
> datalad does; looped in its developers to asess. Rest appear not to.
An external special remote might also make a simple http request to a
key/value API to download a key, and follow a redirect to file:///
or http://localhost/.
@ -153,10 +149,19 @@ special remotes, to block the redirection attack. There could be a config
setting to say that the git-annex repository is not being shared with
untrusted third parties, and relax that check.
> TODO
> done
Tocho Tochev has updated git-annex-remote-pcloud to not follow http
redirects.
TODO Tighten down the gpg decryption to only allow decrypting with
the provided symmetric key, as a further protection against CVE-2018-10859.
If this can be done, then only remotes with encryption=pubkey will
really need to reject WORM and URL keys, since encryption=shared
and encryption=hybrid use a symetric key that's only used to encrypt data
for that remote. Although opening those back up to WORM and URL would
allow the remote sending other content stored on it, to get the wrong
content decrypted. This seems unlikely to be a useful exploit in most
cases, but perhaps not all cases, so probably best to not relax the
rejection aven when doing this. It's still worth doing as a belt and braces
fix.
----