Re: Git remote origin leaks user access token

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2024-07-01 at 11:46:03, Jonathan Nieder wrote:
> (+cc: git@xxxxxxxxxxxxxxx, git-security -> bcc)
> Hi!
> 
> limin wrote:
> 
> > Hi, I found a potential security issue when running a tool in my private
> > project. I think this exposes my personal access token to danger when using
> > "git remote get-url origin".
> 
> I'm moving this conversation to the public Git mailing list, as this
> behavior is well known.
> 
> I look forward to working together on ways to reduce the impact (for
> example, ways to encourage people to use their system's password
> keychain instead of including credentials in URLs).

I'll point out that we already document this in the Git FAQ (git help
gitfaq):

----
How do I specify my credentials when pushing over HTTP?

The easiest way to do this is to use a credential helper via the
`credential.helper` configuration.  Most systems provide a standard
choice to integrate with the system credential manager.  For example,
Git for Windows provides the `wincred` credential manager, macOS has the
`osxkeychain` credential manager, and Unix systems with a standard
desktop environment can use the `libsecret` credential manager.  All of
these store credentials in an encrypted store to keep your passwords or
tokens secure.

In addition, you can use the `store` credential manager which stores in a file
in your home directory, or the `cache` credential manager, which does not
permanently store your credentials, but does prevent you from being prompted for
them for a certain period of time.

You can also just enter your password when prompted.  While it is possible to
place the password (which must be percent-encoded) in the URL, this is not
particularly secure and can lead to accidental exposure of credentials, so it is
not recommended.
----

We also have a FAQ entry about how to read credentials from the
environment as well, since that's a common thing people want to do.

I also recently added support for putting credentials that are not
username and password (e.g., Bearer tokens) in credential helpers
specifically for this purpose, since people were using
`http.extraHeader` for this, which is equally insecure.

I do want to point out that several people, not just me, have worked
together to make using a credential helper as easy and robust as
possible.  I mention this not to contradict Jonathan, who I think is
also trying to help in this regard, but mostly to mention that as a
project we've been trying to gently nudge people into doing the more
secure thing.  If people have further suggestions on how to make this
easier for users in the future, I'm very eager to hear them.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux