Please describe the problem.
After once embedding credentials into a S3 remote, there’s no way to un-embed them.
What steps will reproduce the problem?
- Add a S3 remote with
embedcreds=yes. - Try to set
embedcreds=no. git annex synchere, and in some other clone.- Check
git annex info my-s3-remotefor the other clone. Credentials are still embedded.
What version of git-annex are you using? On what operating system?
6.20170101 on NixOS 16.09 (stable).
Please provide any additional information below.
% g annex info test2 | grep '^creds'
creds: embedded in git repository (gpg encrypted)
% g annex enableremote test2 embedcreds=no
enableremote test2 (encryption update) (to gpg keys: 134164FA6FAFE075) ok
(recording state in git...)
% g annex info test2 | grep '^creds'
creds: embedded in git repository (gpg encrypted)
%
Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Yes, it’s awesome! Thank you!
When you used embedcreds=yes, it committed the creds to the git-annex branch of the git repository. For embedcreds=no to do anything useful, it would need to remove that data from the git repository history.
Removing data from a git repository tends to involve rewriting commits and forced pushes to all remotes, it's not a simple process and not ameanable to automation. It will be much easier, and more secure, to go into S3 and generate new credentials, and revoke access to the old ones.
What
git annex enableremotewithembedcreds=nodoes do is prevent any new creds from being embedded into the repository. Otherwise,git annex enableremotewill update the embedded creds with whatever new ones are set in the environment when you run it.Sure, that’s what I did at the very beginning (revoking the creds on AWS).
But still, when I clone this repo,
git annex info S3in this fresh clone, says that credentials are embedded. This is a bit misleading.Maybe updating S3 configuration with
embedcreds=nocould change that behavior?It wouldn’t matter from the security standpoint (which is solved by changing permissions directly on AWS), but would simply be beneficial for usability. =)
If
git annex infohad said that the creds were not embedded after you triedembedcreds=no, then wouldn't you have belived it, and so not revoked the creds on AWS?