bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] [PATCH] Support metalink:file elements with a "path/file"


From: Matthew White
Subject: Re: [Bug-wget] [PATCH] Support metalink:file elements with a "path/file" format
Date: Sun, 14 Aug 2016 21:27:50 +0200

On Sat, 13 Aug 2016 11:57:46 +0200
Tim Rühsen <address@hidden> wrote:

> On Freitag, 12. August 2016 22:13:53 CEST Matthew White wrote:
> > On Wed, 10 Aug 2016 11:30:12 +0200
> > 
> > After debugging wget and libmetalink, I can confirm that, due to how
> > metalink/libmetalink is conceived (see references), metalink:file names
> > posing a security issue are discarded directly by libmetalink, and so they
> > will never get to the wget's metalink module.
> > 
> > e.g. '../File' and '/File1' cannot be written as 'File1' by wget, because
> > the whole metalink:file name is discarded by libmetalink.
> 
> Good finding.
> 
> But don't rely on it.
> And gracefully handle 'discarded' file names.
> 
> Regards, Tim

Ok. I see that the Metalink/HTTP fields "depth" and "name" are not parsed by 
src/http.c (metalink_from_http):
https://tools.ietf.org/html/rfc6249#section-3.4
https://tools.ietf.org/html/rfc6249#section-4

Using a local server, I'm evaluating how --metalink-over-http works in order to 
make the right changes.

Later,
Matthew

-- 
Matthew White <address@hidden>

Attachment: pgp3VkE60FlI_.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]