Hi!
> Or simply don't have voting rights ...
> Personally I would prefer to see 'empty()' remain limited to real variables.
AFAIK all committers have voting rights on wiki.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PH
Hi!
> The PHP group is totally irrelevant in this process, with all due
> respect. It is about php.net developers.
Which is what I meant - most of the developers (or committers) did not
vote at all.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 2
Hi!
> As Stas suggested earlier, it would help if you can convince one
> person having voted none or both to choose the empty only option, then
> you should be good. It is not that good in general, but for 1/3 of a
> voice for something like that ... :)
AFAIK 2 of the people voting "both" (myself
Hi!
> Please be kind to review and comment my proposal for custom casting in PHP
> (or let me know if a similar proposal was already discussed).
>
> http://pastebin.com/sPb0i8U6
I think there's an issue with this idea. As far as I understand, what is
proposed is kind of cast-constructor paradigm
Hi!
> can I ask how did you come up with that number, and who is the half man? :)
Tyrion Lannister?
(sorry, couldn't help it)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscri
Hi!
> Also as I can understand the frustration for such tight votes, it is
> however a good sign that there is no real consensus nor a huge
> interest to change that.
16/4 is not exactly what I would call "close vote". But I think it's not
the lack of consensus but lack of interest - which raises
Hi!
> So the float comparison behavior under ~B (what's in the patch) may seem
> more desirable because it preserves the numerical comparison when possible
> (and we don't have to add leading whitespace and zeros to the mix,
> strcmp("9, "11") returns 1). Until you realize it's alternating b
Hi!
> I just closed the vote for this RFC. The result (see
> https://wiki.php.net/rfc/empty_isset_exprs#vote) is:
>
> * Both empty() and isset(): 3
> * Only empty(): 13
> * None: 4
Low turnout is kind of disappointing - either people are not interested
in this feature or don't care in general.
Hi!
I know this was discussed a number of times here, but just to bring it
to a conclusion - I intend to apply patch in the bug report - which
removes conversion for strings that do not convert to integers - to 5.4.
If anybody sees anything that breaks because of this please tell. Not
sure what ab
Hi!
> However, is there a predictable process for picking some requests over others?
Yes. Creating and RFC and discussing it on the list raises chance of
resolution (one way or another) of the request.
For smaller feature that does not warrant RFC, pull request on github
and note on internals wou
Hi!
> Because Foo_Bar could be *defined* under a different name, say,
> Foo_Blah. Then, as soon as someone needed Foo_Bar, we would use
> class_alias to add an alias. That is, as soon as someone tried using
class_alias is a dirty hack. instanceof implies that the object is an
instance of speci
Hi!
> May I ask why you agreed to move sqlite away? That is a very close
> situation (well, better as sqlite library status was way better than
> current c-client).
There's sqlite3, but nothing like this for imap. If there were another
superior imap extension it would be different business.
--
S
Hi!
> I think you over estimate the complexity to move something to a clean,
> maintained, user friendly API from a over complex, buggy and
> unmaintained extension and library (which can kill requests under
> certain circumstances too).
No I do not. It doesn't matter if it's maintained or not if
Hi!
> As I said there are many very good alternatives, BSD-like too.
Alternative means rewriting all the code. On top of framework previously
not used in the project, with different APIs, different approach to
IMAP, etc. This is a large piece of work, for many projects - totally
unnecessary as ex
Hi!
> Before I go with a RFC and all that, I would like to check the current
> feeling about killing ext/imap. The c-client project is dead since
> quite some time already. I do not see any viable alternative
> (applicable to server side usages) and it would be very hard to
> maintain the same API
Hi!
> Skim the bug tracker for low hanging fruit.
There's also http://bugs.php.net/random if you're feeling lucky :)
Any bug in "Open" would be a candidate.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Develo
Hi!
>> - Variables may be used as input to out/ref arguments. Properties
>> may not.
This will probably be true for properties too, in some cases. However,
it is in no way an advantage.
>> - Properties may throw exceptions - variables will never do that.
In PHP, properties can not throw excepti
Hi!
> The less people beginning to rely on this bug the better, and this is
> a critical time. The impact of this BC break feels larger considering
> MQ is enabled by default in PHP 5.3 and below.
I understand but a) nobody should be using magic quotes anyway and b)
holding release for 5.4.1 bec
Hi!
> These would also include automatic implementations which call the
> respective functions on the backing field. I could see only allowing
> isset/unset automatic implementations if get/set were also specified
> as automatic implementations.
Another thing about that. The "automatic implement
Hi!
> public $dataArray {
>
> &get { return &$this->_dataArray; }
This is not correct. Please read:
http://php.net/manual/en/language.references.return.php
> These would also include automatic implementations which call the
> respective functions on the backing field. I could see only allowin
Hi!
> would it be possible to add a second shorthand syntax to the complete
> automatic implementation?
>
> Examples:
>
> class TimePeriod
> {
> public $Hours {};
> public property $Hours;
> public $Hours {property};
> }
How it is different from just public $Hours and why one would
Hi!
> https://bugs.php.net/61784
>
> The get_magic_quotes_gpc() function returns 0/1 before 5.4, but now
> it returns boolean false. Instead it should return 0. Fixing this
> feels like a bug fix, which would go in 5.4.1. Thoughts?
I do not see a reason to hold 5.4.1 for this.
--
Stanisla
Hi!
> empty() - Returns true for a property retrieved via __get() or via a
> getter -- Any idea why this would be the case for __get()? Is this a
> bug?
isset() calls __isset(), empty() calls __isset() and __get(). I'm not
sure what exactly you consider to be a bug.
> unset() - Would unset a te
Hi!
> In summary: should abstract protected constructors be inaccessible by
> siblings, as is true of __clone and __destruct? Should __construct, __clone
> and __destruct always be accessible in relatives, as is true of other
> methods? Depending on the answers, there could be a documentation issu
Hi!
> If there is no other discussion for this, I'd like to move this to the voting
> phase, any objects?
>
> https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
Sorry, I didn't have time to look into it yet (yes I know it was around
for a long time...) in detail. From the quick glance
Hi!
> I can't estimate the amount of breakage, but what about using underscore
> (literal _) without quotation marks?
This one is taken. See: http://us2.php.net/_
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime
Hi!
> Before addressing the points individually, I have to reiterate that
> internal functions have no concept of default values. I think this
I disagree. Most of them certainly do, for example, look at strpos
documentation:
int strpos ( string $haystack , mixed $needle [, int $offset = 0 ] )
$
Hi!
> I think the documentation part in this case is not as problematic,
> because the interface has been thoroughly documented in the ICU
> project. Most of your next questions can be answered by reading
>
> http://userguide.icu-project.org/datetime/calendar
This is ICU docs, not PHP docs. Most
Hi!
> Not sure what you mean here. What is this "varargs return"? As far as I
zend_parse_parameters has varargs options. See how var_dump is implemented.
> the number of arguments actually passed. But even if it returned the
> number of arguments passed, it would be irrelevant because you wo
Hi!
> "default" is already a reserved keyword. It's used in switch
> constructs. So it is safe to use :)
Ah, silly me, indeed it is. Then I guess it doesn't hurt to add it as an
option. Will do.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
> This would cause a lot of problems. Basically, all the functions that rely
> on ZEND_NUM_ARGS() will have to be changed. You can't tell if a parameter
> was passed or not by relying on it.
ZEND_NUM_ARGS() would probably work since IIRC it relies on stack size,
not on varargs return. Yes, th
Hi!
> My one comment, which others have raised, is readability of multiple
> commas -- TBH, at first glance it has the appearance of a mistake. I
> think those suggesting a keyword such as "default" make a good point in
> this regard -- it makes it 100% clear that you want the default value
I wou
Hi!
> I'll keep going offtopic a bit more.
> I would rather see named parameters implemented *prior* to this.
I'd rather see named parameters implemented already in 5.0. But somehow
that didn't happen :) It's on my todo list though if nobody beats me to it.
--
Stanislav Malyshev, Software Archit
Hi!
> As already mentioned, There can't be a class constant called "class",
> because it is a keyword. (const class = 'Foo' is a syntax error).
It looks like class constant. So it should work like one (or, in this
case, not work since as you noticed there can not be one).
> But yes, I agree that
Hi!
> The goal is to have community leader participating in our design
> discussions and decisions. It has happened already for a couple of
> RFCs (accepted and rejected) and went very well. The FUDs about core
> devs, legacy developers and the like loosing control about the
> direction PHP takes
Hi!
> NULL or empty string? I.e. will optional parameters always get NULLs
> or their default values?
Their default values. That's the whole point of it - if I wanted just
nulls, I could put nulls in the call, but if I want the actual default,
I'd have to find the definition and copy-paste from t
Hi!
> a) it kind of encourages using long lists of arguments (which is not
> normally regarded as good practice)
This ship has sailed long ago, these lists are the reality. And
rewriting all the code to change all function calls is in most cases
completely infeasible.
> c) the current situation
Hi!
>> BTW: the diffs show a lot of WS changes that you should probably fix.
That's Eclipse, it loves to strip trailing whitespace... Which btw shows
for some reason we have lots of it in our code.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 22
Hi!
> Since func_num_args() won't be able to be used to see if an argument is set,
> could a func_isset_arg() be added? So something like:
> if(func_num_args() > 2) $value = func_get_arg(2);
> would become:
> if(func_isset_arg(2)) $value = func_get_arg(2);
I think it's easier to just do func_get
Hi!
> I'm thinking undefined like JavaScript.
Well, in PHP null is closest, but a bit different. I.e. in JS undefined
a is an error, but a[0] where a is empty is "undefined". In PHP in both
cases you get null and notice, and in both cases you can use isset/empty
to check for it.
--
Stanislav Mal
Hi!
> Introducing "undefined" might be good.
> Intention becomes clearer and we may do
>
> if ($var === undefined) {
> echo '$var is undefined';
> }
What is undefined and how $var gets assigned it?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext
Hi!
One of the annoying things I've encountered in working with PHP was
dealing with functions having long optional parameter lists, especially
if you need to change only the last one - you have to copy all the
defaults. Full named params implementation would solve it, probably, but
before we have
Hi!
> sorry, I can't really follow you with that.
> do you have a problem allowing the non-vcs users (defined by the voting
> rfc) to vote, or do you have a problem providing a clear way for them to
> get their voting karma?
I have a problem that we don't have understanding of what is the goal of
Hi!
> I tend to agree. __CLASS__ to me belongs to the family of constants
> like __DIR__ and __FILE__ where they are meant to be evaluated in-place
> and are simply a substitution for something completely static.
But that's exactly what Foo::class is - completely static constant.
> In my mind
Hi!
> Fantastic question. I am unsure how to handle this. Currently, it will
> simply resolve those names against the rules (I am sure this is the
> wrong behavior.) So,
>
> namespace Foo\Bar { var_dump(self::class); }
This should produce an error outside of class context, I think. Insi
Hi!
> http://www.mail-archive.com/internals@lists.php.net/msg51948.html
> Pierre said that it was a bug(better to say lack of restriction), that
> everybody with wiki account was able to vote, so I changed the voting
> plugin to only allow the specific groups(vcs + voting) to be able to vote.
Thi
Hi!
> Stas tags Wednesday evening US Pacific time
> Stefan builds Thursday during the day US Pacific time
> David announces after all this is done which is Thursday evening EU time
> sometimes it becomes so late that I can only do it friday morning.
>
>
> So if we want to release Thursday, t
Hi!
> May I suggest using foo::__CLASS__ instead of foo::class ? It's longer, but
> closer to what already exists for this semantic (class name as string),
> don't you think ?
I like this. __CLASS__ is already being used as class name, and little
chance of colliding with some code since you're no
Hi!
> Number of posts to the commit list since Jan.1,2012 (top 25):
>
> [s...@php.net] => 412
This figure is unfortunately over-inflated by the unfortunate tags
incident :) So subtract 300 or so from that :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcr
Hi!
> The whole point of releasing on Thursdays is so sysadmins have the
> chance to update their servers in the event of known security problems
> "before the weekend".
> This point however becomes void when we release late Thursdays evening
> American time, and we could just as well release on S
Hi!
> I'm not sure about it. AFAIK when I implemented my patch to restrict the
> voting to the vcs users + the voting wiki group, we lost that ability.
> (see http://www.mail-archive.com/internals@lists.php.net/msg51932.html for
> the history of that change)
I don't see any indication there that
Hi!
> In any case, your selective quoting destroyed the main point of my
> e-mail -- that is, this problem implicates these questions: is
> "9223372036854775808" different from 9223372036854775808? Is
> "9223372036854775808" still deemed to represent an integer, even
> though we cannot represent
Hi!
> no, it only means that our internal processes aren't clear or easily
> accessible.
> people outside the circle can't do much, than asking people inside to
> let them in.
If somebody is an outsider to PHP development, why do you think giving
him a deciding vote on it would be a good thing? O
Hi!
> the voting RFC explicitly states that it is possible for (some) non-vcs
> users to vote, but there isn't any formal process on how can someone
> apply for voting karma, and what is the decision making process on this.
And what is the problem in not having the formal process?
> which went u
Hi!
> So this time, I would like focusing only on the following:
I think before going into these, it is important to answer this
question: what is the problem we're trying to solve?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Inte
Hi!
> I think that once PHP-5.4.1 was branched, then PHP-5.4 should have
> become 5.4.2-dev.
You're right.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://w
Hi!
> It's convenient to assign an empty array to a property in this manner.
>
> private $storage = array();
>
> So why not
> private $storage = new ArrayObject();
array is a static constant. Objects have complex behavior. So it's
better to handle this in ctor. I see no value in splitting ctor
Hi!
> Help me understand, b/c I am not clear what you mean by "we allow
> expressions in function calls". This is my immediate understanding of
> the anatomy of a closure:
Function call:
f($a, $b+$c);
Closure:
$x = function ($arg) use($a, $b+$c as $bplusc) {
/*...*/
}
For the same reason w
Hi!
> Just throwing this out there, but that code wouldn't be run on parse.
> It would be "queued" to run prior to the constructor on instantiation.
Why? You have perfectly good ctor, why not use it?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext.
Hi!
> What's proposed is really more closely related to the functionality of
> "global" since you're taking a non-local variable and making it accessible.
It is like global but with important difference - global inserts the
variable into current scope, with all consequences (modification, etc.).
Hi!
> Why can't we create a new object and assign it to property like this?
Because the engine doesn't run code when parsing class definitions so
defaults should be constants (otherwise would also create a lot of
trouble for bytecode caching as object are not cacheable).
Use ctor for complex ini
Hi!
> Sadly when I proposed this many months ago my post was ignored. :-(
I've looked up your post
(http://marc.info/?l=php-internals&m=130348253124215&w=2 if anybody's
interested) and unfortunately I think it did not have due attention
because it mixed two issues - converting comparison that ==
Hi!
> PHP's goal has always been KISS, but the decisions over the last few
> years run contrary to that. Most onerous is, where Javascript, Java
> and C have one scope resolution operator - a period - PHP has three
> (->, \, :: ). The only possible backwards compat fix to that is to
This is not
Hi!
> There are other situations where the result of the comparison may be
> "inaccurate" -- in the sense that two strings may be constructed as
> representing different numbers, but they compare equal.
>
> * Comparing two different real numbers that map to the same double
> precision numbe
Hi!
> I am not sure but it is too expensive only for memory. I don't think
> that current scope will be very big and operation for copying it very
That depends on the scope, it can be very big - e.g. global scope. But
more important is not that it is big by itself, but that it retains
variables
Hi!
> I'm at a bit of a loss as to why Laruence is claiming that allowing
> closures to implicitly access variables in the outer scope requires
> duplicating the symbol table.
Because variables need to be stored somewhere after the parent function
exits.
> Is there any technical reason why it's
Hi!
> To me it's not about renaming variables, but rather avoiding to clutter
> the parent scope with variables, e.g.:
>
> $closure = function () use ($this->getFooBar() as $foo) {
> $foo->stuff();
> }
>
That sounds like an interesting idea. If it can be done properly (i.e.,
what if that ex
Hi!
> If this is a pecl module library developers cannot use it and trust
> that on php 5.n, it just works. That would fork the language in an
> undesirable way. It should be a core feature, no ini flag, no
> sometimes-there module.
PHP 5.n is at least a year away, wide adoption of it - more like
Hi!
> If I exclude current code, then introducing script only include will be
> preferred one. I preferred dedicated statement for it though.
>
> include
> include_once
> require
> require_once
> script
> script_once
I have a thought here. To implement script/script_once you don't need it
to be
Hi!
> Common sence is allien to some people on this list or what?
While I think you make a good point, I also think we could do without
personal (or multi-personal) attacks. It is fine to discuss and
criticize ideas, but let's avoid attacks on personal level and
disparaging personal qualities of
Hi!
> In summary: should abstract protected constructors be inaccessible by
> siblings, as is true of __clone and __destruct? Should __construct, __clone
> and __destruct always be accessible in relatives, as is true of other
> methods? Depending on the answers, there could be a documentation issu
Hi!
> On that note Mr. Malyshev has indicated (in addition to several other
> threads on the internals list) that no new features will be added in
> 5.3 or 5.4 branches.
5.3 is out of the question, I think, but for 5.4 small self-contained
additions - like adding a couple of functions here and th
Hi!
> You might want to do something like
>
> USE_ZEND_ALLOC=0 ZEND_DONT_UNLOAD_MODULES=1
> TEST_PHP_EXECUTABLE=./sapi/cli/php php ./run-tests.php -m ext/openssl/
Also I would advise adding tests that test failure conditions - right
now the test seem to only test "OK" conditions but not failures
Hi!
> There really doesn't seem to be much interest in this proposed patch. Should
> I continue development efforts on closing this feature request?
Can't say anything here - I don't use these APIs personally, but maybe
other people need them. No idea :)
> I do also have a few questions regardi
Hi!
> handler, which is why it behaves differently from normal methods. In the
> time that I looked, I couldn't find where the access behavior for
> __construct and __destruct was controlled in the source code.
Access for functions is defined by zend_check_protected() and in
zend_std_get_method()
Hi!
> template_mode=on is not a actual security measure, but a
> switch for language mode. template_mode=on has side
> effect that makes PHP as safe as other scripting languages
> or even better!
PHP is as safe as other scripting languages right now. And you are using
security talk to promote thi
Hi!
> If attacker can inject code at the beginning or make valid syntax
> at the beginning, they can succeed injection. This is true not
> only for PHP, but also Ruby/Perl/Python.
This is exactly my point. Since it does not solve the problem that you
are presenting (I am still not convinced it's
Hi!
> btw, It is not a realy issue as we won't use 5.4.1 tests to test the
> release but 5.4's branch ones. Too many false positive.
Who are we? I'll definitely be using 5.4.1, since that's what I will be
releasing. There's no point in testing code different from one you're
releasing. Do you mean
Hi!
> I'm sure you have seen the same code in JSON hijack countermeasure.
>
> while(1){}
I think you misunderstood what I means. What I meant is you can inject
code without http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, v
Hi!
> Well, technically it's discussion /and/ vote. I know we've been wanting
> to get out of the habit of "push first, ask later," which is precisely
> what RFC helps us avoid. Personally, I think any commits for a
Nobody's pushing anything. We're talking about implementing it in a
fork, it's
Hi!
> https://wiki.php.net/rfc/nophptags?&#why_this_is_better_than_now
I'm sorry, but I do not understand how your proposal prevents LFI. Let's
say you had this file kill.php:
http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Hi!
> Err isn't this something that should go through the RFC process first?
> I think it's a good idea and I'll probably vote for it, but as I
> understand the RFC process was created specifically for stuff like this.
One doesn't preclude the other. Pull is code, RFC is discussion, they
can go
Hi!
> Currently the empty() language construct only works on variables. You
> can write if (empty($array)) but not empty if (empty(getSomeArray()).
>
> The original reason for this restriction probably is that - in a way -
> it "doesn't make sense" to pass anything but a variable to empty() as
>
Hi!
> I think my main point still stands: if the git emails are too obscure to
> follow, let us know what goes in via email to internals.
>
> Do you want to bring the NEWS updating process into this discussion?
Sure, though that would be another discussion IMHO. In this discussion,
I just wanted
Hi!
> However, as you won't merge the tests fixes either, we won't 5.4.1's
> tests at all to valid the build (way too many false positive), it does
> not really matter anymore.
Wait, are we talking about new test fixes or about tests that are broken
in RC1 and need fixing? I was assuming it's the
Hi!
> Those were the files with svn:eol-style = LF in SVN. I've committed a
> change to .gitattributes that disables EOL conversion in those files. I'm
> told this could also be accomplished with a eol=lf attribute.
>
> See
> https://github.com/php/php-src/commit/112a476b683a634390b23fe7509
Hi!
> Another important thing i didn't mention - there is a lot of test fixes
> going to be commited, they should be merged into release branches too.
Test fixes are definitely not critical bugs. So I would prefer handling
them as usual fixes.
--
Stanislav Malyshev, Software Architect
SugarCRM:
Hi!
> Scroll down a bit; he gets into valid points about the == operator,
> for instance. It's not a useless post. He does cite too many things
> that he has to follow up himself by saying "this was fixed in PHP
> 5.x.y." If it was fixed, why is it on your laundry list still?
What exactly valid p
Hi!
> On another area, we cruelly need:
>
> http://nebm.ist.utl.pt/~glopes/misc/lf_phpt
>
> applied to all branches, incl. 5.3.11/5.4.1.
I'm not sure I understand what is that and why we can't release 5.4.1
without it? I see a list of files in that link - what are these files,
what is supposed
Hi!
> They are critical as they break BC with previous versions. The
> breakages are introduced with the previous security fix. Please merge
> it.
Could you please describe what exactly was broken?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 22
Hi!
> today I read this post, I think that some points are valid, follow the link
> for
> you guys
>
Could you name a few and explain why you think they are valid and what
you propose to do to fix them? This article is huge and if you want to
start a discussion that makes sense (as opposed to a
Hi!
> This fixes should be merged into the current 5.3.11 and 5.4.1 branches.
> The info about the changes is in the following tickets:
>
> https://bugs.php.net/bug.php?id=61565
> https://bugs.php.net/bug.php?id=61566
Are those critical bugs that break all fileinfo functionality?
--
Stanislav M
Hi!
> LFI risk is unique to PHP. The cause of risk is mandatory embedded script.
No it's not. If you write Python code that loads code from random file
and evaluates it, it will be "vulnerability in Python". If you write in
in Bash, it would be "vulnerability in bash". If you write it in C, it
wi
Hi!
> It's a design vulnerability. It is not has to be attack-able security hole
> without broken code. There are many security issues and countermeasure
> like this. e.g. register globals in PHP, stack smashing attack in C, etc.
It's not stack smashing. It's like saying because you can call exte
Hi!
> I would like to see clarity on when fixes have been merged to the RC
> branch (git emails are still a bit hard to grok). It would help to
> have early communication about fixes you have decided against so we
> can argue their merits and so we don't assume you are planning to pick
> them up.
Hi!
> My concern is that merge conflicts can occur when cherry-picking in this
> manner. It's just generally not a "best practices" approach when using
Which merge conflicts? Diff between 5.4 and 5.4.X will never be big
enough to have any conflicts. It's just 2 weeks of stable version code.
> c
Hi!
> release candidates. I mean, we're still planning on having multiple
> release candidates before an actual release, right? If so, then
Not if we can avoid it. If we don't have critical bugs in RC1, we
release it.
> obviously we'll need a way to commit those changes. If they're not made
>
Hi!
> version of a "Release-x.xx" branch. I would suggest allowing commits on
> that branch, but *only* if they're bugfixes or minor housekeeping. Each
I don't want to do this, because this would very quickly lead us back to
old chaotic situation where people commit stuff at the last moment and
Hi!
> 1. Find FLI vulnerable application.
> 2. Find a way to inject $_SESSION
> 3. Use session file to execute arbitrary PHP code.
So, you assume you have broken application with no security AND it
allows you to inject arbitrary data in the session (which probably means
broken authorization too)
Hi!
>> I'm not sure I follow - which PHP vulnerability you are talking about?
>
> Local file includes. (LFI)
I'm not sure I understand - where's the vulnerability?
> There is a null byte protection for LFI and I really like to the protection.
> It's also beneficial to other problems. However, i
901 - 1000 of 1808 matches
Mail list logo
