Reduce risk of oauth token compromise by storing tokens in $XDG_RUNTIME_DIR

Feature description

On Desktop Linux Git Credential Manager stores Azure DevOps oauth tokens encrypted in Gnome Keyring, but on headless Linux it stores them unencrypted and outputs a warning.

It is understandable that GCM stores oauth tokens unencrypted on headless Linux because headless Linux does not provide a standardized credential store. However, headless Linux is used much than desktop Linux, and storing oauth tokens unencrypted on disk remains a security concern.

What can be done ?

One simple improvement would be to store oauth tokens under directory $XDG_RUNTIME_DIR when this exists.

Many Linux distributions use systemd and create a user session when the user logs in or starts an SSH session. When the user session is first started the system creates a tmpfs runtime filesystem and sets $XDG_RUNTIME_DIR to point to it. When the user's last session ends the system deletes the user's runtime filesystem. This is observed on both Ubuntu and Mariner (with systemd).

Storing oauth tokens under $XDG_RUNTIME_DIR would have two immediate benefits:

1. The runtime filesystem uses tmpfs so oauth tokens stored in $XDG_RUNTIME_DIR are not stored on disk.
2. The runtime filesystem is deleted when the user sessions terminate, so oauth tokens stored in $XDG_RUNTIME_DIR are deleted at the end of the user session.

These two benefits protect the oauth tokens almost as well as Gnome Keyring. Gnome Keyring does not protect against people who have access to the user session (see Gnome Keyring Security Philosophy), so the main difference is probably not encryption but Gnome Keyring having better protection against memory being swapped to disk. (I don't think Windows DPAPI protects encrypted data from people who have access to the user session either, so Windows might not be much better.)

Side effects of the proposed change:

• Users who exit SSH sessions then start a new SSH session need to re-authenticate.
• Processes left running after the SSH session ends (e.g. using nohup or tmux) lose access to oauth tokens.

Since GCM is intended for interactive use these side effects are probably acceptable, but if not we could allow users to override this behavior and store oauth tokens under $HOME rather than $XDG_RUNTIME_DIR (at the cost of persistent oauth tokens on disk).

Proposed Solution

When storing unencrypted oauth tokens on Linux, check whether $XDG_RUNTIME_DIR is set and refers to a valid directory, and if so store oauth tokens under $XDG_RUNTIME_DIR rather than $HOME.

The issue does not name implementation files or tests. Start by locating the Linux code path for unencrypted OAuth token storage, then inspect how the credential location is selected and tested. Done means using a valid $XDG_RUNTIME_DIR instead of $HOME while preserving the existing fallback behavior.