curl / Mailing Lists / curl-users / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: Request to revert Windows path restrictions

From: Daniel Stenberg via curl-users <>
Date: Fri, 10 Apr 2020 23:09:21 +0200 (CEST)

On Fri, 10 Apr 2020, Chris Roberts via curl-users wrote:

This reply is deliberately top-posted so that everyone can see the full
original post as sent to curl-users as I think curl-library is the better list
for the discussion on what to do next. I'm CC'ing my reply to curl-users too
since Chris posted his first mail there.

Can I first highlight the fact that we have updated the advisory for this CVE
over at and the update and new
view is very prominent. If you read the *real* and original advisory (ours)
it shouldn't be possible to miss the update.

It's a little curios, but there seems to be no way to official retract or
"take back" a CVE once filed. This would've been retracted if we could.

Since we don't consider this a security problem, I think the (insufficient)
mitigation should be removed. I agree!


> Hi!
> I have been running into some issues with the new changes included to
> address CVE-2019-15601. After reading through the original CVE, I'm
> not sure that I agree it is an issue with curl, nor do I believe it is
> an issue which curl should be responsible for addressing. After
> reading through some of the archives on this list, I found the thread:
> "Warning: using file:// on Windows with curl"
> That thread seemed to pretty well sum up my feelings around the change
> implemented with regards to the reported CVE. It doesn't really seem
> to be an issue with curl, and if it actually is an issue, it seems to
> be more of an issue with Windows itself. Any other tool or application
> that loads file paths will have the same behavior as described by the
> CVE.
> The request to revert the change:
> is due to the fact that this change seems to result in an added
> restriction to functionality (breaking functionality which was
> previously working) without any significant gain. Network paths can
> still be accessed in other ways, and as the documentation now states,
> if that type of behavior is unacceptable then the file protocol should
> be disabled. But for use cases where the file protocol is desired on
> Windows, the restriction on paths with a double slash prefix is
> breaking the expected behavior (in this case "expected behavior" being
> both handling valid Windows paths and curl's previous behavior until
> this changeset). Is reverting the behavior back to its original state
> something that would be acceptable?
> Thanks so much!
> - Chris
> -----------------------------------------------------------
> Unsubscribe:
> Etiquette:

  / | Commercial curl support up to 24x7 is available!
                   | Private help, bug fixes, support, ports, new features
Received on 2020-04-10