[prev in list] [next in list] [prev in thread] [next in thread]
List: bouncycastle-crypto-dev
Subject: Re: [dev-crypto] Problem with Java-9+
From: Uri Blumenthal <uri () mit ! edu>
Date: 2019-09-24 16:00:08
Message-ID: 6280BF2B-6971-4A9E-A20C-E21F67D71E8E () mit ! edu
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On Sep 24, 2019, at 8:50 AM, David Hook <dgh@cryptoworkshop.com> wrote:
>
> Still thinking.
>
> I'll admit it's a compelling case. It's a bit of an odd one though...
IMHO, nothing to think about, really. You have these options:
Remove explicit module definitions - unattractive for Java-9+, but likely to remain \
compatible across all the JDKs, as automatic module names would be assigned; Change \
module names to match the names of their corresponding JAR files - IMHO the best \
overall, as it both provides what's necessary for utilizing modules in Java-9+, and \
remains compatible across all the JDKs; Rename JAR files to match the new module \
names - breaks compatibility with the old projects, but the names would better match \
what they represent.
I don't think the status-quo is acceptable, as it's incompatible whichever way you \
look - the projects now must be aware of both what JDK you use, and what BC version \
you pull (the latter one is especially bad).
> The jdk15t018 jars are on maven as well.
Thanks!
> On 24/9/19 8:16 am, Uri Blumenthal wrote:
> > Any comment regarding my proposal/request? Can you change the module names to \
> > match JAR names (which, AFAICT, would address the problem I described)?
> > Uri Blumenthal
> > uri@mit.edu <mailto:uri@mit.edu>
> >
> >
> >
> > > On Sep 16, 2019, at 8:26 AM, Uri Blumenthal <uri@mit.edu <mailto:uri@mit.edu>> \
> > > wrote:
> > > On Sep 16, 2019, at 1:38 , David Hook <dgh@cryptoworkshop.com \
> > > <mailto:dgh@cryptoworkshop.com>> wrote:
> > > >
> > > > I'm afraid this has really turned out to be one of those dammed if you do, \
> > > > dammed if you don't kind of things.
> > >
> > > Well, yes - but I think there's a way.
> > >
> > > > If you look in bcprov-jdk15on for 1.60 you'll see:
> > > >
> > > > Automatic-Module-Name: org.bouncycastle.provider
> > > >
> > > > in the manifest, so the reality is module-info was actually introduced with \
> > > > backwards compatibility in mind. I think it was missing from the ext jar in \
> > > > that release.
> > >
> > > I don't know why - but it appears that this statement is ignored, at least by \
> > > Java-11 (or it's added only to bcprov-jdk15on, and not to bcprov-ext-jdk15on). \
> > > I believe this because I can pull bcprov-ext-jdk15on-160 from Maven, and use it \
> > > with my code that says "require bcprov.ext.jdk15on;"
> > >
> > > > You might want to use the *jdk15to18* jars instead.
> > >
> > > What are these? Are they on Maven? How do I refer to them?
> > >
> > >
> > > > I think originally the whole module/multi-release jar thing was envisioned as \
> > > > something that could just be slipped in without causing any unexpected side \
> > > > effects. It has turned out that nothing could have been further from the \
> > > > truth.
> > >
> > > Yes, I hear and understand you. I won't say here what I think of the new Java \
> > > module approach.
> > > Regardless, I think if you revert to module names matching their jar names \
> > > (i.e., "bcprov.ext.jdk15on" for bcprov-ext-jdk15on-163.jar, and such), it would \
> > > allow Java-11+ code to work with any version of BC jars - because in that case \
> > > Automatic module name (determined from the JAR name) would match what the \
> > > actual module name is.
> > > > Apologies,
> > >
> > > Accepted. ;)
> > >
> > > Could you please see if you can make module names match the JAR names?
> > >
> > > Thanks!
> > >
> > > > On 14/9/19 7:20 am, Uri Blumenthal wrote:
> > > > > Of course, I meant module name "bcprov.ext.jdk15on" - dots in the automatic \
> > > > > module name and dashes in it's file name translate into each other.
> > > > > Sent from my test iPhone
> > > > >
> > > > > On Sep 13, 2019, at 16:37, Uri the Great <uri@mit.edu <mailto:uri@mit.edu>> \
> > > > > wrote:
> > > > > > As I resurrected one of my Maven-based projects that retrieve \
> > > > > > BouncyCastle jars from the Maven Central, I discovered that bcprov-ext \
> > > > > > jars for 1.61+ are incompatible with the previous releases, in a way \
> > > > > > that's both bad and unnecessary.
> > > > > > Before 1.61, module-info.class was not added, so for Java-1.8 (and \
> > > > > > before) it worked as expected - and for Java-9+ it took the name of the \
> > > > > > jar file as the module name. So far so good - it worked with all the JDK \
> > > > > > around.
> > > > > > Now comes 1.61. Somebody decided that it's a good thing to give a special \
> > > > > > name to the bcprov module - org.bouncycastle.provider. So, the projects \
> > > > > > are no longer portable across different JDK and BC releases - because now \
> > > > > > they have to list dependency for org.bouncycastle.provider if they use BC \
> > > > > > 1.61+, or for bcprov-ext-jdk15on if they use BC 1.60 or earlier.
> > > > > > I think the correct solution would be to set module name to \
> > > > > > bcprov-ext-jdk15on (or bcprov-jdk15on correspondingly), if you want to be \
> > > > > > backward-compatible.
> > > > > > A nit: there's no JDK-1.9, so it might be better to rename your \
> > > > > > ...jdk1.9... to ...jdk-9... or ...jdk9...
> > > > > > P.S. Thanks for including add_module.sh. It's helpful. May I suggest \
> > > > > > changing export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 to something \
> > > > > > more dynamic, like export JAVA_HOME=`/usr/libexec/java_home -v 11`
> > > >
> > >
> >
>
[Attachment #5 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div \
class="">On Sep 24, 2019, at 8:50 AM, David Hook <<a \
href="mailto:dgh@cryptoworkshop.com" class="">dgh@cryptoworkshop.com</a>> \
wrote:</div><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><div \
class="moz-cite-prefix"><br class=""> </div>
<div class="moz-cite-prefix">Still thinking.</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">I'll admit it's a compelling case. It's
a bit of an odd one though... <br \
class=""></div></div></div></blockquote><div><br class=""></div>IMHO, nothing to \
think about, really. You have these options:</div><div><ul class="MailOutline"><li \
class="">Remove explicit module definitions - unattractive for Java-9+, but likely to \
remain compatible across all the JDKs, as automatic module names would be \
assigned;</li><li class="">Change module names to match the names of their \
corresponding JAR files - IMHO the best overall, as it both provides what's necessary \
for utilizing modules in Java-9+, <u class="">and</u> remains compatible across \
all the JDKs;</li><li class="">Rename JAR files to match the new module names - \
breaks compatibility with the old projects, but the names would better match what \
they represent.</li></ul><div class=""><br class=""></div><div class="">I don't think \
the status-quo is acceptable, as it's incompatible whichever way you look - the \
projects now must be aware of both what JDK you use, <u \
class="">and</u> what BC version you pull (the latter one is especially \
bad).</div><div class=""><br class=""></div><div class=""><br \
class=""></div><blockquote type="cite" class=""><div class=""><div text="#000000" \
bgcolor="#FFFFFF" class=""><div class="moz-cite-prefix"> </div>
<div class="moz-cite-prefix">The jdk15t018 jars are on maven as
well.</div></div></div></blockquote><div><br \
class=""></div>Thanks!</div><div><br class=""></div><div><br \
class=""></div><div><blockquote type="cite" class=""><div class=""><div \
text="#000000" bgcolor="#FFFFFF" class=""> <div class="moz-cite-prefix">On 24/9/19 \
8:16 am, Uri Blumenthal wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:DC035E17-7556-4CD8-8174-791803EB1A64@mit.edu" \
class="">
Any comment regarding my proposal/request? Can you change the
module names to match JAR names (which, AFAICT, would address the
problem I described)?
<div class=""><br class="">
<div class="">
<div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: \
12px; font-style: normal; font-variant-caps: normal; font-weight: normal; \
letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; \
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; \
text-decoration: none;" class="">Uri Blumenthal</div> <div style="caret-color: \
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; \
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: \
start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: \
0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a \
href="mailto:uri@mit.edu" class="" moz-do-not-send="true">uri@mit.edu</a></div> <div \
style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; \
font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: \
normal; text-align: start; text-indent: 0px; text-transform: none; white-space: \
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" \
class=""><br class=""> </div>
<br class="Apple-interchange-newline">
</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Sep 16, 2019, at 8:26 AM, Uri Blumenthal
<<a href="mailto:uri@mit.edu" class="" \
moz-do-not-send="true">uri@mit.edu</a>> wrote:</div> <br \
class="Apple-interchange-newline"> <div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode:
space; line-break: after-white-space;" class="">On Sep
16, 2019, at 1:38 , David Hook <<a \
href="mailto:dgh@cryptoworkshop.com" class="" \
moz-do-not-send="true">dgh@cryptoworkshop.com</a>> wrote:<br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">I'm afraid this has
really turned out to be one of those dammed if
you do, dammed if you don't kind of things.</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
Well, yes - but I think there's a way.</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<div class="moz-cite-prefix">If you look in
bcprov-jdk15on for 1.60 you'll see:</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">Automatic-Module-Name:
org.bouncycastle.provider</div>
</div>
</div>
</blockquote>
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">in the manifest, so
the reality is module-info was actually
introduced with backwards compatibility in
mind. I think it was missing from the ext jar
in that release.<br class="">
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">I don't know why - but it appears that
this statement is ignored, at least by Java-11 (or
it's added only to <b class="">bcprov-jdk15on</b>,
and <b class="">not</b> to <b \
class="">bcprov-ext-jdk15on</b>). I believe this because I can pull
bcprov-ext-jdk15on-160 from Maven, and use it with
my code that says "require bcprov.ext.jdk15on;"</div>
<div class=""><br class="">
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<div class="moz-cite-prefix"> </div>
<div class="moz-cite-prefix">You might want to
use the *jdk15to18* jars instead. </div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">What are these? Are they on Maven? How
do I refer to them?</div>
<div class=""><br class="">
</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<div class="moz-cite-prefix">I think originally
the whole module/multi-release jar thing was
envisioned as something that could just be
slipped in without causing any unexpected side
effects. It has turned out that nothing could
have been further from the truth.</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">Yes, I hear and understand you. I won't
say here what I think of the new Java module
approach.</div>
<div class=""><br class="">
</div>
<div class="">Regardless, I think if you revert to
module names matching their jar names (i.e.,
"bcprov.ext.jdk15on" for bcprov-ext-jdk15on-163.jar,
and such), it would allow Java-11+ code to work with
any version of BC jars - because in that case
Automatic module name (determined from the JAR name)
would match what the actual module name is.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<div class="moz-cite-prefix">Apologies,</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
Accepted. ;)</div>
<div class=""><br class="">
</div>
<div class="">Could you please see if you can make
module names match the JAR names?</div>
<div class=""><br class="">
</div>
<div class="">Thanks!</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<div class="moz-cite-prefix">On 14/9/19 7:20 am,
Uri Blumenthal wrote:<br class="">
</div>
<blockquote type="cite" \
cite="mid:E927692E-67C8-4699-9A2B-2FE7B5B753F4@mit.edu" class=""> Of course, I meant \
module name "bcprov.ext.jdk15on" - dots in the automatic
module name and dashes in it's file name
translate into each other.<br class="">
<br class="">
<div dir="ltr" class="">Sent from my test
iPhone</div>
<div dir="ltr" class=""><br class="">
On Sep 13, 2019, at 16:37, Uri the Great
<<a href="mailto:uri@mit.edu" moz-do-not-send="true" \
class="">uri@mit.edu</a>> wrote:<br class="">
<br class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" class=""><p class="">As I resurrected one \
of my Maven-based projects that retrieve
BouncyCastle jars from the Maven
Central, I discovered that bcprov-ext
jars for 1.61+ are incompatible with the
previous releases, in a way that's both
bad and unnecessary.</p><p class="">Before 1.61, <i \
class="">module-info.class</i> was not added, so for Java-1.8 (and
before) it worked as expected - and for
Java-9+ it took the name of the jar file
as the module name. So far so good - it
worked with all the JDK around.</p><p class="">Now \
comes 1.61. Somebody decided that it's a good thing to give a
special name to the bcprov module - <i \
class="">org.bouncycastle.provider</i>. So, the projects are no longer portable
across different JDK and BC releases -
because now they have to list dependency
for <i class="">org.bouncycastle.provider</i>
if they use BC 1.61+, or for <i \
class="">bcprov-ext-jdk15on</i> if
they use BC 1.60 or earlier.</p><p class="">I think \
the correct solution
would be to set module name to <i \
class="">bcprov-ext-jdk15on</i> (or <i class="">bcprov-jdk15on</i> correspondingly), \
if you want to be
backward-compatible.</p><p class="">A nit: there's no \
JDK-1.9, so it might be better to rename your ...<i class="">jdk1.9... </i>to <i \
class="">...jdk-9...</i> or <i class="">...jdk9...</i></p><p class="">P.S. Thanks for \
including <i class="">add_module.sh</i>. It's
helpful. May I suggest changing <i class="">export
JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64</i>
to something more dynamic, like <i class="">export
JAVA_HOME=`/usr/libexec/java_home -v
11`</i><br class="">
</p>
</div>
</blockquote>
</blockquote><p class=""><br class="">
</p>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote><p class=""><br class="">
</p>
</div>
</div></blockquote></div><br class=""></body></html>
["smime.p7s" (smime.p7s)]
0 *H
010
`He 0 *H
W00" ]\:0
*H
010U Forest CA RSA 40
190820182446Z
220820182446Z010U
Uri the Great0"0
*H
0
#ޝ߂P7~:~]R זh!NOX%% !b}JZm x B
N'ˁяS2]UDYnW@":gm"$
|~XjHXd8[~fa2rmέ ) \
;ɵ|~ǃ53DvzxƤkTmQ-R*"P!gRb-,u}!ESƮ Z8}ٔ8>lp"(}k4 nN6ѣ 00 U 0 0U \
0U 0 uri@mit.edu0 U AJ s Y0/U %(0&+
+7
+U % 0
*H
A9Atȝm_6'M !=KAL
QjHEsv,.'v(H905Xx~jKL
ʸp3DηQφ~րC{ |5m(k E@at b0 \
n/rq 46HQ~{Nn]zn+L~kduf("Y8\H gNʃָ \
16=I!a,ǁ Qg3 )t?U *Xx5CDù P=QM*?
Nțp>qF~~R
0Rh\P<g4Ƹ.~TYk}i 19R9rıt 0 0 W0
*H
010U Forest CA RSA 40
160719204400Z
250719204400Z010U Forest CA RSA 400
*H
0 e \
Wв!{r ! 0y= Vs9vވ4{CdۦgJLdPfla<郮3Nme [ueWa \
ڜc39i8Ddb4Phfͫ<'k;b a;5i!)ٜ~2~2U*f){]wβ>
㓐$?0~ e!]v!tn&叱r_lDtw x ˆ=]nә JKX \
[ X38Di8i 8F`rXk+E\ ђܰ3y,^6~C,M \
jO!cqH-h\@pS_ m0k0U 00U 0EU #>0<sv~hn1l 010U Forest \
CA RSA 4W0 *H
(f* ݊foؤRdÆűSp/,Ndq,
)B' ?<EQ?ԁAwg~"m4Z\G9t=+3X/nxc ̬.bPE|K:c?'r#R9߱T_?/Gf=dT%flBa^WR Qh;kwTzU}ڷKfFl
]]DGmG9mLF58 *ylGw`ޥtl
h)EkN4X:n0*Ta`J'/{ K
~
`ΫC Q ,M:f8.o+H٩a/*[JHẁ͓D \
F}'<.`mB6 0r0 ]\80 *H
010U Forest CA RSA 40
190820181515Z
220820181515Z010U
Uri the Great0"0
*H
0
oVVё c\
g
ĨmLgNM ;*UIepQHL3 :Wu=_4v1Ck*T?:"J 4D \
jr@UϿЉQzp k H›}ckHdvn~Xg!Ϧ=Tꔏf|0\B.qwNٟV. _zg,wT \
HZBJmsuqD}4I27`JRꗃF \
4Q`^ @0<0 U 0 0U 0U 0 \
uri@mit.edu0U #0}z2z 8aYtY~}{0y10U Forest CA ECC \
410U
The Burrow10U Gatherers1 0 U MA1 0 UUS10 *H
uri@mit.edu0 U u5ңG s+u0>U %705++
+7
*H/+0
*H
9Do5-p# JTC/9hQp4~K vTޘӵwK
`8y:iH[(rә:?"ߓ)Fdp<!A^IsU@ \
/rrVgE$ &|Pj WdZ7 )xan,ҿ~,DRI sw->7e6RG \
m^Wf}Ntw( \
xˆ##c:eD+H6Ssuy3͇ dP@"r)9:+6+V@ɔe6:FR y \
5zKo[ }v#W 3X}W*cv[ "'nW.1!0 0"010U Forest CA RSA 4]\80
`He 0 *H
1 *H
0 *H
1
190924160008Z0/ *H
1" 2)t8߷~~Eįg
7]'01 +71$0"010U Forest CA RSA 4]\:03 *H
1$ "010U Forest CA RSA 4]\:0
*H
(wŤQkf،;Q>Iez9$|;.<*
͜_I7 \
B&y#_N+u- aVS{u0&1 Az)D<nGqPS/ \
z n~F3v+w)ObO ' a LEvsNrm \
'E~q啕FeGn4xq0RԂwNj(Ai" D
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic