[
https://issues.apache.org/jira/browse/SOLR-9459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17464017#comment-17464017
]
Uwe Schindler edited comment on SOLR-9459 at 12/22/21, 7:42 PM:
----------------------------------------------------------------
Mailing list:
{quote}Except stone-age deps are dependencies that are not updated, and may
contain vulnerabilities. Less important for build things like RAT since the
risk there is contained within ASF and not to our users, and the inputs are
much more tightly controlled, but not zero risk.
I really don't like shade/shadow modifies distributables which is dodgy for
licensing (though everyone seems to ignore that)... And this causes me to
realize that shade/shadow makes it very hard to know if you have vulnerable
code in your product. It just mixes things that shouldn't be mixed and that's
why I've maintained uno-jar (fork of the no-longer maintained One-JAR). ... I
mean if someone shades something vulnerable into their jar and re-names
packages to avoid clashes, how do you even know if you're running vulnerable
code without reading the pom.xml/build.gradle of the project? Even the hash
signatures of the class files will have changed, right?
{quote}
In the case of gorbiddenapis you have to shade as for example ASM is
incompatible to each oder and for example Gradle ships with its own outdated
versions.
Forbiddenapis is my responsibility and I can decide if and what I'd like to
shade.
Generally the recent log4j discussion and organizations like Adobe (see mailing
list) or governmental organizations enforcing all product upgrades just because
there's a jar file will force for sure application providers to go over and
shade more libs than in the past to actually hide what they use. That's bad!
This should be told to those stupid, stupid people without any technical
knowledge at e.g. Adobe (yes I mean you Adobe!), That they will bring that
problem to all of us.
If we say: "Solr is safe" they should accept that or simply stop using it.
Period. Man man, I will take a shotgun and kill the next one who asks me to
update the library without reason.
Please keep this statement public, I stand to it.
was (Author: thetaphi):
In the case of gorbiddenapis you have to shade as for example ASM is
incompatible to each oder and for example Gradle ships with its own outdated
versions.
Forbiddenapis is my responsibility and I can decide if and what I'd like to
shade.
Generally the recent log4j discussion and organizations like Adobe (see mailing
list) or governmental organizations enforcing all product upgrades just because
there's a jar file will force for sure application providers to go over and
shade more libs than in the past to actually hide what they use. That's bad!
This should be told to those stupid, stupid people without any technical
knowledge at e.g. Adobe (yes I mean you Adobe!), That they will bring that
problem to all of us.
If we say: "Solr is safe" they should accept that or simply stop using it.
Period. Man man, I will take a shotgun and kill the next one who asks me to
update the library without reason.
Please keep this statement public, I stand to it.
> Upgrade dependencies
> --------------------
>
> Key: SOLR-9459
> URL: https://issues.apache.org/jira/browse/SOLR-9459
> Project: Solr
> Issue Type: Improvement
> Reporter: Petar Tahchiev
> Priority: Major
> Attachments: commons-lang3.patch
>
>
> Hello,
> my project has more than 400 dependencies and I'm trying to ban the usage of
> {{commons-collecrtions}} and {{commons-lang}} in favor of
> {{org.apache.commons:commons-collection4}} and
> {{org.apache.commons:commons-lang3}}. Unfortunately out of the 400
> dependencies *only* solr is still using the old {{collections}} and {{lang}}
> dependencies which are more than 6 years old.
> Is there a specific reason for that? Can you please update to the latest
> versions:
> http://repo1.maven.org/maven2/org/apache/commons/commons-lang3/
> http://repo1.maven.org/maven2/org/apache/commons/commons-collections4/
> http://repo1.maven.org/maven2/org/apache/commons/commons-configuration2/
> http://repo1.maven.org/maven2/org/apache/commons/commons-io/
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
