It appears that I assumed a ticket existed for this particular issue, but it doesn't. This is about SSHD in particular. In order to support the following:
https://issues.apache.org/jira/browse/SSHD-594 https://issues.apache.org/jira/browse/SSHD-811 https://issues.apache.org/jira/browse/SSHD-704 Similarly to support the [email protected] cipher, https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL.chacha20poly1305?annotate=HEAD All these issues either require using crypto APIs added in Java 11 or relying on dependencies (I assume there's no desire to maintain cipher implementations here). In Log4j, we've solved some of this problem by using multi-release jars to add version-specific support for newer APIs. In this case, we could include optional support for the JDK APIs when running a new enough JDK; otherwise, the fallback can use Bouncycastle-specific APIs where necessary. However, configuring a Maven project appropriately for multi-version jars is a pain, so I was wondering if there were any plans on going this route anywhere? On Sun, 24 May 2020 at 12:11, Jonathan Valliere <[email protected]> wrote: > > I’m not sure what Mina project or specific problem you’re referring to. > > On Sun, May 24, 2020 at 12:22 PM Matt Sicker <[email protected]> wrote: > > > In order to support ChaCha20-Poly1305, Java 11 is required, or a backport > > of the cipher and mac to Java 8 like in Bouncycastle (whose java > > implementation is based on an unrolled optimized C version). > > > > I was wondering if there was any way to package optional things for multi > > release jars so that we could support ChaCha without requiring BC on Java > > 11+? > > -- > > Matt Sicker <[email protected]> > > -- Matt Sicker <[email protected]> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
