Ok Thanks for the clarification.

Let me take a bit of time to review the hashes. 

For example, comparing this
        
https://build.shibboleth.net/nexus/content/groups/public/org/opensaml/opensaml-xmlsec-impl/4.0.1/opensaml-xmlsec-impl-4.0.1.jar.sha1
to this
        
https://repo1.maven.org/maven2/org/opensaml/opensaml-xmlsec-impl/4.0.1/opensaml-xmlsec-impl-4.0.1.jar.sha1

The example above shows this artifact hash is the same, so maybe it’s fine to 
get it from Central.
I'll just reach out to the Shibboleth dev team to get their thoughts.

Cris 



> On Apr 23, 2021, at 10:52 AM, Robert Munteanu <romb...@apache.org> wrote:
> 
> Hi Cris,
> 
> On Fri, 2021-04-23 at 09:31 -0400, Cris Rockwell wrote:
>> The OpenSAML library was selected because of the support the Shibboleth
>> Consortium has within higher education[0].
>> My institution is a member of the consortium. I am confident about the
>> ongoing support the project has and the maintenance 
>> it receives now and in the future. 
>> 
>> When it comes to using the OpenSAML library, it’s necessary to follow
>> the guidelines about obtaining legitimate versions of the artifacts[1]
>> That means using library artifacts provided by the Shibboleth
>> Repository, and not using the OpenSAML artifacts from Maven Central.
>> 
>> It’s also important to use the library for all parts of the process
>> when it comes to SAML protocols [2]
>> This requires providing lots of dependencies, which the library
>> requires
> 
> First of all, I don't see the choice of external libraries as an issue,
> I am sure that you have chosen well.
> 
> My only concern is that the recommendation of not having repositories
> and build repositories defined for artifacts deployed to Maven Central.
> The official requirements [3] state that:
> 
>   In addition we discourage the usage of <repositories> and
>   <pluginRepositories> and instead publish any required components to the
>   Central Repository. This applies for your own components as well as for
>   3rd party artifacts.
> 
> The downsides to using a third party repository are:
> 
> - if the Shibbboleth Maven repository is retired, our artifacts become
> invalid
> - some organisations have strict procurement rules and would require
> vetting additional repositories
> 
> In the end, I don't think it's a blocker but we should avoid third
> party repositories if at all possible.
> 
> However, I have filed a PR [4] that removes the extra Maven repository
> and the build still passes. If the repository is not actually needed,
> the whole discussion is moot :-)
> 
> Thanks,
> Robert
> 
> [3]: https://central.sonatype.org/publish/requirements/
> [4]: https://github.com/apache/sling-org-apache-sling-auth-saml2/pull/1
> 

Reply via email to