[ https://issues.apache.org/jira/browse/MNG-8184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867475#comment-17867475 ]
Tamas Cservenak commented on MNG-8184: -------------------------------------- Howdy Check out RRF [https://maven.apache.org/resolver/remote-repository-filtering.html] and demo [https://github.com/cstamas/rrf-demo] Also check out cli command itr MNG-7980 > GroupId pinning (supply chain security) > --------------------------------------- > > Key: MNG-8184 > URL: https://issues.apache.org/jira/browse/MNG-8184 > Project: Maven > Issue Type: New Feature > Components: Artifacts and Repositories > Reporter: Lars Bruun-Hansen > Priority: Major > > h2. The problem > At the moment, adding an additional repository to a project's POM has > implications few Maven users realize. > Maven adds the repository _prior_ in the lookup order to say Maven Central. > This means: > * The new repository can now effectively "impersonate" anything in Maven > Central. This is obviously a huge security risk. > * Builds will now take longer time because Maven needs to check the newly > added repository too. And this is for every of your project's dependencies. > You better hope that the added repository responds quickly. > In many, many projects it happens that an additional repository must be > added, either because the organization has an internal Maven Repository > Server or because the project need artifacts from some third-party Maven > Repository Server on the internet, like {{maven.oracle.com}} or whatever. > h2. Proposed solution > What I propose is somewhat inspired by a mechanism in NuGet known as [Package > Source > Mapping|https://learn.microsoft.com/en-us/nuget/consume-packages/package-source-mapping]. > Specifically, I propose to add a groupId matching mechanism to the > {{<repository>}} element. Like this: > {code:xml} > <repository> > <name>Dubious Third Party</name> > <id>rogue</id> > <url>https://maven.wild-rover-rogue.com</url> > <groupIdMatchers> > <groupIdMatcher>com.wild-rover-rogue.*</groupIdMatcher> > </groupIdMatcher> > </repository> > {code} > > As the name suggest, it means the repository will only be considered in the > artifact discovery process if the {{groupId}} matches any of the configured > filters. The absence of any {{<groupIdMatcher>}} would mean the repository > will be considered for any groupId, as today. > The proposal is a simple, yet effective way to massively strengthen the > supply chain security of a Maven build. Indeed, in the future the > recommendation should be to _always_ add {{<groupIdMatcher>}} when you add a > {{{}<repository>{}}}. It is difficult for me come up with a scenario where > you wouldn't be able to come up with good fitting filter values. Even for > your internal corporate Maven Repository Server you can most likely say > without hesitation what the filter value should be. It could look something > like this: > {code:xml} > <repository> > <!-- The organization's internal Maven Repo Server --> > <name>Internal Nexus</name> > <id>nexus</id> > <url>https://maven.carlsberg.internal/repository/releases</url> > <groupIdMatchers> > <groupIdMatcher>com.carlsberg.*</groupIdMatcher> > <groupIdMatcher>dk.jacobsen.*</groupIdMatcher> > </groupIdMatchers> > </repository> > {code} > Imagine: IDE's can do checks for this and flag if you are missing to specify > {{{}<groupIdMatchers>{}}}. If you want the IDE to stop obsessing, you can add: > {code:xml} > <groupIdMatchers> > <groupIdMatcher>*</groupIdMatcher> > </groupIdMatchers> > {code} > ... which gives the same effect as not specifying any {{<groupIdMatchers>}} > but which means you've actively given it consideration. > As an added bonus, the proposal will also make builds go faster. > Finally the proposal is backwards compatible. Unlike other suggestions that > has existed over time, such as changing the [default lookup > order|https://maven.apache.org/guides/mini/guide-multiple-repositories.html#repository-order]. > Prior proposals has suggested new features/switches that would prioritize > Maven Central, this proposal does the opposite: it instead effectively > de-prioritizes other repositories, making Maven Central the one that is > likely to be poked first. > h2. The details > The proposal applies to both {{<repository>}} and {{<pluginRepository>}} and > to the POM as well as the {{{}settings.xml{}}}, in short anywhere > repositories for artifact discovery are configured. > The actual syntax of the filter value would have to be worked out. I propose > something very, simple, not a regexp, but a watered down glob where the only > supported wildcard is the '*' and only as a suffix. But that's because I'm > thinking it needs to be quick to evaluate. Perhaps not a concern? > > h2. Existing workarounds > A known workaround is to re-state Maven Central in your POM _before_ your > third-party repos, like this: > {code:xml} > <repository> > <id>central</id> > <name>Central Repository</name> > <url>https://repo.maven.apache.org/maven2</url> > ... > </repository> > <repository> > <name>Dubious Third Party</name> > <id>rogue</id> > <url>https://maven.wild-rover-rogue.com</url> > ... > </repository> > {code} > > This changes the lookup order, so that lookup is performed in {{central}} > before {{rogue}}. > Obviously, this is less than ideal. Developers forget that they really (IMO) > always should be doing this. And they tend to get the exact definition of > what Maven Central should look like wrong. -- This message was sent by Atlassian Jira (v8.20.10#820010)