OpenSSL 1.1.1c FIPS Causes Rewrite of Crypted Files

[damaestro]

It seems that when I clone an existing repo and use transcrypt on it with correct information I end up rewriting all crypted files with an upgraded openssl.

transcrypt master and 9a8a1f4 tested
openssl-1.1.1c-2.fc30.x86_64 "OpenSSL 1.1.1c FIPS 28 May 2019"

git clone proto://server/my.git
cd my
transcrypt -c aes-256-cbc -p 'the-existing-phrase'

All git operations cause a rewrite of the crypted files. For example:

[damaestro@earth my]$ git status
*** WARNING : deprecated key derivation used.
Using -iter or -pbkdf2 would be better.
[...] repeated for every file
On branch transcrypt-test
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   path/to/crypted.py
[...] all files listed
no changes added to commit (use "git add" and/or "git commit -a")

The files are locally readable.

[damaestro]

Using v1.0.3 does not cause a rewrite and using master someone using an older version is still able to use the repo.

[elasticdog]

Hey @damaestro! There was a recent bug fix to ensure that salt generation was working consistently across operating systems, but it does require a re-encryption. This has been causing trouble for other people as well running in mixed version environments: Encrypted files appearing as changed in git. I hadn't predicted that a lot of people were running against the master branch, and it could cause further problems with new files, depending on who added them and with what version.

I was wanting to batch this change with some other potential breaking changes, but it's going to be a bit until I can circle back to those and make the changes cleanly. I'll publish a new release shortly so at least packages can be bumped and get people in a consistent place.