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