enforce retrievalSecurityPolicy

Leveraged the existing verification code by making it also check the
retrievalSecurityPolicy.

Also, prevented getViaTmp from running the download action at all when the
retrievalSecurityPolicy is going to prevent verifying and so storing it.

Added annex.security.allow-unverified-downloads. A per-remote version
would be nice to have too, but would need more plumbing, so KISS.
(Bill the Cat reference not too over the top I hope. The point is to
make this something the user reads the documentation for before using.)

A few calls to verifyKeyContent and getViaTmp, that don't
involve downloads from remotes, have RetrievalAllKeysSecure hard-coded.
It was also hard-coded for P2P.Annex and Command.RecvKey,
to match the values of the corresponding remotes.

A few things use retrieveKeyFile/retrieveKeyFileCheap without going
through getViaTmp.
* Command.Fsck when downloading content from a remote to verify it.
  That content does not get into the annex, so this is ok.
* Command.AddUrl when using a remote to download an url; this is new
  content being added, so this is ok.

This commit was sponsored by Fernando Jimenez on Patreon.
This commit is contained in:
Joey Hess 2018-06-21 13:34:11 -04:00
parent c981683f77
commit b657242f5d
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
18 changed files with 131 additions and 34 deletions

View file

@ -1228,7 +1228,7 @@ Here are all the supported configuration settings.
Note that even when this is set to `false`, git-annex does verification
in some edge cases, where it's likely the case than an
object was downloaded incorrectly.
object was downloaded incorrectly, or when needed for security.
* `remote.<name>.annex-export-tracking`
@ -1425,6 +1425,43 @@ Here are all the supported configuration settings.
these IP address restrictions to be enforced, curl and youtube-dl will
never be used unless annex.security.allowed-http-addresses=all.
* `annex.security.allow-unverified-downloads`,
For security reasons, git-annex refuses to download content from
most special remotes when it cannot check a hash to verify
that the correct content was downloaded. This particularly impacts
downloading the content of URL or WORM keys, which lack hashes.
The best way to avoid problems due to this is to migrate files
away from such keys, before their content reaches a special remote.
See [[git-annex-migrate]](1).
When the content is only available from a special remote, you can
use this configuration to force git-annex to download it.
But you do so at your own risk, and it's very important you read and
understand the information below first!
Downloading unverified content from encrypted special remotes is
prevented, because the special remote could send some other encrypted
content than what you expect, causing git-annex to decrypt data that you
never checked into git-annex, and risking exposing the decrypted
data to any non-encrypted remotes you send content to.
Downloading unverified content from (non-encrypted)
external special remotes is prevented, because they could follow
http redirects to web servers on localhost or on a private network,
or in some cases to a file:/// url.
If you decide to bypass this security check, the best thing to do is
to only set it temporarily while running the command that gets the file.
The value to set the config to is "ACKTHPPT".
For example:
git -c annex.security.allow-unverified-downloads=ACKTHPPT annex get myfile
It would be a good idea to check that it downloaded the file you expected,
too.
* `annex.secure-erase-command`
This can be set to a command that should be run whenever git-annex