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