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
