"git show" does not decrypt by default

[ljm42]

Running "git show" (without --no-textconv or --textconv): git show HEAD:sensitive_file behaves as though you passed --no-textconv to it. That is not what I expected for a "transparent" encryption process, is there a way to configure the repo so that it will default to --textconv instead?

Along these lines, tests/test_crypt.bats contains this test for git show --no-textconv to prove the file was encrypted: https://github.com/elasticdog/transcrypt/blob/0396245e6a1e238c4a08d0b89271f2490c4ec559/tests/test_crypt.bats#L30-L35

can we add a corresponding test with --textconv to prove it can decrypt too?

@test "crypt: encrypted file contents are decrypted (via git show)" {
  encrypt_named_file sensitive_file "$SECRET_CONTENT"
  run git show HEAD:sensitive_file --textconv
  [[ "$status" -eq 0 ]]
  [[ "${lines[0]}" = "$SECRET_CONTENT" ]]
}

It may also help to add a test showing that git show HEAD:sensitive_file (without any params) is doing the right thing

[jmurty]

Hi @ljm42 I don't think transcrypt can affect how the git show command behaves, according to Git's documentation the default (no)textconv behaviour varies depending on the specific Git command you run.

But I have seen the default behaviour for git show vary between platforms – from macOS to Linux – so I'm not sure the documentation is the final word. And this cross-platform (maybe cross Git version?) difference in behaviour is why the tests explicitly use --no-textconv.

FWIW the transparent encryption is intended to work at the level of the working copy files, where transcrypt-encrypted files will always be decrypted as long as the repo is initialised with the correct password.

[ljm42]

Thanks for confirming it is working as designed. I agree, if there isn't a git config for it, I wouldn't expect transcrypt to somehow change git's behavior.

The transparent part makes sense in terms of the working files, I'll keep that in mind.

Would you mind if I open a PR for that --textconv test? It would help to document the expected behavior. I wouldn't expect cross platform issues since it is just telling git to use the smudge filter when showing the file.

[jmurty]

Sure, an extra test would be good.

[jmurty]

Closing this now that the PR with explicit test of git show HEAD:sensitive_file --textconv is merged in https://github.com/elasticdog/transcrypt/commit/a104a554fb40646fb5da45e4e868e9c8709ffa81