Suppress warnings for OpenSSL 1.1.1

[dirkhas]

Using OpenSSL 1.1.1 (in my case, in Git for Windows, which uses OpenSSL 1.1.1a 20 Nov 2018), the clean script constantly leads to git commands printing out the following warning:

*** WARNING : deprecated key derivation used.
Using -iter or -pbkdf2 would be better.

[dirkhas]

I'll create a pull request to fix it.

in transcrypt 1.1.0, I still get this warning,it recommend 'Using -iter or -pbkdf2 would be better.'

[elasticdog]

This will be a bit tricky to address, as OpenSSL 1.1.1 was released in Sep 2018 and I want to make sure that older versions also work properly. The situation is further complicated by macOS using LibreSSL 2.6.5 these days, which does not support the -pbkdf2 option, as far as I know. I'll have to do a bit more research here to know how far back the -iter option has been around in both projects to see if it makes sense to update the default behavior and introduce a breaking change.

I don't think suppressing the warning is the best way forward in this case since it did bubble up a legit deprecation that will bite us eventually.

[Erotemic]

Perhaps it is possible to do a version check and then actually use -pbkdf2 and -iter when calling openssl, as long as you have at least 1.1.1?

EDIT: After looking into this I realize why its tricky. You couldn't do a checkout on an older machine if you encrypted on a newer machine.

It might be reasonable to add a flag the enables -pbkdf2 to transcrypt when you either setup or authenticate a repository. Then each repo would have the option of forbidding the older versions of openssl.

[andreineculau]

I'm wondering if anyone has a clear path going forward.

Both -pbkdf2 and -iter have landed in 1.1.1 afaik and libressl 2.9.1, so in order to support previous versions, you need to check for the support of the flags. But that is not enough because it should be an active decision of transcrypt not to support openssl@<1.1.1/libressl@<2.9.1, or of the transcrypt user not to support openssl@<1.1.1/libressl@<2.9.1, otherwise you risk weird behavior on two different machines, one with, and the other without these flags.

If someone decides, I can file a PR to test out the decision, no problem.

[jmurty]

I think the best approach for handling this situation would be for transcrypt to switch to using the more secure -pbkdf2 and -iter options by default, but in a way that minimises breaking changes as much as possible.

Here are some rough ideas on how to do this, and a longwinded (sorry) brain-dump about how it could all work.

Additional features

• add support for a new (optional?) transcrypt.openssl-path config setting that points to the OpenSSL binary to be used by the clean / smudge / textconv scripts. With this setting, users on platforms with outdated OpenSSL like macOS could tell transcrypt to use a newer versions installed in a custom location, e.g. with Homebrew.

• add a crypt-cipher or similar attribute to .gitattributes to capture the encryption method transcrypt will use for that file, and support a specific set of values represented as alias like v1 / v2 etc or maybe something more explicit like aes-256-cbc:md5. Again, the clean / smudge / textconv scripts would check and respect this attribute.

• before attempting to run OpenSSL the clean / smudge / textconv scripts could check the required encryption method vs what is supported by OpenSSL and the configured path, and do something sensible if there's a mismatch. Ideally print helpful warnings, if that's possible from within those scripts.

Usage

With the above, on init transcrypt could:

• check the OpenSSL version available on the platform, and if an outdated version is present recommend that the user install and configure a newer OpenSSL version for transcrypt to use.

• prompt the user to choose an encryption method as one of the settings, with an explanation of pros and cons. E.g. the newer method is more secure, but not supported on some platforms without extra work. If a user has an old OpenSSL they wouldn't have the option to use a newer encryption method.

  • The only real effect of this choice would be to use the chosen method in the example line in the generated .gitattributes file, since that is where each file's encryption method should be captured.

Scenarios

If a user chooses to use a newer method for some or all of their secret files:

• other users with the latest transcypt and newer OpenSSL will have things work seamlessly
• other users with the latest transcrypt but older OpenSSL could not decrypt the files, but would at least get the most sensible behaviour possible (e.g. warning messages) for repos that use an encryption method their system doesn't support
• other users with old OpenSSL versions and old transcrypt versions are just out of luck if they encounter a repo using a newer encryption method that their system doesn't support. I don't think there is anything much we can do about that?

If a user chooses to use an older encryption method for maximum compatibility this should be handled transparently for other users in all cases:

• the latest transcrypt will check the file's attributes and apply the older encryption method
• older transcrypt versions would be oblivious to all this and just do their thing, which would happen to be the right thing.

[elasticdog]

I think most of that sounds sane, but I'm not sure if setting an explicit path to the binary (versus just relying on the user's $PATH) would be worth the trouble versus transparently testing and warning about incompatibility issues. Is there a scenario you're imagining where the user would install a more modern version of openssl, but not want it to be their environment's default?

[jmurty]

That is a good point that we should expect users to simply add a newer version of OpenSSL to their path once they have gone to the trouble of installing it.

I myself don't do this on macOS despite installing later versions with Homebrew, mainly because I'm scared of breaking things in subtle ways which is surprisingly easy to do with macOS + OpenSSL + Homebrew. The fact I don't see the ugly OpenSSL warnings is a nice side-benefit. But that whole idea of making transcrypt learn the OpenSSL path is probably just me projecting my own poor practices.

Regarding my suggestions about adding cipher definition attributes to .gitattributes I'm still undecided about whether it really makes sense to do that, or whether it would be better to add explicit transcrypt version headers to the actual encrypted files instead as discussed briefly here, or some combination of the two. I might need to do some rough prototyping in code to try out different things and learn what tends to work best.