Hi, https://3v4l.org/IPXe0#v8.2.20 seems to demonstrate that the plain native `SensitiveParameterValue` does not disclose any more information than your custom `Secured` class. Unless there is more features than you did not mention, I'd also suggest to directly use the native `SensitiveParameterValue` for maximum interoperability and ease of use.
Cheers, Adrien On Wednesday 5 June 2024 at 13:19:57 UTC+7 Grégory Planchat wrote: > Hello Larry, > > > I'm a bit unclear what such a spec would even look like. Do you have any > rough examples of what you're talking about, even if not definitive yet? > > I've copy/pasted in a gist the ADR I wrote and use in my application: > https://gist.github.com/gplanchat/9939898a1ca852fffcd7a651d188c5ed > > This would be the starting point for writing a PSR. > > Grégory > > Le mercredi 5 juin 2024 à 01:13:02 UTC+2, Larry Garfield a écrit : > >> On Tue, Jun 4, 2024, at 11:05 AM, Grégory Planchat wrote: >> > Hello Vincent, >> > >> >> Are you aware of SensitiveParameterValue [1][2]? This class was >> introduced as part of the 'Redacting parameters in back traces' RFC [3]. Is >> this essentially what Opaque should be? >> > >> > Yes, I am aware of SensitiveParameterValue. The ADR I wrote requires to >> > use this attribute in the constructor arguments of the Opaque Object. >> > However, it is one part of the solution of the Opaque Objects. It does >> > not solve the risks related to serialization and var_dump/var_export. >> > >> >> As far as this being PSR worthy, I wonder how this problem space has >> impact on interoperability. Maybe in the broader context of configuration >> and service locator this might be an enhancement. What use cases do you see >> that would require this to be a PSR and not just a library? >> > >> > Managing passwords is a common need for domains like dependency >> > injection, API clients, database access or user authentication. >> > It can be extended to everything that also requires managing >> > keys/tokens or sensible data in general, like logs management. In this >> > case you would be required to identify the sensible data and hide them >> > if present. >> > >> > Today, if you wish to secure your sensible data through Opaque Objects, >> > it would be possible to do it in the code you own. >> > However anytime you need to pass this value to a 3rd party code you >> > would be required to extract (disclose) the data from the Opaque Object >> > and depend on the vendor's ability to keep secured the sensible data in >> > all cases. >> > For example, it can be possible to leak an API password in the logs if >> > your 3rd party library throws an unhandled exception. >> > >> > Creating a PSR would bring an interoperable minimum security level for >> > all libraries wishing to implement such security. >> > >> > Kind regards, >> > >> > Grégory >> >> (If someone bottom-replies, please continue bottom-replying. Don't >> top-reply.) >> >> I'm a bit unclear what such a spec would even look like. Do you have any >> rough examples of what you're talking about, even if not definitive yet? >> >> --Larry Garfield >> > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/6a3e8a54-fd69-4e62-a03e-68a83af2f405n%40googlegroups.com.
