Grzegorz Grzybek created SSHD-1145:
--------------------------------------
Summary: EdDSASecurityProviderRegistrar#isSupported() should check
more classloaders
Key: SSHD-1145
URL: https://issues.apache.org/jira/browse/SSHD-1145
Project: MINA SSHD
Issue Type: Improvement
Reporter: Grzegorz Grzybek
I'm working for Karaf and Camel fix that would allow me to use ssh-ed25519 for
server key.
EdDSA is supported via net.i2p.crypto/eddsa library, but its availability is
checked in a way that is not correct (and not only in OSGi environment).
It's is also problematic for BouncyCastleSecurityProviderRegistrar, but
actually for all methods that use
{{org.apache.sshd.common.util.threads.ThreadUtils#resolveDefaultClassLoader(java.lang.Class<?>)}}.
{{resolveDefaultClassLoader()}} method result is a classloader which is checked
for availability of e.g., "net.i2p.crypto.eddsa.EdDSAKey" class, but the check
result is cached statically. The problem is that if TCCL is used (which is
generally not defined in OSGi) it may be a false negative.
More precisely - if in Karaf, I start Karaf's own sshd server with a TCCL that
_sees_ {{net.i2p.crypto.eddsa}} package, I can use EdDSA algorithm.
If I add camel-ssh usage, it _may_ have own TCCL (depending on how Camel is
started - e.g., through OSGi blueprint) - the first one who calls
{{org.apache.sshd.common.util.security.eddsa.EdDSASecurityProviderRegistrar#isSupported()}}
_wins_.
I'll work on a way to check more classloaders in search for given
provider/registrar and send a PR soon.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
