Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Suggestion: provide a mechanism for users to specify the openssl path #108

Closed
jwatt opened this issue Feb 3, 2021 · 5 comments
Closed

Suggestion: provide a mechanism for users to specify the openssl path #108

jwatt opened this issue Feb 3, 2021 · 5 comments

Comments

@jwatt
Copy link

jwatt commented Feb 3, 2021

On macOS it would be useful to be able to tell transcrypt to use the Homebrew installed openssl, but I don't want to add /usr/local/opt/openssl/bin to PATH due to the potential for side affects. More specifically I'm hoping that yadm could pass any value set for yadm.openssl-program in its configuration file along to transcrypt in order to avoid the "deprecated key derivation used" warnings.
@jmurty
Copy link
Collaborator

jmurty commented Feb 3, 2021

Hi @jwatt this is something we have discussed before in and around this comment: #55 (comment)
So far we have decided against making the OpenSSL binary path configurable, though like you I would enjoy being able to customise the OpenSSL version used on MacOS.

I'm not familiar with yadm (Yet Another Dotfiles Manager). This seems to be the relevant section on using yadm with transcrypt though the only mention of the yadm.openssl-program option I found is here.

Can you talk more about how yadm could, or should, relay settings like yadm.openssl-program through to programs it invokes? If it does something relatively simple, we might be able to work from that to come up with a clean way to set a custom OpenSSL path both with and without using yadm.

@jwatt
Copy link
Author

jwatt commented Feb 4, 2021 •
edited
Loading

Hi @jmurty. Thanks for the reply and link to the previous discussion.

Note that I'm just a casual user of yadm. That said, it seems like yadm is essentially a git wrapper that at its core invokes git --git-dir=~/.local/share/yadm/repo.git --work-tree=~ <other args passed to yadm> (plus other niceties).

yadm, like transcrypt, is just a single file shell script. I had expected that yadm invokes transcrypt frequently, passing command line arguments, and therefore the obvious mechanism for yadm to communicate the openssl path with transcrypt would be for it to pass the openssl path using a new transcrypt command line argument. It looks like I was mistaken in my assumptions about how things work though, and actually once transcrypt is set up yadm plays no direct part in the encryption/decryption or invoking transcrypt code.

Besides that, on reflection it probably wouldn't make sense to tell yadm about the openssl path if it's just passing on the args to transcrypt.

Ignoring yadm for the moment, presumably if transcrypt were to add support for specifying an openssl path it would store it in a [transcrypt] section of the user's $XDG_CONFIG_HOME/git/config / ~/.gitconfig. (Or else in a new ~/.config/transcrypt/config -- yadm stores the path in ~/.config/yadm/config, but it's more a git wrapper than a git integration.) So maybe it would make sense to add a transcrypt config command to allow users to specify an openssl path globally for their user for transcrypt. In that case there would be no need for yadm to coordinate with transcrypt on the openssl path at all.

@jwatt jwatt changed the title Suggestion: add an --openssl-program command line argument Suggestion: provide a mechanism for users to specify the openssl path Feb 4, 2021
@jwatt
Copy link
Author

jwatt commented Feb 6, 2021

As you pointed out in #55 (comment), storing the path in the user's $XDG_CONFIG_HOME/git/config or ~/.gitconfig doesn't seem like a good idea. Many people synchronize their ~/.gitconfig and other dotfiles across multiple machines, and the openssl path will likely vary from machine to machine.

Perhaps storing the path in the per-repo .git/config, or else allowing it to be communicated via an environment variable (.bashrcs etc. can have per-machine conditional if-else blocks), would be better.

jmurty added a commit that referenced this issue Feb 12, 2021
@jmurty
Let user set a custom path to openssl #108
4b319aa 
Add the optional --openssl-path argument when initialising a repo to
tell transcrypt to use an explicit path to the openssl binary,
instead of using whatever version is on the user's path.

The openssl path is now saved as a new transcrypt.openssl-path Git
config local setting in the repository, alongside the other transcrypt
settings like cipher, password etc.

If the user provides --openssl-path this explicit path is stored in
the local Git config, otherwise the default value 'openssl' is stored
which will fall back to the default behaviour of finding openssl on
the user's $PATH.

The --openssl-path argument gets special treatment for upgrades: an
--openssl-path argument value given along with --upgrade will replace
the existing config setting, despite config settings normally being
retained across upgrades.
@jmurty jmurty mentioned this issue Feb 12, 2021
Merged
@jmurty
Copy link
Collaborator

jmurty commented Feb 12, 2021 •
edited
Loading

Hi @jwatt in #111 I have taken a first pass at implementing an --openssl-path argument option to set the OpenSSL binary version transcrypt will use. This setting is stored in the local Git config transcrypt.openssl-path and defaults to 'openssl' (i.e. by default it will use the first openssl binary found on the user's $PATH).

You can use the --upgrade operation to update the path in a pre-configured repo, like so:

./transcrypt --upgrade --yes --openssl-path=/usr/local/opt/openssl@1.1/bin/openssl

Can you try this and see if it works for you? Be warned that I have only done initial testing.

jmurty added a commit that referenced this issue Feb 19, 2021
@jmurty
Remove ability to change custom openssl path on upgrade #108
222bf43 
I reconsidered the feature that let users set or update a custom
openssl path using the --upgrade flag. This was unusual behaviour:
no other transcrypt settings could be altered during upgrade.

Since it is somewhat likely a user will need or want to change their
openssl path over a repository's lifetime, the help text now says
how to do that using a standard git config-setting command.
jmurty added a commit that referenced this issue Feb 19, 2021
@jmurty
Add documentation for openssl-path #108
7a8ce48
jmurty added a commit that referenced this issue Feb 27, 2021
@jmurty
Let user set a custom path to openssl #108
dce1ad0 
Add the optional `--set-openssl-path` argument to tell transcrypt
to use an explicit path to the openssl binary, instead of whatever
version is found on the user's `$PATH`.

The OpenSSL path can be changed on init, during an upgrade,
or along with any other transcrypt command (even by itself).

The openssl path is saved as a new `transcrypt.openssl-path` Git
config local setting in the repository, alongside the other transcrypt
settings like cipher, password etc.
@jmurty
Copy link
Collaborator

jmurty commented Feb 27, 2021

Hi @jwatt I think the recently-merged --set-openssl-path feature in dce1ad0 should let users set a custom path to OpenSSL. --set-openssl-path

For macOS users with newer, better versions of OpenSSL installed with Homebrew a command like the following will tell transcrypt to use that version instead of the one included with macOS: transcrypt --openssl-path=/usr/local/opt/openssl@1.1/bin/openssl

This implementation saves a transcrypt.openssl-path config setting in the local repository, which means it must be re-run for every repo, but because it relies on a standard Git setting you could work around this by setting git config --global transcrypt.openssl-path manually if/when you know it's safe to do this for your particular setup.

Can you confirm this works for you with the latest code from master and re-open this issue if you find problems?

@jmurty jmurty closed this as completed Feb 27, 2021
jmurty added a commit that referenced this issue Oct 15, 2022
@jmurty
Merge branch 'main' into multiple-passphrases-in-one-repo
30a8faf 
# By James Murty (18) and others
# Via GitHub (1) and James Murty (1)
* main: (26 commits)
  Centralise load and save of password into functions #141
  Fix date of 2.2.0 release
  Ensure tests use "main" as default branch name #143
  Use OpenSSL for B64 encoding not `base64` which differs between Linux and Mac #140
  Use core attributesFile from worktree (#137)
  Document `xxd` requirement, and make optional with OpenSSL < 3 (#138)
  Prepare for 2.2.0 release
  Fix when using OpenSSL 3 which no longer embeds salt in output (#135)
  Consolidate all git operation scripts into a single transcrypt script
  Fix handling of small files and files with null in first 8 bytes (#116)
  Improve command hint to fix secret files not encrypted in index (#120) (#130)
  Remove Ubuntu 16.04 LTS from test matrix (#123)
  Configure default Git branch name for macOS tests in GitHub
  Handle rename of primary branch from "master" to "main"
  Ensure Git index is up-to-date before dirty repo  check #37 (#109)
  Fix incorrect salt when partially staged files are commited (#119)
  Use shorthand for grep options for broader compatibility (#121)
  Let user set a custom path to openssl #108
  Install entire transcrypt script into repository
  Change version to indicate development "pre-release" status
  ...

# Conflicts:
#	README.md
#	tests/_test_helper.bash
#	tests/test_cleanup.bats
#	tests/test_crypt.bats
#	tests/test_init.bats
#	tests/test_not_inited.bats
#	transcrypt
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jmurty @jwatt