[PHP-DEV] PROPOSAL: sapi/cli/php -M (similar to gcc -M)
I have recenlty posted on this topic but got no response, probably because
I didn't phrase it well.
I would like to implement this proposed feature if I can get some feedback
to know if it would be accepted for inclusion.
Here is the proposal:
* Add a '-M' option to sapi/cli/php that would behave essentially the same
as gcc -M and enable the use of php command-line scripts to work properly
in a makefile build environment (See below for explanation of gcc -M).
* 'php -M -f myFile.php' should differ from 'gcc -M myFile.c', in two ways:
a) Command output should only list prerequisite files rather than
a complete dependency makefile rule since there is no standard suffix for
php output as for C [ myFile.o : myFile.c ... ]
b) Detect dependencies other than included and required files, as
reported by get_included_files(). There are many other ways that a PHP
script could become dependent on other files which cannot easily be
determined automatically unless a function is available for a script to
explicitly declare that it depends on an external file. [Example: ? if
(file_exists($myFile)) echo hello;?].
* Add two built-in PHP functions to allow '-M' option to accurately
identify file dependencies in PHP source files (the names could change):
void register_prerequisite_file( string $myFile )
Array get_prerequisite_files( )
* With the above two functions, this is how the system should work:
In the following example, /usr/local/bin/php-cli is the command-line
version of PHP: sapi/cli/php
- file: test.php
#!/usr/local/bin/php-cli
?
php include( myIncludedFile.php );
register_prerequisite_file( myRequiredFile)
if (file_exists( myRequiredFile )) echo got file;
?
eof
Internally php-cli -M would call get_included_files() and
get_prerequisite_files() and join them together in a space separated list,
with the first item being the source file. Here is what php-cli would do
from the command line:
$/usr/local/bin/php-cli -M -f test.php
test.php myIncludedFile.php myRequiredFile
---
# A makefile rule could now use these features:
$(PHP):=/usr/local/bin/php-cli
define phpDependencies
$(shell $(PHP) -M -f $(1))
endef
myFile.html : $(call phpDependencies,myFile.php)
$(PHP) -f $ $@ || { echo failed; cat $@; exit 1; }
# end of makefile
-- APPENDIX - For those unfamiliar with gcc -M, following if
from info gcc
`-M'
Tell the preprocessor to output a rule suitable for `make'
describing the dependencies of each object file. For each source
file, the preprocessor outputs one `make'-rule whose target is the
object file name for that source file and whose dependencies are
all the `#include' header files it uses. This rule may be a
single line or may be continued with `\'-newline if it is long.
The list of rules is printed on standard output instead of the
preprocessed C program.
`-M' implies `-E'.
Another way to specify output of a `make' rule is by setting the
environment variable `DEPENDENCIES_OUTPUT' (*note Environment
Variables::.).
`-E'
Run only the C preprocessor. Preprocess all the C source files
specified and output the results to standard output or to the
specified output file.
- Greg Keraunen
http://www.xmake.org
http://www.xmlmake.com
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PROPOSAL: default value handling
Ok, this was my mistake in missing the Ternary operator enhancement for fluent code (http://marc.theaimsgroup.com/?t=9622016834r=1w=2) discussion thread from last year in the archives. It was not my intention to reopen a dead thread. I did make best effort to do prior research in the archives though. Nyk On Saturday, January 11, 2003, at 12:20 PM, Andi Gutmans wrote: This has been discussed in the past and won't be done. PHP behaves like C where the result of the boolean or operation is true or false. Andi At 12:38 AM 1/11/2003 -0500, Nyk Cowham wrote: As a convert from Perl one of the 'features' I miss from Perl is the short-circuit behavior of the or operand (||) and how it can be used to set default values if a passed value is false (0 or ). Thus, in a passed parameter you can write: $result = $value || $default; In perl if the $value variable is false (0 or empty string) then $value will be set to the default value. In PHP the or operand does not short-circuit in this way. Instead I find myself having to write something like: $result = ($_REQUEST['value']) ? $_REQUEST['value'] : 'my default value'; This is not only ugly and difficult to read but has the redundancy of naming the $_REQUEST['value'] variable twice. Another nice feature of using Perl's short-circuit or operand is that defaults can be chained so: $result = $value || $alt_value || $default; Will return the default only if $value and $alt_value have both evaluated as false. In other words the first expression that evaluates as true (actually 'not false' would be more accurate) will be returned, all preceding and subsequent values will be ignored. I don't propose the || operant in PHP should be short-circuited like Perl, but rather either a new operand or new function be added that would have this specific behavior. As an operand it might look like: $result = $value ?: $alt_value ?: [ ...] ?: $default; // reusing the terniary operator in this context would be a reasonable mnemonic. Alternatively if implemented as a function it might look like: $result = choose($value, $alt_value, [ ... ], $default); I would be happy to volunteer to do the work to provide this feature if there is enough support for it's inclusion. Thoughts? Nyk Cowham -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PROPOSAL: unless control structure
My apologies if this has been brought up before, but I searched the
archives and couldn't find a reference to it.
I'm sure this is the sort of thing that would have already been
implemented if there was any desire for it among the developers, but I
was wondering if anyone had considered adding support for an unless
control structure, similar to the one Perl has. I personally find it
much more logical in certain cases. For example, compare this:
if (!$user-isAdministrator) {
header('Location: ...');
exit;
}
With this:
unless ($user-isAdministrator) {
header('Location: ...');
exit;
}
I think the second one is much easier to read. I strive to write code
that is self-documenting, so I tend to pick variable names and
function names that are pretty self explanatory. I think an unless
control structure would go a long way to helping people write
self-documenting code.
Just a thought, sorry if this is not the proper forum for this sort of
thing.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PROPOSAL: unless control structure
On Sun, Jan 12, 2003 at 12:53:12PM -0600, Michael Sims wrote: My apologies if this has been brought up before, but I searched the archives and couldn't find a reference to it. I'm sure this is the sort of thing that would have already been implemented if there was any desire for it among the developers, but I was wondering if anyone had considered adding support for an unless control structure, similar to the one Perl has. I personally find it much more logical in certain cases. While it would no doubt be easy to implement, I would consider it unnecessary syntactic sugar. Besides, it actually ends up using _more_ characters (unless(:7, if(!:4) in the long run. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PROPOSAL: 'unless' control structure
On Sun, 2003-01-12 at 20:47, Sara Golemon wrote:
[...]
This has been discussed (recently in fact) and won't be done. However,
you *can* give your code the type of readability you're looking for with:
($condition) || {
/* This will only run if $condition evals to false */
}
Nope, that gives me a parse error:
thekid@friebes:~ echo '? function unless($c) { return $c; } $c=
FALSE; unless($c) || print(!condition\n); ?' | php -q
!condition
thekid@friebes:~ echo '? function unless($c) { return $c; } $c=
FALSE; unless($c) || { print(!condition\n); } ?' | php -q
Parse error: parse error in - on line 1
It'll work for exactly one statement (e.g. mysql_connect() or die()),
but not with blocks (mysql_connect() or { mail(...); die(); })).
--
Timm Friebe [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PROPOSAL: default value handling
This has been discussed in the past and won't be done. PHP behaves like C where the result of the boolean or operation is true or false. Andi At 12:38 AM 1/11/2003 -0500, Nyk Cowham wrote: As a convert from Perl one of the 'features' I miss from Perl is the short-circuit behavior of the or operand (||) and how it can be used to set default values if a passed value is false (0 or ). Thus, in a passed parameter you can write: $result = $value || $default; In perl if the $value variable is false (0 or empty string) then $value will be set to the default value. In PHP the or operand does not short-circuit in this way. Instead I find myself having to write something like: $result = ($_REQUEST['value']) ? $_REQUEST['value'] : 'my default value'; This is not only ugly and difficult to read but has the redundancy of naming the $_REQUEST['value'] variable twice. Another nice feature of using Perl's short-circuit or operand is that defaults can be chained so: $result = $value || $alt_value || $default; Will return the default only if $value and $alt_value have both evaluated as false. In other words the first expression that evaluates as true (actually 'not false' would be more accurate) will be returned, all preceding and subsequent values will be ignored. I don't propose the || operant in PHP should be short-circuited like Perl, but rather either a new operand or new function be added that would have this specific behavior. As an operand it might look like: $result = $value ?: $alt_value ?: [ ...] ?: $default; // reusing the terniary operator in this context would be a reasonable mnemonic. Alternatively if implemented as a function it might look like: $result = choose($value, $alt_value, [ ... ], $default); I would be happy to volunteer to do the work to provide this feature if there is enough support for it's inclusion. Thoughts? Nyk Cowham -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PROPOSAL: default value handling
As a convert from Perl one of the 'features' I miss from Perl is the short-circuit behavior of the or operand (||) and how it can be used to set default values if a passed value is false (0 or ). Thus, in a passed parameter you can write: $result = $value || $default; In perl if the $value variable is false (0 or empty string) then $value will be set to the default value. In PHP the or operand does not short-circuit in this way. Instead I find myself having to write something like: $result = ($_REQUEST['value']) ? $_REQUEST['value'] : 'my default value'; This is not only ugly and difficult to read but has the redundancy of naming the $_REQUEST['value'] variable twice. Another nice feature of using Perl's short-circuit or operand is that defaults can be chained so: $result = $value || $alt_value || $default; Will return the default only if $value and $alt_value have both evaluated as false. In other words the first expression that evaluates as true (actually 'not false' would be more accurate) will be returned, all preceding and subsequent values will be ignored. I don't propose the || operant in PHP should be short-circuited like Perl, but rather either a new operand or new function be added that would have this specific behavior. As an operand it might look like: $result = $value ?: $alt_value ?: [ ...] ?: $default; // reusing the terniary operator in this context would be a reasonable mnemonic. Alternatively if implemented as a function it might look like: $result = choose($value, $alt_value, [ ... ], $default); I would be happy to volunteer to do the work to provide this feature if there is enough support for it's inclusion. Thoughts? Nyk Cowham -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Proposal for extending gettype()
Hi, I am curious what's is the opinion of the devs about adding new additional parameter to gettype which won't be compulsory. Using it instead of returning a string the function will return an int which. As an addition new consts will be registered - something like IS_STRING, IS_LONG and so on. The reason for that there won't be a need of using long if - elseif (the types in php are not 2 or 3) but a single switch(). Ilia suggested the use of a hash which can be indexed by the values which are returned from gettype() now. So what's your opinion. Andrey -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Proposal for naming tests
Hello, to make easier maintenance and checking possible I would suggest to name our tests more appropriate: Class: Name: Example: Tests for bugs bugbugid.phptbug17123.phpt Tests for functions functionname.phptdba_open.phpt General tests for extensions extnameno.phpt dba3.phpt I do not see a real use to rename tests, but IMO this is the way to go for newly written tests. Of course renaming tests is ok too if you like to do that :) regards, Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions http://www.jdimedia.nl/ --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for naming tests
+1 Moriyoshi Derick Rethans [EMAIL PROTECTED] wrote: Hello, to make easier maintenance and checking possible I would suggest to name our tests more appropriate: Class: Name: Example: Tests for bugs bugbugid.phptbug17123.phpt Tests for functions functionname.phptdba_open.phpt General tests for extensions extnameno.phpt dba3.phpt I do not see a real use to rename tests, but IMO this is the way to go for newly written tests. Of course renaming tests is ok too if you like to do that :) regards, Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions http://www.jdimedia.nl/ --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for naming tests
On Fri, Oct 25, 2002 at 11:57:34AM +0200, Derick Rethans wrote: to make easier maintenance and checking possible I would suggest to name our tests more appropriate: Class: Name: Example: Tests for bugs bugbugid.phptbug17123.phpt Tests for functions functionname.phptdba_open.phpt General tests for extensions extnameno.phpt dba3.phpt +1 Sander -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Proposal! Destructor notification
Some know I'm working to improve swig-php to make module generation easy and satisfying. The final hurdle remains in handling and generating callbacks from the module to PHP. Or rather from the library the module wraps to PHP. This requires some kind of callback wrapper that can convert from a flat function pointer the library expects to a complete object-method (or just function) reference that call_user_function expects. This problem is solved but it requires some per-callback-function allocation to hold this extra data. The new problem is that swig can't tell when the scope of the callback closes (when no more callbacks will occur) and when it can free this structure, so for longer lived scripts which make new objects often to handle callbacks we allocate and do not free ever more and more structures. If a module could request notification when all/specific objects are destroyed it would be able to free these structures when the object dies and thus avoid long term memory leaks. Are PHP developers willing to provide a mechanism where more than one module can request notification when objects generally, or specific objects are destroyed? Sam -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
On Wed, 2002-04-10 at 22:58, Andi Gutmans wrote:
I still prefer to keep PHP a relatively easy to learn, simple yet powerful
language.
I think this is a huge overkill and prefer going with something like I
proposed.
Anyway the inheritance debates have been going on for years and I doubt
we'll solve all possible scenarios for the first time in programming
language history. Also historically the languages which do try and solve
lots of scenarios end up having extremely complex mechanisms to do so.
I'll sum up my proposal again.
Support the following:
class MyClass extends MyParent aggregates Timer, FooBar
{
}
$obj = new MyClass; // Creates $obj-Timer and $obj-FooBar
$obj-method(); // Searches MyClass, MyParent if not found tries to call
the method on $obj-Timer followed by $obj-FooBar
In my head there was always a method_name = object hash in the
aggregating object, but then you can't deal with an aggregated object
aggregating another object. Search every time it must be.
If you want to access an aggregated object directly you can do:
$obj-Timer-method();
Actually, even if class != type in PHP, I think Wez's suggestion is a
better way of expressing this:
($obj as Timer)-method();
However, your $obj-Timer-method() can be implemented with overloading,
so it would make the implementation less complex.
There's one important thing missing in your suggestion though: the
runtime aggregate() function. We also need aggregate_info($this) for
listing aggregated classes, deaggregate($this, class) and
serialization support (you mentioned that didn't you?)
Some issues I thought of that need to be resolved:
* Which methods should be skipped? IMHO it makes sense to skip
ZE1-style constructors and methods starting with at least one
underscore. Those starting with two underscores are reserved, while it
is common practice to use one underscore for declaring a method as
private.
* Should it be possible to have multi-level aggregation?
class a aggregates b {}
class b aggregates c {}
class c { function foo() {} }
$a = new a;
$a-foo();
IMHO, the only sensible thing would be for this to call c::foo(), or
else objects would get different interfaces in different contexts.
* Dealing with possible loops:
class a aggregates b {}
class b aggregates a {}
$a = new a;
$a-unknown_method();
Should it be illegal to loop-aggregate classes, or should it be
detected at runtime? I'm not sure.
- Stig
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
At 00:12 12/04/2002 +0200, Stig S. Bakken wrote:
* Dealing with possible loops:
class a aggregates b {}
class b aggregates a {}
$a = new a;
$a-unknown_method();
Should it be illegal to loop-aggregate classes, or should it be
detected at runtime? I'm not sure.
It can't really be detected but it's the same as doing:
class foo {
function foo()
{
$this-bar = new foo();
}
}
There are lots of ways of shooting yourself in the foot. Simple recursion
will do the trick too.
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
On Fri, 2002-04-12 at 00:42, Andi Gutmans wrote:
At 00:12 12/04/2002 +0200, Stig S. Bakken wrote:
* Dealing with possible loops:
class a aggregates b {}
class b aggregates a {}
$a = new a;
$a-unknown_method();
Should it be illegal to loop-aggregate classes, or should it be
detected at runtime? I'm not sure.
It can't really be detected but it's the same as doing:
class foo {
function foo()
{
$this-bar = new foo();
}
}
There are lots of ways of shooting yourself in the foot. Simple recursion
will do the trick too.
Fair enough. :-)
- Stig
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Proposal for aggregation vs. MI
Hey guys,
I still haven't finished reading the looong thread on aggregation vs.
MI because you guys write so much :)
I would like to make a proposal for a solution which I think would fit PHP
very nicely.
My main concern with MI is that there are many problems with it including
namespace clashes and other problems most of you are probably familiar
with. I think trying to work around and find solutions for all of these
would make a PHP implementation of MI extremely hard to use and would move
away from the spirit of PHP which is powerful simplicity.
What I have in mind is something similar to aggregation (in the original
C++ sense which means a has a relationship) but improve it with an
auto-proxy mechanism.
Basically what I'd like to have is something like:
class a aggregates b, c {
...
}
What would happen is that 'a' will hold an instance of 'b' and an instance
of 'c' like the old historic meaning of aggregation.
However, when a method is called on 'a' and is not found we would
automatically proxy the method call to these instances (in the order of
their aggregation) and call the first existing one.
The plus is that you get something very similar to MI without having to
deal with namespace clashes such as problems when b and c have the same
variable name. Each object lives on its own but you get a central object
which reflects the interfaces of all three objects.
This is a very elegant and simple IMO. It should answer most needs.
I hope I explained it well. Let me know if you have any questions.
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
--- Andi Gutmans [EMAIL PROTECTED] wrote:
Hey guys,
I still haven't finished reading the looong thread on aggregation vs.
MI because you guys write so much :)
I would like to make a proposal for a solution which I think would fit PHP
very nicely.
My main concern with MI is that there are many problems with it including
namespace clashes and other problems most of you are probably familiar
with. I think trying to work around and find solutions for all of these
would make a PHP implementation of MI extremely hard to use and would move
away from the spirit of PHP which is powerful simplicity.
What I have in mind is something similar to aggregation (in the original
C++ sense which means a has a relationship) but improve it with an
auto-proxy mechanism.
Basically what I'd like to have is something like:
class a aggregates b, c {
...
}
I did suggest this method already.
But it really doesn't address the naming clash
class b
{
function print()
{
}
}
class c
{
function print()
{
}
}
class a aggregates b, c
{
}
$a = new A();
$a-print();
you said in the order they were aggregated. but what if i really want to call
c-print();
would i do something like this.
$a-c-print();
and how does this consern serilization. Would it need to be change do designate
which objects are aggregated?
- Brad
What would happen is that 'a' will hold an instance of 'b' and an instance
of 'c' like the old historic meaning of aggregation.
However, when a method is called on 'a' and is not found we would
automatically proxy the method call to these instances (in the order of
their aggregation) and call the first existing one.
The plus is that you get something very similar to MI without having to
deal with namespace clashes such as problems when b and c have the same
variable name. Each object lives on its own but you get a central object
which reflects the interfaces of all three objects.
This is a very elegant and simple IMO. It should answer most needs.
I hope I explained it well. Let me know if you have any questions.
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
At 12:46 10/04/2002 -0700, brad lafountain wrote:
--- Andi Gutmans [EMAIL PROTECTED] wrote:
Hey guys,
I still haven't finished reading the looong thread on aggregation vs.
MI because you guys write so much :)
I would like to make a proposal for a solution which I think would fit PHP
very nicely.
My main concern with MI is that there are many problems with it including
namespace clashes and other problems most of you are probably familiar
with. I think trying to work around and find solutions for all of these
would make a PHP implementation of MI extremely hard to use and would move
away from the spirit of PHP which is powerful simplicity.
What I have in mind is something similar to aggregation (in the original
C++ sense which means a has a relationship) but improve it with an
auto-proxy mechanism.
Basically what I'd like to have is something like:
class a aggregates b, c {
...
}
I did suggest this method already.
Told you I didn't read all Emails :)
But it really doesn't address the naming clash
class b
{
function print()
{
}
}
class c
{
function print()
{
}
}
class a aggregates b, c
{
}
$a = new A();
$a-print();
you said in the order they were aggregated. but what if i really want to call
c-print();
would i do something like this.
$a-c-print();
I was thinking that we could have an explicit way of calling the right one.
I do think that this by far the best solution because as I said it's
extremely simple and it doesn't get us into most of the deep issues the
other solutions get us into.
I think in real life coding it will work extremely well. For each proposal
you can find problems.
and how does this consern serilization. Would it need to be change do
designate
which objects are aggregated?
Each object would know which objects it aggregates so I don't see a real
big problem here. I guess potentially there are always problems when
serializing nested objects.
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
--- Andi Gutmans [EMAIL PROTECTED] wrote:
At 12:46 10/04/2002 -0700, brad lafountain wrote:
--- Andi Gutmans [EMAIL PROTECTED] wrote:
Hey guys,
I still haven't finished reading the looong thread on aggregation vs.
MI because you guys write so much :)
I would like to make a proposal for a solution which I think would fit
PHP
very nicely.
My main concern with MI is that there are many problems with it including
namespace clashes and other problems most of you are probably familiar
with. I think trying to work around and find solutions for all of these
would make a PHP implementation of MI extremely hard to use and would
move
away from the spirit of PHP which is powerful simplicity.
What I have in mind is something similar to aggregation (in the original
C++ sense which means a has a relationship) but improve it with an
auto-proxy mechanism.
Basically what I'd like to have is something like:
class a aggregates b, c {
...
}
I did suggest this method already.
Told you I didn't read all Emails :)
:)
But it really doesn't address the naming clash
class b
{
function print()
{
}
}
class c
{
function print()
{
}
}
class a aggregates b, c
{
}
$a = new A();
$a-print();
you said in the order they were aggregated. but what if i really want to
call
c-print();
would i do something like this.
$a-c-print();
I was thinking that we could have an explicit way of calling the right one.
hmm what would this look like?
$a-c::print();
i guess that's not that bad. and its kinda consistant
but i do like
$a-c-print();
too..
and would we treat member of b and c the same way
$a-member_of_c = false;
then the collision again
$a-same_name_var = false;
$a-c::same_name_var = false;
$a-b::same_name_var = false;
or
$a-c-same_name_var = false;
$a-b-same_name_var = false;
I do think that this by far the best solution because as I said it's
extremely simple and it doesn't get us into most of the deep issues the
other solutions get us into.
I think in real life coding it will work extremely well. For each proposal
you can find problems.
and how does this consern serilization. Would it need to be change do
designate
which objects are aggregated?
Each object would know which objects it aggregates so I don't see a real
big problem here. I guess potentially there are always problems when
serializing nested objects.
I wasn't thinking it would be a problem but the serialization could would need
to change to handle this type of change.
BTW:
Have you looked at my patch to handle method calls differently?
- Brad
__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
At 12:46 10/04/2002 -0700, brad lafountain wrote:
--- Andi Gutmans [EMAIL PROTECTED] wrote:
Hey guys,
I still haven't finished reading the looong thread on aggregation vs.
MI because you guys write so much :)
I would like to make a proposal for a solution which I think would fit PHP
very nicely.
My main concern with MI is that there are many problems with it including
namespace clashes and other problems most of you are probably familiar
with. I think trying to work around and find solutions for all of these
would make a PHP implementation of MI extremely hard to use and would move
away from the spirit of PHP which is powerful simplicity.
What I have in mind is something similar to aggregation (in the original
C++ sense which means a has a relationship) but improve it with an
auto-proxy mechanism.
Basically what I'd like to have is something like:
class a aggregates b, c {
...
}
I did suggest this method already.
But it really doesn't address the naming clash
class b
{
function print()
{
}
}
class c
{
function print()
{
}
}
class a aggregates b, c
{
}
$a = new A();
$a-print();
you said in the order they were aggregated. but what if i really want to call
c-print();
would i do something like this.
$a-c-print();
By the way, the aggregating class could also define it's own proxy
a_print() and c_print() methods.
I don't think it's very important because it will usually not happen and is
easy to solve if it happens.
With MI this kind of stuff stinks too.
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
BTW:
Have you looked at my patch to handle method calls differently?
Yes and I don't like it. I haven't had time to do timings yet. I was very
busy and will try and do it in the next few days.
hmm
The patch wasn't just for speed it was more for sloving 2 main problems.
class a
{
function foo();
function foo();
}
and for sloving
class blah extends Java (and other 'c' overloaded classes);
the speed was just a added bonus.
- Brad
__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
At 13:07 10/04/2002 -0700, brad lafountain wrote:
--- Andi Gutmans [EMAIL PROTECTED] wrote:
At 12:46 10/04/2002 -0700, brad lafountain wrote:
--- Andi Gutmans [EMAIL PROTECTED] wrote:
Hey guys,
I still haven't finished reading the looong thread on
aggregation vs.
MI because you guys write so much :)
I would like to make a proposal for a solution which I think would fit
PHP
very nicely.
My main concern with MI is that there are many problems with it
including
namespace clashes and other problems most of you are probably familiar
with. I think trying to work around and find solutions for all of these
would make a PHP implementation of MI extremely hard to use and would
move
away from the spirit of PHP which is powerful simplicity.
What I have in mind is something similar to aggregation (in the
original
C++ sense which means a has a relationship) but improve it with an
auto-proxy mechanism.
Basically what I'd like to have is something like:
class a aggregates b, c {
...
}
I did suggest this method already.
Told you I didn't read all Emails :)
:)
But it really doesn't address the naming clash
class b
{
function print()
{
}
}
class c
{
function print()
{
}
}
class a aggregates b, c
{
}
$a = new A();
$a-print();
you said in the order they were aggregated. but what if i really want to
call
c-print();
would i do something like this.
$a-c-print();
I was thinking that we could have an explicit way of calling the right
one.
hmm what would this look like?
$a-c::print();
i guess that's not that bad. and its kinda consistant
but i do like
$a-c-print();
too..
and would we treat member of b and c the same way
$a-member_of_c = false;
then the collision again
$a-same_name_var = false;
$a-c::same_name_var = false;
$a-b::same_name_var = false;
or
$a-c-same_name_var = false;
$a-b-same_name_var = false;
I do think that this by far the best solution because as I said it's
extremely simple and it doesn't get us into most of the deep issues the
other solutions get us into.
I think in real life coding it will work extremely well. For each proposal
you can find problems.
and how does this consern serilization. Would it need to be change do
designate
which objects are aggregated?
Each object would know which objects it aggregates so I don't see a real
big problem here. I guess potentially there are always problems when
serializing nested objects.
I wasn't thinking it would be a problem but the serialization could
would need
to change to handle this type of change.
Sure it needs to be changed.
BTW:
Have you looked at my patch to handle method calls differently?
Yes and I don't like it. I haven't had time to do timings yet. I was very
busy and will try and do it in the next few days.
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
some thoughts concerning member name collisions:
(i will also demonstrate a common shortcoming that i personally
consider a design flaw that exists both in C++ and in Java - it sure
would be good to avoid the same flaw in PHP - even if MI doesn't
get into ZE2, keep this in mind for the future)
simply put, the multiple interface paradigm says that a class can provide
an unlimited number of interfaces for already-existing and / or future clients
to operate on. an interface is a contract and it is preferably immutable -
once defined, it is not a good practice to change it. additions and changes
can be accommodated by creating new interfaces. this assures consistency -
you are less likely to break something that relies on a contract if it's final.
but it seems that there is one thing some language designers have overlooked:
two methods with identical signatures (identical names) may have a totally different
meaning in different interfaces, yet it should be possible to multiply implement
both of those in one class. to achieve this, the class implementation has to know
from which interface that ambiguos method was called from. as far as i know,
this is impossible to accomplish in C++ as well as in Java (correct me if i'm wrong).
let me demonstrate (C++, with virtual destructors omitted for simplicity):
// implementation of an animated athlete running,
// so that the result is both an athlete and an animation.
// note that stopping (pausing) the animation is different from
// stopping the athlete from running...
class IAnimation { // the animation interface
public:
virtual void run() = 0;
virtual void stop() = 0;
};
class IAthlete { // the athlete interface
public:
virtual void run() = 0;
virtual void stop() = 0;
};
// so far so good...
class CAthlete: public IAthlete, public IAnimation {
public:
virtual void run() { // now what?
indeed, now what? there's no way to tell which interface we were
being cast up to when run() was called... yet as long as the Virtual
Method Table mechanism is concerned, it would actually be possible
to override such ambiguos methods multiply so that they would depend
on the upcast used - in case of non-virtual multiple inheritance as in the
example above the number of VTBL's equals the number of base classes -
the VTBL of the derived class is shared with the first base class and
the rest base classes get one VTBL each. so it would be technically
possible to allow language constructs such as:
class CAthlete: public IAthlete, public IAnimation {
public:
virtual void run() {}; // shared between derived class and first base
virtual void IAnimation::run() {}; // called when upcast to second base
in case of virtual inheritance it would even be possible to differentiate
between all three possible upcasts. however, sadly, C++ does not
allow to explicitly differentiate overrides in different VTBL's. a similar
equivalent seems to be missing from Java, too, if i'm not horribly mistaken...
the effect of this flaw is that developers have to keep track on interface
method names of all interfaces concurrently and manually avoid conflicts.
this is, of course, a big heavy rock on shoulders. all of this also applies
when multiply inheriting implementation, but i chose interfaces so that
my example would make sense in Java.
in PHP we would, of course, only find use for inheriting implementations,
not interfaces. i suggest the following syntax for resolving ambiguities:
class A {
function foo() {}
}
class B {
function foo() {}
}
class MI extends A, B {
function foo() {} // *must* exist, throw compiler fatal otherwise
function A::foo() {} // may exist, up to the programmer
function B::foo() {} // may exist, up to the programmer
}
$mi = new MI();
$a = (A)$mi; // explicit upcast
$b = (B)$mi; // explicit upcast
$mi-foo(); // calls MI::foo()
$a-foo(); // calls MI::A::foo() if exists, MI::foo() otherwise
$b-foo(); // calls MI::B::foo() if exists, MI::foo() otherwise
since all objects are passed by reference in ZE2, this would
work as expected, that is, quite reasonably well. but what if
someone inherits from MI? let me list the possibilities:
class X extends MI {
function foo() {}
function MI::foo() {}
function MI::A::foo() {}
function MI::B::foo() {}
}
anybody can see that this syntax would bring *polymorphism* to
a new level and open up neverbeforeseen doors in sense of code reuse.
why should we give up on MI and keep all those doors closed?
i see no harm caused by such syntax to neither compatibility with
single inheritance nor to novice / non-expert PHP programmers -
if they simply don't use features they do not comprehend then PHP
looks like plain-vanilla good-old single-inheritance PHP as they've
always known it. but for the wonderers out there, we would give
a whole new world to explore... and finally, the only certain way
to find out whether a product is successful is to put it on the market...
any comments / corrections are most welcome,
lauri
Re: [PHP-DEV] Proposal for aggregation vs. MI
If you want to access an aggregated object directly you can do: $obj-Timer-method(); well, that's exactly what shouldn't be done and what polymorphism is trying to eliminate... consider a huge code library which operates on an object of class Timer and that we want to reuse this library. now if we hand it an aggregated object whose method() points to the wrong method() we would have to search-and-replace, that is, more or less manually change all occurences of -method(); into -Timer-method(); - would you say this is feasible?? the whole idea of polymorphism is to allow both implicit reuse and implicit growth of code base. if a technique that is supposed to head towards code reuse requires a single implicit call to be manually hunt down and changed into an explicit one, then it's quite useless i'd say... having MI and casts you would simply: big_hairy_library_call( (Timer) $MI_obj ); ...and be done with it. as a bonus, you get to sleep the whole night instead of searching-and-replacing text in somebody else's library till the early morning... nothing personal, just trying to provide a scenario :) lauri -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
PHP isn't a compiled language and we aren't going to start adding casting, v-tables and so on. PHP is extremely loosely typed and doing $obj-foo calls the method foo on $obj. This also allows for things like: $blah = foo; $obj-$blah; and so on. I really think that people who are looking for strict typing, v-tables, and so on should be looking at languages such as Java, C# and C++. (Although each one of these also has their quirks). Sorry to be so blunt but I don't want to see PHP changed into yet another hard to use strongly typed compiled language. I want to keep its spirit. Andi At 00:25 11/04/2002 +0300, Lauri Liinat wrote: If you want to access an aggregated object directly you can do: $obj-Timer-method(); well, that's exactly what shouldn't be done and what polymorphism is trying to eliminate... consider a huge code library which operates on an object of class Timer and that we want to reuse this library. now if we hand it an aggregated object whose method() points to the wrong method() we would have to search-and-replace, that is, more or less manually change all occurences of -method(); into -Timer-method(); - would you say this is feasible?? the whole idea of polymorphism is to allow both implicit reuse and implicit growth of code base. if a technique that is supposed to head towards code reuse requires a single implicit call to be manually hunt down and changed into an explicit one, then it's quite useless i'd say... having MI and casts you would simply: big_hairy_library_call( (Timer) $MI_obj ); ...and be done with it. as a bonus, you get to sleep the whole night instead of searching-and-replacing text in somebody else's library till the early morning... nothing personal, just trying to provide a scenario :) lauri -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
On 10/04/02, Lauri Liinat [EMAIL PROTECTED] wrote: big_hairy_library_call( (Timer) $MI_obj ); (insert_the_name_of_your_class_here) might be tricky to implement in the ZE, but I agree with the principle, hence my suggestion for: big_hairy_library_call($MI_obj as Timer); Same thing, slightly different syntax. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
On 10/04/02, Marcus Börger [EMAIL PROTECTED] wrote: At 23:25 10.04.2002, Lauri Liinat wrote: If you want to access an aggregated object directly you can do: $obj-Timer-method(); big_hairy_library_call( (Timer) $MI_obj ); Where is the big difference (first is postfix syntax, second is prefix syntax). And as we have no typesystem we cannot use typecasting but another solution. The problem is that if $MI_obj is_a Timer, $MI_obj-Timer isn't the correct thing to do. I still think we need an as operator to perform this casting, or a has_as operator/function so that an as operator could be coded as a function. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
i'll try to answer both Marcus and Wez here: Where is the big difference (first is postfix syntax, second is prefix syntax). the difference is between whether you have to change *lots* of existing code or do exactly *one* cast in new code while you write it: $timer = (Timer) $MI_obj; library_call_1 ($timer); library_call_2 ($timer); library_call_3 ($timer); etc... what i am proposing here is that the cast would stick when object references are passed around or assigned to. the reference $var would implicitly remember the class it has been cast up to. reasonable enough? And as we have no typesystem we cannot use typecasting but another solution. no typesystem huh? we do have classes, right? so we do have a typesystem, and just because a variable's type is hidden from the programmer most of the time doesn't mean it isn't there. btw, PHP already has the (new_type)$var cast syntax - you can do $var = (int)$var for example. so we wouldn't really be adding a new construct, but rather extending an existing one. so, Wez - why would you want to introduce yet another cast operator - the as keyword? while PHP already has adopted the C-style (new_type)... operator? lauri -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
On 10/04/02, Lauri Liinat [EMAIL PROTECTED] wrote: so, Wez - why would you want to introduce yet another cast operator - the as keyword? while PHP already has adopted the C-style (new_type)... operator? Since we don't have a real type system, (type) casting doesn't actually do what you were thinking. (Look for ZEND_CAST in zend_execute.c). My thought for having a different operator from (cast) was that it avoids possible ambiguities when we have an object class and try (object)$obj. All this would do is return $obj as-is, since it is already a PHP object, and not return a class object representation of it. Likewise for the other basic type names. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for aggregation vs. MI
I was looking at other languages that are loosely typed like PHP to see how
they implemented their classes. A good example that is known by a lot of
people is Javascript. Here are some things I gathered:
Class-based object-oriented languages, such as Java and C++, are founded on
the concept of two distinct entities: classes and instances.
A prototype-based language, such as JavaScript, does not make this
distinction: it simply has objects. A prototype-based language has the
notion of a prototypical object, an object used as a template from which to
get the initial properties for a new object. Any object can specify its own
properties, either when you create it or at run time. In addition, any
object can be associated as the prototype for another object, allowing the
second object to share the first object's properties.
JavaScript implements inheritance by allowing you to associate a
prototypical object with any constructor function. So, you can create
exactly the Employee-Manager example, but you use slightly different
terminology. First you define the Employee constructor function, specifying
the name and dept properties. Next, you define the Manager constructor
function, specifying the reports property. Finally, you assign a new
Employee object as the prototype for the Manager constructor function. Then,
when you create a new Manager, it inherits the name and dept properties from
the Employee object.
function Employee () {this.name = ;this.dept = general;}
function Manager () {this.reports = [];}Manager.prototype = new
Employee;function WorkerBee () {this.projects = [];}WorkerBee.prototype
= new Employee;
In JavaScript, at run time you can add or remove properties from any object.
If you add a property to an object that is used as the prototype for a set
of objects, the objects for which it is the prototype also get the new
property.
So I was wondering if we could use that type of stuff for php, not using
functions to define classes though.
I got the info from
http://developer.netscape.com/docs/manuals/js/core/jsguide/obj2.htm#1008342
where it goes in more details.
Fab.
- Original Message -
From: Lauri Liinat [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, April 10, 2002 6:15 PM
Subject: Re: [PHP-DEV] Proposal for aggregation vs. MI
i'll try to answer both Marcus and Wez here:
Where is the big difference (first is postfix syntax, second is prefix
syntax).
the difference is between whether you have to change *lots* of existing
code
or do exactly *one* cast in new code while you write it:
$timer = (Timer) $MI_obj;
library_call_1 ($timer);
library_call_2 ($timer);
library_call_3 ($timer);
etc...
what i am proposing here is that the cast would stick when object
references are passed around or assigned to. the reference $var would
implicitly remember the class it has been cast up to. reasonable enough?
And as we have no typesystem we cannot use typecasting but another
solution.
no typesystem huh? we do have classes, right? so we do have a
typesystem, and just because a variable's type is hidden from the
programmer most of the time doesn't mean it isn't there. btw, PHP
already has the (new_type)$var cast syntax - you can do $var = (int)$var
for example. so we wouldn't really be adding a new construct, but rather
extending an existing one.
so, Wez - why would you want to introduce yet another
cast operator - the as keyword? while PHP already has
adopted the C-style (new_type)... operator?
lauri
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PROPOSAL] defense against session takeovers
The real IP address can be tracked in most cases (say, using the HTTP_X_FORWARDED header an others) but I am not really sure that we should put the logic for that in the PHP engine itself. Users can add the additional PHP code to their libraries. Anyway, you can change the session id from the PHP code itself. Still the IP of the client can change every once in a while when his DHCP lease expires ... or when they use dial-on-demand and automatic hangup as eg. provided by the linux ISDN subsystem? Do you really want client sessions to become invalid every time their ISP decides to assign them a new IP? For my system at home this could make a service unusable as it automaticly hangs up the ISDN line after 60sec without IP traffic and redials on demand (with ISDN you have connect times of 1sec, so you don't even notice you've been disconnected, but you'll notice the effect on the bill if you are charged by connection time). So my Client IP might even be different for every single request if it takes me more than a minute to read a page or fill out a form ... You got a point there. I am not arguing that this needs to be added to the engine code itself. But I do argue that site owners should at least have such a code to warn them about possible hijack attempts. It all comes to how paranoid you are. For example, a changed IP address of the client (not the proxy) can be accepted as normal, but if the USER_AGENT changes as well - now that is suspicious. Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PROPOSAL] defense against session takeovers
Ivan Ristic wrote: Also, ISPs (like AOL) who use farms of proxy caches will change a users apparent ip during a single session. (i.e. concurrent requests may come from different ips). The real IP address can be tracked in most cases (say, using the HTTP_X_FORWARDED header an others) but I am not really sure that we should put the logic for that in the PHP engine itself. Users can add the additional PHP code to their libraries. Anyway, you can change the session id from the PHP code itself. Still the IP of the client can change every once in a while when his DHCP lease expires ... or when they use dial-on-demand and automatic hangup as eg. provided by the linux ISDN subsystem? Do you really want client sessions to become invalid every time their ISP decides to assign them a new IP? For my system at home this could make a service unusable as it automaticly hangs up the ISDN line after 60sec without IP traffic and redials on demand (with ISDN you have connect times of 1sec, so you don't even notice you've been disconnected, but you'll notice the effect on the bill if you are charged by connection time). So my Client IP might even be different for every single request if it takes me more than a minute to read a page or fill out a form ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns in Halle 6 auf Ihren Besuch am Stand H 18 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re[3]: [PHP-DEV] [PROPOSAL] defense against session takeovers
Hi, But unfortunately a dedicated server does not cost much more than virtual hosting anymore (just have a look at http://powerraq.com/ ). PHP is mostly pre-installed (with dev settings and not production settings - many admins even forget to switch on safe_mode) and this lazyness leads to thousands of insecure PHP installations on production machines. Why would you switch on safe_mode if you have a dedicated server? That makes no sense. There is also nothing unsafe about the session code if you are on a dedicated server. I meant renting a dedicated server for selling virtual hosting. But because safe_mode is so terribly limiting (file uploads dont work as desired etc..) many hosters just leave it off. It's terrible, but I see it quite often. But I don't want to start again a discussion on this. Until Apache 2.0 has reached production quality, there is no standard method of making PHP secure. period. I actually got PHP scripts running as user. I applied a patch to cgiwrap (I know, patching cgiwrap or SuEXEC is no-no) but I still want to test this thoroughly as I don't have any information about stability/security. There's quite a loss of speed (more latency) because of CGI and also because for example persistent database connections are not anymore possible. But at least I can execute shell commands (such as invoking http://www.imagemagick.org/ ) without any problems. Kind Regards, Daniel Lorch -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [PROPOSAL] defense against session takeovers
How about that we use the SERVER_NAME environment variable when generating session filenames? Instead of name like sess_, the name could be sess__, where is a server fingerprint? I understand that this is not foolproof (say, for applications that run on the same domain name) but it will solve the most serious cases (shared hosting solutions). -1 for this because it destroys php functionality. it makes it impossible to have multiple domains with the same sessions f.e. www1.myserver.com www2.myserver.com news.myserver.com archive.myserver.com In order to make the above work you need to put a lot of effort. Cookies sent to www1.myserver.com will not arrive to www2.myserver.com. With the default configuration, a user visiting one server and then the other will create two different sessions. You need to manually tweak session.cookie_domain to make it work. Also, URL rewriting does not work on absolute URLs, and you would have to manually append the SID to the URL to make the session span two different domains. I am saying that with a lot of work required to make the above work, one extra configuration option will not make an impact, and it would certainly be worth the increased default security. Such people can simply override the session.save_path value, and if they do that, we can turn this additional feature off (knowing that they know what they're doing). This will secure the default configuration and yet make things work for people who want to use sessions over several domains. We can make this on by default but also allow it to be turned off it case it creates problems for someone. -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [PROPOSAL] defense against session takeovers
This will secure the default configuration and yet make things work for people who want to use sessions over several domains. But I admit that this improvement can be seen as meaningless since any user on a shared server can write a script to list all sessions in a directory and then read all files. This can be cured only by using the proper PHP engine configuration. Therefore, let us document this and leave it as is. -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] [PROPOSAL] defense against session takeovers
[PROBLEM] Sessions can easily be taken over by other, malicious users. All you need is the session-id and you're done. User who have read-access to the directory where PHP stores it's session-data, can read the ids directly from the filenames. I don't think many administrators are aware of the security risks involved in storing sessions in world-readable directories (like /tmp, which is the default by now). As you'll understand, the possibility of taking over sessions, and that way claiming to be somebody else, can be a serious security hazard. There is a workaround, but IMO, PHP should be as secure as possible without a tricky configuration. Note: this problem is only valid for filebased sessions. [WORKAROUND] A workaround is to create a directory which is only readable by the user who runs the webserver. [PROPOSAL] Instead of directly using the session-id, an alternate id which depends on the session-id and possibly some client-specific data should be used to construct a filename to store the session data. A good option would be, IMO, creating a MD5 hash of the session-id and some client-specific data, like his IP address. That MD5 hash will be the alternate id used to construct the filename to store the session data. [ADVANTAGES] No tricky configuration necessary to assure a safe session-setup. [DISADVANTAGES] There's a slight overhead involved in creating the hash to construct the filename with the session data for each request. Unfortunately my C skills and my knowlegde of PHP internals are by far not supporting to implement this. However, I would like hear any reactions on this proposal. Sander -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [PROPOSAL] defense against session takeovers
Bringing the user's ip into the mix is going to cause all sorts of hard to track down problems as many many people do not have static ips. Having a session break because their lease expires and they are assigned a new one will confuse everyone. As far as I am concerned this is a documentation issue. -Rasmus On Fri, 1 Feb 2002, Sander Roobol wrote: [PROBLEM] Sessions can easily be taken over by other, malicious users. All you need is the session-id and you're done. User who have read-access to the directory where PHP stores it's session-data, can read the ids directly from the filenames. I don't think many administrators are aware of the security risks involved in storing sessions in world-readable directories (like /tmp, which is the default by now). As you'll understand, the possibility of taking over sessions, and that way claiming to be somebody else, can be a serious security hazard. There is a workaround, but IMO, PHP should be as secure as possible without a tricky configuration. Note: this problem is only valid for filebased sessions. [WORKAROUND] A workaround is to create a directory which is only readable by the user who runs the webserver. [PROPOSAL] Instead of directly using the session-id, an alternate id which depends on the session-id and possibly some client-specific data should be used to construct a filename to store the session data. A good option would be, IMO, creating a MD5 hash of the session-id and some client-specific data, like his IP address. That MD5 hash will be the alternate id used to construct the filename to store the session data. [ADVANTAGES] No tricky configuration necessary to assure a safe session-setup. [DISADVANTAGES] There's a slight overhead involved in creating the hash to construct the filename with the session data for each request. Unfortunately my C skills and my knowlegde of PHP internals are by far not supporting to implement this. However, I would like hear any reactions on this proposal. Sander -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [PROPOSAL] defense against session takeovers
Also, ISPs (like AOL) who use farms of proxy caches will change a users apparent ip during a single session. (i.e. concurrent requests may come from different ips). George On Friday, February 1, 2002, at 11:58 AM, Rasmus Lerdorf wrote: Bringing the user's ip into the mix is going to cause all sorts of hard to track down problems as many many people do not have static ips. Having a session break because their lease expires and they are assigned a new one will confuse everyone. As far as I am concerned this is a documentation issue. -Rasmus On Fri, 1 Feb 2002, Sander Roobol wrote: [PROBLEM] Sessions can easily be taken over by other, malicious users. All you need is the session-id and you're done. User who have read-access to the directory where PHP stores it's session-data, can read the ids directly from the filenames. I don't think many administrators are aware of the security risks involved in storing sessions in world-readable directories (like /tmp, which is the default by now). As you'll understand, the possibility of taking over sessions, and that way claiming to be somebody else, can be a serious security hazard. There is a workaround, but IMO, PHP should be as secure as possible without a tricky configuration. Note: this problem is only valid for filebased sessions. [WORKAROUND] A workaround is to create a directory which is only readable by the user who runs the webserver. [PROPOSAL] Instead of directly using the session-id, an alternate id which depends on the session-id and possibly some client-specific data should be used to construct a filename to store the session data. A good option would be, IMO, creating a MD5 hash of the session-id and some client-specific data, like his IP address. That MD5 hash will be the alternate id used to construct the filename to store the session data. [ADVANTAGES] No tricky configuration necessary to assure a safe session-setup. [DISADVANTAGES] There's a slight overhead involved in creating the hash to construct the filename with the session data for each request. Unfortunately my C skills and my knowlegde of PHP internals are by far not supporting to implement this. However, I would like hear any reactions on this proposal. Sander -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: php-list- [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] // George Schlossnagle // Director of Operations // Community Connect, Inc. // 1024D/1100A5A0 1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [PROPOSAL] defense against session takeovers
Hi, i fully support rasmus, saying that we should mention the default configuration as unsafe in the documentation. Unlike Mr. Lorch or similiar people i do not think its our resposibility to configure the server for the admin. And i am a little bit tired about this whole session takeover discussion. Because in the end its our responsibility to design a secure new unsniffable protocol and develop clients and servers for it. Because THIS would be the only way to stop session takeovers. As long session IDs are transferred over http/https they are unsecure *POINT* If you want to blame someone go and bitch at Microsoft who endangers about 70% of all session-ids out there. Stefan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [PROPOSAL] defense against session takeovers
The only reason session data is stored in /tmp is that we want sessions to work out of the box and /tmp is the only place we can be semi-sure that we will have write access to. People who run large servers with multiple sites that all use sessions should of course change the session directory on a per-server basis in their httpd.conf file, or better yet, write their own session back end handler. If we shipped PHP with sessions that did not work out of the box, we would get flooded with questions here. The general philosophy of PHP has always been to make PHP easy for the beginner yet flexible enough for advanced users. This fits that rule. Give the advanced users the tools to configure PHP to have per-virtualhost session handling, while sessions still work for the guy who just installed PHP on his own little server and really doesn't know what he is doing. -Rasmus On Fri, 1 Feb 2002, Ivan Ristic wrote: Also, ISPs (like AOL) who use farms of proxy caches will change a users apparent ip during a single session. (i.e. concurrent requests may come from different ips). The real IP address can be tracked in most cases (say, using the HTTP_X_FORWARDED header an others) but I am not really sure that we should put the logic for that in the PHP engine itself. Users can add the additional PHP code to their libraries. Anyway, you can change the session id from the PHP code itself. I am more afraid of several applications (web sites) sharing the same session directory. Can a sessionid from one site be used as a sessionid for the other site residing on the same server (provided that session files are stored in the same directory)? From all the tests I've done - it can. This would allow an intruder to construct session data with any kind of variables and then switch to the other application with arbitrary privileges. ASP-s are most vulnarable here. If two instances of the same applications are running on the same server, then the administrator of one application can quite possibly become the administrator of the other... -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [PROPOSAL] defense against session takeovers
The general philosophy of PHP has always been to make PHP easy for the beginner yet flexible enough for advanced users. This fits that rule. Give the advanced users the tools to configure PHP to have per-virtualhost session handling, while sessions still work for the guy who just installed PHP on his own little server and really doesn't know what he is doing. That is fine for a philosophy. I would still like to try to make the default setup more secure. I agree, the least we can do is to document this. How about that we use the SERVER_NAME environment variable when generating session filenames? Instead of name like sess_, the name could be sess__, where is a server fingerprint? I understand that this is not foolproof (say, for applications that run on the same domain name) but it will solve the most serious cases (shared hosting solutions). -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [PROPOSAL] defense against session takeovers
That is fine for a philosophy. I would still like to try to make the default setup more secure. I agree, the least we can do is to document this. How about that we use the SERVER_NAME environment variable when generating session filenames? Instead of name like sess_, the name could be sess__, where is a server fingerprint? I understand that this is not foolproof (say, for applications that run on the same domain name) but it will solve the most serious cases (shared hosting solutions). I really do think that someone setting up shared hosting should be clueful enough to configure things themselves or they probably shouldn't be in the business. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [PROPOSAL] defense against session takeovers
How about that we use the SERVER_NAME environment variable when generating session filenames? Instead of name like sess_, the name could be sess__, where is a server fingerprint? I understand that this is not foolproof (say, for applications that run on the same domain name) but it will solve the most serious cases (shared hosting solutions). -1 for this because it destroys php functionality. it makes it impossible to have multiple domains with the same sessions f.e. www1.myserver.com www2.myserver.com news.myserver.com archive.myserver.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re[2]: [PHP-DEV] [PROPOSAL] defense against session takeovers
Hi, This topic was already discussed in bugtraq and there should also be an entry in the PHP bug database about this: http://www.securityfocus.com/archive/1/250196 http://www.securityfocus.com/archive/1/250593 i fully support rasmus, saying that we should mention the default configuration as unsafe in the documentation. I absolutely agree with you. I would even suggest to set engine = Off by default which forces admins to at least have a quick look at php.ini. But unfortunately a dedicated server does not cost much more than virtual hosting anymore (just have a look at http://powerraq.com/ ). PHP is mostly pre-installed (with dev settings and not production settings - many admins even forget to switch on safe_mode) and this lazyness leads to thousands of insecure PHP installations on production machines. Yes, there are many idiots who call themselves admins (cobalt's servers have a graphical user interface, so you never get in touch with the underlying software), but in the end these people could spoil PHP's reputation and *that's* what I'm worrying about. Unlike Mr. Lorch [..] Daniel is ok :) I really don't know why people call me Mr. Maybe add my family name, otherwise I might get taken for Daniel Beulshausen (php4win.de). [..] or similiar people i do not think its our resposibility to configure the server for the admin. And i am a little bit tired about this whole session takeover discussion. Because in the end its our responsibility to design a secure new unsniffable protocol and develop clients and servers for it. Because THIS would be the only way to stop session takeovers. As long session IDs are transferred over http/https they are unsecure *POINT* HTTPS is just a component of the whole end product - PHP is another component and from a modular point of view, each component has to take any possible precautions to ensure maximum security. Kind Regards, Daniel Lorch -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re[2]: [PHP-DEV] [PROPOSAL] defense against session takeovers
But unfortunately a dedicated server does not cost much more than virtual hosting anymore (just have a look at http://powerraq.com/ ). PHP is mostly pre-installed (with dev settings and not production settings - many admins even forget to switch on safe_mode) and this lazyness leads to thousands of insecure PHP installations on production machines. Why would you switch on safe_mode if you have a dedicated server? That makes no sense. There is also nothing unsafe about the session code if you are on a dedicated server. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: Re[2]: [PHP-DEV] [PROPOSAL] defense against session takeovers
Why would you switch on safe_mode if you have a dedicated server? That makes no sense. It can be useful to minimise the damage in case someone finds a hole in your PHP scripts, and the hole allows them to access files on the server. -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [PROPOSAL] defense against session takeovers
based on something nasty i did with cookies a while back Session id [][bb] eg. first 32? chars are the standard md5, the remainder is a variable length key. aaa - the standard session id. (eg. the filename) bbb - an simple key overlay say the session file contains 'abcd' and b contains 0au2dr then the resulting sessoin file would contain : char 1 = (a + 0) mod 256 char 2 = (b + a) mod 256 char 3 = (c + u) mod 256 and so on. -- to decrept you obvious overlay the negative with modulus.. its an incredibly dumb and simple encryption method.. - but it may solve alot of the concerns... - eg. without the full session id, you cant use the session file. or guess the full session file.. anyway its early morning so I probably missed something.. - it doesnt make it impossible - just alot more difficult... regards alan Ivan Ristic wrote: The general philosophy of PHP has always been to make PHP easy for the beginner yet flexible enough for advanced users. This fits that rule. Give the advanced users the tools to configure PHP to have per-virtualhost session handling, while sessions still work for the guy who just installed PHP on his own little server and really doesn't know what he is doing. That is fine for a philosophy. I would still like to try to make the default setup more secure. I agree, the least we can do is to document this. How about that we use the SERVER_NAME environment variable when generating session filenames? Instead of name like sess_, the name could be sess__, where is a server fingerprint? I understand that this is not foolproof (say, for applications that run on the same domain name) but it will solve the most serious cases (shared hosting solutions). -- Ivan Ristic, [EMAIL PROTECTED] [ Weblog on PHP, Software development, Intranets, and Knowledge Management: http://www.webkreator.com ] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [PROPOSAL] Error levels
On Wed, Dec 12, 2001 at 04:58:27PM +0900, Yasuo Ohgaki wrote : php_error(E_WARNING, %s expects size 0, get_active_function_name(TSRMLS_C)); I prefer %s() ... - Markus -- Please always Cc to me when replying to me on the lists. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [PROPOSAL] Error levels
Markus Fischer wrote: On Wed, Dec 12, 2001 at 04:58:27PM +0900, Yasuo Ohgaki wrote : php_error(E_WARNING, %s expects size 0, get_active_function_name(TSRMLS_C)); I prefer %s() ... It should be %s() ... :) -- Yasuo Ohgaki _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] [PROPOSAL] Error levels
Hi all.
We need consistent error levels and handling for all modules. I suppose
all of us can agree with this.
[PROBLEM]
1) Use of error levels are not consistent. Some function returns error
status, yet displays/raises warning message for non faital errors. Other
function just returns error status. PHP is missing rather standard error
levels like E_DEBUG and E_INFO. (I understand histrical reason of this
behavior)
2) Current CODING_STANDARDS does not define use of error level.
From CODING_STANDARDS
[5] Use php_error() to report any errors/warnings during code execution.
Use descriptive error messages, and try to avoid using identical
error strings for different stages of an error. For example,
if in order to obtain a URL you have to parse the URL, connect,
and retreive the text, assuming something can go wrong at each
of these stages, don't report an error Unable to get URL
on all of them, but instead, write something like Unable
to parse URL, Unable to connect to URL server and Unable
to fetch URL text, respectively.
3) No standard for error message format.
[PROPOSAL]
1) Add new error levels E_DEBUG and E_INFO.
2) Define standard for error level usage.
E_ERROR: Fatal error that cannot continue execution.
E_WARNING: Non-fatal error that can continue execution.
This error level must be used only when there is *obvious* bug
in script. Error with this level should not be ignored for production
script. Examples are wrong number of parameters and invalid
data type for function parameter.
E_NOTICE: Non-fatal error like E_WARNING. The error would likely be a
bug in script or problem during execution. This error level may not be
ignored for production script. Examples are connection failure to
database and invalid resource passed to function.
E_DEBUG: Non-fatal error that is most likely not a bug in script, but
useful to debugging script. Errors that may be ingored safely for
production script should use E_DEBUG. Examples are stat failure for file
system funciton and use of undefined variables.
E_INFO: Informational error that is not a error or bug at all. This
error level would be useful to notify use of obsolete API, etc.
3) Error message format.
- Wrong number of paramters or wrong type
Use the same format as zend_parse_parameter() (or use
zend_parse_parameter() actually :)
- If error is not associated with module function, use module name
in error message. (i.e. MINIT, MSHUTDOWN, RINIT, RSHUTDOWN)
- For other errors, function name should be in error message using
get_active_function_name(TSRMLS_C). Programmers can assume there
is a function name in a error message, if error is raised inside a
module function.
php_error(E_WARNING, %s expects size 0,
get_active_function_name(TSRMLS_C));
[TODO]
New error levels, E_DEBUG, E_INFO, E_USER_DEBUG and E_USER_INFO are
needed. Someone must check all php_error() to confirm error level usage
standard.
[ISSUES]
Following issues need to be discussed (there may be others)
- Scripts depends on error levels/messages will have problems with
changes. Major version up is required, perhaps?
- There may be cases that are difficult to choose proper error level,
especially E_NOTICE and E_DEBUG.
- I'm not following ZE2 development closely. ZE2 might have much
better approch, is it?
- TODO-5.0 for PHP 5.0 to cleanup legacy behaviors?
- It is posssible to use #if PHP5 or #if NEW_ERROR_MSG to
keep old error level and message. Question is should we do
that or not.
- --with-all-info-msg configure option for enable E_INFO message
that shows API change info messages, etc.
Code as follows slows down PHP.
if (!strcmp(get_active_function_name(TSRMLS_C),old_function_name)) {
php_error(E_INFO,%s is obsolete function name.,
get_active_function_name(TSRMLS_C));
}
- I suppose people has better idea than me for error message format :)
If this proposal and/or new error levels are accepted, I'll volunteer to
write patch for new error levels. There are about 2300
php_error/zend_error, real hard work is fixing them, though.
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Proposal for release process (Was: Re:[PHP-DEV]4.1.0)
I think we should be realistic about what we can and cannot pull. Using this approach as the standard release process is simply not going to work - we barely manage an RC branch and a dev branch properly, and having to maintain an old release branch sync'd with bug fixes is not going to be within our reach. In very specific cases, such as the 4.1.0 - 4.2.0 change, if there are going to be some key bugs in 4.1.0, releasing a 4.1.1 based on 4.1.0 would be in order. Otherwise, though, I would say that we're only toying with a non practical idea :) Zeev At 02:36 14/11/2001, Stig S. Bakken wrote: Andi Gutmans wrote: At 12:31 AM 11/11/2001 +0100, Stig S. Bakken wrote: Andi Gutmans wrote: Jani, I think in theory what you writes makes sense but it just doesn't work in the PHP project. (I'm talking about the minor versions coming out of branches). There are always cries to go with HEAD because it's got new goodies (I think it often makes sense) and then people don't want to release a second version out of a branch but want to use HEAD. All in all the release process in the past few years hasn't been that bad. I think the timing has been good and we haven't had *that* many screw-ups. What I do think we need is a couple of people who will push things forward once everyone decides that it is time to branch and start QA; so that things don't linger. Andi, If we trim down the PHP distribution to not contain as many goodies, chances are there won't be as many cries for head (no pun intended). The distinction between the second and third digit is basically documenting to the user the level of change in a release. I didn't quite understand what you mean :) All I said was that if you create a branch say 4.1.0 and you want to release 4.1.x from that branch later on whilst HEAD has already moved a couple of months you're going to have a hard time doing it. Yes, merging bug fixes into that branch would be more difficult. But certainly possible, _if_ we identify a need for small bugfix releases. The point is that for the person having a problem with a bug in 4.1.0, upgrading to 4.2.0 may be a problem because of all the other changes. In this case, a 4.1.1 release containing only that bug fix would make a lot of sense. I've been in this situation a few times myself, and it's not funny (X is broken in 4.0.1, 4.0.2 fixes X but breaks Y). - Stig -- PHP Quality Assurance Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Proposal for release process (Was: Re:[PHP-DEV]4.1.0)
Andi Gutmans wrote: At 01:36 AM 11/14/2001 +0100, Stig S. Bakken wrote: I didn't quite understand what you mean :) All I said was that if you create a branch say 4.1.0 and you want to release 4.1.x from that branch later on whilst HEAD has already moved a couple of months you're going to have a hard time doing it. Yes, merging bug fixes into that branch would be more difficult. But certainly possible, _if_ we identify a need for small bugfix releases. The point is that for the person having a problem with a bug in 4.1.0, upgrading to 4.2.0 may be a problem because of all the other changes. In this case, a 4.1.1 release containing only that bug fix would make a lot of sense. I've been in this situation a few times myself, and it's not funny (X is broken in 4.0.1, 4.0.2 fixes X but breaks Y). Stig, I understood the point from the beginning and I have no problem in trying. I was just skeptical about how well it will work in real life. I think it will work if we can streamline the release process so it takes a couple of weeks instead not six months. This way HEAD and the release branch won't be too different when the release is out. If we also get rid of extensions, there's even fewer potential conflicts. He who lives will see. :-) I think it's definitely worth an try. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Proposal for release process (Was: Re:[PHP-DEV]4.1.0)
Andi Gutmans wrote: At 12:31 AM 11/11/2001 +0100, Stig S. Bakken wrote: Andi Gutmans wrote: Jani, I think in theory what you writes makes sense but it just doesn't work in the PHP project. (I'm talking about the minor versions coming out of branches). There are always cries to go with HEAD because it's got new goodies (I think it often makes sense) and then people don't want to release a second version out of a branch but want to use HEAD. All in all the release process in the past few years hasn't been that bad. I think the timing has been good and we haven't had *that* many screw-ups. What I do think we need is a couple of people who will push things forward once everyone decides that it is time to branch and start QA; so that things don't linger. Andi, If we trim down the PHP distribution to not contain as many goodies, chances are there won't be as many cries for head (no pun intended). The distinction between the second and third digit is basically documenting to the user the level of change in a release. I didn't quite understand what you mean :) All I said was that if you create a branch say 4.1.0 and you want to release 4.1.x from that branch later on whilst HEAD has already moved a couple of months you're going to have a hard time doing it. Yes, merging bug fixes into that branch would be more difficult. But certainly possible, _if_ we identify a need for small bugfix releases. The point is that for the person having a problem with a bug in 4.1.0, upgrading to 4.2.0 may be a problem because of all the other changes. In this case, a 4.1.1 release containing only that bug fix would make a lot of sense. I've been in this situation a few times myself, and it's not funny (X is broken in 4.0.1, 4.0.2 fixes X but breaks Y). - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Proposal for release process (Was: Re:[PHP-DEV]4.1.0)
At 01:36 AM 11/14/2001 +0100, Stig S. Bakken wrote: I didn't quite understand what you mean :) All I said was that if you create a branch say 4.1.0 and you want to release 4.1.x from that branch later on whilst HEAD has already moved a couple of months you're going to have a hard time doing it. Yes, merging bug fixes into that branch would be more difficult. But certainly possible, _if_ we identify a need for small bugfix releases. The point is that for the person having a problem with a bug in 4.1.0, upgrading to 4.2.0 may be a problem because of all the other changes. In this case, a 4.1.1 release containing only that bug fix would make a lot of sense. I've been in this situation a few times myself, and it's not funny (X is broken in 4.0.1, 4.0.2 fixes X but breaks Y). Stig, I understood the point from the beginning and I have no problem in trying. I was just skeptical about how well it will work in real life. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV]4.1.0)
At 05:28 12/11/2001, Jani Taskinen wrote: Zeev suggested at some point that we should drop the last number altogether. I *what*? Perhaps I was high on that Kossu :) I was never in favour of dropping the 3rd digit. That indeed would make the current way of doing things more correct but would not really solve anything in the user end.. Indeed. What I suggested: Only bug fixes go into the release branch. And all the nifty new features and big changes and BC breaking stuff go into the next release branch (HEAD). (ie. version 4.x+1.0 ) As I've said repeatedly, there's no reason *at all* to move from our old, de-facto standard versioning scheme to this one. The process is fine, but the following version should be a .0.1 add-up. I really fail to see why you mix the version number with what a new version may include. And, of course, it has nothing to do with the fact that once we branch a release branch, be it 4.0.7 or 6.4.2.4.6.1.2.5.4, no new features should go to it - only bug fixes. It's not very far from what we are doing right now. We have two branches, the release one and HEAD. But what I suggested was to keep the release branch and commit bug fixes into it and release bug-fix-only-releases from it. Why would it be hard time doing it? It's not hard as long as certain rules are followed. It needs a bit more work and people who are dedicated for doing it. But the core developers ([EMAIL PROTECTED]) should first ratify all this stuff. :) Jani, it's simply not going to work. New features and bug fixes are often closely interweaved. Also, *bugs* and new features are often closely interweaved. What you are suggesting is basically to step with full steam into the biggest synchronization nightmare possible. The system and rules we have right now are good. The flaw, if any, is in the amount of work that goes into bug fixing, from your point of view, which I can certainly understand. But changing the system to what you propose will not improve things - only more efforts towards bug fixing will. Not only that - it's bound to create synchronization problems from hell, things you don't even dream about when you use a simple linear development model as we do today. It has nothing to do with whether or not php-dev can live up to certain rules, or whether it should or shouldn't do so. Rules are not the problem here. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV]4.1.0)
At 05:28 AM 11/12/2001 +0200, Jani Taskinen wrote: On Sun, 11 Nov 2001, Andi Gutmans wrote: I didn't quite understand what you mean :) I didn't get it first either. :) All I said was that if you create a branch say 4.1.0 and you want to release 4.1.x from that branch later on whilst HEAD has already moved a couple of months you're going to have a hard time doing it. The idea is NOT to go on for _months_ with the HEAD. The idea is to make it shorter by keeping the amount of testing smaller. And this is what the versioning stuff was aimed at too. Most people out there think that when a version number changes on the 'micro' part (4.1.x) it means that there are only bug fixes in this release and I can safely go ahead and update without fearing that something breaks. At the moment, you can't trust on this. It's definately NOT like all the other projects do. Zeev suggested at some point that we should drop the last number altogether. That indeed would make the current way of doing things more correct but would not really solve anything in the user end.. What I suggested: Only bug fixes go into the release branch. And all the nifty new features and big changes and BC breaking stuff go into the next release branch (HEAD). (ie. version 4.x+1.0 ) It's not very far from what we are doing right now. We have two branches, the release one and HEAD. But what I suggested was to keep the release branch and commit bug fixes into it and release bug-fix-only-releases from it. We can try and do this. I'm not quite sure it'll work in real life but I think it's it's worth a try. I agree that it is not much different than today but it requires someone who will take the job of screaming at ppl if they commit a bug fix to HEAD and not to the release branch. Also at some point we have to decide not to release bug fixes anymore for a certain version but I'm quite sure it'll come naturally with the release of the next more major version. Why would it be hard time doing it? It's not hard as long as certain rules are followed. It needs a bit more work and people who are dedicated for doing it. But the core developers ([EMAIL PROTECTED]) should first ratify all this stuff. :) Oh, I forgot..rules are bad..we're all volunteers..etc. crap. Why can't we improve this? It has worked for so long now.. and that is bull too. It might have worked and might work for a while but if we really want to make the quality better, we have to make some changes. All I meant by it has worked for so long is that it's not as if the situation has been horrible. It's been pretty decent but I am all for improvement. IMO opinion we need to appoint a couple of people so that when there is a concensus to branch and start the release process they will make sure it is pushed a bit. Look at the bug database: 803 open bug reports (feature requests, doc probs and website probs excluded) of which about 70% are not bugs but user errors and such. That still leaves us with over 200 reports that are real bugs. Some of them are in extensions which have been abandoned or the people who 'maintain' them don't simply care. But this is another story. (btw. in Scripting Engine related bugs there are 69 open reports.. :) Anything interesting? :) --Jani ..who's getting pretty tired at banging head on the wall.. I think we're actually getting somewhere. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV]4.1.0)
Andi Gutmans wrote: Jani, I think in theory what you writes makes sense but it just doesn't work in the PHP project. (I'm talking about the minor versions coming out of branches). There are always cries to go with HEAD because it's got new goodies (I think it often makes sense) and then people don't want to release a second version out of a branch but want to use HEAD. All in all the release process in the past few years hasn't been that bad. I think the timing has been good and we haven't had *that* many screw-ups. What I do think we need is a couple of people who will push things forward once everyone decides that it is time to branch and start QA; so that things don't linger. Andi, If we trim down the PHP distribution to not contain as many goodies, chances are there won't be as many cries for head (no pun intended). The distinction between the second and third digit is basically documenting to the user the level of change in a release. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV] 4.1.0)
Jani Taskinen wrote: On Sat, 10 Nov 2001, Zeev Suraski wrote: Guys, We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on which 4.1.0 is currently scheduled to be based on, has branched away a few months ago. Some people have expressed concern that releasing 4.1.0 based on that branch is not a good idea, because there have been so many changes in the HEAD branch, and synchronizing fixes and so on is going to be a headache. I have a bad feeling about this branch and I vote for dropping it and starting new from HEAD. There are several reasons for this: The change between 4.0.7 - 4.1.0 (and also sudden change of the release master from Zeev to Stig) has confused some people according the discussion on php-qa list a while ago. Many of them might have tested 4.0.7 RCs but not necessarily all have tested the 4.1.0 RCs. Not to forget the 11th of September.. I have no idea who have tested the latest RC. Does anyone have? After the latest RC there have been a LOT of fixes in the release branch and also several fixes in the HEAD (which weren't MFH'd) and there hasn't been any new RCs after those fixes were committed. How many people test the branch (from CVS) ? Has anyone kept any list of the test results and problems found ? Has anyone kept eye on fixes done which weren't merged to the branch ? Answer is: We don't KNOW. The thing is that the project has grown to be so big that we can not afford long periods of time between releases. Too much stuff gets in without testing. Too many NEW bugs are introduced and like it has been said many times before, not enough people really pay attention to fixing them. Developers simply ignore them and continue adding new stuff thus creating new possible bugs. Anyone think what I think? Release early, release often http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/x147.html This works very well for Linux, why wouldn't it work for PHP ? Our QA team is very small. It has actually gotten smaller during the last 6 months instead of getting bigger like it should have. Enough ranting, let's get into fixing this situation. I can't see any solutions that won't bite us but one solution that won't bite as so badly in the _long_run_, as if we delay it or release too early we're gonna get hurt. My proposal is this: - Release the current branch as 4.1.0 but clearly state that there will be 4.2.0 soon. Also start the 4.2.0 branch from HEAD now and the QA process on it with some things kept in mind: o Any serious problems found (by our best QA team: the real users) in 4.1 we fix them in 4.2 and announce that after 4.2 release we start following the versioning rules for real. o We continue releasing 4.2.x versions out of the 4.2 branch but with ONLY bug fixes in it. And we do this OFTEN. Any new stuff goes to HEAD. We should decide what amount of fixes or with what severity triggers the (short) QA process for the 4.2.x branch. o After there have been, let's say 5 big ones in HEAD, we start new branch, 4.3 and QA process moves there. The QA should not take so long with this. Security related fixes should trigger new release process immediately. o Any changes into extensions from now on should include the start of using the version numbers in extension. Also, if there are changes in many extensions or there are big changes in some extension we make another 4.2.x release. (compromise for Zeev's sake :) o Any big changes or changes that might possibly break things should be announced on the php-qa list and only after QA has tested that the changes don't break anything, they should be allowed into CVS. - We need to have ONE place where to keep the RC packages. And we need to have also Windows build of the RCs at this same place. Having the packages in someone's home directory is not very good idea. Better place would be at http://qa.php.net/ - We name persons for each branch who work together with QA team and make sure the releases are tested properly. ie. This person merges all fixes into the branch and keeps record how the testing goes on and decides when is the time to release. o List of succesful builds on different platforms - Create a build tracker to qa.php.net (Bat[e] ?) - Make the bug system to send bug reports to php-qa list and only confirmed reports to php-dev thus making it easier for developers to notice which reports are real bugs. Huge amount of the reports coming in are bogus. With all this I think we can avoid this kind of situations in the future as the amount of testing will get smaller. And democracy doesn't always work. :) Of course these release-dictators should be elected somehow so that evil dictators never get the power again. :) I think all of these are good ideas that will contribute to getting us out of this mess.
Re: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV]4.1.0)
At 12:31 AM 11/11/2001 +0100, Stig S. Bakken wrote: Andi Gutmans wrote: Jani, I think in theory what you writes makes sense but it just doesn't work in the PHP project. (I'm talking about the minor versions coming out of branches). There are always cries to go with HEAD because it's got new goodies (I think it often makes sense) and then people don't want to release a second version out of a branch but want to use HEAD. All in all the release process in the past few years hasn't been that bad. I think the timing has been good and we haven't had *that* many screw-ups. What I do think we need is a couple of people who will push things forward once everyone decides that it is time to branch and start QA; so that things don't linger. Andi, If we trim down the PHP distribution to not contain as many goodies, chances are there won't be as many cries for head (no pun intended). The distinction between the second and third digit is basically documenting to the user the level of change in a release. I didn't quite understand what you mean :) All I said was that if you create a branch say 4.1.0 and you want to release 4.1.x from that branch later on whilst HEAD has already moved a couple of months you're going to have a hard time doing it. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV]4.1.0)
Guys, I mentioned this in the conference. Version numbers aren't going to change anything significant. If we're concerned about the users' perception of what the version number means, moving to Jani's versioning scheme, I'm pretty confident it'll mean less to more people. The reason being the fact that people are used to PHP's existing versioning scheme, which is the de-facto standard in the opensource world, and you should be quite aware that the vast majority of users will never read our explanation as to what the version number means, no matter how nicely we put it. That's the advantage of using a standard. I think that we're too harsh on the system we have in place right now. It usually works. It really does. True, 4.0.7 lingered on for a variety of good and bad reasons, but even in this extreme case - we're not faced with a tragedy, but some dilemma, at most. *Every* system has its advantages and its disadvantages, there's no perfect system. Those who suggest that we switch should think carefully about what the gains will be, and whether they'll be worth the losses. I have a feeling that currently people feel that 'anything would be better than what we have now', when in reality, we have a system that works at say 70% or 80% efficiency, and switching may very well make things worse at the bottom line (i.e., worse product for the end user) than they are today. Zeev At 01:31 11/11/2001, Stig S. Bakken wrote: Andi Gutmans wrote: Jani, I think in theory what you writes makes sense but it just doesn't work in the PHP project. (I'm talking about the minor versions coming out of branches). There are always cries to go with HEAD because it's got new goodies (I think it often makes sense) and then people don't want to release a second version out of a branch but want to use HEAD. All in all the release process in the past few years hasn't been that bad. I think the timing has been good and we haven't had *that* many screw-ups. What I do think we need is a couple of people who will push things forward once everyone decides that it is time to branch and start QA; so that things don't linger. Andi, If we trim down the PHP distribution to not contain as many goodies, chances are there won't be as many cries for head (no pun intended). The distinction between the second and third digit is basically documenting to the user the level of change in a release. - Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV] 4.1.0)
On Sat, 10 Nov 2001, Zeev Suraski wrote: Guys, We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on which 4.1.0 is currently scheduled to be based on, has branched away a few months ago. Some people have expressed concern that releasing 4.1.0 based on that branch is not a good idea, because there have been so many changes in the HEAD branch, and synchronizing fixes and so on is going to be a headache. I have a bad feeling about this branch and I vote for dropping it and starting new from HEAD. There are several reasons for this: The change between 4.0.7 - 4.1.0 (and also sudden change of the release master from Zeev to Stig) has confused some people according the discussion on php-qa list a while ago. Many of them might have tested 4.0.7 RCs but not necessarily all have tested the 4.1.0 RCs. Not to forget the 11th of September.. I have no idea who have tested the latest RC. Does anyone have? After the latest RC there have been a LOT of fixes in the release branch and also several fixes in the HEAD (which weren't MFH'd) and there hasn't been any new RCs after those fixes were committed. How many people test the branch (from CVS) ? Has anyone kept any list of the test results and problems found ? Has anyone kept eye on fixes done which weren't merged to the branch ? Answer is: We don't KNOW. The thing is that the project has grown to be so big that we can not afford long periods of time between releases. Too much stuff gets in without testing. Too many NEW bugs are introduced and like it has been said many times before, not enough people really pay attention to fixing them. Developers simply ignore them and continue adding new stuff thus creating new possible bugs. Anyone think what I think? Release early, release often http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/x147.html This works very well for Linux, why wouldn't it work for PHP ? Our QA team is very small. It has actually gotten smaller during the last 6 months instead of getting bigger like it should have. Enough ranting, let's get into fixing this situation. I can't see any solutions that won't bite us but one solution that won't bite as so badly in the _long_run_, as if we delay it or release too early we're gonna get hurt. My proposal is this: - Release the current branch as 4.1.0 but clearly state that there will be 4.2.0 soon. Also start the 4.2.0 branch from HEAD now and the QA process on it with some things kept in mind: o Any serious problems found (by our best QA team: the real users) in 4.1 we fix them in 4.2 and announce that after 4.2 release we start following the versioning rules for real. o We continue releasing 4.2.x versions out of the 4.2 branch but with ONLY bug fixes in it. And we do this OFTEN. Any new stuff goes to HEAD. We should decide what amount of fixes or with what severity triggers the (short) QA process for the 4.2.x branch. o After there have been, let's say 5 big ones in HEAD, we start new branch, 4.3 and QA process moves there. The QA should not take so long with this. Security related fixes should trigger new release process immediately. o Any changes into extensions from now on should include the start of using the version numbers in extension. Also, if there are changes in many extensions or there are big changes in some extension we make another 4.2.x release. (compromise for Zeev's sake :) o Any big changes or changes that might possibly break things should be announced on the php-qa list and only after QA has tested that the changes don't break anything, they should be allowed into CVS. - We need to have ONE place where to keep the RC packages. And we need to have also Windows build of the RCs at this same place. Having the packages in someone's home directory is not very good idea. Better place would be at http://qa.php.net/ - We name persons for each branch who work together with QA team and make sure the releases are tested properly. ie. This person merges all fixes into the branch and keeps record how the testing goes on and decides when is the time to release. o List of succesful builds on different platforms - Create a build tracker to qa.php.net (Bat[e] ?) - Make the bug system to send bug reports to php-qa list and only confirmed reports to php-dev thus making it easier for developers to notice which reports are real bugs. Huge amount of the reports coming in are bogus. With all this I think we can avoid this kind of situations in the future as the amount of testing will get smaller. And democracy doesn't always work. :) Of course these release-dictators should be elected somehow so that evil dictators never get the power again. :) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV] 4.1.0)
Jani, I think in theory what you writes makes sense but it just doesn't work in the PHP project. (I'm talking about the minor versions coming out of branches). There are always cries to go with HEAD because it's got new goodies (I think it often makes sense) and then people don't want to release a second version out of a branch but want to use HEAD. All in all the release process in the past few years hasn't been that bad. I think the timing has been good and we haven't had *that* many screw-ups. What I do think we need is a couple of people who will push things forward once everyone decides that it is time to branch and start QA; so that things don't linger. Andi At 10:34 PM 11/10/2001 +0200, Jani Taskinen wrote: On Sat, 10 Nov 2001, Zeev Suraski wrote: Guys, We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on which 4.1.0 is currently scheduled to be based on, has branched away a few months ago. Some people have expressed concern that releasing 4.1.0 based on that branch is not a good idea, because there have been so many changes in the HEAD branch, and synchronizing fixes and so on is going to be a headache. I have a bad feeling about this branch and I vote for dropping it and starting new from HEAD. There are several reasons for this: The change between 4.0.7 - 4.1.0 (and also sudden change of the release master from Zeev to Stig) has confused some people according the discussion on php-qa list a while ago. Many of them might have tested 4.0.7 RCs but not necessarily all have tested the 4.1.0 RCs. Not to forget the 11th of September.. I have no idea who have tested the latest RC. Does anyone have? After the latest RC there have been a LOT of fixes in the release branch and also several fixes in the HEAD (which weren't MFH'd) and there hasn't been any new RCs after those fixes were committed. How many people test the branch (from CVS) ? Has anyone kept any list of the test results and problems found ? Has anyone kept eye on fixes done which weren't merged to the branch ? Answer is: We don't KNOW. The thing is that the project has grown to be so big that we can not afford long periods of time between releases. Too much stuff gets in without testing. Too many NEW bugs are introduced and like it has been said many times before, not enough people really pay attention to fixing them. Developers simply ignore them and continue adding new stuff thus creating new possible bugs. Anyone think what I think? Release early, release often http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/x147.html This works very well for Linux, why wouldn't it work for PHP ? Our QA team is very small. It has actually gotten smaller during the last 6 months instead of getting bigger like it should have. Enough ranting, let's get into fixing this situation. I can't see any solutions that won't bite us but one solution that won't bite as so badly in the _long_run_, as if we delay it or release too early we're gonna get hurt. My proposal is this: - Release the current branch as 4.1.0 but clearly state that there will be 4.2.0 soon. Also start the 4.2.0 branch from HEAD now and the QA process on it with some things kept in mind: o Any serious problems found (by our best QA team: the real users) in 4.1 we fix them in 4.2 and announce that after 4.2 release we start following the versioning rules for real. o We continue releasing 4.2.x versions out of the 4.2 branch but with ONLY bug fixes in it. And we do this OFTEN. Any new stuff goes to HEAD. We should decide what amount of fixes or with what severity triggers the (short) QA process for the 4.2.x branch. o After there have been, let's say 5 big ones in HEAD, we start new branch, 4.3 and QA process moves there. The QA should not take so long with this. Security related fixes should trigger new release process immediately. o Any changes into extensions from now on should include the start of using the version numbers in extension. Also, if there are changes in many extensions or there are big changes in some extension we make another 4.2.x release. (compromise for Zeev's sake :) o Any big changes or changes that might possibly break things should be announced on the php-qa list and only after QA has tested that the changes don't break anything, they should be allowed into CVS. - We need to have ONE place where to keep the RC packages. And we need to have also Windows build of the RCs at this same place. Having the packages in someone's home directory is not very good idea. Better place would be at http://qa.php.net/ - We name persons for each branch who work together with QA team and make sure the releases are tested properly. ie. This person merges all fixes into the branch and keeps record how the testing goes on and decides when is the time to release. o List of succesful builds on different platforms
Re: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV] 4.1.0)
Because that appears to be rediculous idea. At present, unless you have a problem which requires you to upgrade, you stick with the stable proven release. The only reason why Linux kernel gets released so often is because it contains security fixes that affect everyone and are in the public. Security fixes should be released immediately. Just bug fixes, added features and optimized functions should only be done in major releases. Keep in mind, with every new feature, we break another two. Do you _really_ want that many new things on production machines that haven't been properly testes. In 4.0.7, there was a complete rework of the Zend memory management by my understanding- Imagine not testing that at all and putting it out. You are asking for serious problems. Administrators do not want to be upgrading on a weekly basis (or less). We need to keep stable, quality, secure releases- and that only comes from extensive testing. My point- yes it is more work, but let's make a new release candidate from 4.0.7 and release it. It's stable and seems very reliable. It also makes less work for Zend releasing thier optimizer for each release of PHP. Please guys- do not consider regular small releases. Major releases that are properly tested and released (and yes I do keep up on CVS much of the time to test and contribute to the code- I am one of those properly testing it) -- -- Mike - Original Message - From: Jani Taskinen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, November 10, 2001 4:34 PM Subject: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV] 4.1.0) On Sat, 10 Nov 2001, Zeev Suraski wrote: Guys, We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on which 4.1.0 is currently scheduled to be based on, has branched away a few months ago. Some people have expressed concern that releasing 4.1.0 based on that branch is not a good idea, because there have been so many changes in the HEAD branch, and synchronizing fixes and so on is going to be a headache. I have a bad feeling about this branch and I vote for dropping it and starting new from HEAD. There are several reasons for this: The change between 4.0.7 - 4.1.0 (and also sudden change of the release master from Zeev to Stig) has confused some people according the discussion on php-qa list a while ago. Many of them might have tested 4.0.7 RCs but not necessarily all have tested the 4.1.0 RCs. Not to forget the 11th of September.. I have no idea who have tested the latest RC. Does anyone have? After the latest RC there have been a LOT of fixes in the release branch and also several fixes in the HEAD (which weren't MFH'd) and there hasn't been any new RCs after those fixes were committed. How many people test the branch (from CVS) ? Has anyone kept any list of the test results and problems found ? Has anyone kept eye on fixes done which weren't merged to the branch ? Answer is: We don't KNOW. The thing is that the project has grown to be so big that we can not afford long periods of time between releases. Too much stuff gets in without testing. Too many NEW bugs are introduced and like it has been said many times before, not enough people really pay attention to fixing them. Developers simply ignore them and continue adding new stuff thus creating new possible bugs. Anyone think what I think? Release early, release often http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/x147.h tml This works very well for Linux, why wouldn't it work for PHP ? Our QA team is very small. It has actually gotten smaller during the last 6 months instead of getting bigger like it should have. Enough ranting, let's get into fixing this situation. I can't see any solutions that won't bite us but one solution that won't bite as so badly in the _long_run_, as if we delay it or release too early we're gonna get hurt. My proposal is this: - Release the current branch as 4.1.0 but clearly state that there will be 4.2.0 soon. Also start the 4.2.0 branch from HEAD now and the QA process on it with some things kept in mind: o Any serious problems found (by our best QA team: the real users) in 4.1 we fix them in 4.2 and announce that after 4.2 release we start following the versioning rules for real. o We continue releasing 4.2.x versions out of the 4.2 branch but with ONLY bug fixes in it. And we do this OFTEN. Any new stuff goes to HEAD. We should decide what amount of fixes or with what severity triggers the (short) QA process for the 4.2.x branch. o After there have been, let's say 5 big ones in HEAD, we start new branch, 4.3 and QA process moves there. The QA should not take so long with this. Security related fixes should trigger new release process immediately. o Any changes into extensions from now on should include the start of using the version
Re: [PHP-DEV] Proposal: interface improvement for exec(), system(), and passthru().
No compatibility issues but fixing two annoying safe-mode limitations? Go ahead :-) - Stig Arcady Genkin wrote: This refers to bug 18843 ( http://bugs.php.net/bug.php?id=13843 ) I'm willing to give a shot at coding the fix for this bug, provided that the proposed resolutions (below) are approved by somebody with cvs commit powers. Otherwise, let's discuss how to fix it some other way. Right now magic behavior of exec() and friends under safe mode is not even documented anywhere (at least not under Safe Mode or individual sections for each of the functions), and is the cause of really unreasonable limitations. Problem 1: -- Under safe mode PHP programmer has no mechanism of passing command-line parameters that contain spaces to programs with exec() et al. Proposed Resolution: Allow an array to be passed as the first argument of exec() and friends, with the following semantics: o If the first argument is a string, the functions' semantics is the same as it is now. This way the new interface is 100% backward-compatible. o If the first argument is an array, we assume that: - the first element of the array is the command to be executed, - and all other elements are command-line parameters - if PHP is in safe mode, quote each parameter separately This way the command line and the parameters can be quoted properly under safe mode, and still allow blanks in parameters. Problem 2: -- Under safe mode a programmer has no mechanism to do include 21 in the command line with exec() et all. Proposed resolution: Given the interface improvement as explained above, if the _last element_ of the array passed as the first parameter of exec() is a token 21, treat it as a special case and _don't_ magically escape it under safe mode. Many thanks, -- Arcady Genkin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal
UNSUBSCRIBE ME PLEASE!!
Rasmus Lerdorf schrieb:
The best thing about PHP is that it has such a shallow
learning curve that
non-programmers can write web apps.
The worst thing about PHP is that it has such a shallow learning curve
that non-programmers write web apps.
That is of course oversimplifying things quite a bit, but it is the
root
of the issue here.
The question is not whether we should do something about this, the
question is what we should do about it. After reading all these
messages
and talking to people about it in person, here is what I see we need
to
achieve (not necessarily in order of importance):
1. A painless migration path for existing code
2. Minimal impact on the learning curve. I really don't
like requiring
neophyte users to have to understand associative
arrays before they
can get started with PHP.
3. Maximum protection for existing and new PHP apps
How to get there...
For 4.0.7:
- We leave all default configuration settings as they are now.
- We add $_GET, $_POST, $_COOKIE, $_ENV, $_SERVER and perhaps
make them
super-globals like $GLOBALS
- We add a new function, somewhat like the current extract()
which looks
something like this:
// Import all Get/Post/Cookie variables in
to the global(/current?)
// namespace. Function could also be
called import_symbols() or
// register_globals() although the latter
would be a bit confusing
// since it doesn't take a boolean arg like
the ini version.
// If register_globals is on already this
would be a no-op
import_globals("GPC");
// Another use:
// Only import the given variables from Post
or Cookie data.
import_globals("PC",array('user','password','first','last'));
// And perhaps some globbing:
// Import any variable with abc in its name
from anywhere.
// Could alternatively use SQL-style or perhaps
real regex
// expressions here although I think full
regex support would be
// slightly overkill and perhaps too confusing
for people.
import_globals("GPCES","*abc*");
- With the release of 4.0.7 we start hyping this security issue
by
linking to a spruced up version of the security chapter
in the manual
which describes how exactly to use these new tools.
We could also provide a user-space implementation of the
_$GET,
$_POST... population logic and a user-space implementation
of
import_globals() so existing applications could check
the PHP version
and include our forward-compliance.inc file in order for
their apps
that conform to the new style to be backward compatible
with older
PHP installations. Or better, our .inc/.php file
would do a version
check for them.
- We also start hyping that people who write and distribute PHP
apps
should strive to make their code E_NOTICE-clean.
For 4.0.8:
- If we didn't mess up in 4.0.7 and actually got something that
works for
people we consider turning on E_NOTICE by default and/or
turning
register_globals off by default.
For 4.1:
- I think a namespace approach might be interesting, although
perhaps
hard to get as granular as import_globals()
Reasoning behind something like import_globals():
Large existing web apps reference these GPECS variables everywhere.
There
may literally be thousands of lines of code to change and perhaps 10's
of
thousands of lines of code to check. Simply turning off register_globals
would make these scripts fail invisibly. The end result will
be that
people just turn register_globals back on which may even be the documented
requirement for these distributed apps. This doesn't help anybody.
However, if the authors of these apps could make their code somewhat
more
secure by simply adding:
import_globals("P");
to their app-wide include file and assuming they only want POST variables
imported, then they would probably do that. It isn't much of
a security
benefit at this level, but if they took it slightly further and checked
their forms for form elements and pulled out the valid ones and specified
these in an array we suddenly have a whole lot more security and instead
of changing thousands of lines, they have added perhaps 5 or 6.
And from a neophyte user perspective they don't need to understand
associative arrays, they simply need to understand
import_globals("GPC","form_*") which is much easier to teach.
(assuming
they named their form elements form_foo, form_bar, ...)
Obviously the import_globals documentation should point people at the
_GET[] direct access approach as well, although an import_globals()
call
with a precise list of valid variables should be even safer.
-Rasmus
--
PHP Development Mailing List http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal
UNSUBSCRIBE ME PLEASE!!
Heikki Korpela schrieb:
On Sat, 28 Jul 2001, Rasmus Lerdorf wrote:
> // And perhaps some globbing:
> // Import any variable with abc in
its name from anywhere.
> // Could alternatively use SQL-style
or perhaps real regex
> // expressions here although I think
full regex support would be
> // slightly overkill and perhaps too
confusing for people.
> import_globals("GPCES","*abc*");
This sounds brilliant.
Would something glob(3)bish be a bad idea? I could imagine that
1) more people are familiar
with it than with regexs
2) it'd be easier to grasp
in the first place
> -Rasmus
--
-->
Heikki Korpela
-- [EMAIL PROTECTED] -- http://iki.fi/heko/
--
PHP Development Mailing List http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal
UNSUBSCRIBE ME PLEASE!!
Zeev Suraski schrieb:
It's pretty close to what I had in mind:
At 22:17 28/07/2001, Rasmus Lerdorf wrote:
>The best thing about PHP is that it has such a shallow learning curve
that
>non-programmers can write web apps.
>
>The worst thing about PHP is that it has such a shallow learning curve
>that non-programmers write web apps.
>
>That is of course oversimplifying things quite a bit, but it is the
root
>of the issue here.
>
>The question is not whether we should do something about this, the
>question is what we should do about it. After reading all these
messages
>and talking to people about it in person, here is what I see we need
to
>achieve (not necessarily in order of importance):
>
> 1. A painless migration path for existing code
By definition, it should be somewhat painful, since our working assumption
should be that there are good chances that existing code contains
exploitable bugs related to this issue. No pain no gain :)
> 2. Minimal impact on the learning curve. I really don't
like requiring
> neophyte users to have to understand associative
arrays before they
> can get started with PHP.
I mentioned numerous times that I don't think $foo or $_FORM['foo']
are any
different as far as the learning curve is concerned. Newbies
will copy
both as-is without having to actually understand variables and/or
associative arrays.
> 3. Maximum protection for existing and new PHP apps
>
>How to get there...
>
>For 4.0.7:
>
> - We leave all default configuration settings as they are now.
> - We add $_GET, $_POST, $_COOKIE, $_ENV, $_SERVER and perhaps
make them
> super-globals like $GLOBALS
That's what I suggested...
> - We add a new function, somewhat like the current extract()
which looks
> something like this:
>
> // Import all Get/Post/Cookie variables
in to the global(/current?)
> // namespace. Function could
also be called import_symbols() or
> // register_globals() although the
latter would be a bit confusing
> // since it doesn't take a boolean
arg like the ini version.
> // If register_globals is on already
this would be a no-op
> import_globals("GPC");
>
> // Another use:
> // Only import the given variables
from Post or Cookie data.
> import_globals("PC",array('user','password','first','last'));
>
> // And perhaps some globbing:
> // Import any variable with abc in
its name from anywhere.
> // Could alternatively use SQL-style
or perhaps real regex
> // expressions here although I think
full regex support would be
> // slightly overkill and perhaps too
confusing for people.
> import_globals("GPCES","*abc*");
I'm against a global function like this, but in favour of the 2nd flavour,
where you have to explicitly pass a list of variable names to import.
I
also think that it should only support prefix globbing, other types
of
globbing are prone to errors, and also slow to implement.
> - With the release of 4.0.7 we start hyping this security issue
by
> linking to a spruced up version of the security
chapter in the manual
> which describes how exactly to use these new tools.
> We could also provide a user-space implementation
of the _$GET,
> $_POST... population logic and a user-space implementation
of
> import_globals() so existing applications could
check the PHP version
> and include our forward-compliance.inc file in
order for their apps
> that conform to the new style to be backward compatible
with older
> PHP installations. Or better, our .inc/.php
file would do a version
> check for them.
> - We also start hyping that people who write and distribute
PHP apps
> should strive to make their code E_NOTICE-clean.
Looks good.
>For 4.0.8:
>
> - If we didn't mess up in 4.0.7 and actually got something
that works for
> people we consider turning on E_NOTICE by default
and/or turning
> register_globals off by default.
I think that neither of these should be done in 4.0.x, as it has a too
far-reaching effect. Nothing stops us from releasing 4.1 on this
very
issue, even if the only difference is just in main.c's INI list and
php.ini-dist.
>For 4.1:
> - I think a namespace approach might be interesting, although
perhaps
> hard to get as granular as import_globals()
Namespaces in this case are nothing but syntactic sugar, so it's not
fundamentally different from $_FORM[var], and not any easier for newbies
to
understand. Also, since we're forking the engine CVS quite soon,
we don't
want to make any serious engine level changes in 4.x
>Reasoning behind something like import_globals():
>
>Large existing web apps reference these GPECS variables everywhere.
There
>may literally be thousands of lines of code to change and perhaps
10's of
>thousands of lines of code to check. Simply turning off register_globals
>would make these scripts fail invisibly. The end result will
be that
>people just turn register_globals back on which may even be the documented
>requirement for these distributed apps. This doesn't help anybody.
>
>However, if the authors of these apps could make their
Re: [PHP-DEV] Proposal
UNSUBSCRIBE ME PLEASE!!
Phil Driscoll schrieb:
On Sunday 29 July 2001 07:57, Zeev Suraski wrote:
> I'm against a global function like this, but in favour of the 2nd
flavour,
> where you have to explicitly pass a list of variable names to import.
I
> also think that it should only support prefix globbing, other types
of
> globbing are prone to errors, and also slow to implement.
There is an issue that import_globals('GPC') is surely a better option
- if
you are of the opinion that this register globals stuff helps :) -
than
setting register_globals=on since it only applies to the one script
rather
than all scripts, and it may be all that is available as a quick fix
for some
of the scripts out there.
Cheers
--
Phil Driscoll
--
PHP Development Mailing List http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal
UNSUBSCRIBE ME PLEASE!!
Zeev Suraski schrieb:
At 00:48 29/07/2001, Rasmus Lerdorf wrote:
> > I'm against a global function like this, but in favour of the 2nd
flavour,
> > where you have to explicitly pass a list of variable names to import.
>
>Actually, I mostly had something like: import_globals("ES") in mind
for
>the import all variety. Importing all server and environment
variables
>when there are no external variables imported should not generate
an
>E_NOTICE.
If we go down that route it's ok. I was talking about the
import_globals("P") example, which in my opinion should not work, and
import_globals("P", "*") which should work, but generate an E_NOTICE.
>And jumping to 4.1 for only a config file change seems a bit odd.
It looked odd to me as well, but after thinking about it for a while,
it
looks by far the most right thing to do:
- There are no technical drawbacks whatsoever
- It'll make much more noise than a 4.0.x, and make many more people
realize the difference and do something about it, rather than just
upgrade
and do nothing.
- We finally make use of a x.1 version :)
I think that other than the psychological issue that we're not used
to
bumping the miniversion digit for almost anything, there's no reason
not do
it. If we end up having a semi-major version before 5.0 (which
I doubt,
considering the way things are going now), we can always release 4.2.
Zeev
--
PHP Development Mailing List http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal
UNSUBSCRIBE ME PLEASE!!
Zeev Suraski schrieb:
At 00:27 29/07/2001, Heikki Korpela wrote:
>On Sat, 28 Jul 2001, Rasmus Lerdorf wrote:
>
> > // And perhaps some globbing:
> > // Import any variable with abc in
its name from anywhere.
> > // Could alternatively use SQL-style
or perhaps real regex
> > // expressions here although I think
full regex support would be
> > // slightly overkill and perhaps
too confusing for people.
> > import_globals("GPCES","*abc*");
>
>This sounds brilliant.
>
>Would something glob(3)bish be a bad idea? I could imagine that
I believe so. I think we should only be using a simple prefix
glob. It's
the simplest one to understand, and the least prone to human errors.
Zeev
--
PHP Development Mailing List http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal
UNSUBSCRIBE ME PLEASE!!
Stephen van Egmond schrieb:
Rasmus Lerdorf ([EMAIL PROTECTED]) wrote:
> How to get there...
>
> For 4.0.7:
>
> - We leave all default configuration settings as they are now.
> - We add $_GET, $_POST, $_COOKIE, $_ENV, $_SERVER and perhaps
make them
> super-globals like $GLOBALS
+1
> - We add a new function, somewhat like the current extract()
which looks
> something like this:
> // Another use:
> // Only import the given variables
from Post or Cookie data.
> import_globals("PC",array('user','password','first','last'));
+1
> - With the release of 4.0.7 we start hyping this security issue
by
> linking to a spruced up version of the security
chapter in the manual
> which describes how exactly to use these new tools.
I'm writing "A study in resilience", as a response to the "Study in
Scarlet" newsletter. A bit late, but it can provide a discussion
point.
I'd be happy to see it modified and included in the security chapter.
I like your reasoning for import_globals(). I was wondering if
there
was any thought on my earlier proposal, which would be largely a SAPI
change that:
- dies if GET variable is specified while method != GET
- dies if a file in HTTP_POST_FILES fails is_uploaded_file().
This doesn't solve all the items mentioned in the advisory, but it
squishes quite a few!
-Steve
--
PHP Development Mailing List http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal
that all makes a lot of sense to me!
re,
tc
On Sat, Jul 28, 2001 at 10:17:42PM -0700, Rasmus Lerdorf wrote:
The best thing about PHP is that it has such a shallow learning
curve that
non-programmers can write web apps.
The worst thing about PHP is that it has such a shallow learning curve
that non-programmers write web apps.
That is of course oversimplifying things quite a bit, but it is the root
of the issue here.
The question is not whether we should do something about this, the
question is what we should do about it. After reading all these messages
and talking to people about it in person, here is what I see we need to
achieve (not necessarily in order of importance):
1. A painless migration path for existing code
2. Minimal impact on the learning curve. I really don't like requiring
neophyte users to have to understand associative arrays before they
can get started with PHP.
3. Maximum protection for existing and new PHP apps
How to get there...
For 4.0.7:
- We leave all default configuration settings as they are now.
- We add $_GET, $_POST, $_COOKIE, $_ENV, $_SERVER and perhaps make them
super-globals like $GLOBALS
- We add a new function, somewhat like the current extract() which looks
something like this:
// Import all Get/Post/Cookie variables in to the global(/current?)
// namespace. Function could also be called import_symbols() or
// register_globals() although the latter would be a bit confusing
// since it doesn't take a boolean arg like the ini version.
// If register_globals is on already this would be a no-op
import_globals(GPC);
// Another use:
// Only import the given variables from Post or Cookie data.
import_globals(PC,array('user','password','first','last'));
// And perhaps some globbing:
// Import any variable with abc in its name from anywhere.
// Could alternatively use SQL-style or perhaps real regex
// expressions here although I think full regex support would be
// slightly overkill and perhaps too confusing for people.
import_globals(GPCES,*abc*);
- With the release of 4.0.7 we start hyping this security issue by
linking to a spruced up version of the security chapter in the manual
which describes how exactly to use these new tools.
We could also provide a user-space implementation of the _$GET,
$_POST... population logic and a user-space implementation of
import_globals() so existing applications could check the PHP version
and include our forward-compliance.inc file in order for their apps
that conform to the new style to be backward compatible with older
PHP installations. Or better, our .inc/.php file would do a version
check for them.
- We also start hyping that people who write and distribute PHP apps
should strive to make their code E_NOTICE-clean.
For 4.0.8:
- If we didn't mess up in 4.0.7 and actually got something that works for
people we consider turning on E_NOTICE by default and/or turning
register_globals off by default.
For 4.1:
- I think a namespace approach might be interesting, although perhaps
hard to get as granular as import_globals()
Reasoning behind something like import_globals():
Large existing web apps reference these GPECS variables everywhere. There
may literally be thousands of lines of code to change and perhaps 10's of
thousands of lines of code to check. Simply turning off register_globals
would make these scripts fail invisibly. The end result will be that
people just turn register_globals back on which may even be the documented
requirement for these distributed apps. This doesn't help anybody.
However, if the authors of these apps could make their code somewhat more
secure by simply adding:
import_globals(P);
to their app-wide include file and assuming they only want POST variables
imported, then they would probably do that. It isn't much of a security
benefit at this level, but if they took it slightly further and checked
their forms for form elements and pulled out the valid ones and specified
these in an array we suddenly have a whole lot more security and instead
of changing thousands of lines, they have added perhaps 5 or 6.
And from a neophyte user perspective they don't need to understand
associative arrays, they simply need to understand
import_globals(GPC,form_*) which is much easier to teach. (assuming
they named their form elements form_foo, form_bar, ...)
Obviously the import_globals documentation should point people at the
_GET[] direct access approach as well, although an import_globals() call
with a precise list of valid variables should be even safer.
-Rasmus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list
Re: [PHP-DEV] Proposal
It's pretty close to what I had in mind:
At 22:17 28/07/2001, Rasmus Lerdorf wrote:
The best thing about PHP is that it has such a shallow learning curve that
non-programmers can write web apps.
The worst thing about PHP is that it has such a shallow learning curve
that non-programmers write web apps.
That is of course oversimplifying things quite a bit, but it is the root
of the issue here.
The question is not whether we should do something about this, the
question is what we should do about it. After reading all these messages
and talking to people about it in person, here is what I see we need to
achieve (not necessarily in order of importance):
1. A painless migration path for existing code
By definition, it should be somewhat painful, since our working assumption
should be that there are good chances that existing code contains
exploitable bugs related to this issue. No pain no gain :)
2. Minimal impact on the learning curve. I really don't like requiring
neophyte users to have to understand associative arrays before they
can get started with PHP.
I mentioned numerous times that I don't think $foo or $_FORM['foo'] are any
different as far as the learning curve is concerned. Newbies will copy
both as-is without having to actually understand variables and/or
associative arrays.
3. Maximum protection for existing and new PHP apps
How to get there...
For 4.0.7:
- We leave all default configuration settings as they are now.
- We add $_GET, $_POST, $_COOKIE, $_ENV, $_SERVER and perhaps make them
super-globals like $GLOBALS
That's what I suggested...
- We add a new function, somewhat like the current extract() which looks
something like this:
// Import all Get/Post/Cookie variables in to the global(/current?)
// namespace. Function could also be called import_symbols() or
// register_globals() although the latter would be a bit confusing
// since it doesn't take a boolean arg like the ini version.
// If register_globals is on already this would be a no-op
import_globals(GPC);
// Another use:
// Only import the given variables from Post or Cookie data.
import_globals(PC,array('user','password','first','last'));
// And perhaps some globbing:
// Import any variable with abc in its name from anywhere.
// Could alternatively use SQL-style or perhaps real regex
// expressions here although I think full regex support would be
// slightly overkill and perhaps too confusing for people.
import_globals(GPCES,*abc*);
I'm against a global function like this, but in favour of the 2nd flavour,
where you have to explicitly pass a list of variable names to import. I
also think that it should only support prefix globbing, other types of
globbing are prone to errors, and also slow to implement.
- With the release of 4.0.7 we start hyping this security issue by
linking to a spruced up version of the security chapter in the manual
which describes how exactly to use these new tools.
We could also provide a user-space implementation of the _$GET,
$_POST... population logic and a user-space implementation of
import_globals() so existing applications could check the PHP version
and include our forward-compliance.inc file in order for their apps
that conform to the new style to be backward compatible with older
PHP installations. Or better, our .inc/.php file would do a version
check for them.
- We also start hyping that people who write and distribute PHP apps
should strive to make their code E_NOTICE-clean.
Looks good.
For 4.0.8:
- If we didn't mess up in 4.0.7 and actually got something that works for
people we consider turning on E_NOTICE by default and/or turning
register_globals off by default.
I think that neither of these should be done in 4.0.x, as it has a too
far-reaching effect. Nothing stops us from releasing 4.1 on this very
issue, even if the only difference is just in main.c's INI list and
php.ini-dist.
For 4.1:
- I think a namespace approach might be interesting, although perhaps
hard to get as granular as import_globals()
Namespaces in this case are nothing but syntactic sugar, so it's not
fundamentally different from $_FORM[var], and not any easier for newbies to
understand. Also, since we're forking the engine CVS quite soon, we don't
want to make any serious engine level changes in 4.x
Reasoning behind something like import_globals():
Large existing web apps reference these GPECS variables everywhere. There
may literally be thousands of lines of code to change and perhaps 10's of
thousands of lines of code to check. Simply turning off register_globals
would make these scripts fail invisibly. The end result will be that
people just turn register_globals back on which may even be the documented
requirement for these distributed apps. This doesn't help anybody.
However, if the
Re: [PHP-DEV] Proposal
On Sat, 28 Jul 2001, Rasmus Lerdorf wrote: // And perhaps some globbing: // Import any variable with abc in its name from anywhere. // Could alternatively use SQL-style or perhaps real regex // expressions here although I think full regex support would be // slightly overkill and perhaps too confusing for people. import_globals(GPCES,*abc*); This sounds brilliant. Would something glob(3)bish be a bad idea? I could imagine that 1) more people are familiar with it than with regexs 2) it'd be easier to grasp in the first place -Rasmus -- -- Heikki Korpela -- [EMAIL PROTECTED] -- http://iki.fi/heko/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal
I'm against a global function like this, but in favour of the 2nd flavour, where you have to explicitly pass a list of variable names to import. Actually, I mostly had something like: import_globals(ES) in mind for the import all variety. Importing all server and environment variables when there are no external variables imported should not generate an E_NOTICE. And jumping to 4.1 for only a config file change seems a bit odd. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal
At 00:48 29/07/2001, Rasmus Lerdorf wrote: I'm against a global function like this, but in favour of the 2nd flavour, where you have to explicitly pass a list of variable names to import. Actually, I mostly had something like: import_globals(ES) in mind for the import all variety. Importing all server and environment variables when there are no external variables imported should not generate an E_NOTICE. If we go down that route it's ok. I was talking about the import_globals(P) example, which in my opinion should not work, and import_globals(P, *) which should work, but generate an E_NOTICE. And jumping to 4.1 for only a config file change seems a bit odd. It looked odd to me as well, but after thinking about it for a while, it looks by far the most right thing to do: - There are no technical drawbacks whatsoever - It'll make much more noise than a 4.0.x, and make many more people realize the difference and do something about it, rather than just upgrade and do nothing. - We finally make use of a x.1 version :) I think that other than the psychological issue that we're not used to bumping the miniversion digit for almost anything, there's no reason not do it. If we end up having a semi-major version before 5.0 (which I doubt, considering the way things are going now), we can always release 4.2. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal
At 00:27 29/07/2001, Heikki Korpela wrote: On Sat, 28 Jul 2001, Rasmus Lerdorf wrote: // And perhaps some globbing: // Import any variable with abc in its name from anywhere. // Could alternatively use SQL-style or perhaps real regex // expressions here although I think full regex support would be // slightly overkill and perhaps too confusing for people. import_globals(GPCES,*abc*); This sounds brilliant. Would something glob(3)bish be a bad idea? I could imagine that I believe so. I think we should only be using a simple prefix glob. It's the simplest one to understand, and the least prone to human errors. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal
Rasmus Lerdorf ([EMAIL PROTECTED]) wrote:
How to get there...
For 4.0.7:
- We leave all default configuration settings as they are now.
- We add $_GET, $_POST, $_COOKIE, $_ENV, $_SERVER and perhaps make them
super-globals like $GLOBALS
+1
- We add a new function, somewhat like the current extract() which looks
something like this:
// Another use:
// Only import the given variables from Post or Cookie data.
import_globals(PC,array('user','password','first','last'));
+1
- With the release of 4.0.7 we start hyping this security issue by
linking to a spruced up version of the security chapter in the manual
which describes how exactly to use these new tools.
I'm writing A study in resilience, as a response to the Study in
Scarlet newsletter. A bit late, but it can provide a discussion point.
I'd be happy to see it modified and included in the security chapter.
I like your reasoning for import_globals(). I was wondering if there
was any thought on my earlier proposal, which would be largely a SAPI
change that:
- dies if GET variable is specified while method != GET
- dies if a file in HTTP_POST_FILES fails is_uploaded_file().
This doesn't solve all the items mentioned in the advisory, but it
squishes quite a few!
-Steve
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Proposal
The best thing about PHP is that it has such a shallow learning curve that
non-programmers can write web apps.
The worst thing about PHP is that it has such a shallow learning curve
that non-programmers write web apps.
That is of course oversimplifying things quite a bit, but it is the root
of the issue here.
The question is not whether we should do something about this, the
question is what we should do about it. After reading all these messages
and talking to people about it in person, here is what I see we need to
achieve (not necessarily in order of importance):
1. A painless migration path for existing code
2. Minimal impact on the learning curve. I really don't like requiring
neophyte users to have to understand associative arrays before they
can get started with PHP.
3. Maximum protection for existing and new PHP apps
How to get there...
For 4.0.7:
- We leave all default configuration settings as they are now.
- We add $_GET, $_POST, $_COOKIE, $_ENV, $_SERVER and perhaps make them
super-globals like $GLOBALS
- We add a new function, somewhat like the current extract() which looks
something like this:
// Import all Get/Post/Cookie variables in to the global(/current?)
// namespace. Function could also be called import_symbols() or
// register_globals() although the latter would be a bit confusing
// since it doesn't take a boolean arg like the ini version.
// If register_globals is on already this would be a no-op
import_globals(GPC);
// Another use:
// Only import the given variables from Post or Cookie data.
import_globals(PC,array('user','password','first','last'));
// And perhaps some globbing:
// Import any variable with abc in its name from anywhere.
// Could alternatively use SQL-style or perhaps real regex
// expressions here although I think full regex support would be
// slightly overkill and perhaps too confusing for people.
import_globals(GPCES,*abc*);
- With the release of 4.0.7 we start hyping this security issue by
linking to a spruced up version of the security chapter in the manual
which describes how exactly to use these new tools.
We could also provide a user-space implementation of the _$GET,
$_POST... population logic and a user-space implementation of
import_globals() so existing applications could check the PHP version
and include our forward-compliance.inc file in order for their apps
that conform to the new style to be backward compatible with older
PHP installations. Or better, our .inc/.php file would do a version
check for them.
- We also start hyping that people who write and distribute PHP apps
should strive to make their code E_NOTICE-clean.
For 4.0.8:
- If we didn't mess up in 4.0.7 and actually got something that works for
people we consider turning on E_NOTICE by default and/or turning
register_globals off by default.
For 4.1:
- I think a namespace approach might be interesting, although perhaps
hard to get as granular as import_globals()
Reasoning behind something like import_globals():
Large existing web apps reference these GPECS variables everywhere. There
may literally be thousands of lines of code to change and perhaps 10's of
thousands of lines of code to check. Simply turning off register_globals
would make these scripts fail invisibly. The end result will be that
people just turn register_globals back on which may even be the documented
requirement for these distributed apps. This doesn't help anybody.
However, if the authors of these apps could make their code somewhat more
secure by simply adding:
import_globals(P);
to their app-wide include file and assuming they only want POST variables
imported, then they would probably do that. It isn't much of a security
benefit at this level, but if they took it slightly further and checked
their forms for form elements and pulled out the valid ones and specified
these in an array we suddenly have a whole lot more security and instead
of changing thousands of lines, they have added perhaps 5 or 6.
And from a neophyte user perspective they don't need to understand
associative arrays, they simply need to understand
import_globals(GPC,form_*) which is much easier to teach. (assuming
they named their form elements form_foo, form_bar, ...)
Obviously the import_globals documentation should point people at the
_GET[] direct access approach as well, although an import_globals() call
with a precise list of valid variables should be even safer.
-Rasmus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal for updating the PDF-extension
+1 for PHP way on both questions. The language should be consistent. I think one of the goals - a major one - of PHP (or any other programming language, for that matter) should be: provide a single, consistent interface to many different areas of programmer's life. In other words, I think consistency is what distinguishes a programming language from a pile of libs quickly hacked together into something resembling Crude Puppy rather than anything else. At 17:16 24.1. 2001, Uwe Steinmann wrote the following: -- On Wed, Jan 24, 2001 at 03:07:09PM +0100, Cynic wrote: maybe they should be pdf_find_font, pdf_add_local_link etc? that would be more consistent with the func-naming convention, I guess, but I'm in no position to decide this. but I definitely think that it should be either underscore everywhere, or just between the ext. prefix and the rest of the name (i. e. pdf_findfont, pdf_injectasmanywordasyouseefit), or whatever, but it should be consistent. that is, don't mix pdf_open_file with pdf_add_locallink, because that only confuse folks. and the consensus (at least I got it it's agreed on) is pdf_add_local_link-like names. From the php point of view there should be underscores but the pdflib api doesn't use them except for the one after the 'pdf'. The question is, shall we enforce the php naming or allow the pdflib naming. There are probably other points which need to be discussed like what a function should return if it fails. Many php functions return false but pdflib's api requires to return -1. Uwe -- [EMAIL PROTECTED] Tel: +2331 987 4528Fax: +2331 987 375 --end of quote-- Cynic: A member of a group of ancient Greek philosophers who taught that virtue constitutes happiness and that self control is the essential part of virtue. [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal for updating the PDF-extension
Jani Taskinen wrote: On Wed, 24 Jan 2001, Uwe Steinmann wrote: On Wed, Jan 24, 2001 at 03:07:09PM +0100, Cynic wrote: confuse folks. and the consensus (at least I got it it's agreed on) is pdf_add_local_link-like names. From the php point of view there should be underscores but the pdflib api doesn't use them except for the one after the 'pdf'. The question is, shall we enforce the php naming or allow the pdflib naming. This API is used in PHP - use the PHP naming. If we start making exceptions we end up having a mess in our hands.. :) This is the same problem for us. We have to support eight (number is still growing) PDFlib language bindings including documentation and samples, on differnent plattforms. So it is very essential for us to have a consistent API and documentation. We cannot afford to duplicate the whole PDFlib-Manual for each language binding, and therefore strive to supply a single unified reference Manual for all languages. The benefit for the developer is that allwas has access to the latest and comprehensive PDFlib documentation. The maintainers not neccesarly have to duplicate the manual into the PHP documentation. Even another little detail, if somebody changes from i.e. ASP to php they can simply reuse the pdflib-code :-) There are probably other points which need to be discussed like what a function should return if it fails. Many php functions return false but pdflib's api requires to return -1. Again, we should be consistant within PHP the language. ie. if function fails - RETURN_FALSE. After some discussion with Thomas, we are convinced to do it the php way. The extension will take care to convert the PDFlib error convention to PHP conventions. In addition PDFlib exceptions are mapped to php_error(). IMO. --Jani Rainer + Thomas ([EMAIL PROTECTED]) -- Rainer Schaaf [EMAIL PROTECTED]http://www.pdflib.com ___PDFlib - a library for generating PDF on the fly -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal for updating the PDF-extension
At 05:43 PM 1/24/2001 +0200, Jani Taskinen wrote: On Wed, 24 Jan 2001, Uwe Steinmann wrote: On Wed, Jan 24, 2001 at 03:07:09PM +0100, Cynic wrote: confuse folks. and the consensus (at least I got it it's agreed on) is pdf_add_local_link-like names. From the php point of view there should be underscores but the pdflib api doesn't use them except for the one after the 'pdf'. The question is, shall we enforce the php naming or allow the pdflib naming. This API is used in PHP - use the PHP naming. If we start making exceptions we end up having a mess in our hands.. :) There are probably other points which need to be discussed like what a function should return if it fails. Many php functions return false but pdflib's api requires to return -1. Again, we should be consistant within PHP the language. ie. if function fails - RETURN_FALSE. IMO. I agree. PHP doesn't need to map the C API's one-to-one but implement PHP functions in the PHP spirit and in a consistent way. That consistent way is returning false. We've talked about this numerous times. When we implement an extension module for a C library we don't even necessarily need to map the functions one-to-one to PHP but think of what API would be the most useful for PHP programmers allowing them flexibility but staying with it's short development time advantage. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
