Include SSH_AUTH_SOCK in filtered environment

[Noctem]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew tests with your changes locally?

---

So my situation may not be very common, but brew update broke for me after b26a0d4 because I have the following in my .gitconfig:

[url "[email protected]:"]
	insteadOf = https://github.com/

which forces all GitHub connections to use SSH. With SSH_AUTH_SOCK removed from the environment git is no longer able to find my SSH agent and I get:

Permission denied (publickey).
fatal: Could not read from remote repository.

for each of my taps. Copying SSH_AUTH_SOCK into the filtered environment fixed the problem.

Fixes #3503

[reitermarkus]

Neat, I didn't know about insteadOf.

Although, it is weird that I cannot reproduce this if I'm using the same config. Does this only happen if you haven't called ssh-add -A yet?

[Noctem]

@reitermarkus No, my keys were already added to the agent but the errors still occurred on both machines I tried it on.

So when you tried to reproduce you had [email protected]:.insteadof=https://github.com/ in your global config and homebrew.devcmdrun=true in your local config?

[reitermarkus]

So when you tried to reproduce you had [email protected]:.insteadof=https://github.com/ in your global config and homebrew.devcmdrun=true in your local config?

Yes, seems like SSH_AUTH_SOCK has no effect on anything for me. I can even completely unset it and everything still works.

[MikeMcQuaid]

Also, I'm not sure this is configuration we want to allow, anyway. I'm going to investigate how to have Homebrew's brew update and friends bypass ~/.gitconfig.

[Noctem]

@reitermarkus Do you have an unencrypted key (that's authorized on GitHub) at a standard location like ~/.ssh/id_rsa? It's probably finding it automatically if you do. The key I have authorized for GitHub is encrypted and named github_ed25519 so it can't be found or used without the help of the agent.

@MikeMcQuaid Why is that?

[MikeMcQuaid]

@MikeMcQuaid Why is that?

You don't need SSH authentication to access public GitHub repositories. That we use Git for our update mechanism is an implementation detail that we don't want to allow user configuration of (because user custom configuration breaks things; here is an example where your configuration has broken things, for instance). This isn't too bad when users know what has broken it but often people will copy-paste to ~/.gitconfig or ~/.curlrc and then get confused when Homebrew doesn't work for them.

[reitermarkus]

Do you have an unencrypted key (that's authorized on GitHub) at a standard location like ~/.ssh/id_rsa?

My github_rsa says Proc-Type: 4,ENCRYPTED, so I guess it's encrypted.

[reitermarkus]

@Noctem, can you try if changing https://github.com/Homebrew/brew/blob/master/Library/Homebrew/cmd/update.sh#L22 to

env HOME=/dev/null "$GIT_EXECUTABLE" "$@"

works?

[Noctem]

@reitermarkus

My github_rsa says Proc-Type: 4,ENCRYPTED, so I guess it's encrypted.

Weird. I don't know how it works for you then, maybe I'll take a look at the git source code to see how it finds keys. Does it ask for a password to decrypt your key while it updates?

env HOME=/dev/null "$GIT_EXECUTABLE" "$@" works for everything except for my own tap which is a private repo on GitHub and thus requires SSH (apparently the same situation as #3503).

@MikeMcQuaid

You don't need SSH authentication to access public GitHub repositories. That we use Git for our update mechanism is an implementation detail that we don't want to allow user configuration of

I understand, and I sympathize with having to deal with support requests resulting from misconfiguration. I just prefer using SSH whenever possible, and I previously forgot to mention the more justifiable use-case of having private taps which require SSH access (which also applies to me, as mentioned above).

If you do end up ignoring users' .gitconfigs, I would just request that there be an option or environment variable to override that (like HOMEBREW_NO_ENV_FILTERING). There are other git options that I want to retain as well (core.compression for example).

[MikeMcQuaid]

I'm convinced, thanks again for your contribution, @Noctem!