summaryrefslogtreecommitdiff
path: root/doc/upgrades
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2014-09-18 19:03:15 -0400
committerGravatar Joey Hess <joey@kitenet.net>2014-09-18 19:03:15 -0400
commit0d2191dbea26c30f9d5ebbdca5aa130ba2b261cc (patch)
treeeb961c9b30f554b96e33d3f062cb851f99fb4562 /doc/upgrades
parent78bef2bbb873fa41de277092d9c897fa8d6ee923 (diff)
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.
Diffstat (limited to 'doc/upgrades')
-rw-r--r--doc/upgrades/insecure_embedded_creds.mdwn33
1 files changed, 20 insertions, 13 deletions
diff --git a/doc/upgrades/insecure_embedded_creds.mdwn b/doc/upgrades/insecure_embedded_creds.mdwn
index 19713f9b0..a221fb51f 100644
--- a/doc/upgrades/insecure_embedded_creds.mdwn
+++ b/doc/upgrades/insecure_embedded_creds.mdwn
@@ -6,12 +6,9 @@ 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.
+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.
If your repository has this problem, chose from one of these approaches
to deal with it:
@@ -25,11 +22,21 @@ to deal with it:
`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. Keep in mind that this will not
- necessarily delete data from clones you do not control.
+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.
-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.
+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.