Hi Robert There are a few things the Shibboleth devs wanted to reinforce with me. A) They don’t upload artifacts to Maven Central. The canonical way to get their latest libraries is through the Shibboleth repo. The v4.0.1 was uploaded to Central by other parties, and they don't know anything about it. B) Given that supply-chain attacks happen more frequently (e.g. SolarWinds, npm issues, etc), it’s important to actually validate the dependency artifact’s signatures during the build. C) Maven Central has 'no well-defined provenance and no in-band signature check in all builds'
After adding a plugin (pgpverify-maven-plugin) which checks dependency signatures, I have to agree. The build failed when due to invalid dependency signatures https://ci-builds.apache.org/blue/organizations/jenkins/Sling%2Fmodules%2Fsling-org-apache-sling-auth-saml2/detail/PR-1/2/pipeline [ERROR] net.shibboleth.utilities:java-support:pom:8.0.0 PGP Signature INVALID KeyId: 0x51B52DC5DD452F92BE342CC2858FC4C4F43856A3 UserIds: [J. Daniel Kulp < [email protected]>, J. Daniel Kulp <[email protected]>, J. Daniel Kulp < [email protected]>, J. Daniel Kulp <[email protected]>, J. Daniel Kulp < [email protected]>] For me, ensuring against dependency supply-chain attacks is more important than choosing to trust certain repositories inherently. As a test, I added the Shib repo back to ensure that the build passes with dependency signatures checking. The plugin provides a warning... No keysmap specified in configuration or keysmap contains no entries. PGPVerify will only check artifacts against their signature. File corruption will be detected. However, without a keysmap as a reference for trust, valid signatures of any public key will be accepted. So, I would actually like to provide a key mapping for the OpenSAML library and clear that warning. Regards Cris On Apr 23, 2021, at 10:52 AM, Robert Munteanu <[email protected]> wrote: Hi Cris, On Fri, 2021-04-23 at 09:31 -0400, Cris Rockwell wrote: The OpenSAML library was selected because of the support the Shibboleth Consortium has within higher education[0]. My institution is a member of the consortium. I am confident about the ongoing support the project has and the maintenance it receives now and in the future. When it comes to using the OpenSAML library, it’s necessary to follow the guidelines about obtaining legitimate versions of the artifacts[1] That means using library artifacts provided by the Shibboleth Repository, and not using the OpenSAML artifacts from Maven Central. It’s also important to use the library for all parts of the process when it comes to SAML protocols [2] This requires providing lots of dependencies, which the library requires First of all, I don't see the choice of external libraries as an issue, I am sure that you have chosen well. My only concern is that the recommendation of not having repositories and build repositories defined for artifacts deployed to Maven Central. The official requirements [3] state that: In addition we discourage the usage of <repositories> and <pluginRepositories> and instead publish any required components to the Central Repository. This applies for your own components as well as for 3rd party artifacts. The downsides to using a third party repository are: - if the Shibbboleth Maven repository is retired, our artifacts become invalid - some organisations have strict procurement rules and would require vetting additional repositories In the end, I don't think it's a blocker but we should avoid third party repositories if at all possible. However, I have filed a PR [4] that removes the extra Maven repository and the build still passes. If the repository is not actually needed, the whole discussion is moot :-) Thanks, Robert [3]: https://central.sonatype.org/publish/requirements/ [4]: https://github.com/apache/sling-org-apache-sling-auth-saml2/pull/1
