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
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.
Op 21 februari 2012 12:33 heeft Marc Delisle marc@infomarc.info het volgende geschreven:
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?
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?
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
Le 2012-02-21 07:29, Dieter Adriaenssens a écrit :
Op 21 februari 2012 12:33 heeft Marc Delisle marc@infomarc.info het volgende geschreven:
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?
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?
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.
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.
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi
Dne Tue, 21 Feb 2012 08:18:45 -0500 Marc Delisle marc@infomarc.info napsal(a):
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.
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).
Le 2012-02-27 15:45, Michal Čihař a écrit :
Hi
Dne Tue, 21 Feb 2012 08:18:45 -0500 Marc Delisle marc@infomarc.info napsal(a):
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.
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.
Le 2012-02-29 06:51, Marc Delisle a écrit :
Le 2012-02-27 15:45, Michal Čihař a écrit :
Hi
Dne Tue, 21 Feb 2012 08:18:45 -0500 Marc Delisle marc@infomarc.info napsal(a):
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.
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.
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 :)
Hi
Dne Sun, 04 Mar 2012 18:48:29 -0500 Marc Delisle marc@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.
-
Dieter Adriaenssens -
Marc Delisle -
Michal Čihař