Possible information disclosure via Objects::stringOf about core

[thekid]

I disagree that there is an information disclosure problem in util.Objects. Secret values that should not appear in stacktraces or anywhere else should use the util.Secret class introduced in 6.8.0 almost 7 years ago (see #108).

However, having toString() called even if objects do not implement lang.Value would simplify quite some code where hashCode() and compareTo are implemented in a way that always yield distinct objects, simply because the interface requires their implementation. I've come up with PR #313 but will have to give this some more thought.

[thekid]

The PropertyManager class was deprecated in 9.8.0 (October 2018) and subsequently removed in XP 11, which is the currently supported release series, see #290. You should really think about moving away from using this API!

[johannes85]

Yes, we are thinking about moving away from this old stuff, but you know... priorities.
PropertyManager + Properties isn't using util.Secret when reading the secrets from an .ini file.
Yes, I know PropertyManager is deprecated but in this case we have to migrate some old code using Scriptlets to a newer PHP version with minimum efford.

[thekid]

So, using an educated guess after looking at the code for PropertyManager and friends, your problem is a ResourcePropertySource where instead of just root, the cache is also dumped. The cache contains util.Properties instances, whose toString() method then also dumps any secrets in the property file. It all boils down to this:

$ cat test.ini
[global]
db.pass=secret!

$ xp -w '$p= new \util\Properties("test.ini"); $p->reset(); return $p->toString()'
util.Properties(test.ini)@{[global => [db.pass => "secret!"]]}

Also happens if we use the {$secret.xyz} notation, all of these expansions are performed while loading the file.

👉 This would mean the root cause is the Properties class. I'll come up with a PR for this.

[thekid]

Fix released in https://github.com/xp-framework/core/releases/tag/v11.4.0