git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 3/3] clone: auto-enable git-credential-store when necessary

From
Jeff King <peff@peff.net>
Date
May 20, 2019, 15:24 UTC
Message-ID
<20190520152433.GB4583@sigill.intra.peff.net>
In-Reply-To
<87h89pupdr.fsf@evledraar.gmail.com>
On Mon, May 20, 2019 at 05:17:20PM +0200, Ævar Arnfjörð Bjarmason wrote:
Show 23 quoted lines
> > There are more cases beyond that, too. You might have a helper defined
> > which doesn't actually store passwords, but just sometimes tries to
> > provide one. My thinking was that if you're clueful enough to have
> > configured helpers, you can probably deal with the fallout. But you're
> > right that it may still be a regression in the sense that the user may
> > still have to actually _do_ something to get their fetch to work.
> >
> > I guess a more robust version of this is that _after_ the successful
> > clone, we could ask the credential system "hey, do you have the
> > credential for $URL?". And if it can't answer, then we can take action
> > (whether that action is setting up credential-store and seeding it with
> > the password, or just advising the user about the situation).
> >
> > -Peff
> 
> Yeah I don't mean deal with some there-but-broken helper, but this:
> 
>     /usr/share/doc/git/contrib/credential/gnome-keyring/git-credential-gnome-keyring:
>     not found
> 
> Until then the observable effect of that has been to make the
> credential.helper config a noop, but now it's causing "we have a helper"
> behavior.

Right, I understood. The other case I mean is not one that's broken, but a helper that's designed to provide a password from a read-only store (which presumably doesn't have _this_ password, else why would they be providing it in the URL?).

It is not going to help that the clone will feed the password to such a helper because it will (correctly, and by design) ignore any "store" requests.

In other words, I am agreeing with you and indicating that there are even more cases where a non-empty helper config will mislead us.

I'm going to try to re-work the patch to do this check-at-the-end technique, and probably try to make the UI for clearing and seeding passwords a bit more friendly, too.

-Peff
Previous: Ævar Arnfjörð BjarmasonNext: Ævar Arnfjörð Bjarmason
Message 21 of 23 in “Git ransom campaign incident report - May 2019”
  1. Martin LanghoffMay 15, 2019
  2. Ævar Arnfjörð BjarmasonMay 15, 2019
  3. Jeff KingMay 16, 2019
  4. Johannes SchindelinMay 17, 2019
  5. Jeff KingMay 17, 2019
  6. Martin LanghoffMay 17, 2019
  7. Jeff KingMay 19, 2019
  8. 1/3 transport_anonymize_url(): support retaining usernameJeff King, May 19, 2019
  9. Eric SunshineMay 19, 2019
  10. René ScharfeMay 20, 2019
  11. Johannes SchindelinMay 20, 2019
  12. Johannes SchindelinMay 20, 2019
  13. 2/3 clone: avoid storing URL passwords in configJeff King, May 19, 2019
  14. 3/3 clone: auto-enable git-credential-store when necessaryJeff King, May 19, 2019
  15. Eric SunshineMay 20, 2019
  16. Jeff KingMay 20, 2019
  17. Johannes SchindelinMay 20, 2019
  18. Ævar Arnfjörð BjarmasonMay 20, 2019
  19. Jeff KingMay 20, 2019
  20. Ævar Arnfjörð BjarmasonMay 20, 2019
  21. Jeff KingMay 20, 2019
  22. Ævar Arnfjörð BjarmasonMay 20, 2019
  23. Johannes SchindelinMay 20, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.