Avoid accidentally committing unencrypted files.

[mrmachine]

I use the GitUp client on OS X, and I just discovered that it does not execute attribute filters (git-up/GitUp#224).

If I'm not careful (or someone else using GitUp isn't careful), it is very easy to stage and commit an encrypted file from GitUp.

Could transcrypt automatically configure a pre/post-commit or pre-push hook to ensure that any files that should be encrypted, are always encrypted?

[elasticdog]

I'm not quite sure how that would work. Even if it could automatically create a client-side hook, how could it test if the files are encrypted? The clean filter script does some naive testing for encrypted files, but there are cases where it doesn't hold up (like if an empty file is set to be encrypted). There could also be false-positives if you try and encrypt an already-encrypted file.

I'm also not familiar with the internal workings of GitUp, but it looks like it runs hooks itself so there might be some odd interactions if the hook were to try and shell out to normal Git/transcrypt commands in order to check the attributes. Give me a bit to think about this...

[mrmachine]

We switched away to git-secret to avoid accidentally committing unencrypted files, but it has it's own problems (GPG2 pain, no diffs in commit history, etc.)

So we're thinking about switching back, but we are still worried about how easy it is to accidentally commit unencrypted sensitive data with the wrong Git client.

Did you have any other ideas about how we might be able to minimise that risk?

It seems we can't do server side hooks on GitHub, so we'd have to tell everyone to manually setup a local hook, which is probably just as ineffective as telling people to be careful when using GitUp.

Would it be possible to have transcrypt have a less transparent mode of operation that stores the encrypted version in a *.secret file and adds the unencrypted file to .gitignore to ensure it is never accidentally committed?

It would be OK if we had to manually run commands (e.g. transcrypt hide, transcrypt reveal) to encrypted and decrypt the files.

[elasticdog]

So in your proposed mode of operation, you'd still have to define a pattern for matching files somewhere (like as is done within the .gitattributes file now), and then transcrypt would then manage the .gitignore file? I'm not understanding how that would make things any safer, as you'd already have to define a pattern to match files that you want to encrypt (and trust your users to do the same). That also wouldn't be supported by clients that ignore the attribute filters, assuming that built-in Git pattern matching mechanisms could be used.

Or are you saying that transcrypt should have a mode that would allow for the manual creation of *.secret files that also added the original plaintext files into the .gitignore file? That's somewhat orthogonal to the transparent nature of transcrypt's current operation, and I'd think would be much more error-prone...

The origins of me writing transcrypt in the first place was the observation of multiple teams of developers relying upon manual encryption/decryption of files within a repository (using varying non-safe practices/commands), and then manually checking those in. The transparent nature of the encryption is what makes it much easier than just having an encrypt-file and decrypt-file openssl wrapper script checked into the repository and relying on your users to exercise them properly.

To add the safety that you want, could you not use something like git-secret in tandem with transcrypt? I'm not familiar with the former project, but from a cursory glance, it seems like the could work together and prevent issues if your users are using clients that do not support the attribute filters. Although, I'm not sure if there's a good workaround for requiring everyone to configure local hooks.

[mrmachine]

Yes. I suppose my request is orthogonal to the purpose of transcrypt, being transparent encryption.

When transcrypt works, it is excellent. I'm just not sure about how safe it is when it's easy for a git client that doesn't execute git attribute filters to accidentally commit an unencrypted file containing sensitive data.

It might be enough for transcrypt to automatically configure a local post-commit or pre-push hook that verifies that any files covered by a crypt filter in .gitattributes is actually encrypted?

All users will need to configure their new repo clones with transcrypt, regardless of which client they use. If their client supports git attributes, it will work transparently. If it doesn't support git attributes, at least the hook will prevent them from accidentally committing unencrypted sensitive data?

[mrmachine]

@elasticdog any further thoughts on this? We are again looking at modifying transcrypt to include an additional header in the encrypted version of the file (to indicate that it is in fact encrypted) and a pre-commit hook to verify that the header exists, while stripping the header when decrypting...

Would such a PR be acceptable to you?

[elasticdog]

Nice idea! A custom header in the encrypted version of the files would be a much nicer solution and more reliable than trying to auto-detect encryption. The only downside is that it would break decryption with standard tooling, but it's not a huge burden to switch from cat sensitive_file to tail -n +2 sensitive_file, plus this caveat could be documented in the README.

I'd definitely be open to a PR that takes that approach and manages a pre-commit hook.

[jmurty]

Here is a pull request against our fork of version 1.1.0 that adds a pre-commit hook script to abort a commit if any transcrypt-managed files are not encrypted in the index, based on a simplistic check for the "Salted" B64 prefix in the raw content.

At time of writing this is a prototype, but I'll follow up if we find the hook to be problematic or problem-free.

[jmurty]

A new pre-commit hook that performs safety checks is now merged to master branch, to be included in the next release.