On 2/2/2016 6:26 PM, Daniel Stenberg wrote:
> Hey Ray,
>
> In your commit 2b6dadc, you said: "This is a partial revert of 3017d8a
> until I write a proper fix."
>
> Do you have a time frame for that, or do you think we can release a
> patch release of curl already without that proper fix? I'd prefer to
> get our 7.47.1 release out by Thursday or Friday this week.
>

Sounds fine. I'm on it. The security impact of the revert is very low,
because it requires user-specified substituted strings. My intention at
the time was to stop something like this:

curl --output f#1 http://example.com/{:\\foo,:\\bar}

[1/2]: http://example.com/:\foo --> f:\foo
[2/2]: http://example.com/:\bar --> f:\bar

The question I guess is what's appropriate for the different operating
systems. You could argue the user is responsible if they are using
substitutions. Though it seems rational to me that we wouldn't allow any
path separators from the URL to be used in the output filename. Do you
guys think that's too far? Here's an example that's probably closer to
home on Linux:

curl --output #1 http://example.com{/foo,/bar}

[1/2]: http://example.com/foo --> /foo
[2/2]: http://example.com/bar --> /bar

So do you think that type of thing should continue to be allowed, or no?
My "fix" would basically be to sanitize path separators (and colons on
MSDOS/Win) from the substitutions. I don't want to break anyone's
scripts though.

Also if you could separately reply to my off-list e-mail from 1/30 I'd
appreciate it.

Ref: https://github.com/bagder/curl/issues/624

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2016-02-03