| Commit message (Collapse) | Author | Age |
| |
|
| |
|
|\ |
|
| | |
|
| | |
|
| | |
|
|\| |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
remote's key.
encryptionSetup must be called before setRemoteCredPair. Otherwise,
the RemoteConfig doesn't have the cipher in it, and so no cipher is used to
encrypt the embedded creds.
This is a security fix for non-shared encryption methods!
For encryption=shared, there's no security problem, just an
inconsistentency in whether the embedded creds are encrypted.
This is very important to get right, so used some types to help ensure that
setRemoteCredPair is only run after encryptionSetup. Note that the external
special remote bypasses the type safety, since creds can be set after the
initial remote config, if the external special remote program requests it.
Also note that IA remotes never use encryption, so encryptionSetup is not
run for them at all, and again the type safety is bypassed.
This leaves two open questions:
1. What to do about S3 and glacier remotes that were set up
using encryption=pubkey/hybrid with embedcreds?
Such a git repo has a security hole embedded in it, and this needs to be
communicated to the user. Is the changelog enough?
2. enableremote won't work in such a repo, because git-annex will
try to decrypt the embedded creds, which are not encrypted, so fails.
This needs to be dealt with, especially for ecryption=shared repos,
which are not really broken, just inconsistently configured.
Noticing that problem for encryption=shared is what led to commit
cc54ff9e49260cd94f938e69e926a273e231ef4e, which tried to
fix the problem by not decrypting the embedded creds.
This commit was sponsored by Josh Taylor.
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
the repository was configured with encryption=shared embedcreds=yes."
This reverts commit cc54ff9e49260cd94f938e69e926a273e231ef4e.
I can find no basis for that commit and think that I made it in error.
setRemoteCredPair always encrypts using the cipher from remoteCipher,
even when the cipher is shared.
|
| | |
|
|/ |
|
|
|
|
| |
not yet supported on Windows.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| | |
repository, rather than just the file's base name. Note that if you're relying on such things to keep files separate with WORM, you should really be using a better backend.
|
|/ |
|
|\ |
|
| |
| |
| |
| | |
direct mode. (Fixing a very minor reversion.)
|
|/ |
|
| |
|
| |
|
|\ |
|
| | |
|
| | |
|
| |
| |
| |
| | |
processes were both working to perform the same set of transfers.
|
| | |
|
| | |
|
| | |
|
|/ |
|
|\ |
|
| |
| |
| |
| | |
key is present on a rsync remote, and when dropping a key from the remote.
|
|/ |
|