Page Comparison

The Shibboleth developers are, from time to time, asked if we will publish our build artifacts to Maven Central. This page describes our position on the use of artifacts from, and on publishing artifacts to, Maven Central.

Issues with Maven and Maven Central

Maven itself has no support for validating signatures of artifacts (be they signed jars or jars with a detached PGP signature). It assumes that any repository from which artifacts are pulled is trusted and has properly vetted the artifacts before making them available.

Maven Central does not perform adequate vetting of the people uploading artifacts or the artifacts they upload. Thus, the integrity and origin of the artifacts therein is not known or verifiable. As an example, any OpenSAML artifacts currently uploaded to Maven Central are not provided by the Shibboleth project nor are they always even artifacts that we've released (i.e., the jars we know of there have been changed in some ways, though we have some general sense of what those changes were).

Taken together, the problems with this setup should be obvious.

Publishing to Maven Central

Because of the issues described above, the Shibboleth developers question the value of publishing product artifacts to Maven Central. We are, however, not specifically opposed to it. If other people aren't worried about the veracity of the artifacts they use that's on them. However, Maven Central does require that all the dependencies of an artifact also be in Maven Central and that is currently not the case for some of the Shibboleth products. So, for now, the Shibboleth product artifacts will not be published to Maven Central. This may change in the future as product dependencies and the state of those dependencies in Maven Central changesAs a project we have a number of concerns with Maven Central, but there is a practical consideration that outweighs the rest: their terms of service preclude us as individual developers from uploading anything there because of their requirement for indemnification. We are not at present a legal organization and the activities of the project are not covered by any organization’s liability shield. None of us, as individuals, are willing to assume that liability personally. (The same issue applies to GitHub, by the way.)

There are some other considerations:

• Not all of our dependencies are in Central anyway. If Central allowed us to upload them, one should rightly question their policies, and we would not be willing to do so in any event.

• We know for certain that Central has allowed unauthorized individuals or groups to upload artifacts they should not have been permitted to upload (e.g., this is exactly why older versions of OpenSAML ended up there, and we did not put them there). In fact, those artifacts weren’t even direct copies, they had been tampered with (not maliciously, but again, the lack of provenance should raise concerns with anybody immediately).

• While it is possible we could locate an individual willing to upload our software on our behalf, the lack of “permanence” of that approach makes it too big a risk to take, as we could without warning be unable to continue to maintain the artifacts there, and so requiring people to get them from us is the better solution for stability.

We realize that this creates an inconvenience for some projects, but we are not trying to cause you problems, this is simply the situation as it exists.

Should you choose to rely on any of our code, the instructions for doing so are under MavenRepositories.