Hi Robert > Maybe use the releases group instead of the public one? > https://build.shibboleth.net/nexus/content/repositories/releases/ > <https://build.shibboleth.net/nexus/content/repositories/releases/>Yes that’s > a good idea.
> Is that ticket public? I could not find anything on Maven Central. I haven’t seen the ticket either. > Nevertheless, I wouldd be _very_ concerned if they oppose distribution > in any form, as that would be a license violation (IANAL, of course). I don’t think they oppose distribution. OpenSAML and Shibboleth libraries have Apache 2 license <https://www.apache.org/licenses/LICENSE-2.0.html> according to the website and source code. So there is no legal worry about distribution or redistribution as the Apache license allows that. But the Shibboleth devs warn that if you get the library from other distributions, 'then it is on you’ to verify the veracity of the artifacts <https://wiki.shibboleth.net/confluence/display/DEV/Use+of+Maven+Central>. > Ack. Do you have a public reference to that? There’s a few records of my communications with the shib team Regarding modularity and OSGi... https://shibboleth.1660669.n2.nabble.com/Modular-Installation-in-the-IdP-tt7645931.html <https://shibboleth.1660669.n2.nabble.com/Modular-Installation-in-the-IdP-tt7645931.html> Regarding Central... https://shibboleth.1660669.n2.nabble.com/OpenSAML-v4-0-1-Artifacts-in-Central-Repository-tt7649256.html <https://shibboleth.1660669.n2.nabble.com/OpenSAML-v4-0-1-Artifacts-in-Central-Repository-tt7649256.html> > 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. Ack > 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. * > 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? Thanks Cris
