From: Jeff King <peff@peff.net>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Cc: Shawn Pearce <spearce@spearce.org>,
Alexander Miseler <alexander@miseler.de>,
Nguyen Thai Ngoc Duy <pclouds@gmail.com>,
Ramkumar Ramachandra <artagnon@gmail.com>,
Jonathan Nieder <jrnieder@gmail.com>,
Jens Lehmann <Jens.Lehmann@web.de>,
Christian Couder <chriscool@tuxfamily.org>,
Thomas Rast <trast@student.ethz.ch>, git <git@vger.kernel.org>,
Pranav Ravichandran <prp.1111@gmail.com>
Subject: Re: GSoC resumable clone
Date: Fri, 11 Mar 2011 16:43:46 -0500 [thread overview]
Message-ID: <20110311214346.GA19235@sigill.intra.peff.net> (raw)
In-Reply-To: <20110311205041.GA10210@LK-Perkele-VI.localdomain>
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
next prev parent reply other threads:[~2011-03-11 21:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-11 15:17 GSoC resumable clone Shawn Pearce
2011-03-11 15:37 ` Jeff King
2011-03-11 15:41 ` Shawn Pearce
2011-03-11 15:48 ` Jeff King
2011-03-11 20:50 ` Ilari Liusvaara
2011-03-11 21:43 ` Jeff King [this message]
2011-03-11 15:42 ` Nguyen Thai Ngoc Duy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110311214346.GA19235@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=Jens.Lehmann@web.de \
--cc=alexander@miseler.de \
--cc=artagnon@gmail.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=ilari.liusvaara@elisanet.fi \
--cc=jrnieder@gmail.com \
--cc=pclouds@gmail.com \
--cc=prp.1111@gmail.com \
--cc=spearce@spearce.org \
--cc=trast@student.ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).