Hi
This is lot. So thanks to all who might be following this.
> 1. Are the users getting the right Sling dependencies?
Maybe or maybe not. That’s why verifying the artifacts’ signatures is
important. I added fingerprint files for Sling and Shibboleth to the SAML
project, so at least this bundle verifies those artifacts. Sling's artifacts
are not embedded (their scope is provided), so that’s not super important in
that case. Sig verification of the OpenSAML dependency is actually of higher
importance because they’re included in the release of the bundle.
> 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.
> 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 :-)
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.
> 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.
Yes, the order of multiple repositories is defined in the maven docs. When
searching for artifacts, it would look first to the project pom.xml
(Shibboleth), then parent pom (Apache Snapshots) and then to the super pom
(Maven Central). This shows it `mvn help:effective-pom -Dverbose` also `mvn
clean install -U` shows the sources downloaded.
> 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?
That’s correct. I would argue quite necessary as the SolarWinds attack deep
drive below shows that build and release processes are critical junctures.
https://owasp.org/www-chapter-singapore/assets/presos/Deconstructing_the_Solarwinds_Supply_Chain_Attack_and_Deterring_it_Honing_in_on_the_Golden_SAML_Attack_Technique.pdf
<https://owasp.org/www-chapter-singapore/assets/presos/Deconstructing_the_Solarwinds_Supply_Chain_Attack_and_Deterring_it_Honing_in_on_the_Golden_SAML_Attack_Technique.pdf>
> 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.
> 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.
> 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"
> 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.
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.
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 <romb...@apache.org> 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 <
>> 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
>
