cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: [SECURITY ADVISORY] curl invalid URL parsing with '#'

From: Kamil Dudka <kdudka_at_redhat.com>
Date: Sun, 06 Nov 2016 09:34:24 +0100

On Friday, November 04, 2016 16:08:32 Ray Satiro via curl-library wrote:
> On 11/4/2016 11:43 AM, Mike Crowe wrote:
> > On Friday 04 November 2016 at 08:26:28 -0700, bch wrote:
> >> >On Nov 4, 2016 8:18 AM, "Mike Crowe"<mac_at_mcrowe.com> wrote:
> >>> > >On Friday 04 November 2016 at 08:04:34 -0700, bch wrote:
> >>>> > > >On Nov 4, 2016 8:01 AM, "Mike Crowe"<mac_at_mcrowe.com> wrote:
> >>>>> > > > >The fix for this in 3bb273db7e40ebc284cff45f3ce3f0475c8339c2
> >>>>> > > > >appears
> >> >
> >> >to
> >> >
> >>>>> > > > >have changed the existing behaviour offile:// URLs for me:
> >>>>> > > > >
> >>>>> > > > >On current master (9ea3a6e150dfc822ba1565f649b634848597d2d9):
> >>>>> > > > > $ src/curlfile://config.log
> >>>>> > > > > curl: (37) Couldn't open file /config.log
> >>>>> > > > >
> >>>>> > > > >On master with 3bb273db7e40ebc284cff45f3ce3f0475c8339c2
reverted:
> >>>>> > > > > $ src/curlfile://config.log
> >>>>> > > > > [contents of config.log]
> >>>>> > > > >
> >>>>> > > > >Rightly or wrongly, we've used URLs like"file://test.txt" in
> >>>>> > > > >many of
> >> >
> >> >our
> >> >
> >>>>> > > > >unit tests which are now failing.:(
> >>>> > > >
> >>>> > > >What doesfile:///test.txt (3 slashes) yield?
> >>> > >
> >>> > >On both:
> >>> > > $ src/curlfile:///config.log
> >>> > > curl: (37) Couldn't open file /config.log
> >> >
> >> >Is that the correct path, or is the fully qualified path something like
> >> >/var/log/config.log (file:///var/log/config.log) ?
> >
> > /config.log is not the correct path.
> >
> > ./config.log is the correct path.
> >
> > The change in behaviour is thatfile://config.log used to refer to
> > ./config.log whereas after 3bb273db7e40ebc284cff45f3ce3f0475c8339c2 that
> > URL now refers to /config.log.
>
> Yes now if the path doesn't start with a slash one is added [1] so it's
> going to be rebuilt like
>
> * Rebuilt URL to: file:///
>
> I'm not sure that this is a bug, it seems more correct than it was
> before.

Then what is the correct way to reference a file by its relative path using
libcurl and file:// ?

Kamil

> However if for backwards compatibility we wanted to skip that
> for file it should be simple
>
> - if(path[0] != '/') {
> + if(path[0] != '/' && !strcasecompare(protop, "file")) {
>
>
> [1]: https://github.com/curl/curl/commit/3bb273db7e#diff-8fb104cR4292
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-11-06