21 Feb
2012
21 Feb
'12
7:43 a.m.
Hi
all, I think we can agree on register globals being evil. So let's do
radical breakage in master and remove ./libraries/grab_globals.lib.php.
I know lot of things will get broken, but this is something what needs
to be done for 4.0 and I think it should be done ASAP to prevent any
new code using this.
So I don't give you question whether to do this, but rather when to do
this with possible rationale for the choice:
- right now - anyway people should be using QA_3_5 so master breakage
should not matter
- after releasing 3.5 - developers can focus on master after releasing
3.5
- after releasing 3.5.1 - final release 3.5 will most likely bring lot
of bug reports, which will need to be fixed in 3.5.1
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
21 Feb
21 Feb
9:33 a.m.
Le 2012-02-21 04:43, Michal Čihař a écrit :
Hi
all, I think we can agree on register globals being evil. So let's do
radical breakage in master and remove ./libraries/grab_globals.lib.php.
I know lot of things will get broken, but this is something what needs
to be done for 4.0 and I think it should be done ASAP to prevent any
new code using this.
So I don't give you question whether to do this, but rather when to do
this with possible rationale for the choice:
- right now - anyway people should be using QA_3_5 so master breakage
should not matter
- after releasing 3.5 - developers can focus on master after releasing
3.5
- after releasing 3.5.1 - final release 3.5 will most likely bring lot
of bug reports, which will need to be fixed in 3.5.1
I think that right now is a good time, before we get too busy with 3.5.1.
What do you suggest? remove the library, add a big warning to demo and
then test everything?
Also, I suggest to get rid of $_REQUEST, because the origin of its
contents is unclear. Ideally, at every place where we refer to
$_REQUEST, a comment should explain the possible origin of the contents.
--
Marc Delisle
http://infomarc.info
10:29 a.m.
Op 21 februari 2012 12:33 heeft Marc Delisle <marc(a)infomarc.info> het
volgende geschreven:
Le 2012-02-21 04:43, Michal Čihař a écrit :
Harsh, but effective. It might break some functionality for some time,
but it probably is the fastest way. Unless there is a way of detecting
every place were this register_globals is needed?
Hi
all, I think we can agree on register globals being evil. So let's do
radical breakage in master and remove ./libraries/grab_globals.lib.php.
I know lot of things will get broken, but this is something what needs
to be done for 4.0 and I think it should be done ASAP to prevent any
new code using this.
So I don't give you question whether to do this, but rather when to do
this with possible rationale for the choice:
- right now - anyway people should be using QA_3_5 so master breakage
should not matter
- after releasing 3.5 - developers can focus on master after releasing
3.5
- after releasing 3.5.1 - final release 3.5 will most likely bring lot
of bug reports, which will need to be fixed in 3.5.1
I think that right now is a good time, before we get too busy with 3.5.1.
What do you suggest? remove the library, add a big warning to demo and
then test everything? Also, I suggest to get rid of $_REQUEST, because the
origin of its
contents is unclear. Ideally, at every place where we refer to
$_REQUEST, a comment should explain the possible origin of the contents.
What do you suggest? Only to use $_POST or $_GET instead of $_REQUEST?
I don't see another way of getting the values of url variables.
Maybe we could create a function/class to get the value of a POST/GET
variable and check the validity? I mean, if you need input from a url
variable, you call the function with some parameters : variable name,
allowed origin (POST, GET, COOKIE, SESSION, ...), type of data
(string, bool, int, ...); and the function checks this and returns the
value if it is safe.
So all $_REQUEST, $_POST, $_GET, $_COOKIE, ... in the code should be
replaced by a call to this function.
What do you think?
Kind regards,
Dieter
11:18 a.m.
Le 2012-02-21 07:29, Dieter Adriaenssens a écrit :
Yes; it could be $_COOKIE also, see
http://www.php.net/manual/en/reserved.variables.request.php.
Op 21 februari 2012 12:33 heeft Marc Delisle
<marc(a)infomarc.info> het
volgende geschreven:
Dieter,
When Michal talked about register globals, he meant that in
grab_globals.lib.php, we take some variables from superglobals (except
some that are in a blacklist) and make them globals, so that the other
scripts can work with them.
In grab_globals.lib.php, we could output to a trace file the names of
the variables that are globalized, then verify in the code where these
global variables are used.
Le 2012-02-21 04:43, Michal Čihař a écrit :
Harsh, but effective. It might break some functionality for some time,
but it probably is the fastest way. Unless there is a way of detecting
every place were this register_globals is needed? Hi
all, I think we can agree on register globals being evil. So let's do
radical breakage in master and remove ./libraries/grab_globals.lib.php.
I know lot of things will get broken, but this is something what needs
to be done for 4.0 and I think it should be done ASAP to prevent any
new code using this.
So I don't give you question whether to do this, but rather when to do
this with possible rationale for the choice:
- right now - anyway people should be using QA_3_5 so master breakage
should not matter
- after releasing 3.5 - developers can focus on master after releasing
3.5
- after releasing 3.5.1 - final release 3.5 will most likely bring lot
of bug reports, which will need to be fixed in 3.5.1
I think that right now is a good time, before we get too busy with 3.5.1.
What do you suggest? remove the library, add a big warning to demo and
then test everything? Also, I suggest to get rid of $_REQUEST, because
the origin of its
contents is unclear. Ideally, at every place where we refer to
$_REQUEST, a comment should explain the possible origin of the contents.
What do you suggest? Only to use $_POST or $_GET instead of $_REQUEST?
I don't see another way of getting the values of url variables.
Maybe we could create a function/class to get the value of a POST/GET
variable and check the validity? I mean, if you need input from a url
variable, you call the function with some parameters : variable name,
allowed origin (POST, GET, COOKIE, SESSION, ...), type of data
(string, bool, int, ...); and the function checks this and returns the
value if it is safe.
So all $_REQUEST, $_POST, $_GET, $_COOKIE, ... in the code should be
replaced by a call to this function.
What do you think?
I'm a little afraid about the overhead of such functions calls.
Kind regards,
Dieter
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
--
Marc Delisle
http://infomarc.info
27 Feb
27 Feb
5:45 p.m.
Hi
Dne Tue, 21 Feb 2012 08:18:45 -0500
Marc Delisle <marc(a)infomarc.info> napsal(a):
Yes; it could be $_COOKIE also, see
http://www.php.net/manual/en/reserved.variables.request.php.
I'm not 100% confident about need to differentiate between GET/POST,
however cookies should be surely treated differently (what I believe is
already the case).
--
Michal Čihař | http://cihar.com | http://phpmyadmin.cz
When Michal talked about register globals, he meant
that in
grab_globals.lib.php, we take some variables from superglobals (except
some that are in a blacklist) and make them globals, so that the other
scripts can work with them.
Yes, basically this was introduced as short term hack before we get rid
of using globals. However it stayed longer than everyone did expect.
In grab_globals.lib.php, we could output to a trace
file the names of
the variables that are globalized, then verify in the code where these
global variables are used.
In pretty much everything we use $db/$table, so these would be obvious.
Also, I suggest to get rid of $_REQUEST, because the
origin of its
contents is unclear. Ideally, at every place where we refer to
$_REQUEST, a comment should explain the possible origin of the contents.
What do you suggest? Only to use $_POST or $_GET instead of $_REQUEST?
I don't see another way of getting the values of url variables.
29 Feb
29 Feb
8:51 a.m.
Le 2012-02-27 15:45, Michal Čihař a écrit :
Hi
Dne Tue, 21 Feb 2012 08:18:45 -0500
Marc Delisle <marc(a)infomarc.info> napsal(a):
Yes; it could be $_COOKIE also, see
http://www.php.net/manual/en/reserved.variables.request.php.
I'm not 100% confident about need to differentiate between GET/POST,
however cookies should be surely treated differently (what I believe is
already the case).
I have removed some lines from grab_globals.lib.php. I am currently
testing the impact of removing the globalization of $_GET on
server_privileges.php.
--
Marc Delisle
http://infomarc.info
When Michal talked about register globals, he
meant that in
grab_globals.lib.php, we take some variables from superglobals (except
some that are in a blacklist) and make them globals, so that the other
scripts can work with them.
Yes, basically this was introduced as short term hack before we get rid
of using globals. However it stayed longer than everyone did expect.
In grab_globals.lib.php, we could output to a
trace file the names of
the variables that are globalized, then verify in the code where these
global variables are used.
In pretty much everything we use $db/$table, so these would be obvious.
Also, I suggest to get rid of $_REQUEST, because the
origin of its
contents is unclear. Ideally, at every place where we refer to
$_REQUEST, a comment should explain the possible origin of the contents.
What do you suggest? Only to use $_POST or $_GET instead of $_REQUEST?
I don't see another way of getting the values of url variables.
4 Mar
4 Mar
8:48 p.m.
Le 2012-02-29 06:51, Marc Delisle a écrit :
Le 2012-02-27 15:45, Michal Čihař a écrit :
For master,globalization of $_GET is now commented out in the script.
I'll start experimenting with commenting out the code for $_POST. Anyone
can join the fun :)
--
Marc Delisle
http://infomarc.info
Hi
Dne Tue, 21 Feb 2012 08:18:45 -0500
Marc Delisle <marc(a)infomarc.info> napsal(a):
I'm not 100% confident about need to differentiate between GET/POST,
however cookies should be surely treated differently (what I believe is
already the case).
I have removed some lines from grab_globals.lib.php. I am currently
testing the impact of removing the globalization of $_GET on
server_privileges.php. When Michal talked about register globals, he
meant that in
grab_globals.lib.php, we take some variables from superglobals (except
some that are in a blacklist) and make them globals, so that the other
scripts can work with them.
Yes, basically this was introduced as short term hack before we get rid
of using globals. However it stayed longer than everyone did expect.
In grab_globals.lib.php, we could output to a
trace file the names of
the variables that are globalized, then verify in the code where these
global variables are used.
In pretty much everything we use $db/$table, so these would be obvious.
> Also,
I suggest to get rid of $_REQUEST, because the origin of its
> contents is unclear. Ideally, at every place where we refer to
> $_REQUEST, a comment should explain the possible origin of the contents.
What do you suggest? Only to use $_POST or $_GET instead of $_REQUEST?
I don't see another way of getting the values of url variables.
Yes; it could be $_COOKIE also, see
http://www.php.net/manual/en/reserved.variables.request.php.
6 Mar
6 Mar
7:46 a.m.
Hi
Dne Sun, 04 Mar 2012 18:48:29 -0500
Marc Delisle <marc(a)infomarc.info> napsal(a):
For master,globalization of $_GET is now commented out
in the script.
I'll start experimenting with commenting out the code for $_POST. Anyone
can join the fun :)
Great job! I'm currently busy with other things to join you on this
challenge.
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
4569
days inactive
4583
days old
7 comments
3 participants
participants (3)
-
Dieter Adriaenssens -
Marc Delisle -
Michal Čihař