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
openssl
binary.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 --upgrade
within 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.0
plus 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-transcypt
wget https://raw.githubusercontent.com/elasticdog/transcrypt/bea184767608d0c24d20dce01381d3ea3ff50a62/transcrypt
chmod u+x transcrypt
git init
git config --local transcrypt.cipher aes-256-cbc
git config --local transcrypt.password abc123
echo "Plaintext for testing" > test-secret-file
Once 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 version
cat test-secret-file | ./transcrypt clean test-secret-file
U2FsdGVkX18HgDaYdwMdMtRxglvIjDqKGpAP66vzqy4QHyqEzouDb0YweqfVm5+/
*** WARNING : deprecated key derivation used.
andUsing -iter or -pbkdf2 would be better.
cat test-secret-file | ./transcrypt clean test-secret-file | ./transcrypt smudge
Plaintext for testing
Repeat the above commands, but substitute the path to
openssl
for 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/openssl
git config --local transcrypt.openssl-path /opt/homebrew/opt/openssl@3/bin/openssl
openssl
binary used on your system (no explicit path):git config --local transcrypt.openssl-path openssl
If 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 (clean
andsmudge
) 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
openssl
paths. 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 -u
beforehand.Same problem here on Ventura 😦
I tried the version on
main
branch 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.