I wasn't actually making a request to specifically upgrade there. Sorry if you took it that way. Please don't shoot :) I was just stating a general point relating to a peeve of mine (which was why I replied to the list for possible discussion not on the issue). I actually fault Java for the situation with them not having come up with a good nested packaging solution for distributions with dependencies included in the 20+ years of it's existence. Shade/shadow are just hacks around that missing feature.
I think people shading to hide what they use would be terrible, totally agree with you there. However, such a thing probably would also be considered a serious legal risk so I suspect it probably won't happen. I do wish the world were simple enough that what we say could be the final word. I'm in no way doubting that solr is safe. However politics, legal risk and inability to track statements made (or not made) by thousands of products in use at large companies is a reality unlikely to change. Tracking that stuff costs money and requires complex solutions too. Trusting low level folks with boots on the ground to do the right thing is also hard and not always wise since there will always be variation in ability and commitment. On Wed, Dec 22, 2021 at 2:43 PM Uwe Schindler (Jira) <[email protected]> wrote: > > [ > 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] > > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
