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

git with https and client cert asks for password repeatedly

From
Mark Lodato <lodatom@gmail.com>
Date
Feb 25, 2009, 03:11 UTC
Message-ID
<ca433830902241911x10b08a4fg8e790000a5cf9f3b@mail.gmail.com>

First off, I am fairly new to git, so let me apologize in advance if I suggest anything stupid.

When fetching or pushing over https:// with a client certificate (http.sslCert / http.sslKey), git asks for a password for every single requested file. For example, here I push three commits with a couple changed files each:

> git push origin master
Enter PEM pass phrase:
Enter PEM pass phrase:
Fetching remote heads...
  refs/
  refs/tags/
  refs/heads/
updating 'refs/heads/master'
  from 1df865db590b4a7d4991c13053437ac90b2780e4
  to   05e856a6a5ce9b05a5a7d10cb5d10010467eea72
Enter PEM pass phrase:
Enter PEM pass phrase:
Enter PEM pass phrase:
Enter PEM pass phrase:
Enter PEM pass phrase:
Enter PEM pass phrase:
Enter PEM pass phrase:
Enter PEM pass phrase:
Enter PEM pass phrase:
Enter PEM pass phrase:
Enter PEM pass phrase:
Enter PEM pass phrase:
Enter PEM pass phrase:
    sending 12 objects
Enter PEM pass phrase:
Enter PEM pass phrase:
Enter PEM pass phrase:
Enter PEM pass phrase:
Enter PEM pass phrase:
    done
Updating remote server info

To make matters worse, when you try to CTRL-C from the "Enter PEM pass phrase" prompt, it just re-prompts you! If you want to see this in action, set up a webdav server on https://localhost with a copy of git.git and try cloning it with a password-protected client certificate.

This problem makes client-side certificates unusable with git. A possible workaround is to leave the key unencrypted, but this is usually unacceptable for security reasons. Ideally, I would just type my password once per invocation and git would remember it. (This is how svn works.)

I think the root problem is that git creates a completely new http(s) connection for every request, rather than using one persistent connection. Using a persistent connection would theoretically speed up the transfers, in addition to fixing the password prompt issue. I'm pretty sure that calling `curl_easy_cleanup()' after every request is causing this behavior; I don't think this is necessary.

I tried fixing this myself, but the http/curl code is pretty
confusing.  Just wondering - why is HTTP_MULTI required for http-push?
 I saw a thread from Jan '08 about this, but it never said *why*
HTTP_MULTI is required, only that the push doesn't work without it.
It doesn't appear to me that git uses concurrent connections in any
useful way, so I don't know why having a single connection would not
work.

Finally, is there interest in refactoring the http code to make it a little cleaner? That is, make a wrapper library around curl so that you can just call GET or POST or whatever and not worry about how to invoke curl?

-- Mark Lodato

Next: Daniel Stenberg
Message 1 of 4 in “git with https and client cert asks for password repeatedly”
  1. Mark LodatoFeb 25, 2009
  2. Daniel StenbergFeb 25, 2009
  3. Josef WolfFeb 25, 2009
  4. Johannes SchindelinFeb 26, 2009

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.