pytrin wrote:Umm, and this helps ... how?
Any vulnerability that will be able to read a php file will also be able to read the ini file. Even worse, a LFI on a .php-based configuration will just execute the configuration php code, while a LFI on a .ini file will display it on the browser.
Parsing an INI file does not include it, don't see how you came to that conclusion. Not sure what you mean by LFI, I'm assuming some sort of attack I am not familiar with - the initials just stand for Local File Include.
In any case it's safer to have the configuration in a non PHP script, since those can sometimes be accessed directly (depending on the development style), while a separate INI file can be placed in a non-accessible place.
LFI = local file include, yes.
I didn't mean that the regular usage of the ini file would include it while parsing (I don't see how you came to the conclusion that I came to that conclusion either

)
What I meant is that there are classes of vulnerabilities which will be mitigated if the config is in .php and not in .ini (and actually there is not a single benefit in using an .ini I can think of - maybe there are some I'm not seeing?)
Example one is being able to access the file directly, which you already mentioned. With config.inc.php direct access does not do any harm, so no additional measures are needed (which is better - there are fewer points of failure)
A second one is LFI, still a common vulnerability in the wild, whereby an include statement is manipulated to include another (but local) file. Again, including the config.inc.php will do no harm (it only defines variables, doesn't do anything), while including config.ini will display it to the attacker.
I hope I have explained it more clearly now.