olamy commented on issue #590:
URL: https://github.com/apache/mina-sshd/issues/590#issuecomment-2323096474
> Re: property:
>
> If I understand it right, the BC classes are there (with the same package
names), but the provider name is not BC but BCFIPS? If so, all we have to do is:
>
I didn't check but I would not rely on BC and BCFIPS using the same classes
(BCRandon is already different :))
> * De-couple the registrar name ("BC") from the security provider name
("BC" or "BCFIPS")
> * Use "BC" only if we want to get the registrar, and otherwise use the
provider's name.
>
> Then we don't need a property for this.
>
> Re: ServiceLoader and OSGi:
>
> ServiceLoader in an environment where there are partitioned classloaders
(like OSGi, or Plexus classworlds) can be made to work. In OSGi, a very simple
approach is to place services in fragments for the host bundle
(org.apache.sshd.osgi in that case). Classes in fragments get put on the
bundle's class path and are accessible via the normal BundleClassloader, so
they will be found. We use that in JGit extensively. Otherwise, using an SPI
bridge like SPI Fly is an option.
>
> Using ThreadUtils and manual classloading doesn't prevent these problems.
>
> I'd go with ServiceLoader for a possible override, and otherwise silently
fall back to JceRandom if the BC random cannot be used. `BouncyCastleRandom`
should implement `OptionalFeature`, and test whether the needed BC classes are
present in its `isSupported()` method.
`BouncyCastleRandomFactory.isSupported()` should then just forward to
`BouncyCastleRandom.isSupported()`. And `SecurityUtils.getRandomFactory()` can
then become
>
Sounds good. And no real need of ServiceLoader.
> ```
> // Optionally use serviceloader to load some override
> if (isBouncyCastleRegistered() &&
BouncyCastleRandomFactory.INSTANCE.isSupported()) {
> return BouncyCastleRandomFactory.INSTANCE;
> }
> return JceRandomFactory.INSTANCE;
> ```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
