#56 Use 16 hex characters in salt

[dirkhas]

• The current salt uses 15 hex characters and the new-line character on
  *nix, and 14 hex characters and carriage-return plus new-line characters
  on Windows. Stripping both characters in salt-generation makes
  the code cross-platform and eliminates the OpenSSL warning that would
  otherwise be printed.
• WARNING: This requires re-encrypting secrets because salts change!
• Fixes Openssl 1.1.1 salt warnings / Git for Windows interoperability #56

[dirkhas]

Because #58 already suppresses warnings, a way to make a backwards-compatible change that would fix the cross-platform issues described in #56 (i.e. make the salt-derivation work identical on both *nix and Windows) would be to substitute
tr -d '\r'
for
tr -d '\r\n'
With no '\r' to remove on *nix, the change only has effect on Windows.

[leclairmael]

@dirkhas Thanks for the PR, looks good. Hopefully it gets released soon.

[ghost]

why not tail -c 17 ?

[leclairmael]

@ricardo0624 The salt needs to be exactly 16 characters.

[ghost]

@leclairmael tail -c 17 is exactly 16 characters. op ,tail -c 16 is just 15 characters.

[dirkhas]

@leclairmael tail -c 17 is exactly 16 characters. op ,tail -c 16 is just 15 characters.

@ricardo0624 tail -c 17 is exactly 17 characters and tail -c 16 is exactly 16 characters, but if you feed something ending in a new-line -- for example anything from echo -- the last character is a new-line. So it looks like there is one less character.

Try for example
echo "1234567890abcdef" | tail -c 16 | wc and notice that 16 characters are counted. Also notice that
echo "1234567890abcdef" | tail -c 16 doesn't print the '1' because echo appends a new-line character so 17 characters are fed to tail but only the last 16 should be printed.

[elasticdog]

@dirkhas Sorry for the radio silence on all these issues...thank you for noticing the inconsistency and for providing the fix! What's the proposed workflow for re-encrypting in this case? Once I can sort out easy directions for people to migrate, I'll get this merged and will cut a new release once I've gone through the rest of the backlog.

[elasticdog]

I guess this would be it after updating transcrypt:

$ git add -- $(transcrypt --list)
$ git commit --message="Re-encrypt files protected by transcrypt using new salt value"

[elasticdog]

Actually, it's not quite that simple since the repository's configured clean filter script will have to be updated, and transcrypt won't do that if the repo is dirty. Need to think about this a bit more, as I think this is the first real backward incompatible change the project has needed. If you have a working set of steps, please do let me know...

[elasticdog]

For posterity, flushing the credentials first and then re-configuring the repo before adding the files does the trick:

$ transcrypt --display
The current repository was configured using transcrypt version 1.1.0
and has the following configuration:

  GIT_WORK_TREE:  /home/elasticdog/src/transcrypt
  GIT_DIR:        /home/elasticdog/src/transcrypt/.git
  GIT_ATTRIBUTES: /home/elasticdog/src/transcrypt/.gitattributes

  CIPHER:   aes-256-cbc
  PASSWORD: correct horse battery staple

Copy and paste the following command to initialize a cloned repository:

  transcrypt -c aes-256-cbc -p 'correct horse battery staple'
$ transcrypt --flush-credentials
$ transcrypt -c aes-256-cbc -p 'correct horse battery staple'
$ git add -- $(transcrypt --list)
$ git commit --message="Re-encrypt files protected by transcrypt using new salt value"