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:
parent
c981683f77
commit
b657242f5d
18 changed files with 131 additions and 34 deletions
|
@ -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
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue