Failed to sign SSH on Windows

[DrBarnabus]

Version

0.14.5

Operating System

Windows

Distribution Method

msi (Windows)

Describe the issue

With the latest release I gave SSH signing on Windows another go, this used to show Program not found.

It's now getting further but I'm still hitting an issue with it now instead returning Failed to sign SSH: Cannot open C:UsersDanielWAppDataLocalTemp.tmp1cG0m8 for signing: No such file or directory

Looks like sh from Git likes the windows formatted path being passed in, curiously the signing key which is also a similar path does work though.

How to reproduce (Optional)

1. Open Gitbutler & Navigate to the Git settings of a Project
2. Select to Sign commits & configure for SSH signing with a valid key & signing program empty (default)
3. Click Test Signing

Expected behavior (Optional)

I should be able to sign using SSH on Windows without receiving an error.

Relevant log output (Optional)

From Test in Settings

2025-01-20T21:05:10.414873Z  INFO check_signing_settings: crates\gitbutler-tauri\src\repo.rs:39: new id=7f364b41-2e01-4bef-abb3-9529ca64f1c6
2025-01-20T21:05:10.468239Z ERROR check_signing_settings: crates\gitbutler-tauri\src\repo.rs:39: error=Error(Failed to sign SSH:  Cannot open C:UsersDanielWAppDataLocalTemp.tmp1id5Uw for signing: No such file or directory
) id=7f364b41-2e01-4bef-abb3-9529ca64f1c6
2025-01-20T21:05:10.468268Z  INFO check_signing_settings: crates\gitbutler-tauri\src\repo.rs:39: close time.busy=53.4ms time.idle=10.2µs id=7f364b41-2e01-4bef-abb3-9529ca64f1c6

From Committing

2025-01-20T20:56:33.865799Z  INFO commit_virtual_branch: crates\gitbutler-tauri\src\virtual_branches.rs:31: new project_id=7f364b41-2e01-4bef-abb3-9529ca64f1c6 branch=2d6b08c6-db63-4e8c-9d18-ed34e411a83a Test commit ownership=Some(BranchOwnershipClaims { claims: [OwnershipClaim { file_path: "CHANGELOG.md", hunks: [Hunk { hash: Some(75b3ae88934aac9988ec5ca701136536), start: 1, end: 7 }] }] })
2025-01-20T20:56:33.973946Z ERROR commit_virtual_branch: crates\gitbutler-tauri\src\virtual_branches.rs:31: error=Error(failed to commit

Caused by:
    0: errors.commit.signing_failed
    1: Failed to sign commit: Failed to sign SSH:  Cannot open C:UsersDanielWAppDataLocalTemp.tmpdhLpLR for signing: No such file or directory
       ) project_id=7f364b41-2e01-4bef-abb3-9529ca64f1c6 branch=2d6b08c6-db63-4e8c-9d18-ed34e411a83a Test commit ownership=Some(BranchOwnershipClaims { claims: [OwnershipClaim { file_path: "CHANGELOG.md", hunks: [Hunk { hash: Some(75b3ae88934aac9988ec5ca701136536), start: 1, end: 7 }] }] })
2025-01-20T20:56:33.973978Z  INFO commit_virtual_branch: crates\gitbutler-tauri\src\virtual_branches.rs:31: close time.busy=108ms time.idle=9.50µs project_id=7f364b41-2e01-4bef-abb3-9529ca64f1c6 branch=2d6b08c6-db63-4e8c-9d18-ed34e411a83a Test commit ownership=Some(BranchOwnershipClaims { claims: [OwnershipClaim { file_path: "CHANGELOG.md", hunks: [Hunk { hash: Some(75b3ae88934aac9988ec5ca701136536), start: 1, end: 7 }] }] })

[DrBarnabus]

Did a bit of debugging, it seems like wrapping the path with single quotes resolves the issue and allows the signing to succeed.

Confirmed using a debug build that this is the case. I imagine this could be an issue with the other windows paths being passed into sh.exe shell that's bundled with Git.

For reference, I added the single quotes to the second parameter here, and it fixed the issue:

gitbutler/crates/gitbutler-repo/src/repository_ext.rs

Line 458 in e6713c7

let args = format!("{} {}", signing_key, buffer_file_to_sign_path_str);

I'd be happy to contribute a PR, but I'm not sure if this change would affect other environments such as macOS/Linux negatively.

[GordonBeeming]

I'm wondering if a recent fix for windows broke this on Mac 😅... my signing has been working for months with 1Password... it looks like maybe we're hitting the same or similar error messages though... posted as another issue in case it's not related #6014

[Byron]

Thanks a lot for reporting!

Probably on Windows, launching things through the Git shell allows it to find various other Unix programs that otherwise wouldn't be in PATH, so overall it improves the situation.

As for the path, quoting it should work everywhere in case you want to submit a PR, @DrBarnabus, that would be much appreciated.

As for the regression on MacOS, @GordonBeeming, I am not sure how this can happen, but would like to reproduce it before attempting a fix. Maybe the solution should be to use a shell on Windows, and no shell everywhere else, but ideally we'd understand why this works fist to maybe find a solution that works everywhere.

[Caleb-T-Owens]

After some initial debugging, the macos issue seems to be related to having a literal SSH key. I've setup 1password signing where I've put the public key into a file, and put the filepath to the public key into my config, which seems to work.

[GordonBeeming]

I'll give that a try and check if it's worth calling out in the docs (assuming it's not there already) 😅... thank you.

I tried checking through commits but couldn't see what would have changed this behaviour 🫣

Edit: Just realised I'm on this issue, I'm assuming it's a similar fix for my other issue

[Byron]

Thanks for the hint at quoting, which I believe is now implemented here: #6028 .
It was tested thoroughly on MacOS and doesn't make anything worse. On Windows I'd expect the backslashes now be literal which is exactly what should be needed.