sublimehq / sublime_merge

Issue tracker for Sublime Merge
https://www.sublimemerge.com
273 stars 14 forks source link

ssh-agent not supported #1430

Open mpldr opened 2 years ago

mpldr commented 2 years ago

Version info

Description

SSH_AGENT is not respected/Passed to git

Steps to reproduce

Steps to reproduce the behavior:

  1. Configure git to use ssh-agent by setting SSH_AUTH_SOCK and SSH_AGENT_PID
  2. push to repo that requires a key from the ssh-agent
  3. image

I know that it works, because when I do my usual git push --tags --follow-tags origin HEAD it works just fine

Expected behavior

the ssh-key from the agent is used

dpjohnst commented 2 years ago

Hi @mpldr,

Thanks for reaching out - I'll be looking into this further.

How are you setting these environment variables? For example, via the command line? via the .bashrc file? etc

Thanks, - Dylan from Sublime HQ

mpldr commented 2 years ago

I set them in my .zshrc and .zshenv and just found the cause. I have to start SMerge from the commandline for these variables to be part of the environment (duh).

So, allow me to replace this Bugreport with a feature request.

Would it be possible to add an option to set a SSH_AUTH_SOCK value similar to how it is handled in KeePassXC? (see attached screenshot) Preferences > Advanced right below the custom SSH executable maybe.

mpldr commented 2 years ago

Cool, apprently GitHub does not handle attached images… great

2022-03-03-10-28-27

dpjohnst commented 2 years ago

Hi @mpldr,

Thanks for the additional information.

For some context, Sublime Merge loads the environment variables using /bin/zsh -l. As a result, it will only load environment variables set in the login profile (i.e. in .zprofile). As a result, setting the required variables in the .zprofile file should resolve the issue.

Let me know if this is not the case for you, and I can investigate further.

Cheers, - Dylan from Sublime HQ

mpldr commented 2 years ago

Sublime Merge loads the environment variables using /bin/zsh -l. When running zsh -l (my user's login shell) it is correctly loaded and can be used without issues. My system's /bin/sh is dash though (faster script execution). Is SMerge using /bin/sh or the user-defined login shell?

dpjohnst commented 2 years ago

Hi @mpldr,

My apologies, I was mistakenly under the impression you were on MacOS. In the case of Linux, the environment variables are not loaded from the login shell.

I would suggest either adding the variables to the environment file (i.e. /etc/environment), or using the git_env setting in Sublime Merge.

The git_env setting can be used to set environment variables when running Git commands. For example, you can add the following to the Sublime Merge settings file (accessible via Preferences > Edit Settings...):

// Settings in here override those in "Default/Preferences.sublime-settings",
// and are overridden in turn by syntax-specific specific settings.
{
    "git_env":
    {
        "KEY_1": "VALUE_1",
        "KEY_2": "VALUE_2",
    },
}

Hope this helps!

Kind regards, - Dylan

mpldr commented 2 years ago

Thanks a lot, this definitely helps. Is there a reason why SMerge does not load the environment from the loginshell on Linux?

dpjohnst commented 2 years ago

Hi @mpldr,

Apologies for the delay in getting back to you. I've investigated this further, and the environment variables set in the login profile should be loaded automatically by the desktop environment, and shouldn't require the above workaround I mentioned. You should be able to set the variables in the corresponding login config file and have them reflect in Sublime Merge (may require logging in again).

When you have a spare moment, could you run the following and share the output to determine what your login shell is:

getent passwd $LOGNAME | cut -d: -f7

Thanks, - Dylan

mpldr commented 2 years ago

Apologies for the delay in getting back to you. I've investigated this further, and the environment variables set in the login profile should be loaded automatically by the desktop environment, and shouldn't require the above workaround I mentioned.

This might be part of the issue, since I'm using sway

When you have a spare moment, could you run the following and share the output to determine what your login shell is:

getent passwd $LOGNAME | cut -d: -f7

/usr/bin/zsh