I am curious if remote.log in the repository (or anything in the repository for that matter) gives someone access to the data stored in the special remotes.
If I'm using an encrypted s3 special remote, and someone gets access to the entire repository, will they be able to decrypt things? Or is the gpg stuff stored completely separately and therefore completely unaccessable, even if someone got access to the entire contents of the git repository?
What is the cipher and the cipherkeys stored in git show git-annex:remote.log?
it depends how you configured encryption. this is pretty well described in the encryption page, but basically, unless you used "shared" encryption, only the holders of the GPG private key material will be able to decrypt the contents. Objects are encrypted with GPG using a symmetric key, and that key is then encrypted with OpenPGP public keys.
This is all pretty well described in encryption. --anarcat
I read the encryption page but I just want to know if I'm understanding it correctly.
Let's say I initiated my remote with this command:
And then, I handed out my remote.log file to people publicly. Does that expose any security hole at all? Or is 100% of the information in remote.log secured using gpg?
I would believe that people couldn't decrypt my file contents, but could they get into my bucket or my S3 account?
I think you are understanding this correctly... let's see..
It won't expose your S3 credentials, if that's what your are asking. Those are stored in
.git/annex/creds/and not in the git-annex branch. You can see the content ofremote.logyourself with:... if that helps you at all..
Well, it would expose the bucket name and the GPG key id ("XXXXXXXX") that you set there. The remote.log, itself, is not encrypted with gpg, from what I understand. Or to put it another way, the
remote.logis not actually sent to the S3 remote there, and if you put the git repo publicly, then its content will be publicly readable. To protect against that, you would need a gcrypt remote.Not unless they have the S3 credentials, no. Furthermore, if the bucket is not publicly readable (see public Amazon S3 remote for that), they won't be able to get the file contents either. And even if it is public, they would get the encrypted content which they couldn't decrypt without the private key associated with the keyid you supplied.
s3credsinremote.logthen? Something base64 encoded that is named suspiciously like creds for logging into s3?interesting! i don't see that here, maybe that could be a problem there. my s3 remote doesn't use encryption, so maybe i don't have this problem...
i don't know!
There are two cases there s3creds= can be in the remote.log.
If you enabled gpg encryption, it stores the S3 creds there, encrypted with the gpg key you told it to use. So you can share the repo to users who don't have the gpg key, and they cannot access the S3 login credentials.
If you didn't use gpg encryption, and you manually set
embedcreds=yesthen the s3creds= will contain the un-encrypted creds. And like the docs for embedcreds says, you then need to be careful who you give the git repo to, since they can then access those S3 credentials. This is not a default configuration.(There was also the insecure embedded creds bug in 2014. But, git-annex will detect repos with that problem and warns very verbosely about it.)