[PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

a proper solution out of the box. Paddy On Tue, Sep 18, 2012 at 1:11 PM, Derick Rethans der...@php.net 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 standardised means of escaping

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 padraic.br...@gmail.com wrote: Hi all, I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper. The RFC is a proposal to implement

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

:27 PM, Pádraic Brady padraic.br...@gmail.com 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 escaping is available to all PHP

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

nomenclature 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 List

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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://www.sugarcrm.com/ (408)454-6900 ext. 227 -- Pádraic Brady http://blog.astrumfutura.com http

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 st...@mrclay.org wrote: On 9/18/12 7:30 AM, Pádraic Brady wrote

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

, to which I see no purpose unless you seek to arrive at pre-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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

us all a favour by addressing a significant security risk in PHP applications. 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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

will finally get an ESAPI reference out of me ;)). 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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 ras...@lerdorf.com 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 ras...@lerdorf.com wrote: If we want

Re: [PHP-DEV] Re: RFC: Implementing a core anti-XSS escaping class

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

Re: [PHP-DEV] Re: RFC: Implementing a core anti-XSS escaping class

, 2012 at 9:58 AM, Pádraic Brady padraic.br...@gmail.com wrote: 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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

, 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 -- Pádraic Brady http://blog.astrumfutura.com http

Re: [PHP-DEV] Re: RFC: Implementing a core anti-XSS escaping class

remove the barrier of having to rewrap functions into a class for those who do practice OOP regularly. So, yes, obviously it's a preference but not an unnecessary layer of complexity since it actually simplifies overall usage in the OO setting. Paddy -- Pádraic Brady http://blog.astrumfutura.com http

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 variables/statements or anything else. Those can never ever be subject to any form of untrusted input. Paddy -- Pádraic Brady http://blog.astrumfutura.com http

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

is better served with good quality documentation and examples (I'm all for docs with a dose of reality). Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team -- PHP Internals - PHP Runtime Development Mailing List

Re: [PHP-DEV] Re: RFC: Implementing a core anti-XSS escaping class

is not the same as other encodings once you get over the theoretical perfection that should exist and meet the rebels: browsers. Please bear in mind that using the correct encoding has been preached for many many years as a minimum requirement in secure escaping for PHP. Paddy -- Pádraic Brady http

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

($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 clear meaning have their advantages. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 Team -- PHP Internals - PHP Runtime Development

Re: [PHP-DEV] Reviving scalar type hints

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 -- PHP Internals - PHP Runtime Development Mailing

Re: [PHP-DEV] Scalar Type Hints v0.4

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 not. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com -- PHP Internals - PHP Runtime

Re: [PHP-DEV] Scalar Type Hints v0.4

not 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 Zend Framework PHP-FIG

Re: [PHP-DEV] I quit.

/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team Zend Framework PHP-FIG Representative -- PHP Internals - PHP

Re: [PHP-DEV] Using Other Channels (was Scalar Type Declarations v0.5)

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 Brady http://blog.astrumfutura.com http://www.survivethedeepend.com -- PHP Internals - PHP

Re: [PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5

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.astrumfutura.com http://www.survivethedeepend.com -- PHP Internals - PHP Runtime Development Mailing List

Re: [PHP-DEV] Voting irregularities

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

Re: [PHP-DEV] [RFC] [VOTE] Vote open for reliable user-land CSPRNG

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.survivethedeepend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http

Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types

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.astrumfutura.com http://www.survivethedeepend.com -- PHP Internals - PHP

Re: [PHP-DEV] [RFC] [INFO] Basic Scalar Types

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 Runtime Development

Re: [PHP-DEV] [RFC][Status] Scalar Type Declarations Voting Date Change

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

Re: [PHP-DEV] Voting irregularities

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 http://www.survivethedeepend.com -- PHP Internals

Re: [PHP-DEV] STH and the 3 RFCs

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

Re: [PHP-DEV] [RFC] Basic Scalar Types

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

Re: [PHP-DEV] A plea for unity on scalar types

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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit

Re: [PHP-DEV] User perspective on STH

bugging you now. But you responded later! :) 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

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

! 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

Re: [PHP-DEV] [RFC] Script only include/require

keep mentioning magic quotes. That was never an improvement. It was removed from PHP. Please stop trying to associate two unrelated things to establish bad practice by word proximity. The sentence is obviously true. Paddy -- -- Pádraic Brady http://blog.astrumfutura.com http

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

Hi On 24 February 2015 at 21:33, Anthony Ferrara ircmax...@gmail.com wrote: Padraic, On Tue, Feb 24, 2015 at 4:17 PM, Pádraic Brady padraic.br...@gmail.com wrote: Hi On 24 February 2015 at 20:04, Anthony Ferrara ircmax...@gmail.com wrote: If random_bytes() is harder than uniqid(), it's

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

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 Development Mailing List To unsubscribe, visit

Re: [PHP-DEV] [RFC] Script only include/require

. 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

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

On 21 February 2015 at 23:13, Lester Caine les...@lsces.co.uk 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 library

Re: [PHP-DEV] [RFC][Discussion] In Operator

you have considered a Plan B for the operator naming? Mostly curious if these is already some alternative outside of the field of langs I'm familiar with that might be acceptable. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com -- PHP Internals - PHP Runtime

Re: [PHP-DEV] Re: [RFC] Script only include/require

). 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 Internals

Re: [PHP-DEV] [RFC] [FINAL DISCUSSION] Script only include/require

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 Community Review Team Zend Framework PHP-FIG Representative

Re: [PHP-DEV] [RFC][Discussion] In Operator

. I'm not fumbling in the dark, it has created a security issue in at least two frameworks. Since it's a new operator in isolation, tightening such rules would be welcome. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com -- PHP Internals - PHP Runtime

Re: [PHP-DEV] Coercive Scalar Type Hints RFC

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

Re: [PHP-DEV] [RFC] Coercive Scalar Type Hints

. Boolean coercion from other 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

Re: [PHP-DEV] Re: [RFC][VOTE] Introduce script only include/require

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.survivethedeepend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net

Re: [PHP-DEV] Re: [RFC][VOTE] Introduce script only include/require

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://blog.astrumfutura.com http://www.survivethedeepend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit

Re: [PHP-DEV] Travis support PHP Nightly builds (PHP 7)

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. Paddy -- Pádraic Brady http://blog.astrumfutura.com http

Re: [PHP-DEV] Re: [RFC][VOTE] Introduce script only include/require

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. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com -- PHP Internals - PHP

Re: [PHP-DEV] [RFC] Script only include/require

- 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 -- PHP Internals - PHP

Re: [PHP-DEV] Re: [RFC][VOTE] Introduce script only include/require

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's not covered by that setting. Paddy -- Pádraic Brady http://blog.astrumfutura.com http

Re: [PHP-DEV] [RFC] Script only include/require

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

Re: [PHP-DEV] [RFC] Script only include/require

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

Re: [PHP-DEV] [RFC] Script only include/require

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG

be there ;). 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

Re: [PHP-DEV] [RFC] Script only include/require

Hi Dan On Wednesday, February 25, 2015, Dan Ackroyd dan...@basereality.com wrote: On 25 February 2015 at 00:09, Pádraic Brady padraic.br...@gmail.com javascript:; wrote: Your example omitted the image validation step which would have noticed your attempt to upload a phar immediately. Add

Re: [PHP-DEV] Coercive STH - some real world tests and updated RFC

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

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

, 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

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

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

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

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

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

’m on record as believing that while 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 Ru

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

oosely 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 exist, depending on local laws, I imagine the cost would be prohibitive (for not outright criminal beha

Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of Conduct

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 manner via the appeals mechanism. All steps are also clearly tied to the existence of evid

Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct

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

Re: [PHP-DEV] Specific incident in relationship to the proposed Code of Conduct

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

Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of Conduct

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

Re: [PHP-DEV] Specific incident in relationship to the proposed Code of Conduct

treatment, I disagree. 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 gath

Re: [PHP-DEV] Specific incident in relationship to the proposed Code of Conduct

e. Who knows, eventually we may one day solve most of them. I like to think so, at least :). Paddy -- Pádraic Brady http://blog.astrumfutura.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Specific incident in relationship to the proposed Code of Conduct

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 authority to punish them? Paddy -- Pádraic Brady http://blog

Re: [PHP-DEV] [VOTE] Contributor Guidelines, and Updates to Code of Conduct progress

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