[PATCH 2 of 3 V6] hgweb: teach archive how to download a specific directory or file

Pierre-Yves David pierre-yves.david at logilab.fr
Wed Mar 20 11:12:16 CDT 2013


On Wed, Mar 20, 2013 at 04:20:26PM +0100, Angel Ezquerra wrote:
> On Wed, Mar 20, 2013 at 3:38 PM, Pierre-Yves David
> <pierre-yves.david at logilab.fr> wrote:
> > On Wed, Mar 13, 2013 at 09:34:08AM +0100, Angel Ezquerra wrote:
> >> I checked archival.archive() and it does not check whether the number
> >> of files matching the pattern is 0.
> >>
> >> I cannot tell if that is the desired behavior or a bug.
> >>
> >> In any case I think that is something that, if needs fixing, should be
> >> fixed on a separate patch?
> >
> > That should probably be fixed. But this certainly deserve another
> > patches.
> 
> So should we raise an exception in that case?
> 
> >> Also, I personally like the fact that we give a 403 error. IMHO it
> >> tells you exactly what is the problem without compromising the
> >> security of the server because we append "path:" to the requested file
> >> path anyway (unless there is some way to feed '\b' into the requested
> >> path?).
> >>
> >> So I'd vote to take the latest version of my patch series (V7!) which
> >> explicitly checks for known patterns, and I would deal with the
> >> possible archive.archival bug separately.
> >
> > Black-listing security does not work. extension and futur version may
> > (will) add extra patterns ("et bim"). I vote for requesting plain file
> > name all the time. this means inconditionnaly adding "path:" in the
> > front of the parameter.
> 
> I agree. In fact that is what the patch does already. This means that
> if you try to use _any_ pattern (including "path") the web server will
> respond with an error. The only difference is that if you try to use a
> "known" pattern the server will respond with a nice 403 "Archive
> pattern not allowed" message.

And what if the repo contains a root directory whose name starts with
this very known pattern?

The nicety turn's into a big bad wolf :-(

I advertise a "simpler is better" route here. (But I'm won't die for it)

-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130320/14441dd8/attachment.pgp>


More information about the Mercurial-devel mailing list