Issue with upgrade from OpenSAML 4.0.1 to 5.1.3

[Brent Putman]

On 3/6/25 11:50 AM, Rohit Soni via dev wrote:
>
>
> We are looking to migrate from 4.0.1 to 5.1.3 , we are seeing issues 
> with bouncycastle libraries , as we see bc-fips and bcprov-jdk18on 
> both in classpath ,


OpenSAML has never shipped with any dependency on the BC FIPS library.  
So if the FIPS variant is there, it's because of something you are 
doing locally. (And use of BC FIPS isn't formally supported, btw, and 
has numerous issues.)


> when doing Initialization its complaining about "package sealing 
> violation" , because "org.bouncycastle.crypto" package is present in 
> both the jars


Yes, if both are present on the classpath then that error would make 
sense if you are now using a version of Java that supports the Java 
package system (IIRC was Java 9+).


> and we cannot remove any of them from classpath , this issue was not 
> there in 4.0.01 , because opensaml-xmlsec which is used 
> during Initialization , did not have depndency on bcprov-jdk18on , 
> but now in 5.1.3 , that dependency is introduced ,


Not correct.  For many many years OpenSAML has always had a Maven 
'compile' dependency on BC.  I checked and OpenSAML 4.0.1 shipped with 
a compile dependency on bcprov-jdk15on v1.64.  (Their artifact naming 
of "jdkXon" is just about the Java 'target' version for the binary 
artifact.)


> have you guys seen this issue before? , any recommendations ?
>

Not exactly this, but it's not surprising based on what you described. 
AFAIK with modern version of Java that support the package system, you 
can't have both on the classpath. (And doesn't make sense to do so, for 
obvious reasons.)

The bc-fips is coming from something you are doing locally. You need to 
decide if you really want to continue doing that, given that at this 
time it is not officially supported by us.

And as I mentioned there are numerous issues with trying to just 
replace bcprov-jdkXon with the bc-fips variant. Search the list 
archives to get an idea of what you are up against there.

Thanks,
Brent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20250306/fa7e0d53/attachment.htm>