{"thread":{"id":"58763","subject":"The enduring popularity of git-credential-store","startedAt":"2022-11-08T10:51:22Z","lastAt":"2023-05-29T09:54:27Z","messageCount":13,"participants":["M Hickford","Michal Suchánek","Jeff King","Taylor Blau","brian m. carlson","Matthew John Cheetham","Lessley Dennington"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"466811","messageId":"CAGJzqskRYN49SeS8kSEN5-vbB_Jt1QvAV9QhS6zNuKh0u8wxPQ@mail.gmail.com","threadId":"58763","inReplyTo":null,"subject":"The enduring popularity of git-credential-store","fromName":"M Hickford","fromEmail":"mirth.hickford@gmail.com","sentAt":"2022-11-08T10:50:33Z","receivedAt":"2022-11-08T10:51:22Z","isPatch":false,"sender":{"key":"mirth.hickford@gmail.com","avatar":"https://avatars.githubusercontent.com/u/105314?v=4"},"body":"Among StackOverflow users [1], git-credential-store appears several\ntimes more popular than any other credential helper. Does this make\nanyone else uneasy? The docs warn that git-credential-store \"stores\nyour passwords unencrypted on disk\" [2]. Are users sacrificing\nsecurity for convenience?\n\nFirstly, how grave is storing credentials in plaintext? Software\ndevelopment guidelines such as CWE discourage storing credentials in\nplaintext [3]. Password managers in desktop environments, mobile\noperating systems and web browsers typically encrypt passwords on disk\nand guard them behind a master password.\n\nSecondly, the docs recommend git-credential-cache [2] which ships with\nGit and is equally easy to configure. So why isn't it more popular? My\nhypothesis: while caching works great for passwords typed from memory,\nthe combination of caching with personal access tokens has poor\nusability. The unmemorised token is lost when the cache expires, so\nthe user has to generate a new token every session. I suspect GitHub's\n2021 decision to stop accepting passwords [4] may have inadvertently\npushed users from 'cache' to 'store'.\n\nThirdly, why doesn't everyone use SSH keys? Unlike HTTP remotes,\nupfront set-up is necessary to clone a public repo. For users\nunfamiliar with SSH, this set-up may be intimidating. Introducing\nusers new to Git to SSH at the same time is a significant cognitive\nload.\n\nAny ideas how to improve the security of the average Git user?\n\n[1] https://stackoverflow.com/questions/35942754/how-can-i-save-username-and-password-in-git\n probably as good a survey of non-expert users as we can get\n[2] https://git-scm.com/docs/git-credential-store\n[3] https://cwe.mitre.org/data/definitions/256.html\n[4] https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/\n[5] https://lore.kernel.org/git/20111210103444.GL16529@sigill.intra.peff.net/t/#u\ndiscussion at introduction of store helper\n"},{"id":"466814","messageId":"20221108120024.GN28810@kitsune.suse.cz","threadId":"58763","inReplyTo":"CAGJzqskRYN49SeS8kSEN5-vbB_Jt1QvAV9QhS6zNuKh0u8wxPQ@mail.gmail.com","subject":"Re: The enduring popularity of git-credential-store","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2022-11-08T12:00:24Z","receivedAt":"2022-11-08T12:00:31Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"Hello,\n\nOn Tue, Nov 08, 2022 at 10:50:33AM +0000, M Hickford wrote:\n> Among StackOverflow users [1], git-credential-store appears several\n> times more popular than any other credential helper. Does this make\n> anyone else uneasy? The docs warn that git-credential-store \"stores\n> your passwords unencrypted on disk\" [2]. Are users sacrificing\n> security for convenience?\n> \n> Firstly, how grave is storing credentials in plaintext? Software\n> development guidelines such as CWE discourage storing credentials in\n> plaintext [3]. Password managers in desktop environments, mobile\n> operating systems and web browsers typically encrypt passwords on disk\n> and guard them behind a master password.\n> \n> Secondly, the docs recommend git-credential-cache [2] which ships with\n> Git and is equally easy to configure. So why isn't it more popular? My\n> hypothesis: while caching works great for passwords typed from memory,\n> the combination of caching with personal access tokens has poor\n> usability. The unmemorised token is lost when the cache expires, so\n> the user has to generate a new token every session. I suspect GitHub's\n> 2021 decision to stop accepting passwords [4] may have inadvertently\n> pushed users from 'cache' to 'store'.\n> \n> Thirdly, why doesn't everyone use SSH keys? Unlike HTTP remotes,\n> upfront set-up is necessary to clone a public repo. For users\n> unfamiliar with SSH, this set-up may be intimidating. Introducing\n> users new to Git to SSH at the same time is a significant cognitive\n> load.\n\nI think that basically there is very small user base that could make use\nof the provided authentication options in a more secure manner.\n\nThe novice users use the simplest option. Using any king of passsword\nmanager with git is difficult to set up and platform-specific.\n\nThe advanced users need automation which in the end means storing the\naccess credentials in plaitext in one way or another.\n\nIf github provides access tokens that can be assigned per-application,\nmanaged, and individually revoked this is probably as good as it gets.\nHow well the users make use of this feature depends on their security\nawareness and requirements.\n\nThanks\n\nMichal\n"},{"id":"466849","messageId":"Y2p4rhiOphuOM0VQ@coredump.intra.peff.net","threadId":"58763","inReplyTo":"CAGJzqskRYN49SeS8kSEN5-vbB_Jt1QvAV9QhS6zNuKh0u8wxPQ@mail.gmail.com","subject":"Re: The enduring popularity of git-credential-store","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2022-11-08T15:41:34Z","receivedAt":"2022-11-08T15:41:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 08, 2022 at 10:50:33AM +0000, M Hickford wrote:\n\n> Among StackOverflow users [1], git-credential-store appears several\n> times more popular than any other credential helper. Does this make\n> anyone else uneasy? The docs warn that git-credential-store \"stores\n> your passwords unencrypted on disk\" [2]. Are users sacrificing\n> security for convenience?\n> \n> Firstly, how grave is storing credentials in plaintext? Software\n> development guidelines such as CWE discourage storing credentials in\n> plaintext [3]. Password managers in desktop environments, mobile\n> operating systems and web browsers typically encrypt passwords on disk\n> and guard them behind a master password.\n\nSo obviously credential-store is the least-common-denominator of\nstorage, and it should (and does) come with a big warning. However, I\nwonder if it actually is a reasonable solution for a lot of people:\n\n  - \"passwords\" these days are often not keys-to-the-kingdom, but\n    special-use tokens that allow limited access.\n\n  - the threat model for many people assumes that their local system is\n    trusted. Git needs the credential in plaintext at _some_ point. If\n    your local user account is compromised, people can read your\n    passwords. But they can also trojan Git, etc.\n\n    I do think one is much worse than the other. Stealing a password\n    once is easier than installing a malicious Git that records the\n    password. And a stolen password can be used many times, as opposed\n    to a malicious Git that misbehaves when run by the local user.\n\nSo yeah, obviously using a system password store is better if you can.\nBut it's sometimes difficult to set up, especially when automation is\ninvolved. And I think it buys people less than they might think.\nEspecially for git's credential helpers, which are meant to be\nscriptable, you can just _ask_ them to retrieve the password from the\nsystem store. So they are really only protecting the credentials at\nrest. And other approaches, like full-disk encryption, may be enough for\nsome people.\n\nYou asked \"does it make anyone else uneasy?\". A little, I guess, because\nlike you I'm sure there are people who are using it only because they\ndon't know better, and are not heeding the warnings. But it may also be\nthat some people are using it as a part of a reasoned tradeoff.\n\nSo if you're asking \"should we stop shipping credential-store\", I'm not\n_completely_ opposed, but I do wonder if its popularity means it is\nbetter-than-nothing for some folks. If you're asking how we can nudge\npeople to better systems, that seems like a pure win. But I also don't\nknow how to do it. ;)\n\n> Secondly, the docs recommend git-credential-cache [2] which ships with\n> Git and is equally easy to configure. So why isn't it more popular? My\n> hypothesis: while caching works great for passwords typed from memory,\n> the combination of caching with personal access tokens has poor\n> usability. The unmemorised token is lost when the cache expires, so\n> the user has to generate a new token every session. I suspect GitHub's\n> 2021 decision to stop accepting passwords [4] may have inadvertently\n> pushed users from 'cache' to 'store'.\n\nAnother big problem with credential-cache is that it requires Unix\nsockets, so it doesn't run on Windows.\n\n> Thirdly, why doesn't everyone use SSH keys? Unlike HTTP remotes,\n> upfront set-up is necessary to clone a public repo. For users\n> unfamiliar with SSH, this set-up may be intimidating. Introducing\n> users new to Git to SSH at the same time is a significant cognitive\n> load.\n\nYes, I think it's just that it's too hard to set up. In the early days\nof GitHub, people getting confused and flustered by setting up SSH keys\nwas one of the biggest barriers to adoption (which is the whole reason I\nimproved the https auth flow, including adding credential helpers).\n\nI do wonder what that's like these days, though. When people could\nswitch to just using their password from the website, I'm sure it was\nmuch easier than learning about ssh keys. But these days you have to\nlearn about PATs, etc. I don't know if people do that by hand, or rely\non tools to help (like GitHub Desktop, or probably gh-cli).\n\n> Any ideas how to improve the security of the average Git user?\n\nAll of which is to say that I have no clue what the user experience is\nlike these days, or what drives people in their decision about which\ntools to use. ;)\n\nI do stand by credential-store as not being _completely_ without value,\nbut I also recognize that its existence may cause people to make bad\ndecisions. If you have a plan, I'm all-ears.\n\n-Peff\n"},{"id":"466899","messageId":"Y2rEOxgEskE0seAs@nand.local","threadId":"58763","inReplyTo":"Y2p4rhiOphuOM0VQ@coredump.intra.peff.net","subject":"Re: The enduring popularity of git-credential-store","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2022-11-08T21:03:55Z","receivedAt":"2022-11-08T21:04:02Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Tue, Nov 08, 2022 at 10:41:34AM -0500, Jeff King wrote:\n> So if you're asking \"should we stop shipping credential-store\", I'm not\n> _completely_ opposed, but I do wonder if its popularity means it is\n> better-than-nothing for some folks. If you're asking how we can nudge\n> people to better systems, that seems like a pure win. But I also don't\n> know how to do it. ;)\n\nGCM is such an alternative, but I don't think it necessarily should ship\nin the contrib/ tree. I don't love the idea of a banner nudging people\nto use arbitrary software in Git's ordinary output, either.\n\nSo, I think my point is that there are easy-to-configure alternatives\nout there, and they are certainly worth using over what's in contrib in\ncertain circumstances, but I, too, don't have a good plan on how to\nnudge people to try them out.\n\nThanks,\nTaylor\n"},{"id":"466919","messageId":"Y2rdw7RD8mGTF40w@tapette.crustytoothpaste.net","threadId":"58763","inReplyTo":"CAGJzqskRYN49SeS8kSEN5-vbB_Jt1QvAV9QhS6zNuKh0u8wxPQ@mail.gmail.com","subject":"Re: The enduring popularity of git-credential-store","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-11-08T22:52:51Z","receivedAt":"2022-11-08T22:52:57Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2022-11-08 at 10:50:33, M Hickford wrote:\n> Among StackOverflow users [1], git-credential-store appears several\n> times more popular than any other credential helper. Does this make\n> anyone else uneasy? The docs warn that git-credential-store \"stores\n> your passwords unencrypted on disk\" [2]. Are users sacrificing\n> security for convenience?\n\nI definitely think there are better approaches.  However, none of the\ncredential managers for the three major platforms work without a\ndesktop environment, so if someone's logging in over SSH, then there's\nno more secure option that's going to work for them.  Taylor did\nmention GCM, but I believe it has the same problem, and even if it\ndidn't, it's written in C#, which isn't portable to many Unices and\nisn't viable on servers anyway due to dependencies.\n\nEven on Linux desktops, Debian and Ubuntu don't ship the libsecret\ncredential helper, so users have to build it themselves.\n\nI have written a tool that lets you access credential helpers on your\nlocal machine over an SSH session for trusted machines[0], but it's very\npreliminary.\n\nIn the ideal world, we'd ship an encrypted store that people could use,\nbut then we have to deal with export regulations and sanctions and\nnobody wants to do that.  We'd also have to deal with multiple\ncryptographic libraries for portability and license reasons and nobody\nwants to do that, either.\n\n> Firstly, how grave is storing credentials in plaintext? Software\n> development guidelines such as CWE discourage storing credentials in\n> plaintext [3]. Password managers in desktop environments, mobile\n> operating systems and web browsers typically encrypt passwords on disk\n> and guard them behind a master password.\n\nI think there's space for credential managers that operate with major\npassword managers.  Unfortunately, op (the 1Password CLI) isn't open\nsource, although LastPass has an open-source CLI.  If Firefox and/or\nChromium can offer command-line functionality to access the password\nmanager, those could be supported.  Such a tool would probably live\noutside of Git's codebase because I think interacting with some of those\ntools requires parsing JSON, which we won't want to do in C.\n\n> Secondly, the docs recommend git-credential-cache [2] which ships with\n> Git and is equally easy to configure. So why isn't it more popular? My\n> hypothesis: while caching works great for passwords typed from memory,\n> the combination of caching with personal access tokens has poor\n> usability. The unmemorised token is lost when the cache expires, so\n> the user has to generate a new token every session. I suspect GitHub's\n> 2021 decision to stop accepting passwords [4] may have inadvertently\n> pushed users from 'cache' to 'store'.\n\nThat may be the case, but I'd much rather people use tokens instead of\npasswords because they're much more limited and can easily be revoked\n(or can even just expire).  We know that people are very bad about\nreusing passwords all over the place, so in the event people do\ncompromise their credentials, they're substantially more limited.\n\n> Thirdly, why doesn't everyone use SSH keys? Unlike HTTP remotes,\n> upfront set-up is necessary to clone a public repo. For users\n> unfamiliar with SSH, this set-up may be intimidating. Introducing\n> users new to Git to SSH at the same time is a significant cognitive\n> load.\n\nSSH keys are also more difficult to make work with multiple accounts,\nand judging from my experience on StackOverflow, that's not an uncommon\nsituation to be in.  I have diligently added entries in the FAQ to cover\nthis, but in general people don't read it unless specifically directed\nthere.\n\nI do think SSH keys in general work well for forwarding to other\nmachines, but in a decent number of corporate environments there are\nintercepting proxies so everything has to be HTTP.\n\n[0] https://github.com/bk2204/lawn\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"467187","messageId":"CAGJzqskHSn973AaXLV3btAZistH0jH87JJbG1CabbDnLJBkRzA@mail.gmail.com","threadId":"58763","inReplyTo":"Y2rdw7RD8mGTF40w@tapette.crustytoothpaste.net","subject":"Re: The enduring popularity of git-credential-store","fromName":"M Hickford","fromEmail":"mirth.hickford@gmail.com","sentAt":"2022-11-12T02:30:22Z","receivedAt":"2022-11-12T02:31:10Z","isPatch":false,"sender":{"key":"mirth.hickford@gmail.com","avatar":"https://avatars.githubusercontent.com/u/105314?v=4"},"body":"On Tue, 8 Nov 2022 at 22:52, brian m. carlson\n<sandals@crustytoothpaste.net> wrote:\n>\n> On 2022-11-08 at 10:50:33, M Hickford wrote:\n> > Among StackOverflow users [1], git-credential-store appears several\n> > times more popular than any other credential helper. Does this make\n> > anyone else uneasy? The docs warn that git-credential-store \"stores\n> > your passwords unencrypted on disk\" [2]. Are users sacrificing\n> > security for convenience?\n>\n> I definitely think there are better approaches.  However, none of the\n> credential managers for the three major platforms work without a\n> desktop environment, so if someone's logging in over SSH, then there's\n> no more secure option that's going to work for them.  Taylor did\n> mention GCM, but I believe it has the same problem, and even if it\n> didn't, it's written in C#, which isn't portable to many Unices and\n> isn't viable on servers anyway due to dependencies.\n\nOn my headless Raspberry Pi, I use OAuth access tokens (generated by\nGCM) stored in cache with a long timeout. The usability is pretty good\n-- once per day I do the OAuth device flow [1] entering a code from\nthe Raspberry Pi into a device with a web browser [2].\n\nGCM was indeed awkward to install on Linux arm64. I wrote\ngit-credential-oauth [3][4] in Go to be easier for Linux distros to\npackage.\n\n[1] https://www.rfc-editor.org/rfc/rfc8628.html\n\n> The OAuth 2.0 device authorization grant is designed for Internet-\n> connected devices that either lack a browser to perform a user-agent-\n> based authorization or are input constrained to the extent that\n> requiring the user to input text in order to authenticate during the\n> authorization flow is impractical.  It enables OAuth clients on such\n> devices (like smart TVs, media consoles, digital picture frames, and\n> printers) to obtain user authorization to access protected resources\n> by using a user agent on a separate device.\n\n[2] https://github.com/login/device\n[3] https://github.com/hickford/git-credential-oauth\n[4] recent thread on git-credential-oauth\nhttps://lore.kernel.org/git/CAGJzqs=+fCQzkDX53H8Mz-DjXicVVgRmmzPjkatSiOpYO7wGGA@mail.gmail.com/T/#u\n[5] device flow support for git-credential-oauth\nhttps://github.com/hickford/git-credential-oauth/pull/9\n"},{"id":"467451","messageId":"AS2PR03MB98158D49DC655F6DC6D10ECDC0069@AS2PR03MB9815.eurprd03.prod.outlook.com","threadId":"58763","inReplyTo":"Y2rdw7RD8mGTF40w@tapette.crustytoothpaste.net","subject":"Re: The enduring popularity of git-credential-store","fromName":"Matthew John Cheetham","fromEmail":"mjcheetham@outlook.com","sentAt":"2022-11-17T17:17:53Z","receivedAt":"2022-11-17T17:18:40Z","isPatch":false,"sender":{"key":"mjcheetham@outlook.com","avatar":"https://avatars.githubusercontent.com/u/5658207?v=4"},"body":"On 2022-11-08 14:52, brian m. carlson wrote:\n\n> On 2022-11-08 at 10:50:33, M Hickford wrote:\n>> Among StackOverflow users [1], git-credential-store appears several\n>> times more popular than any other credential helper. Does this make\n>> anyone else uneasy? The docs warn that git-credential-store \"stores\n>> your passwords unencrypted on disk\" [2]. Are users sacrificing\n>> security for convenience?\n> \n> I definitely think there are better approaches.  However, none of the\n> credential managers for the three major platforms work without a\n> desktop environment, so if someone's logging in over SSH, then there's\n> no more secure option that's going to work for them.  Taylor did\n> mention GCM, but I believe it has the same problem, and even if it\n> didn't, it's written in C#, which isn't portable to many Unices and\n> isn't viable on servers anyway due to dependencies.\n\nNot trying to \"sell\" GCM on the list, but some small corrections re GCM:\nGCM today is built on .NET 6 (previously named \".NET Core\".. yeah, their\nnaming sucks :-)) which runs on various Linux distros and FreeBSD (and\nMac and Windows). Althought admitidely not some of the more obscure Unices\nlike AIX or Solaris..\n\nhttps://learn.microsoft.com/en-gb/dotnet/core/install/linux\n\nGCM also supports storing credentials securely without a desktop\nenvironment when appropriately configured. On Linux we support at-rest\nencryption via GPG, compatible with the `pass` tool (alongside libsecret stores\nwhere we have some plans to try and get working w/o a desktop environment).\n\nhttps://github.com/GitCredentialManager/git-credential-manager/blob/main/docs/credstores.md#gpgpass-compatible-files\nhttps://www.passwordstore.org/\n\nThe problem that others have aluded to with GCM and wider Linux availablity\nis more a question of supportability of providing pre-built binaries from\nour side, not .NET's. GCM is built to link the .NET CLR (the runtime) and is\nbundled, so the required deps. are minimal; mainly: glibc, openssl, zlib.\n\n> Even on Linux desktops, Debian and Ubuntu don't ship the libsecret\n> credential helper, so users have to build it themselves.\n> \n> I have written a tool that lets you access credential helpers on your\n> local machine over an SSH session for trusted machines[0], but it's very\n> preliminary.\n> \n> In the ideal world, we'd ship an encrypted store that people could use,\n> but then we have to deal with export regulations and sanctions and\n> nobody wants to do that.  We'd also have to deal with multiple\n> cryptographic libraries for portability and license reasons and nobody\n> wants to do that, either.\n\nOne option rather than shipping (or including in contrib/) any of these\ncredential helpers, could we not reference several other popular helpers\nin the docs, and let users make their own choice (but at least some are\nthen possibly more discoverable)?\n\n>> Firstly, how grave is storing credentials in plaintext? Software\n>> development guidelines such as CWE discourage storing credentials in\n>> plaintext [3]. Password managers in desktop environments, mobile\n>> operating systems and web browsers typically encrypt passwords on disk\n>> and guard them behind a master password.\n> \n> I think there's space for credential managers that operate with major\n> password managers.  Unfortunately, op (the 1Password CLI) isn't open\n> source, although LastPass has an open-source CLI.  If Firefox and/or\n> Chromium can offer command-line functionality to access the password\n> manager, those could be supported.  Such a tool would probably live\n> outside of Git's codebase because I think interacting with some of those\n> tools requires parsing JSON, which we won't want to do in C.\n> \n>> Secondly, the docs recommend git-credential-cache [2] which ships with\n>> Git and is equally easy to configure. So why isn't it more popular? My\n>> hypothesis: while caching works great for passwords typed from memory,\n>> the combination of caching with personal access tokens has poor\n>> usability. The unmemorised token is lost when the cache expires, so\n>> the user has to generate a new token every session. I suspect GitHub's\n>> 2021 decision to stop accepting passwords [4] may have inadvertently\n>> pushed users from 'cache' to 'store'.\n> \n> That may be the case, but I'd much rather people use tokens instead of\n> passwords because they're much more limited and can easily be revoked\n> (or can even just expire).  We know that people are very bad about\n> reusing passwords all over the place, so in the event people do\n> compromise their credentials, they're substantially more limited.\n> \n>> Thirdly, why doesn't everyone use SSH keys? Unlike HTTP remotes,\n>> upfront set-up is necessary to clone a public repo. For users\n>> unfamiliar with SSH, this set-up may be intimidating. Introducing\n>> users new to Git to SSH at the same time is a significant cognitive\n>> load.\n> \n> SSH keys are also more difficult to make work with multiple accounts,\n> and judging from my experience on StackOverflow, that's not an uncommon\n> situation to be in.  I have diligently added entries in the FAQ to cover\n> this, but in general people don't read it unless specifically directed\n> there.\n> \n> I do think SSH keys in general work well for forwarding to other\n> machines, but in a decent number of corporate environments there are\n> intercepting proxies so everything has to be HTTP.\n> \n> [0] https://github.com/bk2204/lawn\n\nThere are also enterprises that out-right block the use of SSH (either\ntechically or as a policy) as they require strict continuous evaluation\nof various security policies, on each token use or refresh/re-generation.\n\nOther scenarios I've seen include *per-request/one-time-use* tokens that\nare cryptographically bound to the device using hardware security modules.\nNot something that SSH is suited for sadly.\n\nThanks,\nMatthew\n"},{"id":"467459","messageId":"Y3aCx1SYq6jrYfuO@coredump.intra.peff.net","threadId":"58763","inReplyTo":"AS2PR03MB98158D49DC655F6DC6D10ECDC0069@AS2PR03MB9815.eurprd03.prod.outlook.com","subject":"Re: The enduring popularity of git-credential-store","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2022-11-17T18:51:51Z","receivedAt":"2022-11-17T18:52:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 17, 2022 at 09:17:53AM -0800, Matthew John Cheetham wrote:\n\n> > In the ideal world, we'd ship an encrypted store that people could use,\n> > but then we have to deal with export regulations and sanctions and\n> > nobody wants to do that.  We'd also have to deal with multiple\n> > cryptographic libraries for portability and license reasons and nobody\n> > wants to do that, either.\n> \n> One option rather than shipping (or including in contrib/) any of these\n> credential helpers, could we not reference several other popular helpers\n> in the docs, and let users make their own choice (but at least some are\n> then possibly more discoverable)?\n\nI don't have any problem with documenting the options better. The main\nreason we have store/cache at all, even though they kind of suck, was to\nact as least-common-denominators and pave the way for people making\nbetter helpers. That happened, but nobody ever went back to adjust the\ndocs.\n\nI do think having the docs say \"you should go use X\" means that X will\nhave an advantage over other projects which may compete with it. So I\nthink we need to be careful to be inclusive of what we'll mention, and\nto word it so that we're not endorsing any one project.\n\n-Peff\n"},{"id":"467460","messageId":"a76a5e37-0c0a-b9e8-13cb-abaa44cf8911@gmail.com","threadId":"58763","inReplyTo":"Y3aCx1SYq6jrYfuO@coredump.intra.peff.net","subject":"Re: The enduring popularity of git-credential-store","fromName":"Lessley Dennington","fromEmail":"lessleydennington@gmail.com","sentAt":"2022-11-17T19:29:35Z","receivedAt":"2022-11-17T19:29:53Z","isPatch":false,"sender":{"key":"lessleydennington@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11321782?v=4"},"body":"On 11/17/22 10:51 AM, Jeff King wrote:\n> I do think having the docs say \"you should go use X\" means that X will\n> have an advantage over other projects which may compete with it. So I\n> think we need to be careful to be inclusive of what we'll mention, and\n> to word it so that we're not endorsing any one project.\n> \n> -Peff\n\nCompletely agree with this. I've long wished for a page on git-scm.com \nthat's dedicated to (1) explaining what a credential helper is and\n(2) offering a list of suggested helpers along with scenarios for which\neach is best-suited. This could also be a good place to call out the risks\nof using helpers like git-credential-store in a factual, unbiased way.\n\nThanks,\nLessley\n"},{"id":"467462","messageId":"Y3ac9ZuvpDJO3k9F@coredump.intra.peff.net","threadId":"58763","inReplyTo":"a76a5e37-0c0a-b9e8-13cb-abaa44cf8911@gmail.com","subject":"Re: The enduring popularity of git-credential-store","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2022-11-17T20:43:33Z","receivedAt":"2022-11-17T20:43:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 17, 2022 at 11:29:35AM -0800, Lessley Dennington wrote:\n\n> On 11/17/22 10:51 AM, Jeff King wrote:\n> > I do think having the docs say \"you should go use X\" means that X will\n> > have an advantage over other projects which may compete with it. So I\n> > think we need to be careful to be inclusive of what we'll mention, and\n> > to word it so that we're not endorsing any one project.\n> > \n> > -Peff\n> \n> Completely agree with this. I've long wished for a page on git-scm.com\n> that's dedicated to (1) explaining what a credential helper is and\n> (2) offering a list of suggested helpers along with scenarios for which\n> each is best-suited. This could also be a good place to call out the risks\n> of using helpers like git-credential-store in a factual, unbiased way.\n\nIt's also a nice place because it's easier to keep up-to-date compared\nto say, a manpage.\n\n-Peff\n"},{"id":"471974","messageId":"CAGJzqsk=vbyrzeeq091RcKFmprpFaukFbcO9ctV1ti5vr-95ig@mail.gmail.com","threadId":"58763","inReplyTo":"Y2p4rhiOphuOM0VQ@coredump.intra.peff.net","subject":"Re: The enduring popularity of git-credential-store","fromName":"M Hickford","fromEmail":"mirth.hickford@gmail.com","sentAt":"2023-02-11T07:11:00Z","receivedAt":"2023-02-11T07:11:19Z","isPatch":false,"sender":{"key":"mirth.hickford@gmail.com","avatar":"https://avatars.githubusercontent.com/u/105314?v=4"},"body":"On Tue, 8 Nov 2022 at 15:41, Jeff King <peff@peff.net> wrote:\n>\n> On Tue, Nov 08, 2022 at 10:50:33AM +0000, M Hickford wrote:\n>\n> > Secondly, the docs recommend git-credential-cache [2] which ships with\n> > Git and is equally easy to configure. So why isn't it more popular? My\n> > hypothesis: while caching works great for passwords typed from memory,\n> > the combination of caching with personal access tokens has poor\n> > usability. The unmemorised token is lost when the cache expires, so\n> > the user has to generate a new token every session. I suspect GitHub's\n> > 2021 decision to stop accepting passwords [4] may have inadvertently\n> > pushed users from 'cache' to 'store'.\n>\n> Another big problem with credential-cache is that it requires Unix\n> sockets, so it doesn't run on Windows.\n\nThanks to the work of Carlo Marcelo Arenas Belón [1], credential-cache\n*can* be built on Windows 10 April 2018 update or later. But Git for\nWindows has to support older Windows versions for many more years so\nthe build flag can't be enabled. Perhaps Git for Windows could ship\nwith a credential-cache binary that works on Windows 10 and gracefully\ndegrades on older Windows versions? That's beyond my expertise. Help\nvery welcome at https://github.com/git-for-windows/git/issues/3892\n\nMight this be suitable for a GSoC project? If a mentor could be found.\n\n[1] https://lore.kernel.org/git/20210914072600.11552-1-carenas@gmail.com/\n"},{"id":"477770","messageId":"CAGJzqskaM80+8+79yUf435tP93Sk8sFu7marCvyimE=2gOKnog@mail.gmail.com","threadId":"58763","inReplyTo":"Y3aCx1SYq6jrYfuO@coredump.intra.peff.net","subject":"Re: The enduring popularity of git-credential-store","fromName":"M Hickford","fromEmail":"mirth.hickford@gmail.com","sentAt":"2023-05-28T19:33:29Z","receivedAt":"2023-05-28T19:34:11Z","isPatch":false,"sender":{"key":"mirth.hickford@gmail.com","avatar":"https://avatars.githubusercontent.com/u/105314?v=4"},"body":"On Thu, 17 Nov 2022 at 18:51, Jeff King <peff@peff.net> wrote:\n>\n> On Thu, Nov 17, 2022 at 09:17:53AM -0800, Matthew John Cheetham wrote:\n>\n> > > In the ideal world, we'd ship an encrypted store that people could use,\n> > > but then we have to deal with export regulations and sanctions and\n> > > nobody wants to do that.  We'd also have to deal with multiple\n> > > cryptographic libraries for portability and license reasons and nobody\n> > > wants to do that, either.\n> >\n> > One option rather than shipping (or including in contrib/) any of these\n> > credential helpers, could we not reference several other popular helpers\n> > in the docs, and let users make their own choice (but at least some are\n> > then possibly more discoverable)?\n>\n> I don't have any problem with documenting the options better. The main\n> reason we have store/cache at all, even though they kind of suck, was to\n> act as least-common-denominators and pave the way for people making\n> better helpers. That happened, but nobody ever went back to adjust the\n> docs.\n>\n> I do think having the docs say \"you should go use X\" means that X will\n> have an advantage over other projects which may compete with it. So I\n> think we need to be careful to be inclusive of what we'll mention, and\n> to word it so that we're not endorsing any one project.\n\nI agree, although Git for Windows installs Git Credential Manager by\ndefault. Hard to compete with that, but it's fantastic for users.\n\nOAuth credential helpers are so widely useful I think it's worth\nintroducing them in the documentation. I'll draft a patch.\n"},{"id":"477775","messageId":"CAGJzqsmZSTDLLHO1B87c-GUW_7awgCv2Eci_OKVoWLaU8DP+Eg@mail.gmail.com","threadId":"58763","inReplyTo":"Y3ac9ZuvpDJO3k9F@coredump.intra.peff.net","subject":"Re: The enduring popularity of git-credential-store","fromName":"M Hickford","fromEmail":"mirth.hickford@gmail.com","sentAt":"2023-05-29T09:53:45Z","receivedAt":"2023-05-29T09:54:27Z","isPatch":false,"sender":{"key":"mirth.hickford@gmail.com","avatar":"https://avatars.githubusercontent.com/u/105314?v=4"},"body":"On Thu, 17 Nov 2022 at 20:43, Jeff King <peff@peff.net> wrote:\n>\n> On Thu, Nov 17, 2022 at 11:29:35AM -0800, Lessley Dennington wrote:\n>\n> > On 11/17/22 10:51 AM, Jeff King wrote:\n> > > I do think having the docs say \"you should go use X\" means that X will\n> > > have an advantage over other projects which may compete with it. So I\n> > > think we need to be careful to be inclusive of what we'll mention, and\n> > > to word it so that we're not endorsing any one project.\n> > >\n> > > -Peff\n> >\n> > Completely agree with this. I've long wished for a page on git-scm.com\n> > that's dedicated to (1) explaining what a credential helper is and\n> > (2) offering a list of suggested helpers along with scenarios for which\n> > each is best-suited. This could also be a good place to call out the risks\n> > of using helpers like git-credential-store in a factual, unbiased way.\n>\n> It's also a nice place because it's easier to keep up-to-date compared\n> to say, a manpage.\n>\n> -Peff\n\nGreat idea Lessley! Here's a pull request\nhttps://github.com/git/git-scm.com/pull/1786 to create such a page at\nhttps://git-scm.com/doc/credential-helpers\n"}]}