Unnecessarily strict GUI requirement for Secret Service API

[cyqsimon]

When SSH-ed into a remote host that uses GCM with Secret Service API, authentication fails with this message:

fatal: Cannot use the 'secretservice' credential backing store without a graphical interface present.
See https://aka.ms/gcm/credstores for more information.

The linked docs provides the following justification:

A graphical user interface is required in order to show a secure prompt to request a secret collection be unlocked.

But this does not take into account that maybe the keyring is already unlocked by other means. The user could:

1. Also have a graphical login separate from the SSH instance.
2. Or configured the provider to unlock over SSH.

... the first one being my use case.

Indeed running lssecret in the SSH session confirms that the keyring is already unlocked and accessible. That means GCM's refusal to proceed is overly restrictive.

Versions

Arch Linux x86_64
GCM 2.6.1+786ab03440ddc82e807a97c0e540f5247e44cec6

[cyqsimon]

Taking a look at the implementation, as a workaround I simply ran DISPLAY=foo git pull over SSH and everything works just fine. So yeah, this current behaviour is certainly overly restrictive.

[dscho]

I don't see any alternative, though: Not requiring a graphical user interface to be able to be shown would deteriorate the user experience massively. The exceedingly common use case, after all, is that the users do not have unlocked the keyring separately and the operation is still run within the grace period before the next unlock is required.

[cyqsimon]

Not requiring a graphical user interface to be able to be shown would deteriorate the user experience massively.

I don't get it. How so?

The exceedingly common use case, after all, is that the users do not have unlocked the keyring separately and the operation is still run within the grace period before the next unlock is required.

If I understand you correctly, you are worried that the user may have set up some automation while graphically logged in, see that it is working, then logging out causing the keyring to lock and hence failing said automation. Is that correct?

I understand the reasoning behind this. But I disagree that "to prevent a potential footgun" is sufficient justification to completely disallow using GCM in a headless environment, which is perfectly reasonable if the user takes care to set up keyring unlock properly. So what I'm suggesting is perhaps just downgrade the hard error to a warning, or at minimum provide an explicit option to override this guard.

[dscho]

@cyqsimon I understand that you're really keen on having your use case addressed. However, the vast majority of users who use Git on Linux via SSH will require some way to authenticate using a GUI via the same SSH connection. Hence the requirement. I don't think that you truly appreciate how other users use GCM, and would be harmed by the change you proposed. Neither do you need to: You are not a maintainer. Since you do have a workaround, we can actually close this ticket, without having to make things worse for other Git Credential Manager users.

[cyqsimon]

I don't think that you truly appreciate how other users use GCM, and would be harmed by the change you proposed.

Please be assured that I would not suggest any changes that I know would harm other users' UX. I'm not that selfish. I simply do not understand why you believe this proposed change (downgrading the hard error to a warning) would be harmful. Can you please explain your reasoning in a bit more detail?

Since you do have a workaround, we can actually close this ticket.

The problem with this workaround is that it relies on a specific implementation detail. If for whatever reason in the future, the detection logic for "whether this is a GUI environment" changes, this workaround would break without warning.