[
https://issues.apache.org/jira/browse/MNG-6612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802696#comment-16802696
]
Max Lee commented on MNG-6612:
------------------------------
While this might be a valid solution for big enterprises it isn't really viable
for small open source projects where the goal of using maven usually is to be
able to simply checkout the repository and build it without having to setup any
kind of additional software. (Something that maven was supposed to get rid of
in the first place)
Another suggested approach is for the repository offered by the developer of
the software to include all necessary dependencies that the project might have
(so you only need to add this one repository instead of the ones of your
libraries) which fails again when looked at with an "ease of use" approach in
two aspects: The developer of the software would need to manually update all
libraries in their repository and also be required to have the ability to
actually host such a repository (which many have not), lots don't even provide
repositories for their own projects and only provide it on some git repository
(mostly github, thank god for
[jitpack|[http://jitpack.io|http://jitpack.io/]]...). Of course you could
potentially host a maven repository on github (or the git repository hoster of
your choice) directly but this seems a bit odd and is also generally
discouraged by those service's TOS.
There is also another potential security concern with querying all listed
repositories instead of doing that per dependency: A malicious actor could
publish an artifact that you shade into your project to a repository that
didn't already contain it which you only used for a provided dependency (hence
require less trust) but which gets queried before the one were the artifact is
actually included. (I assume central checks each published artifacts but other
repository managers might not be) That way one could introduce code into built
artifacts (at least for new builds) without anyone noticing (unless they check
where a certain dependency was downloaded from I guess)
Of course you could kinda work around this attack vector by listing
repositories of shaded dependencies before the ones of provided dependencies
but I feel like this is kinda an un-intuitive approach. It also fails as soon
as one of the previous repositories is unreachable for whatever reason...
especially as DDOS-attacks to achieve other goals aren't too uncommon these
days. So I don't think such an issue should be ignored ‒ especially if a quite
small addition of "repository pinning" directly in the pom would already solve
lots of the mentioned issues.
> Ability to set repository of dependency
> ---------------------------------------
>
> Key: MNG-6612
> URL: https://issues.apache.org/jira/browse/MNG-6612
> Project: Maven
> Issue Type: New Feature
> Components: Dependencies
> Reporter: Max Lee
> Priority: Minor
> Labels: Repository, dependency
>
> In a setup where you specify multiple different repositories for your project
> it would be a useful to be able to specify which repository contains which
> dependency in the pom and not resolve such dependencies from the general
> repositories but only the ones defined for the dependency.
> E.g. in cases where you don't want other dependencies to get resolve in
> certain repositories because they contain broken versions or when you simply
> want to stop the potential privacy/security issues that leaking dependencies
> to another repository that doesn't even include the dependency could
> introduce. (Theoretically an ignored/skip-repositories setting could also
> solve this issue) Another application of this feature could be to define
> different update or checksum check setting for different artifacts that would
> use the same repository.
> This could theoretically be setup using the repository name:
>
> {code:java}
> <dependency>
> <groupId>id.group</groupId>
> <artifactId>artifact-id</artifactId>
> <version>version-string</version>
> <repositories>
> <repository>repository-id</repository>
> </repositories>
> </dependency>
> {code}
> or by allowing to directly set the repository-settings in the dependency and
> not on the outer scope (this would allow for a wider range of applications by
> allowing different repository settings per artifact but require a larger
> config for simply setting the repository of an artifact)
>
> {code:java}
> <dependency>
> <groupId>id.group</groupId>
> <artifactId>artifact-id</artifactId>
> <version>version-string</version>
> <repositories>
> <repository>
> <id>repository-id</id>
> <url>https://repo.example.com/</url>
> </repository>
> </repositories>
> </dependency>
> {code}
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
