elasticdog / transcrypt

transparently encrypt files within a git repository
MIT License
1.43k stars 102 forks source link

xxd is now required? #138

Closed ljm42 closed 2 years ago

ljm42 commented 2 years ago

Hi, I'm back to this and I see there was an update just yesterday :)

It failed on my Unraid system though because I didn't have the "xxd" binary. I was able to get past that by installing vim.

It looks like xxd was added in this commit: https://github.com/elasticdog/transcrypt/commit/c6ec80e4b03f517023c81aadf4968214f548fbf4

It would be ideal if xxd wasn't required, but if it is now a requirement, the transcrypt install should probably check to confirm it is available before setting up the repo?

jmurty commented 2 years ago

Yes, xxd is now required to make transcrypt work with OpenSSL version 3+ (#133). We use it to convert hex-encoded salt data back to binary.

Is there a better option, ideally one that is available by default on most (or all) nixy systems? It would be a shame to add xxd as a requirement for the tiny job we use it for, if there is an alternative we could use instead.

cc @Erotemic

Erotemic commented 2 years ago

Agh, I should have checked if xxd was a common tool or not. I wasn't even thinking.

I do remember finding a tool to get the conversion to work was a huge PIA. I wroteup a note file on the best ways I found to do the conversion in bash: https://github.com/Erotemic/misc/blob/main/learn/bash_base_conversions.sh which is in large part based on this blog https://boubakr92.wordpress.com/2012/12/14/numeral-systems-conversion-in-bash/

One confounding factor is that bash variables can't contain raw bytes, so the conversion has to be done entirely in a stream.

@lmj42 do you know of a more common unix tool that can do the conversion from hex to raw bytes? Most things I'm seeing are just pointing to xxd.

If xxd is the most widely available program for accomplishing the task (which is 100% necessary for transcrypt to function with OpenSSL3), then we have to bite the bullet, but one mitigation could be to support OpenSSL1.x when xxd is not installed, via:

    openssl_major_version=$($openssl_path version  | cut -d' ' -f2 | cut -d'.' -f1)
    if [ "$openssl_major_version" -ge "3" ]; then
        # openssl 3.x usage that requires xxd
    else
        # openssl 1.x usage that does not need xxd. 
    fi

That in addition to checking that xxd is available on install. But the best option would be to find a more native solution (does one exist?)

jmurty commented 2 years ago

After looking around I think we might be stuck with xxd as a new requirement for compatibility with OpenSSL 3+ but I like @Erotemic's idea of making it a requirement only when it's really needed for that compatibility.

I have made these changes, and documented the new requirement, in commit a258dc442b3e7d0a766fb289492a794d909b6378 on the main branch.