Using crypto in J11 and removing bouncycastle requires code changes. Not sure how to do that other than branching.
On Mon, May 25, 2020 at 11:14 AM Matt Sicker <[email protected]> wrote: > By far the easiest way to do it is via a separate maven module. It just > adds another jar dependency. Alternatively, you can use the maven > dependencies plugin to copy in code from another module to make an > aggregate one (how we package a multi version jar in log4j2 at least). > > On Mon, May 25, 2020 at 02:15 Emmanuel Lecharny <[email protected]> > wrote: > >> Hi Matt, >> >> we could modify the build to generate distinguish packages for the >> various JAVA version (at least for the LTS supported versions, like >> Java 11 and Java 14). >> >> The thing is that we added some Jenkins tasks for Java 11 and 14n, and >> MINA tests fail with those versions, so there are thing we need to >> investigate before cutting a new release. >> >> Not that it should forbid us to get those specific versions though, >> it's just that we need to get that fixed first. >> >> Regarding the build process, I can foresee the usage of profiles to >> get those specific packages cut. However, we need to find a way to >> have a common code base, with a way to make the extensions optional. >> That probably mean excluding some specific java file from being >> compiled in Java 8 - assuming we can limit the impact on just a few >> added files -. >> Or maybe a separate maven module ? >> >> On Sun, May 24, 2020 at 7:44 PM Matt Sicker <[email protected]> wrote: >> > >> > 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] >> > >> >> >> -- >> Regards, >> Cordialement, >> Emmanuel Lécharny >> www.iktek.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> -- > Matt Sicker <[email protected]> >
