Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58898
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
Message-ID: <4F5E7186.7060303@gmail.com>
Date: Mon, 12 Mar 2012 22:58:30 +0100
User-Agent: Thunderbird
MIME-Version: 1.0
To: Richard Lynch <ceo@l-i-e.com>
CC: internals@lists.php.net
References: <CAOfKkdQMOgxBmKSo3DHaJZeHFe4fAOzg8a7amA9_--1=CeSBjA@mail.gmail.com>    <4F5C5540.8010204@sugarcrm.com>    <CAORXhG+=Tpzad-OxdWNcZdjvJDrF7jVOtiQ9PGvymL9HQAFEwA@mail.gmail.com>    <4F5D3569.8050307@sugarcrm.com> <8d17c1162ecbe11172e4f09630200c17.squirrel@www.l-i-e.com>
In-Reply-To: <8d17c1162ecbe11172e4f09630200c17.squirrel@www.l-i-e.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] CURL file posting
From: keisial@gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)

On 12/03/12 20:36, Richard Lynch wrote:
> On Sun, March 11, 2012 6:29 pm, Stas Malyshev wrote:
>> This doesn't look good. Documentation does say the @ prefix exists,
>> but
>> it has very high potential of creating security holes for unsuspecting
>> people. open_basedir would help limit the impact, but still it's not a
>> good thing. Any ideas on fixing it without breaking the BC?
> Ouch.
>
> Issue an E_NOTICE when it happens?
>
> Add a new CURLOPT_FILEFIELDS that takes an array of the parameters
> that are supposed to be files, so the ones that are expected to have
> "@..." do not fire the E_NOTICE.
>
> Issuing E_NOTICE is a BC, I suppose, but you'd think people would
> appreciate an alert about a potential security threat...
That would only trigger the notice when you transfer data beginning with
an @,
which would end up being only when finally attacked.

I'd make it need another option to make @ options work (eg.
CURLOPT_AT_TRANSFERS_FILES)
which default to false. Similar to SO_BROADCAST, where binding a socket
to a
broadcast address is not enough to send the packets there.
It *is* a BC break, but the current API is badly provided. I don't see a
way to
work around that. A one-line fix to get the previous not-too-used(?)
behavior back
seems as good as can be achieved.
It is also possible to make a completely new option API without those
problems,
and deprecate the old one, but that's still a BC break.