In the case of forbiddenapis 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. Am 22. Dezember 2021 19:00:20 UTC schrieb Gus Heck <[email protected]>: >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? > >On Wed, Dec 22, 2021 at 11:55 AM Uwe Schindler (Jira) <[email protected]> >wrote: > >> >> [ >> https://issues.apache.org/jira/browse/SOLR-9459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17463964#comment-17463964 >> ] >> >> Uwe Schindler commented on SOLR-9459: >> ------------------------------------- >> >> By the way inside forbiddenapis are (willingly) stoneaged dependencies >> shaded. Reason: small and bloatfree. >> >> > 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] >> >> > >-- >http://www.needhamsoftware.com (work) >http://www.the111shift.com (play) -- Uwe Schindler Achterdiek 19, 28357 Bremen https://www.thetaphi.de
