aboutsummaryrefslogtreecommitdiff
path: root/doc/upgrades/insecure_embedded_creds.mdwn
blob: a221fb51f488145e961af0f379d7a1cd798ab7be (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
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..

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:

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. 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 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.