mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

error, don't warn about insecure creds

Browse source 
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.
This commit is contained in:
Joey Hess 2014-09-18 19:03:15 -04:00
parent 23f60da002
commit 15c502588e
2 changed files with 21 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
Creds.hs
View file

@ -110,7 +110,7 @@ getRemoteCredPair c storage = maybe fromcache (return . Just) =<< fromenv
-- Not a problem for shared cipher. -- Not a problem for shared cipher.
case storablecipher of case storablecipher of
SharedCipher {} -> showLongNote "gpg error above was caused by an old git-annex bug in credentials storage. Working around it.." SharedCipher {} -> showLongNote "gpg error above was caused by an old git-annex bug in credentials storage. Working around it.."
_ -> warning "*** Insecure credentials storage detected for this remote! See https://git-annex.branchable.com/upgrades/insecure_embedded_creds/" _ -> error "*** Insecure credentials storage detected for this remote! See https://git-annex.branchable.com/upgrades/insecure_embedded_creds/"
fromcreds $ fromB64 enccreds fromcreds $ fromB64 enccreds
fromcreds creds = case decodeCredPair creds of fromcreds creds = case decodeCredPair creds of
Just credpair -> do Just credpair -> do

33
doc/upgrades/insecure_embedded_creds.mdwn
View file

@ -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 That means that anyone who gets a copy of the git repository can extract the
AWS credentials from it. Which would be bad.. AWS credentials from it. Which would be bad..
Fixed versions of git-annex will detect this problem when enabling such a A remote with this problem cannot be enabled using `git annex
remote, and print a warning message (including a pointer to this web page). enableremote`. Old versions of git-annex will fail with a gpg error;
the current version will fail with 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 If your repository has this problem, chose from one of these approaches
to deal with it: to deal with it:
@ -25,11 +22,21 @@ to deal with it:
`AWS_SECRET_ACCESS_KEY` and `AWS_ACCESS_KEY_ID` environment variables, `AWS_SECRET_ACCESS_KEY` and `AWS_ACCESS_KEY_ID` environment variables,
and running `git annex enableremote $remotename embedcreds=yes` and running `git annex enableremote $remotename embedcreds=yes`
2. Remove the history of the git-annex branch of the repository. 2. Fix the problem and then remove the history of the git-annex branch
You can use `git annex forget` to do that; note that it will of the repository.
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 Make sure you have a fixed version of git-annex, and force git-annex
to leave it as-is. It's no more insecure than if you had used to rewrite the embedded creds, with encryption this time, by setting
encryption=shared in the first place when setting it up. 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.