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

Re: [RFC 0/2] Git-over-TLS (gits://) client side support

From
Andreas Krey <a.krey@gmx.de>
Date
Jan 13, 2010, 18:35 UTC
Message-ID
<20100113183520.GA23674@inner.home.ulmdo.de>
In-Reply-To
<20100113173610.GA7609@Knoppix>

On Wed, 13 Jan 2010 19:36:10 +0000, Ilari Liusvaara wrote: ...

> That would violate layering badly. You need to decode the request
> first before you can authorize. And the git daemon does that.

Well, yes. The script hackery would just decide between 'is allowed to read (or write commits)' and 'is allowed to modify refs'. On the other hand, git-daemon does not do fine-grained (read: per-branch) access control, you'd only prevent pushing commits at all.

...
> > (Is the unix auth via unix domain sockets part of GnuTLS?)
> 
> No, that server-only feature is part of the OS itself. In fact, it
> needs no client-side support.

Ok, then I'll be really interested in the server-side support and the man pages on the whole stuff. Especially in how this is going to be different from what ssh:// does or can do.

...
> GIT_PROXY abuse? There are even better ways: smart transport remote
> helpers (in next I think). Git can actually dispatch those (and yes,
> that's exactly what this uses).

Yeah, since the last mail I noticed that gitproxy is not quite what some google hits suggest, and should have read the patch in some more detail to find that gits is a remote helper.

Please consider my objections revoked, other than the claim that it could be done with stunnel, however ugly that would be.

...
> Actually, that was little badly choosen term and not the true problem,
> but the basic problem is that one peer has to trust the the other peer's
> authentication for security of its own authentication.

I don't see how that would endanger the standard certificate auth in ssl (client or server).

...
> HTTP basic auth can be trivially sniffed if attacker can become other end
> of the encrypted link

Of course, you have another problem in that case...also I'd personally like to rely on ssl client certificates when using https.

Andreas
Previous: Ilari LiusvaaraNext: Ilari Liusvaara
Message 11 of 28 in “[RFC 0/2] Git-over-TLS (gits://) client side support”
  1. Ilari LiusvaaraJan 13, 2010
  2. 1/2 Git-over-TLS (gits://) client side support (part 1 of 2)Ilari Liusvaara, Jan 13, 2010
  3. 2/2 Git-over-TLS (gits://) client side support (part 2 of 2)Ilari Liusvaara, Jan 13, 2010
  4. Alex RiesenJan 13, 2010
  5. Nguyen Thai Ngoc DuyJan 13, 2010
  6. Ilari LiusvaaraJan 13, 2010
  7. Andreas KreyJan 13, 2010
  8. Ilari LiusvaaraJan 13, 2010
  9. Andreas KreyJan 13, 2010
  10. Ilari LiusvaaraJan 13, 2010
  11. Andreas KreyJan 13, 2010
  12. Ilari LiusvaaraJan 13, 2010
  13. Avery PennarunJan 13, 2010
  14. Ilari LiusvaaraJan 13, 2010
  15. Avery PennarunJan 13, 2010
  16. Ilari LiusvaaraJan 13, 2010
  17. Avery PennarunJan 13, 2010
  18. Shawn O. PearceJan 13, 2010
  19. Ilari LiusvaaraJan 13, 2010
  20. Avery PennarunJan 13, 2010
  21. Ilari LiusvaaraJan 14, 2010
  22. Avery PennarunJan 14, 2010
  23. Ilari LiusvaaraJan 14, 2010
  24. Andreas KreyJan 13, 2010
  25. Ilari LiusvaaraJan 13, 2010
  26. Avery PennarunJan 13, 2010
  27. Ilari LiusvaaraJan 13, 2010
  28. Edward Z. YangJan 13, 2010

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.