[
https://issues.apache.org/jira/browse/MRESOLVER-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608228#comment-17608228
]
ASF GitHub Bot commented on MRESOLVER-268:
------------------------------------------
raphw commented on PR #191:
URL: https://github.com/apache/maven-resolver/pull/191#issuecomment-1254893057
As for the overhead: I use a Maven extension today that does the same thing
- that is evaluating the sha256 of each file - and it causes an overhead of
about 300 milliseconds on a build time of about 1 minute and 10 seconds. I
think this is defensible; assuming that people can choose to not provide
checksums.
As for the local repository: the easiest "hack" is to define a custom
repository is a settings.xml. But this will trigger a new download on each
build, and not everybody can rely on GitHub Actions, even though they get it
right.
From a security perspective, the best model is one of zero trust. And the
beauty of being able to evaluate checksums upon resolution is that you do not
need to trust the build server to be configured correctly. All you need to do
is to create a Maven project, and all code that is loaded from outside the
project will be evaluated to be legitimate, independent of the build server's
setup.
As for making this an extension: this is a bit of a chicken and egg problem.
the extension needs to be downloaded, and normally is via Maven Central. If
this extension is invalid, the security model is broken. This is why I would
want it to be a part of Maven Resolver. If Maven Wrapper is validating the
checksums of its downloaded artifacts, the validation chain would be complete
and a zero trust model is established for any Maven build. (Gradle offers the
same feature.)
> Apply artifact checksum verification for any resolved artifact
> --------------------------------------------------------------
>
> Key: MRESOLVER-268
> URL: https://issues.apache.org/jira/browse/MRESOLVER-268
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
> Reporter: Rafael Winterhalter
> Assignee: Tamás Cservenák
> Priority: Major
>
> Maven resolver currently only verifies provided checksums (via
> ProvidedChecksumsSource) when artifacts are downloaded from a remote
> repository. While this strategy is efficient when working with a clean local
> repository, it can create problems if two Maven projects share a local
> repository, where only one project validates hashes. If the first project has
> downloaded a corrupted artifact, the second project would now use this
> corrupted artifact despite knowing a non-matching checksum.
> With the proposed change, artifacts are validated whenever they are resolved.
> This allows to retain the integrity of a project also when sharing a local
> Maven repository with other, unsecured projects.
> The current PR only activates this general validation if a global validation
> policy is defined.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
