Thanks for the pointers. It's also worth noting that Google's build tool Bazel allows users to list an artifact sha1 as part of the artifact definition, although it's not particularly automated. They consider it important: "It is a security risk to omit the SHA-1 as remote files can change." https://docs.bazel.build/versions/master/be/workspace.html#maven_jar
On Wed, Nov 21, 2018 at 4:01 AM Bernd Eckenfels <e...@zusammenkunft.net> wrote: > 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 > >
