[
https://issues.apache.org/jira/browse/MNG-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17216175#comment-17216175
]
Michael Osipov commented on MNG-7001:
-------------------------------------
[~rfscholte], correct in terms of what? Please keep in mind that checksums are
not intended to verify authenticity of artifacts, but detect transport errors.
Also note that TLS has [integrity
checks|https://stackoverflow.com/a/18392991/696632] when can guarantee that all
hops are TLS encrypted. Authenticity is only verified with signatures.
Now, as I have layed out previously in MNG-5883, a common case is a roaming
developer. Working from the office and then from home. When using a different
{{settings.xml}} which does not contain corporate repos from profile or a
mirror serving them Resolver notices this and says repo is not available.
[~pbodnar], please correct me if I am wrong from your POV.
I also don't understand how the reverification of hashes can work? Consider
that a unique, non-public artifact has been downloaded and sits in the local
repo. Now, I am disconnected, I cannot reobtain that artifact or its hash from
any public repository, of course. It does not sum up (for me).
[~pbodnar], kindly explain what is wrong with my understanding: I have a laptop
from work. I have zero repositories in our POMs. We have some hosted repos in
Nexus, and proxied Central of course. Now, all of them are in a repository
group which is registered as a mirror of {{external:*}}. Now, I can reach that
Nexus instance only via VPN or from corporate network. I never touch/change my
{{settings.xml}}. What I don't understand, how people work disconnected with
Central only. You are going sooner or later miss data from your corporate repos.
We must also bear in mind that we have very little resources, rewriting
essential parts of Resolver to sastify a too simple local repo manager is just
not feasible for us. We must find a balance between reality and correctness. A
simple example: I have spends hours on a simple patch for MNG-6754 because they
is a lot of code spots and verifications, yet I don't have an IT for it. How
many weeks of discussion, design, implementation and testing we'll spend to
make it less simple.
> Reconsider seemingly useless check of artifacts' source repository introduced
> in Maven 3.0
> ------------------------------------------------------------------------------------------
>
> Key: MNG-7001
> URL: https://issues.apache.org/jira/browse/MNG-7001
> Project: Maven
> Issue Type: Improvement
> Affects Versions: 3.0, 3.1.1, 3.2.5, 3.3.9, 3.5.4, 3.6.3
> Reporter: Petr Bodnar
> Priority: Major
>
> This problem of "by-nobody-really-requested check for artifacts' source
> repository" (just "repo-check" further on) is actually considered a bug by
> many Maven users. It was introduced back in Maven 3.0, 10 years ago \(!). The
> repo-check and its _practical_ disadvantages have been already thoroughly
> described for example in my blog
> [here|https://programmedbycoincidence.blogspot.com/2019/01/the-biggest-wtf-new-feature-ive-ever.html]
> and discussed here within Jira: MNG-5181, MNG-5185, MNG-5289 and MNG-5883.
> *TL;DR What is requested in this issue:*
> # Remove the repo-check altogether.
> # If that's not possible, make the repo-check disabled by-default and have an
> option to enable it for those who need it for whatever reason.
> # If even that is not possible, alter Maven and its warnings and errors so
> that they do not confuse users.
> # Reason about the need for the repo-check, document the reasons.
> ----
> The repo-check can be _somewhat_ avoided by passing the {{-llr}} option to
> Maven. AFAIK though, e. g. Eclipse's embedded Maven used for dependency
> resolution doesn't support this option. Another long-outstanding issue is
> that using the {{-llr}} option generates this warning on Maven build:
> {noformat}
> [WARNING] Disabling enhanced local repository: using legacy is strongly
> discouraged to ensure build reproducibility.
> {noformat}
> Generally it might make sense (possibly because of activating some quite
> another old part of Maven that, apart from other things, doesn't mark down
> the artifacts' sources to "\*.repositories" files?). But when users have _no
> other option_ that could be used for making their build reproducible by
> skipping the repo-check, then the warning doesn't make sense to them. The
> only other choice they have is to remove all those "\*.repositories" files
> from their local Maven repository in order to make their builds work again.
> Another mind-blowing issue is described in MNG-5185: If an already-downloaded
> artifact doesn't go through the hard-coded repo-check, Maven just tells the
> user "the artifact could not be resolved". _But you'll get the very same
> message when downloading an artifact really fails._ So unless you dig in,
> these two totally different situations are not distinguishable from each
> other.
> ----
> Yet to date, no action was taken by Maven authors to help with any of the
> problems. There is also no really good (read "making-sense-in-real-life")
> explanation of real pros of the introduced repo-check, that would out-weight
> its cons, other than for example:
> {quote}The artifacts have an identity. It matters where the artifacts were
> downloaded from. Artifact A downloaded from X is not the same thing to Maven
> 3 as A downloaded from Y. This can happen when you flip your settings.xml to
> go from using a repository manager to using Maven Central directly for
> example.
> {quote}
> (taken from MNG-5289 comment)
> The logical question here is, to whom concretely "it matters"? Please, give
> examples of what could go wrong if one has downloaded a released version of
> an artifact and now its source repository changes or becomes unavailable.
> Please note that we shouldn't consider the very improbable case of artifacts
> downloaded from various repositories would have different content even though
> having the very same GAV. The Maven's local repository filesystem structure
> is not able to cope with that situation anyway, or is it?
> Finally, there is also a performance-wise con of the repo-check - Maven needs
> to contact the source repository every time it builds a project referencing
> the checked artifact as one of its dependencies. Or doesn't it?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
