summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2014-09-18 17:58:03 -0400
committerGravatar Joey Hess <joey@kitenet.net>2014-09-18 17:58:03 -0400
commit2df9a6f1c9eff911cf27ab788cb28c78f6d20535 (patch)
tree0734065e2c55cea4620facea921da2001956640e /doc
parent2fb7ad68637cc4e1092f835055a974f141808ca0 (diff)
deal with old repositories with non-encrypted creds
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.
Diffstat (limited to 'doc')
-rw-r--r--doc/upgrades/insecure_embedded_creds.mdwn34
1 files changed, 34 insertions, 0 deletions
diff --git a/doc/upgrades/insecure_embedded_creds.mdwn b/doc/upgrades/insecure_embedded_creds.mdwn
new file mode 100644
index 000000000..b0554a5d8
--- /dev/null
+++ b/doc/upgrades/insecure_embedded_creds.mdwn
@@ -0,0 +1,34 @@
+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..
+
+Fixed versions of git-annex will detect this problem when enabling such a
+remote, and print a warning message (including a pointer to this web page).
+
+This message will only be printed one time, since git-annex will
+change the embedded credentials to be encrypted properly.
+However, this leaves the non-encrypted version still in the git history.
+
+If your repository has this problem, you have two courses of action to fix
+it:
+
+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`
+
+2. Remove the history of the git-annex branch of the repository.
+ You can use `git annex forget`` to do that; note that it will
+ remove other historical data too.
+
+3. If 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.