search

elasticdog / transcrypt

transparently encrypt files within a git repository
MIT License
1.46k stars 102 forks source link

Removing a file from .gitattributes does not unencrypt it #102

Closed Jake-Gillberg closed 4 years ago

Jake-Gillberg commented 4 years ago

My workflow in a repo that I am working on has been:

  1. [x] Encrypt fileA that has secrets and non-secrets stored in it, commit
  2. [x] Break out secrets into their own files
  3. [ ] Remove encryption from fileA now that it no longer contains secrets

I am unsure of how to do step 3. I removed the file from gitattributes, but the file was commited in encrypted form.

Jake-Gillberg commented 4 years ago

Ah, I suppose if I have already git add fileA /and then/ remove it from .gitattributes, git has no reason to think that it might be dirty and check it for changes. A bit annoying. Unsure if there would be an easy fix for this, other than maybe adding transcrypt commands for modifying the attributes file that also somehow marked the file as "dirty" when it is removed.

jmurty commented 4 years ago

Hi @Jake-Gillberg I'm not sure adding and removing file paths from the .gitattributes file is a good idea. It isn't a common use case, and you might hit edge cases where you see unexpected behaviour or need to find work-arounds.

I would recommend instead that you have a file naming scheme where secrets files are always encrypted. Maybe something like my-data for unencrypted data and a corresponding my-data.secret file for encrypted data, with an entry for *.secret in the .gitattributes file.

With all that said, and to address your specific question, this is the easiest way I found just now to do what you want:

  1. Remove no-longer-encrypted file entry (fileA) from .gitattributes file
  2. Trigger some change to the file in the working copy so Git recognises a change: a simple touch fileA was enough in my testing.
  3. git add both changed files .gitattributes and the now plaintext fileA

You should then be able to commit as usual, and ideally confirm that Git has really changed its internal copy of the file to have the plaintext with git log -p --no-textconv or similar.

jmurty commented 4 years ago

I haven't tested this ☝️ approach in detail so there could be problems with it. I'm not familiar enough with how Git treats the .gitattributes file to know for sure that it is safe to remove entries from that file in the same commit as decrypting the referenced file. It should be fine, but just in case maybe clone your changes to a new repo and checkout the before and after commits just to make sure.

Jake-Gillberg commented 4 years ago

Thanks for the reply! I like the idea of using a pattern to decide which files are encrypted. I'll most likely create a secrets directory in my project and add secrets/* to .gitattributes.

Closing, since this isn't an issue when using this project as intended.