transcrypt: Version 2.2.0 is not compatible with MacOS Ventura's `/usr/bin/openssl`
In release 2.2.0 we included a fix for #133 to work around a compatibility problem with OpenSSL versions 3+, which changed how salt values are included in encrypted output (they aren’t)
Unfortunately our work-around relied on a check of the openssl version’s major version: if the major version is 3 or greater it forcibly includes the salt values in the encrypted output.
The recent release of MacOS Ventura includes the LibreSSL project’s openssl command which also reports a major version of 3, but our work around is not necessary for the LibreSSL project’s openssl because that project didn’t make the breaking change to remove salt values from encrypted output.
The upshot of all this is transcrypt release 2.2.0 is currently broken on MacOS Ventura when using the default built-in /usr/bin/openssl binary, because our work-around will end up prefixing the salt value unnecessarily.
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 3
- Comments: 20
Commits related to this issue
- Fix compatibility with LibreSSL v3+ `openssl` command and MacOS Ventura (#148 #147) Detect OpenSSL major version 3 or later which requires a compatibility work-around to include the prefix 'Salted__... — committed to elasticdog/transcrypt by jmurty 2 years ago
- Fix compatibility with LibreSSL v3+ `openssl` command and MacOS Ventura (#148 #147) Detect OpenSSL major version 3 or later which requires a compatibility work-around to include the prefix 'Salted__'... — committed to elasticdog/transcrypt by jmurty 2 years ago
- Detect and fix decryption of files encrypted with doubled "Salted" prefixes due to #147 If someone has committed and encrypted a file using Transcrypt version 2.2.0 on a MacOS 13 Ventura system and u... — committed to elasticdog/transcrypt by jmurty a year ago
- Detect and fix decryption of files encrypted with doubled "Salted" prefixes due to #147 If someone has committed and encrypted a file using Transcrypt version 2.2.0 on a MacOS 13 Ventura system and u... — committed to elasticdog/transcrypt by jmurty a year ago
- Merge branch '2.2' * 2.2: Release 2.2.1 Run tests for PR changes even if it doesn't target `main` Detect and fix decryption of files encrypted with doubled "Salted" prefixes due to #147 Fix c... — committed to elasticdog/transcrypt by jmurty a year ago
- Avoid null bytes decryption work-around for files with doubled "Salted" prefix due to #147 Improve the work-around for files incorrectly encrypted with doubled "Salted" prefixes due to #147 to avoid ... — committed to elasticdog/transcrypt by jmurty a year ago
- Avoid null bytes decryption work-around for files with doubled "Salted" prefix due to #147 Improve the work-around for files incorrectly encrypted with doubled "Salted" prefixes due to #147 to avoid ... — committed to elasticdog/transcrypt by jmurty a year ago
Thanks very much for your feedback @Fausto95 @Z7oussem @emcniece, it gives me more confidence I’ve finally fixed the bug using the LibreSSL 3+ flavour of the
opensslbinary.I have released a new version 2.2.1 of transcrypt with a fix for the original bug.
I also added a work-around which should properly decrypt files committed on systems that were affected by the bug, so these should now give you the original content instead of showing binary junk at the top of the file. See details in b380f2c9 Note that incorrectly encrypted files will remain in your repository even with this work-around – manifesting as phantom changed files that look no different in diffs – but if you commit the seemingly unchanged file transcrypt will fix the encrypted version stored in Git.
Please grab the 2.2.1 version of transcrypt, make sure it’s updated on all systems by running
transcrypt --upgradewithin every repository, and check whether it finally resolves this problem.Hi, could those of you experiencing incompatibility with MacOS Venture please help me to isolate the ongoing bug by running some tests on your Mac, ideally on both MacOS 13 (Ventura) and prior versions like 12?
I have pushed a new version of the transcrypt script in bea18476 with nothing but the released version
2.2.0plus my prior attempted fix for MacOS / LibreSSL compatibility.I’d very much appreciate feedback on your results of running some low-level encrypt and decrypt commands to test what results you get using this version of the script with the different versions of OpenSSL and LibreSSL you have on your system.
To get ready to run the tests:
mkdir test-transcypt && cd test-transcyptwget https://raw.githubusercontent.com/elasticdog/transcrypt/bea184767608d0c24d20dce01381d3ea3ff50a62/transcryptchmod u+x transcryptgit initgit config --local transcrypt.cipher aes-256-cbcgit config --local transcrypt.password abc123echo "Plaintext for testing" > test-secret-fileOnce the testing directory is set up, run these commands to test encrypting and decrypting the example file:
git config --local transcrypt.openssl-path /usr/bin/openssl/usr/bin/openssl versioncat test-secret-file | ./transcrypt clean test-secret-fileU2FsdGVkX18HgDaYdwMdMtRxglvIjDqKGpAP66vzqy4QHyqEzouDb0YweqfVm5+/*** WARNING : deprecated key derivation used.andUsing -iter or -pbkdf2 would be better.cat test-secret-file | ./transcrypt clean test-secret-file | ./transcrypt smudgePlaintext for testingRepeat the above commands, but substitute the path to
opensslfor step1.to use different versions you have from the OpenSSL or LibreSSL projects, for example:git config --local transcrypt.openssl-path /opt/homebrew/opt/openssl@1.1/bin/opensslgit config --local transcrypt.openssl-path /opt/homebrew/opt/openssl@3/bin/opensslopensslbinary used on your system (no explicit path):git config --local transcrypt.openssl-path opensslIf the script is working correctly you should get exactly the same outputs each time for the
2.encrypt (clean) command and the3.encrypt-then-decrypt (cleanandsmudge) commands.If you see anything different, such as a different encrypted text blob or garbage characters after the round-trip, that could give me a vital clue to figure out what problems remain. Any anomalies you can report would be much appreciated, I need the help to figure this out!
For what it’s worth, when I run the test commands on my system (Ventura 13.1) I get the same results for all versions of OpenSSL and LibreSSL
opensslpaths. So it “works on my machine” which is making it very difficult to debug.FYI, to downgrade brew installation of transcrypt, use the following:
Make sure to have a clean repo without transcrypt v2.2.0 configured, otherwise uninstall transcrypt configuration with
transcrypt -ubeforehand.Same problem here on Ventura 😦
I tried the version on
mainbranch andI have the same issue. I tried the solution by @alb777 but even if file is decrypted I have weird characters added to the file.Makes team work nearly impossible.
Let me know if you need more info or help.
Still failing even doing the workaround above.