Hi Cris, Sorry for taking so long to reply. tl;dr - I'm not opposed to validating signatures, and I think we need some tweaks to it.
On Mon, 2021-04-26 at 16:16 -0400, Cris Rockwell wrote: > > They are getting the Sling dependency from Maven Central, and they > > would also be betting > > the OpenSAML dependecies from Maven Central. > > I don’t think that's correct. With Shibboleth repo in the project pom > and Central being the default. Maven would fallback to Central for > artifacts not in the project (pom) or parent pom repositories. There > are no Sling artifacts in the Shib repo, so it would default to the > super pom (Central) for those. I noticed that the Shibboleth repo is actually hosting more artifacts than their own. Building locally I got org/apache/commons artifacts downloaded, but I think we should only get the shibboleth artifacts. Maybe use the releases group instead of the public one? https://build.shibboleth.net/nexus/content/repositories/releases/ > > > What do we actually gain with specifying another Maven repository? > > * We get unchanged OpenSAML libraries from the source and not > whatever some random dev has uploaded to Central. > * Secondly, using the Shibboleth repository allows the project to > update to the latest versions as they become available. > 4.0.1 was released in June 2020, but in Central on Feb 2021 > (~9 months lag) > 4.1.0 was released in Mar 2021 and not available in Central > * Central has an invalid signature for net.shibboleth.utilities:java- > support 8.0.0. Only when obtained from Shibboleth repo is the > signature for that artifact valid. After configuring pgpverify-maven- > plugin to verify signatures and removing the Shibboleth repo, in the > CI build was now broken again (I hope you’re happy :-) For some definition of happy, yes :-) > While the invalid signature was probably just a mistake, it shows how > artifacts in Central may not always be what they seem. By adding the > Shibboleth repository to the project, we are able to verify the > artifacts signatures during the build, if the build passes we have > piece of mind the proper artifacts were used and embedded. > * FYI It seems the Shib devs have now opened a ticket with Sonatype > asserting ownership of org.opensaml and net.shibboleth in attempt to > prevent others from uploading copies or fakes. If that happens, > Central may not receive new releases again, because the devs are > committed to the Shib repository as the canonical repo for their > stuff. Is that ticket public? I could not find anything on Maven Central. Nevertheless, I wouldd be _very_ concerned if they oppose distribution in any form, as that would be a license violation (IANAL, of course). > > 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? > > I asked the Shibboleth devs about making an OSGI version, but it’s > not a likely possibility at least at this point as they’re product > uses Spring Framework. They have some modularity in the Maven > structure, but it’s not modular in a technical Java sense. The Shib > devs strongly recommend against using bits and pieces. Ack. Do you have a public reference to that? Also, I am not sure how hard it is, but we could consider contributing an OSGi bundle to OpenSAML. Some projects have such a module which is basically a redistribution with a proper manifest. But that's something for the future. > > > > 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? > > Being the library that processes SAML payloads for a huge variety of > frameworks and applications, OpenSAML is a obvious target for bad > actors. Introducing malicious payloads in the SAML processing library > could have an affect across the sector in a large scale. Just as an > example, SolarWinds was an attack on SAML authentication and was a > supply-chain attack. > > Embedding OpenSAML means we have a responsibility to ensure that > proper artifacts are used. We also need to show respect for the > developers recommendations about how it should be used. > > In theory, all dependencies should be validated. It’s not a crazy > idea. Apache Sling projects generally don'y validate dependency > signatures, so where to begin? The obvious stuff like the auth and > security bundles, but then also the Sling artifacts themselves. > Feature Model should verify signatures of downloaded bundles if you > ask me. I would not agree here, but it's not critical to do so. My reasoning is that if we have a dependency that is on the authentication processing stack, e.g. OpenSAML using commons-lang, the commons-lang is also a an attack target. Any bundle that has loginAdministrative privileges is an attack target. OpenSAML just happens to be more visible. Anyway, agree to disagree, > > > > Are you trying to assert that the artifacts from Maven Central are > > the > > same ones as deployed on the Shibboleth repository? > > The fact that net.shibboleth.utilities has an invalid signature (in > Central) castes much doubt in my mind about whether we really want to > use that or other unverified things from Central. It is an > illustration of the problems with the Central repo; that forgeries > are apparently easy to do. I have never done that, and have no plans > to illustrate via “proof of concept" Ack. > > > > 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] > > I sent the developer DKulp an email about the invalid signature. > > > OK, let's see where that takes us. Do you have any updates on that? > > This comment was in response to the idea about validating signatures > of the artifacts using a map for fingerprints [0]. I think it’s a > good start. but pgpverify-maven-plugin also has an out-of-band map of > sig keys [1] which could be used as another example. > > Hopefully that helps explain why org.apache.sling.auth.saml2 has the > Shibboleth repository in the project pom. Yes, mostly, and I think we need a couple of items clarified. Thanks, Robert > > Regards > Cris > > [0] > https://github.com/apache/sling-org-apache-sling-auth-saml2/pull/1/commits/db8f93e0d866eb631f57178816e7645857265098#diff-be3e14e5394ba1f880a128897c3d36932f12e7bb793a7ca4e8de5801a95b64a9 > < > https://github.com/apache/sling-org-apache-sling-auth-saml2/pull/1/commits/db8f93e0d866eb631f57178816e7645857265098#diff-be3e14e5394ba1f880a128897c3d36932f12e7bb793a7ca4e8de5801a95b64a9 > > > [1] > https://github.com/s4u/pgp-keys-map/blob/master/resources/pgp-keys-map.list > < > https://github.com/s4u/pgp-keys-map/blob/master/resources/pgp-keys-map.list > > > > > > On Apr 26, 2021, at 4:41 AM, Robert Munteanu <[email protected]> > > wrote: > > > > 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 < > > > [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. > > > > 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 > > >
