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

Re: [RFC] Adding a challenge-response authentication method to git://

From
Shawn O. Pearce <spearce@spearce.org>
Date
Aug 13, 2008, 18:08 UTC
Message-ID
<20080813180857.GH3782@spearce.org>
In-Reply-To
<20080813173757.GE12200@cuci.nl>
"Stephen R. van den Berg" <srb@cuci.nl> wrote:
Show 9 quoted lines
> Shawn O. Pearce wrote:
> >"Stephen R. van den Berg" <srb@cuci.nl> wrote:
> >> What are the opinions on adding a basic challenge-response type
> >> authentication mechanism to the native git protocol?
> 
> In order to aid them in setting up a simple accesslist, git would do
> just fine by simply offering a flat-file like list.  Forcing those
> setups to use anything more complicated makes adoption of git for those
> kind of projects unreasonably more complicated (IMO).

Well, anytime you get into a flat-file access list you get into management of that list. How do users change their own password? How does an admin add/remove a user, or reset a password? What defines an admin? Can you do these things remotely? Can you keep the password encrypted on the remote side so an admin cannot see a user's (common) password and maybe gain access to unrelated sites?

If you are going to keep it "really simple" you may be tempted to say that all user additions/deletions/password changes should be done by the admin directly editing the password list. At which point it may actually be easier (and safer) for the admin to just handle a GnuPG or SSH public key.

This is why we tend to rely on SSH. It neatly solves all of this for us, and does it in a way that UNIX administrators are familiar with managing.

This is also why the last discussion on this topic went down the road of using GnuPG to handle the authentication portion of the protocol. Unfortunately dealing with the server side keychain is a little bit more complex then I'd like it to be out of the box, and the client side I think is lacking something as common as ssh-agent for caching the decrypted key.

I can see how it would be pretty simple to add authentication to
git-daemon based upon a shared secret, but such schemes always
cause management problems on both sides.
 
-- 
Shawn.
Previous: Stephen R. van den BergNext: Stephen R. van den Berg
Message 10 of 18 in “[RFC] Adding a challenge-response authentication method to git://”
  1. Stephen R. van den BergAug 13, 2008
  2. Petr BaudisAug 13, 2008
  3. David BrownAug 14, 2008
  4. Petr BaudisAug 14, 2008
  5. Stephen R. van den BergAug 14, 2008
  6. Petr BaudisAug 14, 2008
  7. Stephen R. van den BergAug 14, 2008
  8. Shawn O. PearceAug 13, 2008
  9. Stephen R. van den BergAug 13, 2008
  10. Shawn O. PearceAug 13, 2008
  11. Stephen R. van den BergAug 14, 2008
  12. Shawn O. PearceAug 14, 2008
  13. Stephen R. van den BergAug 14, 2008
  14. Andreas EricssonAug 14, 2008
  15. Stephen R. van den BergAug 14, 2008
  16. david@lang.hmAug 14, 2008
  17. david@lang.hmAug 14, 2008
  18. Shawn O. PearceAug 14, 2008

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.