SSH: Unable to find program

[TGTGamer]

Version

0.14.4

Operating System

Windows

Distribution Method

msi (Windows)

Describe the issue

Using 1password as my ssh agent. Was working until I updated to latest version:

SSH agent path: C:\Program Files\1Password\app\8\op-ssh-sign.exe
Confirmed it exists, is working for other programs

How to reproduce

No response

Expected behavior

Should sign commits.

Relevant log output

Program not found
user.C034edPS.js:4 
 ipc->check_signing_settings: {"id":"31d6e997-0f4b-4b08-8a9a-e666c46c1609"} s: Program not found
    at s.fromError (http://tauri.localhost/_app/immutable/chunks/ipc.DM3tJdKb.js:1:1093)
    at w (http://tauri.localhost/_app/immutable/chunks/ipc.DM3tJdKb.js:1:1297)
    at async Object.C [as onclick] (http://tauri.localhost/_app/immutable/nodes/27.0QkJqKa9.js:10:818) 
Object
user.C034edPS.js:4 
 Error checking signing: s: Program not found
    at s.fromError (http://tauri.localhost/_app/immutable/chunks/ipc.DM3tJdKb.js:1:1093)
    at w (http://tauri.localhost/_app/immutable/chunks/ipc.DM3tJdKb.js:1:1297)
    at async Object.C [as onclick] (http://tauri.localhost/_app/immutable/nodes/27.0QkJqKa9.js:10:818)
(anonymous)	@	user.C034edPS.js:4

[Byron]

Thanks a lot for reporting!

I am pretty sure that #5756 has something to do with it.

• The problem is that on Windows, the current implementation won't use a shell which is probably required for all required environment variables to be picked up.

This I will address, hoping that it will work again then.

[DS-DanielW]

Still getting this same issue on the latest nightly with the potential fix merged.

2025-01-03T08:34:23.899332Z  INFO check_signing_settings: crates\gitbutler-tauri\src\repo.rs:38: new id=258c22eb-ba53-4ee5-a89d-ff5c4781f566
2025-01-03T08:34:23.906000Z ERROR check_signing_settings: crates\gitbutler-tauri\src\repo.rs:38: error=Error(program not found) id=258c22eb-ba53-4ee5-a89d-ff5c4781f566
2025-01-03T08:34:23.906021Z  INFO check_signing_settings: crates\gitbutler-tauri\src\repo.rs:38: close time.busy=6.68ms time.idle=10.9µs id=258c22eb-ba53-4ee5-a89d-ff5c4781f566

[Caleb-T-Owens]

@Byron I've taken a look at the PR which seems to use with_shell which is always uses sh, which most people probably don't have an environment set up for. We possibly ought to try doing with_shell_program and pass in $SHELL by default, and have a user setting that lets them override it.

WDYT?

[Byron]

This is also what I had in mind when adding with_shell_program(), and I am not surprised the fix didn't work after all. What I kept wondering is how this could ever work, as previously it was launching ssh directly if I remember correctly.

In any case, even when using the shell configured by the user, it might not come up as login shell and thus doesn't read all the configuration files that it would need to truly resemble the environment that the user sees in a terminal. On top of that, what it takes to spawn a login shell seems to differ depending on the shell.

What we'd really want is a way to use the environment that the user sees in their standard terminal environment, and if available, there wouldn't be a need to go through a shell at all.

Thinking about it more, once it's clear how to make a shell launch as interactive shell at least, or login shell even, while executing a command, then doing so might be the most compatible as on each invocation it would pick up the latest settings. Otherwise, if GitButler were to read the environment from the loginshell and make it its own, it would effectively cache these and can't pick up changes easily.

Probably it will be easiest to to try to use $SHELL and with_shell_program(), and if that isn't good enough for some shells, one could add something like with_login_shell() which will automatically add the required arguments depending on the currently set shell.

How does that sound?

[Caleb-T-Owens]

Probably it will be easiest to to try to use $SHELL and with_shell_program(), and if that isn't good enough for some shells, one could add something like with_login_shell() which will automatically add the required arguments depending on the currently set shell.

How does that sound?

Sounds good to me 👍

[Caleb-T-Owens]

Are you interested in working on it? Otherwise I can take a look

[Byron]

I just realized that I was still assigned, but would love if you could take it over.

[Byron]

The linked PR will now enforce using the current users default shell, assuming it is picked up in the $SHELL environment variable, which should make signing more likely. And I say it carefully as my tests indicate that the environment of my login shell is actually already present in the GitButler application even when started through the finder. Thus, if launching these programs through a shell changes something, their effect is probably more subtle than environment variables.

In any case, at most a day after the PR gets merged one should be able to try it out in the nightly build.