-
Notifications
You must be signed in to change notification settings - Fork 128
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
Remove deprecated dependencies to satisfy security scanners #233
base: master
Are you sure you want to change the base?
Conversation
This is a PoC on how to remove deprecated libraries from the POM file (or move them to the `test` scope) to appease some primitive security scanners. The trick is to extract classes/methods from the Avalon, LogKit and Log4j 1.x libraries that are used in the Commons Logging code and put them in an additional source code directory `src/main/dummy`. **Remark:** The source files in `src/main/dummy` are **not** included in the any Commons Logging artifact. They are only used by the compiler to include the correct signatures in the class files.
Question: Wouldn't it be sufficient to change the scope for those dependencies to "provided"? |
I don't have access to those so-called "security" scanners. As far as I can test using This PR certainly tricks the CycloneDX plugin to remove |
@ppkarwasz |
Let's wait for the Remark: many "security" scanners treat
It doesn't have the same problem with |
@ppkarwasz |
Does you security scanner at work still complain about Log4j 1, Avalon or LogKit? |
This is a PoC on how to remove deprecated libraries from the POM file (or move them to the
test
scope) to appease some primitive security scanners.The trick is to extract classes/methods from the Avalon, LogKit and Log4j 1.x libraries that are used in the Commons Logging code and put them in an additional source code directory
src/main/dummy
.Remark: The source files in
src/main/dummy
are not included in the any Commons Logging artifact. They are only used by the compiler to include the correct signatures in the class files.Motivation
From a developer perspective the change is useless and the new artifacts should be identical to those before this change (except the embedded
pom.xml
,module-info.class
and the aesthetic change inLog4JLog
).However many developers struggle to explain to their security experts that having
log4j:log4j
somewhere in a POM file is not a problem (cf. many questions on SO). This is also in line with #231.