On Wed, 2021-05-19 at 15:10 -0400, Cris Rockwell wrote: > > 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. > Ack. Regarding validation of dependency signatures, my thinking has > changed a little bit. I think there are two types to consider: jars > embedded in bundle, dependencies provided by OSGi. Validating embeds > is a job for the bundle or project doing the embedding. Dependencies > provided by OSGi framework is a framework problem, which deserves a > prototype in the whiteboard. Transient dependencies are either > embedded or provided, so I think there are two types for the sake of > argument. Embedded jars should probably have their signatures > validated during build and release to demonstrate that the proper > version was embedded. Or if the project embeds alternative or > shadowed jars, then the developers should be really transparent about > that. *
I mostly agree with your statements. Plain compile-time dependencies we build our bundles against and don't embed only affect the manifest generation and internal details of the compiled class files. Embedded classes and bundles we distribute using the Sling Starter feature archives, Docker images, etc, should be validated. If we were to start checking signatures it for everything we fall back to the old classic web of trust idea - do we actually trust the GPG signatures we are validating against? I think we should do this only for selected dependencies where we really know the GPG signatures are good. OpenSAML is I think one project where we can rely on the published GPG keys, and Apache projects as well. But I would not start checking signatures for everything we embed/distribute. On top of that, I think that we should make it easier for various project to check signatures and move as much configuration as possible in the parent pom, so ideally we only need to declare a new execution in the child modules and configure the artifacts to check. > > > > Do you have any updates on that? > > Yes. I’m paraphrasing the response... > "The shibboleth folks ... refused to publish anything to central. ... > I’ve been the one publishing it to central, but in order to do that, > the pom has to be modified to remove the repository section. I then > have to resign the pom. The signature IS correct for the pom in > central. Thus, if you delete your org/shibboleth and org/opensaml > stuff from your ~/.m2/repository and force downloading from central > (remove references to the shibboleth repo), then it works and > verifies correctly." > > > Technically, we may be able to use and validate the opensaml.org and > shibboleth.net artifacts from Central if we remove the shib repo from > the pom.xml and force an update to CI's .m2. However, for a lot of > the reasons previously stated, I’m not in favor of doing that. I > would rather take the agreement to use Shibboleth's public release > repo, and validate signatures for all the embedded jars. Does this > sound OK? Yes, sounds OK to me. It's not ideal, but hopefully it will not impact consumers. Thanks, Robert
