mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
git-annex/doc/upgrades/insecure_embedded_creds.mdwn

43 lines
2 KiB
Text
Raw Normal View History

deal with old repositories with non-encrypted creds See 2f3c3aa01ff0eb1dfdf1e30ff29fef40ed8fd167 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.
2014-09-18 21:58:03 +00:00
git-annex had a bug in the S3 and Glacier remotes where if embedcreds=yes
was set, and the remote used encryption=pubkey or encryption=hybrid,
the embedded AWS credentials were stored in the git repository
in (effectively) plaintext, not encrypted as they were supposed to be.
That means that anyone who gets a copy of the git repository can extract the
AWS credentials from it. Which would be bad..
error, don't warn about insecure creds 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.
2014-09-18 23:03:15 +00:00
A remote with this problem cannot be enabled using `git annex
enableremote`. Old versions of git-annex will fail with a gpg error;
the current version will fail with a pointer to this web page.
deal with old repositories with non-encrypted creds See 2f3c3aa01ff0eb1dfdf1e30ff29fef40ed8fd167 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.
2014-09-18 21:58:03 +00:00
number
2014-09-18 22:25:33 +00:00
If your repository has this problem, chose from one of these approaches
to deal with it:
deal with old repositories with non-encrypted creds See 2f3c3aa01ff0eb1dfdf1e30ff29fef40ed8fd167 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.
2014-09-18 21:58:03 +00:00
1. Change your AWS credentials, so the ones stored in the clear in git
won't be used.
After changing the credentials, make sure you have a
fixed version of git-annex, and you can then re-embed the new creds
into the repository, encrypted this time, by setting the
`AWS_SECRET_ACCESS_KEY` and `AWS_ACCESS_KEY_ID` environment variables,
and running `git annex enableremote $remotename embedcreds=yes`
error, don't warn about insecure creds 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.
2014-09-18 23:03:15 +00:00
2. Fix the problem and then remove the history of the git-annex branch
of the repository.
Make sure you have a fixed version of git-annex, and force git-annex
to rewrite the embedded creds, with encryption this time, by setting
by setting the `AWS_SECRET_ACCESS_KEY` and `AWS_ACCESS_KEY_ID`
environment variables, and running `git annex enableremote $remotename embedcreds=yes`
Then, to get rid of old versions of the git-annex branch that still
contain the creds in cleartext, you can use `git annex forget`;
note that it will remove other historical data too.
Keep in mind that this will not necessarily delete data from clones
you do not control.
deal with old repositories with non-encrypted creds See 2f3c3aa01ff0eb1dfdf1e30ff29fef40ed8fd167 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.
2014-09-18 21:58:03 +00:00
error, don't warn about insecure creds 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.
2014-09-18 23:03:15 +00:00
3. If you're sure that you're the only one who has access to the repository,
you could decide to leave it as-is. It's no more insecure than if you
had used encryption=shared in the first place when setting it up.
Reference in a new issue Copy permalink