Hi Cris, (I find that top-posting makes long conversations hard to follow, please try to reply inline)
On Fri, 2021-04-23 at 17:17 -0400, Cris Rockwell wrote: > 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' Ah, I see your point now. You would like to make sure that users get the 'right' OpenSAML dependencies. That raises a couple of questions: 1. Are the users getting the right Sling dependencies? They are getting the Sling dependency from Maven Central, and they would also be betting the OpenSAML dependecies from Maven Central. What do we actually gain with specifying another Maven repository? 2. Are we sure that when specifying a new repository in the pom, the looked up artifacts are coming from the shibboleth repository if they are hosted in Maven Central as well? Not sure that the artifact resolution order is. 3. I see we are embedding the OpenSAML jars. IIUC then the only protection is when running in Jenkins (for CI scenarios) and when the release manager creates a release. Users should not consume snapshots, so this is basically a protection from the release manager, right? 4. Instead of embedding, can the OpenSAML artifacts be deployed as OSGi bundles so that the responsibility is passed on to the user to obtain the OpenSAML bundles as they see fit? 5. What is the difference between a supply-chain attack on OpenSAML vs a supply-chain attack on any other bundle either coming from Apache Sling or other dependencies? > 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 < > d...@kulp.com>, J. Daniel Kulp <dk...@apache.org>, J. Daniel Kulp < > dk...@progress.com>, J. Daniel Kulp <dk...@talend.com>, J. Daniel Kulp > < > dan.k...@sopera.com>] > > 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. Are you trying to assert that the artifacts from Maven Central are the same ones as deployed on the Shibboleth repository? That would be a very good way of ensuring that we have the right artifacts. It would also be interesting to reach out to whoever uploaded the artifacts - AFAICT an ASF committer. The 'paper trail' regarding Maven Central/OpenSAML artifacts is at [4] [4]: https://issues.sonatype.org/browse/OSSRH-5729?jql=text%20~%20%22Shibboleth%22 > > 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. OK, let's see where that takes us. Thanks! Robert
