ppkarwasz commented on PR #4098: URL: https://github.com/apache/logging-log4j2/pull/4098#issuecomment-5886699826
Thank you for this PR and for the time you put into it. We appreciate it. After some more discussion, we'll most likely go in the opposite direction in #4365, which removes `assertFiltered` again. The check only looked like security. It rejected some unfiltered streams, but it didn't make deserializing untrusted data safe, and it couldn't. That's confusing for users. It also suggests that Log4j enforces a trust boundary whenever an application deserializes data, which then brings in reports that expect us to guarantee exactly that. Keeping deserialization safe has always been the responsibility of the application that performs it, and we don't want to give the impression otherwise. Log4j's position is to stay neutral: we don't deserialize anything ourselves, and when we create nested streams, they get the `ObjectInputFilter` the user set on the outer stream. We don't add protection of our own, and we don't make the user's filter any weaker. See the [Security FAQ](https://logging.apache.org/security/faq.html#deserialization) for our position on deserialization. Thanks again for the contribution. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
