[WFCORE-7142] Upgrade BouncyCastle from 1.79 to 1.80

[yersan]

Jira issue: https://issues.redhat.com/browse/WFCORE-7142

[yersan]

@jamezp @jimma Could you approve from your side?

[darranl]

I think we need to pick this up again this year and ideally look at how to separate BouncyCastle from the project that calls it .

If to start we can wrap it behind some form of SPI maybe we can write sufficient tests against the SPI to demonstrate it has not changed.

[jamezp]

I think we need to pick this up again this year and ideally look at how to separate BouncyCastle from the project that calls it .

If to start we can wrap it behind some form of SPI maybe we can write sufficient tests against the SPI to demonstrate it has not changed.

This makes sense to be @darranl

[yersan]

@jimma Could you review this?

[yersan]

I think we need to pick this up again this year and ideally look at how to separate BouncyCastle from the project that calls it .
If to start we can wrap it behind some form of SPI maybe we can write sufficient tests against the SPI to demonstrate it has not changed.

This makes sense to be @darranl

@darranl / @jamezp I'm not sure if I am following correctly. Are the affected components that use Bouncy Castle getting it from a WildFly Core version or are they getting Bouncy Castle as an independent dependency?

My understanding is we want WildFly Core to provide an SPI with a set of tests in the WildFly Core testsuite to verify the blackguard compatibility of that SPI, and then use that SPI in the third-party components (RESTEasy and Webservices). The ultimate goal is to avoid wanting to get third-party components' test suite results when we are upgrading Bouncy Castle in WildFly Core. Is that the plan you suggest?

[jamezp]

@yersan I can only speak for RESTEasy and my personal preference there is to remove Bouncy Castle all together. I don't think RESTEasy can have a dependency on WildFly Core, so if the SPI lived there it wouldn't likely be able to use it.