15c502588e
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.
42 lines
2 KiB
Markdown
42 lines
2 KiB
Markdown
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.
|