On Fri, 2016-11-11 at 10:40 +0100, Lars Schneider wrote: > On 11 Nov 2016, at 10:31, Jeff King <p...@peff.net> wrote: > > > On Fri, Nov 11, 2016 at 10:28:56AM +0100, Lars Schneider wrote: > > > > > > Yeah, that is the solution I was going to suggest. The credentials are > > > > totally orthogonal to the filters, and I would rather not shove them > > > > into the protocol. It's an extra process, but with the new multi-use > > > > smudge filter, it's one per git invocation, not one per file. > > > > > > > > > The trouble with "git credential" is that it works only if the credential > > > helper is setup correctly. Although I assume that most people have setup > > > this, > > > I have also worked with a number of people who prefer to enter their > > > passwords > > > every time Git makes a network connection. > > > > > > Are you sure about that? If I do: > > > > echo url=https://example.com/repo.git | > > git credential fill > > > > I get prompted for a username and password. > > > Hm.. either I don't understand you or I expressed myself unclear. > > Let's say a user runs: > > $ git clone https://myrepo.git > > If no credential helper is setup, then Git asks the user for credentials. > Afterwards Git starts downloading stuff. At some point Git will run my > smudge filter on some files and in my case the smudge filter needs the > Git credentials. AFAIK, the smudge filter has no way to get the credentials > from Git at this point - not even by invoking "git credential". > Is this correct?
I think that's correct, but the same argument goes both ways: unless I use a credential helper, or explicitely give a filter application my credentials, I don't want a helper to be able to get to those credentials. I'd consider that a security bug. D.
