[
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)
