Better visibility into underlying git commands being run?

[VolatileDream]

Running some of the git-subrepo commands can cause multiple connections to git remotes, each requiring their own authentication action. This can be confusing or concerning for users using hardware backed credentials.

Example:

• Create a GPG Authentication key on a Yubikey, and use it for SSH
• Set the policy to "touch everytime" -> require a yubikey touch every time an SSH connection uses that key
• Configure some git subrepos using git:
• Perform git-subrepo actions (eg: push)
• Notice the yubikey flash for touch input, but nothing is printed to the terminal

The Git commands being run are printed when passing the -v flag, but connecting to remotes should probably be printed by default to help users understand why they are being prompted.

[admorgan]

You are absolutely correct. I will have to find a way to test this without a yubi key, but I expect just requiring an ssh password with a similar setting would be sufficient.

[VolatileDream]

[...] I expect just requiring an ssh password with a similar setting would be sufficient.

👍 I'd expect that as well.

I recall ssh doing some sort of key caching, but I can't remember if that was by default or not, so there may also be some ssh config required to maximize password prompting. With a quick read over the ssh, ssh-agent, and ssh_config manual pages it looks like the relevant pieces of config would be:

AddKeysToAgent no in .ssh/config:

Specifies whether keys should be automatically added to a running ssh-agent(1). [...] The argument must be no (the default), yes, confirm (optionally followed by a time interval), ask or a time interval.

Or explicitly starting the agent with ssh-agent -t 0s, which would affect both ssh and ssh-add:

Set a default value for the maximum lifetime of identities added to the agent. [...] Without this option the default maximum lifetime is forever.

But it's probably just as simple as unsetting SSH_AUTH_SOCK when running git commands, ie: SSH_AUTH_SOCK= git subrepo ....