Security implications of parsing env variables in .ini

Hi internals team, The discussion of extending the .ini env variable parsing capabilities with ability to specify defaults it occurred to me that the while feature of env variables may have undesirable security implications. For instance, functions parse_ini_string() and parse_ini_file() do support the aforementioned env variables syntax, because the underlying code is reused. That means that these functions can potentially be exploited to read sensitive information! For example: AWS_SECRET_ACCESS_KEY=amazonWebServicesSecretAccessKeyExample1 php -r 'var_export(parse_ini_string("secret=\${AWS_SECRET_ACCESS_KEY}"));' array ( 'secret' => 'amazonWebServicesSecretAccessKeyExample1', ) This only affects INI_SCANNER_NORMAL (the default). Should the mode argument be changed to disallow the env parsing by default? Perhaps another constant can be introduced to activate it, for example: INI_SCANNER_NORMAL | INI_SCANNER_PARSE_ENV This would be a BC breaking behavior but it's doubtful many people expected the env variable parsing syntax to extend to parse_ini_file/string() functions in the first place. P.S. My email client doesn't properly support the top-reply and/or quoting requirements of the mailing list. That's what made me disengage from the mailing list to not annoy anybody with butchered reply threads until I find time to migrate to another email client. Here's a related tweet of mine: https://twitter.com/SergiiShymko/status/1679598903925129222?s=20 Regards, Sergii Shymko