[
https://issues.apache.org/jira/browse/MNG-8184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867502#comment-17867502
]
Lars Bruun-Hansen commented on MNG-8184:
----------------------------------------
[~cstamas]. Okay, so introduced in Maven 3.9 ? Can't believe I missed that. I
would have liked a solution implemented via the POM rather than via a plugin as
the former brings many benefits. Having build instructions scattered in
several files (in addition to the POM) is less then ideal, IMO. In any case, if
my proposal is one day implemented it would add nicely to the new feature
implemented in 3.9 in the Maven Resolver. It would simply be another way of
configuring it.
Still, let me stress that I find the new feature in Maven Resolver very
valuable. Thanks!
I would go as far as saying that any project which uses a repository which is
not Maven Central should be using either a Prefixes Filter or a GroupId Filter
in their source code. Blindly adding repositories to your build (even if it
your organization's own internal Maven Repository Server) opens you up to all
kind of nasty things. I'll ponder it some more, but at the moment I don't see
why we shouldn't put in such "corporate best practice rule" where I work.
I'll give it a spin.
> 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)
