On Tue, 28 Aug 2007, Jeff King wrote:
quoted text
> 
> Sorry, I have not been keeping up with this thread, so I may be
> confused. But I thought you were saying that there is no point to
> git-daemon over TLS, since git-daemon is purely for fetching public
> data. My point is that it's not, and thus there might be some value to
> it

There's possibly another reason: using TLS for validating not the *client* 
or encrypting the data, but in order to be able to trust the *server* in 
the face of man-in-the-middle attacks etc.

A lot of people think if authentication as a way to verify the identity of 
the client. But it's equally valid as a way to verifyt that the server you 
talk to is the one you _expected_ to talk to.

[ That said, I'd also actually like to support encrypted git repositories, 
  at least on a pack-file basis. I realize that people should probably use 
  whole-disk encryption on their laptops etc regardless, but I really can 
  see the point of wanting to secure your repository history even if you 
  might not care anough to secure everything else - including necessarily 
  the last checked-out version. I could well imagine the repo history 
  being considered much more critical than any particular checked-out 
  state.

  I could also imagine just having a bare repository (encrypted) on hand, 
  to get access to it *if*needed*. I suspect I'd have used something like 
  that back when I worked at Transmeta if it had been available - not 
  necessarily have anything checked out, but just knowing that I *could* 
  get to if it I needed to ]

			Linus

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html