> > I'm considering uploading any dependencies I do need from JitPack > directly into my own Artifactory as a workaround, but that's crazy and > not long term maintainable. >
I would counter that is actually the only appropriate action. Who is JitPack? Will it go away tomorrow? As near as I can tell, it's a one person operation based in the UK, not something a professional would base their build process around. Configuring your Artifactory as a caching proxy as Thomas suggests is the easy way to insulate yourself, but I'd recommend trying to avoid JitPack entirely. On Mon, Jun 20, 2022 at 3:27 PM Thomas Broyer <t.bro...@gmail.com> wrote: > Le lun. 20 juin 2022 à 20:38, Pawel Veselov <pawel.vese...@gmail.com> a > écrit : > > > TL;DR: > > > > Is there a way, and what is the correct one if there is, to prevent a > > package being downloaded from a particular repository (or lock it to > > being downloaded from a particular one, though I thought the answer to > > that one is "no")? > > > > Use a repository manager? > Have everything go through your repo manager (by declaring it as proxying > `*` in your settings.xml), and manage "filters" there to make sure you only > get from Jitpack what you expect to get from it (using Nexus, this is done > through "routing rules", I don't know with Artifactory). > That's the route we've taken to avoid a few supply chain attacks, including > dependency confusion like you're seeing here (even though it's probably not > an "attack") > > LR: > > > > Maven 3.8.6, JDK 1.8. > > > > I've run into this strange problem with > > com.github.jsonld-java:jsonld-java:0.13.4 > > The package includes fine as a dependency if it is downloaded from > > Maven Central: > > pom.xml: https://pastebin.com/qev5Udp2 > > Build output: https://pastebin.com/MzUVqWLt (pending moderation, LMK > > if you want me to attach that) > > > > The package fails to download as a dependency if it is downloaded from > > JitPack: > > pom.xml: https://pastebin.com/7L2rEWPz > > Build output: https://pastebin.com/U3StAtMZ > > > > AFAIU, there are two things that are "wrong" in this entire thing: > > a) Developer declared packaging as "bundle" (I'm not entirely sure > > that's wrong, but I don't see a reason for them to have done so, and > > it seems to be a contributing factor) > > b) JitPack/somebody republished the dependency as a virtual package > > that depends on itself, and broke this entirely. > > > > But what I don't understand is why the Maven's behavior is different > > in these two cases. > > > > NOT WORKING CASE: The package is found on JitPack, Maven is asked to > > get com.github.jsonld-java:jsonld-java:0.13.4 of type "bundle" by an > > explicit dependency statement. There is no such downloadable binary, > > so the entire process fails. > > > > WORKING CASE: The package is found on Central, Maven is asked to get > > com.github.jsonld-java:jsonld-java:0.13.4, without packaging > > specification. The packaging specification in the POM is "bundle". But > > Maven is satisfied with just downloading the JAR > > > > Few questions: > > - How come Maven is OK creating/uploading a package with "bundle" > > packaging, but without a "bundle" file? > > - How does Maven decide to download the .jar when the packaging says > > "bundle" in the POM, and is satisfied with that? > > > > This is done through "artifact handlers" (the 'type' from a 'dependency' is > technically unrelated to the 'packaging' from the POM). If your dependency > doesn't declare a 'type', then it defaults to 'jar' (the 'packaging' > selects a lifecycle that determines how to *build* that project, > irrespective of how to consume it) > > - Is there a way to find out who published a package on JitPack, to > > get them to fix it? The developer didn't do that, that was done > > without their consent and/or them being made aware of it > > > > Thank you. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
