It’s an idea I also started a while back, but the problem is, it is not really a good security as long as you do the checksum Test before executing any plugins, which is a bit hard to do. You find some older sample code here https://github.com/ecki/lockdep-maven-plugin
Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Robert Scholte <rfscho...@apache.org> Gesendet: Dienstag, November 20, 2018 7:48 PM An: Maven Users List Betreff: Re: Ensuring artifact integrity with artifact pinning Hi, seems related to MNG-6026[1]. thanks, Robert [1] https://issues.apache.org/jira/browse/MNG-6026 On Tue, 20 Nov 2018 12:26:54 +0100, Andrew Todd <a...@auspicacious.org> wrote: > Hello all, > > I am considering writing a Maven plugin to help improve confidence in the > integrity of the Maven artifacts used by a project. I'm looking for > feedback on this idea before I start working on it, hopefully this > winter. > > Here's a brief overview of what I have in mind. > > Maven, like many other package and artifact managers, doesn't offer > particularly strong protections against the compromise of artifacts. The > situation has improved somewhat in the last few years, as more people > have > paid attention to the problem. When the central repository enabled HTTPS > for everyone, it was a big step forward -- it's now much harder for > someone > to deliver a malicious package to you by intercepting your Web traffic, > for > instance. Central also requires code signing when artifacts are uploaded, > which helps prevent the uploading of malicious artifacts somewhat. > > However, it's my understanding that there's no useful way for Maven > clients > to check those signatures -- not to mention that there's still other ways > that a malicious or malformed package could be served to a Maven client. > And any dependency in your application is a potential attack vector. > > You may have heard of Certificate Pinning: > https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning, which adds a > trust-on-first-use aspect to HTTPS certificates (and was not quite the > right solution for the problem it was helping to solve; it's now > deprecated). > > What I propose is a similar idea, but for Maven artifacts. When this > plugin > is enabled, each Maven build will generate a manifest of all artifacts > that > that build depends on, along with the hashes for all of those artifacts. > This manifest could be committed into source control alongside the POM > file. From that point on, the artifact is considered "pinned" to that > hash > value. If the plugin observes that any of the hashes it has already > pinned > have changed, the build will fail until a developer investigates and > corrects the problem. > > Aside from improving trust, using this plugin could also help > troubleshoot > "works on my machine" errors with more transparency into the actual > artifacts used in the build than is present in current tools such as mvn > help:dependency-tree. > > Of course, this wouldn't work for SNAPSHOTs. I'm not sure how much more > improvement can be made there. This plugin would also be inappropriate > for > environments where artifacts are routinely overwritten -- which is really > not a good idea anyway. With more work the plugin could be configured to > ignore specific artifacts. > > In the future, this plugin could also support publishing the manifest > alongside your artifact in Central, so that someone else who depends on > your artifact can determine that all transitive dependencies have been > retrieved identically to how they were by the original developer. > > With a lot more support in the longer-term, this could move in the > direction that Certificate Transparency has, towards public logs: > https://en.wikipedia.org/wiki/Certificate_Transparency > > These measures, if adopted widely by Maven users, could help detect > unexpected changes to artifacts in Central early, as well as help expose > build stability problems. Building trust in computing is an incremental > problem, and this would help move things a little in the right direction, > in a backwards-compatible fashion. > > I'd like to hear your thoughts and suggestions -- not to mention hearing > if > you'd be interested in adopting such a tool. Obviously there's a number > of > details to hammer out. > > > Thanks, > Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
