-
Notifications
You must be signed in to change notification settings - Fork 874
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
html.validator: Remove dependency on log4j #5716
html.validator: Remove dependency on log4j #5716
Conversation
This PR is currently for only for review. Before merge the binary will be moved to the OSUOL server. |
patch looks good. An alternative approach for something like this could be to use SLF4J bridges, since the project has a bridge for almost everything. In this particular case:
this would map log4j 1 to slf4j and use the weirdly named https://www.slf4j.org/legacy.html#log4j-over-slf4j + edit: |
a756d7d
to
f39dbba
Compare
@mbien ah - nice idea. Would be good to consider if we can get the patching down or updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
This commit modifies the patched version of the html.validator not to rely on log4j anymore. There is no security gain estimated. This commit exists only to silence "security" teams, that have some strange interpretation of security. They assume, that you can deduce from the presence of a dependency/ library, whether or not there is a security problem. There is no evidence, that any of the CVEs against log4j 1 apply here.
f39dbba
to
0a7374e
Compare
Pushed new binary to the OSUOSL server and updated the reference. Will merge tomorrow once tests are green. |
This commit modifies the patched version of the html.validator not to rely on log4j anymore.
There is no security gain estimated. This commit exists only to silence "security" teams, that have some strange interpretation of security. They assume, that you can deduce from the presence of a dependency/ library, whether or not there is a security problem. There is no evidence, that any of the CVEs against log4j 1 apply here.