Hi!
On 9 February 2016 at 13:56, Matt Prelude wrote:
> I feel that the CoC has a much greater chance of achieving consensus if we
> don't
> try to impose a 'court of law' alongside it, especially considering that
> most
> proposals for a 'court' have been secretive and focused on privacy rather
>
r them in scope unless there's a very good
reason not to.
> That's all I have to say at the moment. I'm going to go back to addressing
> technical problems; human problems are beyond me to solve adequately.
They are beyond most of us, but we can all chip away at those problems
has teeth, or has no teeth.
If it has no teeth, then how is it enforceable? If it's not
enforceable, then why should anyone bother making reports?
Worse, if the Code of Conduct doesn't even mention the teeth, can
someone involved in a rare extreme case then claim that the project
lacks the
Hi,
On 23 January 2016 at 21:30, Matt Prelude wrote:
> Hi all,
>
> This is my first mail to the list so please let me know if I do anything
> wrong or if there's a better channel by which to have this kind of
> discussion.
>
> I'd like to propose adoption of an alternative code of conduct, the Go
Hi,
On 23 January 2016 at 22:02, Zeev Suraski wrote:
>> -Original Message-
>> From: Brandon Savage [mailto:bran...@brandonsavage.net]
>> Sent: Saturday, January 23, 2016 7:44 PM
>> To: PHP internals
>> Subject: [PHP-DEV] Specific incident in relationship to the proposed Code of
>> Conduc
ee. They would then both have
allegations of unknown value which should be evaluated. This would
also open the door to baseless allegations being used to thwart the
process as a defensive tactic. As a basic level, the "demonstrated"
test still needs investigation, evidence ga
e absence of a defined process
doesn't mean there's no process at all. It's also important to note
that the COC makes it clear that the proposed small team has very
limited abilities, with any additional action needing to be taken to
the entire project, and can be overruled in the same manne
hile punitive action
need not be the central theme in a COC, it has to clear somewhere that
it CAN be employed when absolutely necessary. Hopefully never! But I
left my crystal ball at home…so I can’t rule it out.
Paddy
--
Pádraic Brady
--
PHP Internals - PHP Runtime Development Mailing Li
Honestly, I don’t care if it’s one line in a footnote
in pt2 font size, so long as it’s there.
Also, loosely connected and off on a tangent perhaps, it’s important
that we don’t just expect legal consequences to solve everything at
the extreme end of the spectrum. While that avenue can certainly
ex
Hi,
>For example, http://code-of-merit.org/ seems much more reasonable in
>"getting the things done" than the Covenant.
I reviewed this last night, and it hasn’t fared any better after a
night’s sleep. The Code of Merit essentially creates an armour clad
rejection of any non-technical topic. It m
Hi,
On 21 January 2016 at 04:37, Kevin Smith wrote:
> I noticed you were contacted by Randi Lee Harper [https://archive.is/b8RDW],
> the ironically abusive founder of the Online Abuse Prevention Initiative
> [https://archive.is/eqco9][http://archive.is/A1Azz] known for attacking and
> attempti
Hi,
Up front, I agree the objective of the COC needs to be clearly stated.
There is confusion, whether it's here or externally by observers, as
to whether this is intended to fix mailing list toxicity (I assume,
for now, not) or intended to state the projects intentions should
there be a complaint
supplementary or
inline statement of accompanying principles?
Regards,
Paddy "But I Only Voted That One Time" Brady
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
a
reason why type hints, in some form, have support from the community.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
useless to the present
time, and it's all kinds of frustrating. I understand your
perseverance, but we seem stuck with this situation and it won't look
any prettier tomorrow either. Whatever the outcome, PHP 7's process
will be talked about for a very long time.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
r votes so we do have
"issues" to resolve in making it absolutely clear who may or may not
vote without feeling some sense of guilt or inviting comment when the
vote count reaches for the sky and those like me come out of the
woodwork ;).
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
ed at my email. I'll wait
and see what the RFC announcement brings, however, since that is the
only thing of relevance in seeing whether my own concerns are
addressed or not.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
--
PHP Internals - PHP Runtim
Hell, no.
What is? It's just the only approach we can possibly follow on Sunday,
March 15th.
If this RFC enters into voting in any time period not allowed within
the rules as they are written, I will obviously not recognise it as
valid in any way.
Paddy
--
Pádraic Brady
http://blog.astrum
y earned it, has been brought up by both sides to
RFCs inside and outside of this list.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
nterface to: systems which take a truly random seed and output
pseudorandom values. The difference is that the underlying system is
designed to be cryptographically secure (for most uses). mt_rand(), on
the other hand, is not.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.
's the case then you should be arguing for the PHP7 timing to be
changed, if you feel that any RFC will need additional development
time, not for the typehinting RFCs to all be withdrawn.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
--
PHP Interna
are actually quite
important.
Are there any other rules waiting to be unilaterally suspended? I
guess we'll see...
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
spaces.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
y appear attractive to
limit the phar: protocol, it's a fairly vital extension of the
filesystem that we should be wary of tampering with.
It would probably be more productive to clarify the status of phar:
URLs in the docs for allow_url_include, if only to emphasise that it&
trated that the change will prevent a specific
vulnerability in the wild. I would ask you to consider that example,
and then raise any concern you wish as it pertains to that relevant
example which captures the purpose of this RFC very neatly. To say
that there is no benefit is simply not true.
Pad
ml, inc, or whatever. As those are all commonly
> associated with PHP and offer no good reason to be allowed in user uploads,
> I guess it's safe.
No objections here for common extensions well established as being
intentionally PHP bearing files.
Paddy
--
Pádraic Brady
http://blo
other
> extensions - like Smarty or some other template library - and it may be
> non-trivial to find out all of them.
Use grep.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative
g PHP bearing JPEGs as one example
mentioned several times.
Is there some sort of meter on Internals where, in the red, there is
an obligation to fill it back up with FUD, logical fallacies and the
occasional fib?
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepe
y testing real code and also so as
>> to have as much real code as possible getting ready for PHP 7.
>
> It would also mean that PHP officially endorses travis.
I read Pascal's email as merely a suggestion to disseminate some
information, not an endorsement for what it's worth.
iginal proposal. It's in the similar vein as
> password_hash(): If users have to think, they'll screw up. Don't make them
> think.
>
> --Larry Garfield
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
--
PHP Internals - PHP Runtime
instance, exploiting the web server itself.
This last sentence is true enough. For some reason though, we still
fix other entirely unrelated security weaknesses in PHP itself...
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
.
>
No it doesn't! You are misrepresenting this RFC as a magic wand. That is
not the case and it is extremely frustrating to see you persist on this.
Read my emails and read Yasuo's and then Dan's. Then we can have some sort
of intelligible discussion.
Paddy
--
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative
Hi Dan
On Wednesday, February 25, 2015, Dan Ackroyd wrote:
> On 25 February 2015 at 00:09, Pádraic Brady > wrote:
> >
> > Your example omitted the image validation step which would have
> > noticed your attempt to upload a phar immediately. Add that and try
> >
plicit assumption is the files are
pre-validated so it exists to mop up certain edge cases that may
bypass validation.
This is just basic defense in depth.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ain image validation checks, would
indeed be preventable by his RFC. Please stick to what the RFC
actually claims to do.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Yasuo,
On 24 February 2015 at 22:08, Yasuo Ohgaki wrote:
> Random bytes is better. People would use it for IV or like with the
> size of IV. If we use string, users loose effective bits.
Suggestion was for an additional function, so random_bytes() would
still be there ;).
Paddy
--
P
Hi
On 24 February 2015 at 21:33, Anthony Ferrara wrote:
> Padraic,
>
> On Tue, Feb 24, 2015 at 4:17 PM, Pádraic Brady
> wrote:
>> Hi
>>
>> On 24 February 2015 at 20:04, Anthony Ferrara wrote:
>>> If random_bytes() is harder than uniqid(), it's
thing obviously!
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ntal improvements add up to a significant improvement.
>
> If that were always true, safe mode and magic quotes would still be here
> with us.
>
You keep mentioning magic quotes. That was never an improvement. It was
removed from PHP. Please stop trying to associate two unrelated thi
). As such, this patch would lock out
an obvious path by restricting the files that can be included to a
more limited subset.
Enough incremental improvements add up to a significant improvement.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
--
PHP Interna
t webhook for a git repo?
> This is what I want from STH, no more no less: sane casting rules, and the
> ability to code to scalar types safely. While I can see some of the benefits
> of
> strict mode, I'm concerned about the schism it may create in the PHP library
>
On 21 February 2015 at 23:13, Lester Caine wrote:
> On 21/02/15 19:56, Pádraic Brady wrote:
>> 1. Happy to see leading/trailing spaces excluded.
> Fixed length fields may well be a data source so having to strip them
> before using them just seems a backward step. The basic C
types... Not entirely sure myself.
Completely off the cuff: <=0: false, >0:true, floats and strings need
not apply.
7. In string to float, only capital E or also small e?
8. I'll never stop call them "stringy" ints.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
us assuming we are
excluding stringy integers like hex, oct and binary
4. I'm assuming the stringy ints are rejected?
5. Is ".32" coerced to float or only "0.32"? Merely for clarification.
6. Boolean coercion from other types... Not entirely sure myself.
Completely off th
u all who have participated to discussions.
>
> Those who are not involved, this is the time to check this RFC.
>
> Thank you.
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
--
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Commu
On 20 February 2015 at 23:38, Larry Garfield wrote:
> While I love the idea, strict type comparison for in would, in essence, be a
> toe-dip into the scalar strict typing world (see other thread) that would be
> very confusing. Consider:
>
> if (3 in $_GET['filters']) { ... }
>
> That would alway
fficult
to use in certain use cases. A common usage would be a contains/in
validator, for example, where loose comparisons can pass unwanted
values depending on how it's written. I'm not fumbling in the dark, it
has created a security issue in at least two frameworks.
Since it's a new operat
would be required to be outside the namespace
> block).
>
> I'm considering adding it, as it's a valid use-case. What do you think?
Seems a valid use case, and the block solution is therefore the
logical step. I see no reason to exclude it.
Paddy
--
Pádraic Brady
http://blog.a
l circumstances.
As I believe Sara noted before, she will work with either of the RFCs
(yours or Anthony's) as it fits her own purposes, so it will boil down
to whichever RFCs gets published in the end. There's one up. I assume
yours will follow. That shall make two :).
Paddy
--
Pádraic
to call folk "radicals" if you intend to pursue
a compromise with them ;).
I wouldn't necessarily mind int->float - it's lossless assuming one way only.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Ze
.
So, I agree with Nikita that this is less than strict typing, but one
single logical exception doesn’t instantly demote it to extreme weak
typing if its sufficiently narrow in scope. We are compromising, no?
It’s imperfect in other ways, but I’ll let others debate if those are
significant or n
ut with the bath water and coming up
> with some new approach that will be bike-shedded over until PHP 8 is
> in feature freeze.
Hear, hear.
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative
;
> So, thank you, PHP community. It has been a wonderful 2 years.
>
> Goodbye.
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
-
any case, hopefully I'll be back with real hardcore C code for PHP
5.5. In the meantime, if anyone has any lingering concerns or
questions about the RFC, let me know!
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review
Nobel prise?
HTMLPurifier by Edward Z. Yang. It only works on body content - not
the header section, but knock yourself out ;). There's also the far
less CPU intensive option of the Content Security Policy though we're
reliant on the penetration of modern browsers to distribute that
a
easons but consider being a
programmer writing PHP templates...
htmlspecialchars($value, ENT_QUOTES|ENT_SUBSTITUTE, 'utf-8');
str_escape($string, ESCAPE_HTML_BODY, 'utf-8');
vs
escape_html($value, 'utf-8');
$e->escapeHtml($value);
Brevity and a clea
use everyone is making points and I have other emails to
respond to ;), but any debate of this nature around the RFC appears to
have relevance.
Flame away :P
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
--
PHP Internals
rrect encoding has been
preached for many many years as a minimum requirement in secure
escaping for PHP.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ue, of course, but the game is already lost if the user
isn't aware of where to safely apply escaping (a different problem to
applying the correct encoding over the wrong encoding). I think we're
bumping into a slightly different area of education here. Once users
know where escaping applies,
a whitelist of allowed ids/props.
> Also, escapeForJS isn't very clear, you should explicitly specify you're
> escaping a string of text for a JavaScript string literal. I don't think you
> can escape JS identifier names.
JS is purely for literal values and not any JS v
y programmers use objects, dependency injection and all
that other stuff. Adding the class simplifies usage in an OOP setting
and ideally helps remove the barrier of having to rewrap functions
into a class for those who do practice OOP regularly. So, yes,
obviously it's a prefe
Ls that also need to be validated.
HTML, of course, has HTMLPurifier - easily the best HTML sanitiser.
URLs must always be validated to a known good whitelist (not
filter_var() only).
CSS can also be sanitised if the user has access to properties and not
just the property values.
Paddy
-
; On 19 Sep 2012, at 08:39, Tomas Creemers wrote:
>>
> [snip]
>>>
>>> I really don't see what class instantiation would add to this design
>>> (if it's going to be a class at all). It doesn't have
>>> instance-specific state.
>>>
&g
You did notice the character encoding parameter to the constructor? The point
of the class is to share that little piece of state and omit it as a required
method parameter thus removing one OOP layer for those practicing OOP like all
the major frameworks.
The RFC notes already that character
ters to be taken advantage of. There are benefits to reusing
pre-peer review rules.
Paddy
On Tue, Sep 18, 2012 at 8:40 PM, Rasmus Lerdorf wrote:
> On 09/18/2012 03:28 PM, Pádraic Brady wrote:
>> Hi Rasmus,
>>
>> On Tue, Sep 18, 2012 at 7:34 PM, Rasmus Lerdorf wrote:
>>
variants
and these are already well known in PHP.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Ángel,
The methods all refer to literal strings, values or digits. We can't
reasonably escape data while allowing valid markup for the current
context since that's a contradiction by its very nature. If you needed
to let user values drive CSS names, Javascript functions or variable
naming, or H
the
scope of the average programmer, barely within the scope of large
frameworks but should be perfectly within PHP's scope to manage and
have some level of confidence in its security while doing us all a
favour by addressing a significant security risk in PHP applications.
Paddy
--
Pádra
re-determined conclusion that we need to duplicate APIs because it's
> called "filter".
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
up via a Javascript string defined in a HTML
attribute interpreted as PCDATA.
Oh, and that does happen. It's far from recommended these days - we
should all start applying the new Content-Security Policy standard.
Paddy
On Tue, Sep 18, 2012 at 6:19 PM, Steve Clay wrote:
> On 9/18/12 7:30 AM,
is in the RFC) and whatever might
theoretically exist if PHP actually had Javascript and CSS options.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survive
lementation it'd be much harder.
>
> So far I am not convinced we should really do it. But if somebody
> creates PECL extension and it proves popular, it may be merged into core
> once it does.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://
menclature for escaping on output in general with options for various types
> (and should just be utf-8 by default :))
>
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
--
PHP Internals - PHP Runtime Development Mailing
12 at 2:27 PM, Pádraic Brady
> wrote:
>> Hi Derick,
>>
>> This is already available over composer. The RFC contains links to the
>> two frameworks which have implemented Escapers in line with the RFC.
>>
>> The point of the RFC is to ensure a consistent API for esc
C that you have a bunch of functions, I believe all
> these could be options to filter_var, ie.: FILTER_ESCAPE_[URL, JS,
> CSS, HTMLATTR].
>
> - Paul.
>
>>
>> - Paul.
>>
>> On Tue, Sep 18, 2012 at 12:30 PM, Pádraic Brady
>> wrote:
>>> Hi all,
>&
HP distributing a proper solution out of the box.
Paddy
On Tue, Sep 18, 2012 at 1:11 PM, Derick Rethans wrote:
> On Tue, 18 Sep 2012, Pádraic Brady wrote:
>
>> I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper.
>> The RFC is a proposal to implement a
.
https://wiki.php.net/rfc/escaper
Best regards,
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
77 matches
Mail list logo
