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

Most upvoted comments

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:

  1. Create and cd into a new directory for testing, separate from any existing code directory, e.g: mkdir test-transcypt && cd test-transcypt
  2. Download and save this transcrypt version to test: wget https://raw.githubusercontent.com/elasticdog/transcrypt/bea184767608d0c24d20dce01381d3ea3ff50a62/transcrypt
  3. Make the transcrypt script executable: chmod u+x transcrypt
  4. Initialise git in the test directory: git init
  5. Set the cipher to use: git config --local transcrypt.cipher aes-256-cbc
  6. Set a fake password, use this exact command: git config --local transcrypt.password abc123
  7. Create this plaintext file to test against, use this exact command: 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:

  1. Configure transcrypt to use your system default openssl: git config --local transcrypt.openssl-path /usr/bin/openssl
  • Check the version reported by that openssl path for cross-checking, e.g: /usr/bin/openssl version
  1. Output the encrypted version of the plaintext file: cat test-secret-file | ./transcrypt clean test-secret-file
  • The output should be exactly U2FsdGVkX18HgDaYdwMdMtRxglvIjDqKGpAP66vzqy4QHyqEzouDb0YweqfVm5+/
  • You can ignore output lines like *** WARNING : deprecated key derivation used. and Using -iter or -pbkdf2 would be better.
  1. Do a roundtrip encrypt-then-decrypt: cat test-secret-file | ./transcrypt clean test-secret-file | ./transcrypt smudge
  • The output should be exactly Plaintext for testing

Repeat the above commands, but substitute the path to openssl for step 1. to use different versions you have from the OpenSSL or LibreSSL projects, for example:

  • OpenSSL version 1.1 installed with Homebrew: git config --local transcrypt.openssl-path /opt/homebrew/opt/openssl@1.1/bin/openssl
  • OpenSSL version 3 installed with Homebrew: git config --local transcrypt.openssl-path /opt/homebrew/opt/openssl@3/bin/openssl
  • The default 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 the 3. encrypt-then-decrypt (clean and smudge) 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:

brew tap-new $USER/local-transcrypt
brew extract --version=2.1.0 transcrypt $USER/local-transcrypt
brew uninstall transcrypt
brew install transcrypt@2.1.0

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.