From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: Re: GSoC resumable clone Date: Fri, 11 Mar 2011 16:43:46 -0500 Message-ID: <20110311214346.GA19235@sigill.intra.peff.net> References: <20110311153752.GA30329@sigill.intra.peff.net> <20110311154822.GA30605@sigill.intra.peff.net> <20110311205041.GA10210@LK-Perkele-VI.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Shawn Pearce , Alexander Miseler , Nguyen Thai Ngoc Duy , Ramkumar Ramachandra , Jonathan Nieder , Jens Lehmann , Christian Couder , Thomas Rast , git , Pranav Ravichandran To: Ilari Liusvaara X-From: git-owner@vger.kernel.org Fri Mar 11 22:43:54 2011 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PyA7l-0004Yv-IK for gcvg-git-2@lo.gmane.org; Fri, 11 Mar 2011 22:43:53 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755160Ab1CKVns (ORCPT ); Fri, 11 Mar 2011 16:43:48 -0500 Received: from 99-108-226-0.lightspeed.iplsin.sbcglobal.net ([99.108.226.0]:41602 "EHLO peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754981Ab1CKVnr (ORCPT ); Fri, 11 Mar 2011 16:43:47 -0500 Received: (qmail 12764 invoked by uid 107); 11 Mar 2011 21:44:18 -0000 Received: from sigill.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.7) (smtp-auth username relayok, mechanism cram-md5) by peff.net (qpsmtpd/0.84) with ESMTPA; Fri, 11 Mar 2011 16:44:18 -0500 Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Fri, 11 Mar 2011 16:43:46 -0500 Content-Disposition: inline In-Reply-To: <20110311205041.GA10210@LK-Perkele-VI.localdomain> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: 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