ppkarwasz commented on PR #4144: URL: https://github.com/apache/logging-log4j2/pull/4144#issuecomment-4699752839
> * How many LoC will be removed from Log4j? > * How many LoC will be added to Log4j? As you can see, today around 10-20 LoC are dedicated to the configuration of `DocumentBuilderFactory` security-wise. What we lack is around 100-200 LoC of tests to verify that those setting actually work. If we add the library and shade it, we have 1 LoC and some build configuration. I don't think lines of code is the real measure here. We can of course optimize them by: - Either forbidding `DOCTYPE` declarations: no external subsets, no entities (external or internal). This kind of attack would be moot even *if* an attacker is able to modify a configuration file (which can do much more damage than entity-based attacks anyway). - Or minimizing the calls based on our needs: `FEATURE_SECURE_PROCESSING` and a deny-all resolver is enough for all the implementations I have tested up to now. But all these solutions still require us to be responsible for the code, instead of maintaining it in a common dependency. > * How often do we expect this library to be updated? I don't expect any new `DocumentBuilderFactory` implementations to appear, but not all those currently in use have been accounted for yet. **TL;DR:** If you look at it through the prism of lines of code, adding an external (shaded) dependency does not provide a clear advantage. However my proposal is more about delegating responsibility than complexity in keeping our current implementation. -- 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]
