> > Full agreement with Tim here - make PHP friendly to development. Generally I do agree with this sentiment. Languages should be developer-friendly, but not at the expense of safety.
Developers are able to configure an INI setting in multiple ways including modifying an ini file, using the `ini_set()` method, and SAPI configuration. We cannot assume that every installation of every PHP webapp out there is managed by someone who knows, and understands, the risks of every INI setting. > > There are only few places where secrets would be actually relevant, and > > those can be covered by #[SensitiveParameter]. > I tend to agree as well. #[SensitiveParameter] is the better solution in the > 95% case. If there are libraries still not using it (as the RFC suggests), > those should have bugs (or preferably patches) filed against them. > > The great thing about attributes is they're intrinsically backward > compatible, so there's no meaningful cost to adding/patching liberally. While I agree that #[SensitiveParameter] is a nice idea, I believe it’s currently insufficient in both implementation and adoption to be relied on as the primary means of protecting sensitive data. Firstly it isn't only a few places where secrets are relevant. People have different views of what should be considered Sensitive. For example, under EU regulations anything which contains any Personally Identifiable Information (PII) should be considered sensitive, that includes first and last name, e-mail address, phone number, IP address, and so on. As developers we may not agree, but a stack trace which was displayed and included some of this information technically needs to be declared to the data commissioner in the EU within 72 hours (https://www.edps.europa.eu/data-protection/our-role-supervisor/personal-data-breach_en). Secondly you cannot apply the #[SensitiveParameter] attribute to object properties. If you have an object which contains any passwords or PII, then you have to declare anywhere that you receive that object in a parameter with the #[SensitiveParameter] attribute. In many projects that is a huge number of methods - for example anywhere you format a string _might_ be passed a string which contains PII and therefore that would arguably need to have the attribute. In the case of libraries like Guzzle where any Request may contain a credential then the entire Request object must be declared sensitive at every usage. Thirdly, if you pass additional parameters to a function/method there is no way to apply this attribute (https://3v4l.org/8lBso#v8.4.6). I'm sure there is still plenty of code out there which makes use of `func_get_args()` instead of variadic arguments. There are still libraries out there which insist on supporting ancient versions of PHP which don't support variadic arguments so there is no way to set these as Sensitive. Even massive and well-supported libraries like the AWS-SDK still use `func_get_args()` in places like their TokenProvider. While you're correct that it is backwards compatible (and I agree that this is a fantastic feature of attributes), it is not widely used. Taking a look at some of the most popular libraries around, many don't have a single instance of it when arguably they will be passing around lots of sensitive information, for example: - aws-sdk-php only uses the SensitiveParameter in unit tests but it accepts credentials in a variety of places - Monolog has no uses of it, but is almost certainly going to be passed around PII, Tokens, Session IDs, etc. - Guzzle has no uses of it, but again it will almost certainly be passed credentials, tokens, etc. (e.g. for authentication) These are all widely used, well-maintained projects, and yet offer none of the apparent protection from the attribute. While the attribute is backwards compatible, the process of identifying appropriate usage and contributing patches can carry a non-trivial cost to identify possible uses, create a patch, and go through any pull request review processes. Different groups have different views on what should be considered Sensitive, so it is also likely to get caught up in any reviews for discussion.
