On Fri, Mar 11, 2011 at 10:50:41PM +0200, Ilari Liusvaara wrote:
> > Sorry, I didn't mean to imply that it was limited to bundles. It would
> > support arbitrary URLs or schemes. See this thread for some past
> > discussion:
>
> Security pitfall: You need a way to restrict URL schemes that can
> be specified from the remote. Some URL schemes are wildly unsafe
> to use that way (or just don't make sense).
Did you mean on the server end? Or the client?
If the server, then I think no, it's a client decision. If on the client
end, then yes, but it's one of many criteria.
The server end provides specially-formed refs that mention alternate
locations. The client decides which of those locations, if any, meet
its criteria for mirroring, including but not limited to:
1. Whether the client supports the protocol in question (not everybody
will be able to torrent, for example).
2. Whether the client's network allows it (e.g., restrictive proxies).
3. Whether it meets the client's security requirements (e.g., we
probably shouldn't accept file:// URLs at all).
But it's clear to me that the security decision is only one of many
criteria, and that the client is in a much better place to make those
decisions. And that some of those decisions are going to have to be
configurable by the user.
So yes, I agree we shouldn't blindly follow URLs.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html