transcrypt does not update built-in clean/smudge filters

[apeschel]

As far as I can tell, there's no code path that updates the transcrypt scripts stored in .git/crypt, and these files are only updated on initialization.

This is problematic, as changes to these scripts are never propagated out to repositories with transcrypt already initialized.

In c8e4f72 the method for generating the salt was modified, and is not backwards compatible with the previous method. As a result, users who initialized a repository with transcrypt previous to this commit will be generating different salts, and thus be producing different output than those who initialized the repository after this commit.

For now, the work around is to have all users run transcrypt -u and rerun transcrypt, but this is a very tedious exercise to orchestrate across any organization of any size, and is prone to error.

transcrypt should have some facility to update these files automatically and transparently to users.

The most straightforward approach I can think of to fix this in transcrypt is to have it update these files every time it is run in a git repository, but that might be overkill.

A better solution might be to have these files be replaced with either symlinks or simple wrappers that call back out to transcrypt, and add this functionality in as a sub-module to the transcrypt program. This way these functions would always be tied in to the correct version expected by the current version of transcrypt.

[jmurty]

Hi @apeschel the new --upgrade command added in #86 might help with updates. It's still a manual step, but easier than the uninstall-then-reinit process.

[jmurty]

Hi @apeschel I think the new --upgrade command added to the master branch in ea4aa35 solves the main problem outlined in this issue, so I am closing this specific issue. Please let us know what you think of it if you are able to try the --upgrade command now on the master branch.

Your idea about "internalising" the various clean / smudge / merge scripts as mentioned here and explored in detail in PR #73 is an interesting one, and something I'm still considering in a broader context where we may need more sophisticated and (hopefully) shared code to handle different versions and capabilities in OpenSSL for #55 etc.

Thanks for contributing!