| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |/ |
|
| |
|
|
|
|
|
|
|
|
| |
A one-time warning was not good enough. A hard error will force the user to
notice the problem.
Perhaps worth noting that git-annex enableremote already failed with an
error, and nobody reported a bug. Suggests that not many people have used
the insecure configuration, or if they did, they went to the bother to
embedcreds, but never re-enabled the special remote.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See 2fb7ad68637cc4e1092f835055a974f141808ca0 for backstory about how a repo
could be in this state.
When decryption fails, the repo must be using non-encrypted creds. Note
that creds are encrypted/decrypted using the encryption cipher which is
stored in the repo, so the decryption cannot fail due to missing gpg keys
etc. (For !shared encryptiom, the cipher is iteself encrypted using some
gpg key(s), and the decryption of the cipher happens earlier, so not
affected by this change.
Print a warning message for !shared repos, and continue on using the
cipher. Wrote a page explaining what users hit by this bug should do.
This commit was sponsored by Samuel Tardieu.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |\ |
|
| | |
| |
| |
| | |
already done in indirect mode.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
|
| |
This needs optparse-applicative 0.10. Dropped support for 0.9 and older,
but kept 0.9.1 working since autobuilders and debian testing still use it.
(The display is not perfect with 0.9.1.)
|
| |\ |
|
| | |
| |
| |
| | |
introduced in version 5.20140817.)
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |\ |
|
rasmus
Joey Hess
anarcat
http://joeyh.name/
xn
https://www.google.com/accounts/o8/id?id=AItOawmH7o6q2l99M-PQolOfbR3_i5B_jtTIcAE
https://www.google.com/accounts/o8/id?id=AItOawlog_5wIICaMcrKTexlFNA6IO6UTp323aE
pot
https://id.koumbit.net/anarcat