Encrypted files appearing as changed in git

[cdimitroulas]

Hey there.

I have a colleague who reports that their git status is never clean in the repos where we have encrypted files using transcrypt. We have compared versions of all the relevant software (transcrypt, git, openssl, OS...) and did not find any differences.

I am not sure why it is happening, but if you have any hints or advice on where to look to start tackling such an issue then I'm all ears!

I realise this is a bit vague and I don't have a way to reproduce the error so I understand if you aren't able to help but thought it was worth a shot.

[collegeimprovements]

I'm facing the same issue. It's happening on RHEL Linux as well as on mac.
Not sure how to tackle this. We are not able to run git reset --hard or git stash.

[andreineculau]

My colleagues are experiencing the same. Most of us are on MacOS with a rigid bootstrap procedure (i.e. installing global deps via homebrew) and we have never experienced this. Currently we are on Mojave, git 2.20.0+, openssl=libressl 2.6.5.

BUT now some colleagues on Ubuntu 18.04, git 2.22.0+, openssl 1.0.2s and 1.1.1,
plus our Travis CI running Ubuntu 16.04, git 2.21.0, openssl 1.0.2g are experiencing this, both by decrypting via gpg and directly with ./transcrypt -y -c aes-256-cbc -p 'some/secret/pass'.

git diff --raw shows
:100644 100644 90b0595 0000000 M some/secret/file

I'm debugging at the moment, but posting this info in case someone is faster.

[andreineculau]

Spoke too soon. Ignore.

A quick update: I think I identified the issue.
https://github.com/elasticdog/transcrypt/blob/master/transcrypt#L294 ends up producing a newline character with ubuntu's openssl, but not macos'. Thus the file looks dirty.

[andreineculau]

I forgot about #57 PR --- WARNING: This requires re-encrypting secrets because salts change!

The fix is explained in #57 (comment)

@cdimitroulas @collegeimprovements can you confirm?

[andreineculau]

Seems to be smth else. I tested #57 and re-encryption didn't fix the situation.

[andreineculau]

git ls-files --eol shows this diff for me between the two OSes:

i/lf    w/lf    attr/                 	doc/how-to-manage-secrets.md.test.secret #macos
i/lf    w/-text attr/                 	doc/how-to-manage-secrets.md.test.secret #ubuntu

[andreineculau]

I was completely wrong. I had too many shell sessions open and I tested incorrectly in an old repository.

After re-encryption, ubuntu on Travis CI reports no diff. Closing.

[cdimitroulas]

@andreineculau I followed the steps to re-key the repo but after reconfiguring transcrypt there are no changes to commit.
So your solution doesn't fix the issue for us.

[andreineculau]

@cdimitroulas can you describe your setup? what OS, git, openssl version are you running? what OS, git, openssl version is the author of the repo (that you're trying to decrypt) running? which transcrypt version are you running? I suggest downloading the latest from the master branch https://raw.githubusercontent.com/elasticdog/transcrypt/master/transcrypt and try to re-key the repo, if you didn't do so already.

[cdimitroulas]

Hey @andreineculau - just tried pulling the latest from the master branch and I was able to re-key the repo successfully. Just confirming with @kbonev whether this has fixed the issue.

For info:
OS - Ubuntu 18.04
git - 2.17.1
openssl - 1.1.1

[cdimitroulas]

@andreineculau this seems to have resolved the issue. Thanks for your help!

[andreineculau]

Cool! Thanks for confirming.

[andreineculau]

@cdimitroulas

As a personal advice, not shared on the README.md of transcrypt is to actually commit the transcrypt script in the repo. It's small and it's not a binary even, and it means you can actually run different versions of transcrypt, one per repo. This also removes the esoteric details because you probably don't mention which version of transcrypt is needed for repo x. That's at least what I do in my team with tens of transcrypted repos.

Wdyt @elasticdog ?

[cdimitroulas]

That's a neat idea, thanks for the suggestion.

[elasticdog]

Yeah, it's not a bad suggestion as it will ensure that everyone is using the same consistent version...you just have to remember to update things when new releases come out. I haven't pushed a new official release yet due to this breaking change, and have been wanting to tackle a couple of other things before making it more widely available.

[elasticdog]

Oh, and thank you @andreineculau for troubleshooting this issue with @cdimitroulas!

[andreineculau]

you just have to remember to update things when new releases come out

When in the repo it's only one repo author that needs to remember and commit an update, otherwise it's everyone that interacts with the repo.

Primarily i worry about security bugs. Bugs that I don't experience or new features - not something to worry about. Nice to get for free, but not an issue if not. If it ain't broken, don't fix it.

[cdimitroulas]

@elasticdog @andreineculau can we please release a new version of transcrypt to include the latest changes? People who are installing the library with package managers like brew do not receive the new version as it hasn't been bumped up since 1.1.0 which was several commits ago

[elasticdog]

@cdimitroulas I've just released transcrypt v2.0.0 and added release notes with how to handle the re-encryption after upgrade.

[cdimitroulas]

Awesome that's great - thanks a lot @elasticdog