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.) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
