Re: Problem with Java-9+
Uri Blumenthal <[email protected]> Tue, 24 Sep 2019 16:00:08 +0000
| Newsgroups | gmane.comp.encryption.bouncy-castle.devel |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail=_256AD213-B4D9-4877-8AC5-AB822CB56692 Content-Type: multipart/alternative; boundary="Apple-Mail=_65F23E96-4BD9-4CD9-B1F7-D3B6A390CD9E" --Apple-Mail=_65F23E96-4BD9-4CD9-B1F7-D3B6A390CD9E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 24, 2019, at 8:50 AM, David Hook <dgh-rTAZ0PM/[email protected]> = wrote: >=20 > Still thinking. >=20 > I'll admit it's a compelling case. It's a bit of an odd one though...=20= 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=E2=80=99s 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=E2=80=99t think the status-quo is acceptable, as it=E2=80=99s = 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)? >>=20 >> Uri Blumenthal >> [email protected] <mailto:[email protected]> >>=20 >>=20 >>=20 >>> On Sep 16, 2019, at 8:26 AM, Uri Blumenthal <[email protected] = <mailto:[email protected]>> wrote: >>>=20 >>> On Sep 16, 2019, at 1:38 , David Hook <dgh-rTAZ0PM/[email protected] = <mailto:dgh-rTAZ0PM/[email protected]>> wrote: >>>>=20 >>>> 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. >>>=20 >>> Well, yes - but I think there=E2=80=99s a way. >>>=20 >>>> If you look in bcprov-jdk15on for 1.60 you'll see: >>>>=20 >>>> Automatic-Module-Name: org.bouncycastle.provider >>>>=20 >>>> 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. >>>=20 >>> I don=E2=80=99t know why - but it appears that this statement is = ignored, at least by Java-11 (or it=E2=80=99s 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 =E2=80=9Crequire bcprov.ext.jdk15on;" >>>=20 >>>=20 >>>> You might want to use the *jdk15to18* jars instead. >>>=20 >>> What are these? Are they on Maven? How do I refer to them? >>>=20 >>>=20 >>>> 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. >>>=20 >>> Yes, I hear and understand you. I won=E2=80=99t say here what I = think of the new Java module approach. >>>=20 >>> Regardless, I think if you revert to module names matching their jar = names (i.e., =E2=80=9Cbcprov.ext.jdk15on=E2=80=9D 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. >>>=20 >>>> Apologies, >>>=20 >>> Accepted. ;) >>>=20 >>> Could you please see if you can make module names match the JAR = names? >>>=20 >>> Thanks! >>>=20 >>>> 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. >>>>>=20 >>>>> Sent from my test iPhone >>>>>=20 >>>>> On Sep 13, 2019, at 16:37, Uri the Great <[email protected] = <mailto:[email protected]>> wrote: >>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> A nit: there's no JDK-1.9, so it might be better to rename your = ...jdk1.9... to ...jdk-9... or ...jdk9... >>>>>>=20 >>>>>> P.S. Thanks for including add_module.sh. It's helpful. May I = suggest changing export JAVA_HOME=3D/usr/lib/jvm/java-11-openjdk-amd64 = to something more dynamic, like export JAVA_HOME=3D`/usr/libexec/java_home= -v 11` >>>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_65F23E96-4BD9-4CD9-B1F7-D3B6A390CD9E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" = class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On = Sep 24, 2019, at 8:50 AM, David Hook <<a = href=3D"mailto:dgh-rTAZ0PM/[email protected]" = class=3D"">dgh-rTAZ0PM/[email protected]</a>> wrote:</div><div class=3D""><div= text=3D"#000000" bgcolor=3D"#FFFFFF" class=3D""><div = class=3D"moz-cite-prefix"><br class=3D""> </div> <div class=3D"moz-cite-prefix">Still thinking.</div> <div class=3D"moz-cite-prefix"><br class=3D""> </div> <div class=3D"moz-cite-prefix">I'll admit it's a compelling case. = It's a bit of an odd one though... <br = class=3D""></div></div></div></blockquote><div><br class=3D""></div>IMHO, = nothing to think about, really. You have these options:</div><div><ul = class=3D"MailOutline"><li class=3D"">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=3D"">Change module names to match the names of their = corresponding JAR files - IMHO the best overall, as it both provides = what=E2=80=99s necessary for utilizing modules in Java-9+, <u = class=3D"">and</u> remains compatible across all the JDKs;</li><li = class=3D"">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=3D""><br class=3D""></div><div = class=3D"">I don=E2=80=99t think the status-quo is acceptable, as it=E2=80= =99s incompatible whichever way you look - the projects now must be = aware of both what JDK you use, <u class=3D"">and</u> what BC = version you pull (the latter one is especially bad).</div><div = class=3D""><br class=3D""></div><div class=3D""><br = class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><div= text=3D"#000000" bgcolor=3D"#FFFFFF" class=3D""><div = class=3D"moz-cite-prefix"> </div> =20 <div class=3D"moz-cite-prefix">The jdk15t018 jars are on maven as well.</div></div></div></blockquote><div><br = class=3D""></div>Thanks!</div><div><br class=3D""></div><div><br = class=3D""></div><div><blockquote type=3D"cite" class=3D""><div = class=3D""><div text=3D"#000000" bgcolor=3D"#FFFFFF" class=3D""> <div class=3D"moz-cite-prefix">On 24/9/19 8:16 am, Uri Blumenthal wrote:<br class=3D""> </div> <blockquote type=3D"cite" = cite=3D"mid:DC035E17-7556-4CD8-8174-791803EB1A64-3s7WtUTddSA@public.gmane.org" class=3D""> =20 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=3D""><br class=3D""> <div class=3D""> <div style=3D"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=3D"">Uri Blumenthal</div> <div style=3D"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=3D""><a href=3D"mailto:[email protected]" class=3D"" = moz-do-not-send=3D"true">[email protected]</a></div> <div style=3D"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=3D""><br class=3D""> </div> <br class=3D"Apple-interchange-newline"> </div> <div class=3D""><br class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D"">On Sep 16, 2019, at 8:26 AM, Uri Blumenthal <<a href=3D"mailto:[email protected]" class=3D"" = moz-do-not-send=3D"true">[email protected]</a>> wrote:</div> <br class=3D"Apple-interchange-newline"> <div class=3D""> =20 <div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">On Sep 16, 2019, at 1:38 , David Hook <<a = href=3D"mailto:dgh-rTAZ0PM/[email protected]" class=3D"" = moz-do-not-send=3D"true">dgh-rTAZ0PM/[email protected]</a>> wrote:<br class=3D""> <div class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div text=3D"#000000" bgcolor=3D"#FFFFFF" = class=3D""> <div class=3D"moz-cite-prefix"><br class=3D""> </div> <div class=3D"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=3D""><br class=3D""> </div> Well, yes - but I think there=E2=80=99s a way.</div> <div class=3D""><br class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div text=3D"#000000" bgcolor=3D"#FFFFFF" = class=3D""> <div class=3D"moz-cite-prefix">If you look in bcprov-jdk15on for 1.60 you'll see:</div> <div class=3D"moz-cite-prefix"><br class=3D""> </div> <div = class=3D"moz-cite-prefix">Automatic-Module-Name: org.bouncycastle.provider</div> </div> </div> </blockquote> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div text=3D"#000000" bgcolor=3D"#FFFFFF" = class=3D""> <div class=3D"moz-cite-prefix"><br class=3D""> </div> <div class=3D"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=3D""> </div> </div> </div> </blockquote> <div class=3D""><br class=3D""> </div> <div class=3D"">I don=E2=80=99t know why - but it = appears that this statement is ignored, at least by Java-11 (or it=E2=80=99s added only to <b = class=3D"">bcprov-jdk15on</b>, and <b class=3D"">not</b> to <b = class=3D"">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 =E2=80=9Crequire = bcprov.ext.jdk15on;"</div> <div class=3D""><br class=3D""> </div> <br class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div text=3D"#000000" bgcolor=3D"#FFFFFF" = class=3D""> <div class=3D"moz-cite-prefix"> </div> <div class=3D"moz-cite-prefix">You might want to use the *jdk15to18* jars instead. </div> </div> </div> </blockquote> <div class=3D""><br class=3D""> </div> <div class=3D"">What are these? Are they on Maven? How do I refer to them?</div> <div class=3D""><br class=3D""> </div> <br class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div text=3D"#000000" bgcolor=3D"#FFFFFF" = class=3D""> <div class=3D"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=3D""><br class=3D""> </div> <div class=3D"">Yes, I hear and understand you. I = won=E2=80=99t say here what I think of the new Java module approach.</div> <div class=3D""><br class=3D""> </div> <div class=3D"">Regardless, I think if you revert to module names matching their jar names (i.e., =E2=80=9Cbcprov.ext.jdk15on=E2=80=9D 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=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div text=3D"#000000" bgcolor=3D"#FFFFFF" = class=3D""> <div class=3D"moz-cite-prefix">Apologies,</div> </div> </div> </blockquote> <div class=3D""><br class=3D""> </div> Accepted. ;)</div> <div class=3D""><br class=3D""> </div> <div class=3D"">Could you please see if you can make module names match the JAR names?</div> <div class=3D""><br class=3D""> </div> <div class=3D"">Thanks!</div> <div class=3D""><br class=3D""> </div> <div class=3D""> <blockquote type=3D"cite" class=3D""> <div class=3D""> <div text=3D"#000000" bgcolor=3D"#FFFFFF" = class=3D""> <div class=3D"moz-cite-prefix">On 14/9/19 7:20 = am, Uri Blumenthal wrote:<br class=3D""> </div> <blockquote type=3D"cite" = cite=3D"mid:E927692E-67C8-4699-9A2B-2FE7B5B753F4-3s7WtUTddSA@public.gmane.org" class=3D""> 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=3D""> <br class=3D""> <div dir=3D"ltr" class=3D"">Sent from my test iPhone</div> <div dir=3D"ltr" class=3D""><br class=3D""> On Sep 13, 2019, at 16:37, Uri the Great <<a href=3D"mailto:[email protected]" = moz-do-not-send=3D"true" class=3D"">[email protected]</a>> wrote:<br class=3D""> <br class=3D""> </div> <blockquote type=3D"cite" class=3D""> <div dir=3D"ltr" class=3D""><p class=3D"">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=3D"">Before 1.61, <i class=3D"">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=3D"">Now comes 1.61. Somebody decided that it's a good thing to give a special name to the bcprov module - <i = class=3D"">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=3D"">org.bouncycastle.provider</i> if they use BC 1.61+, or for <i = class=3D"">bcprov-ext-jdk15on</i> if they use BC 1.60 or earlier.</p><p = class=3D"">I think the correct solution would be to set module name to <i = class=3D"">bcprov-ext-jdk15on</i> (or <i class=3D"">bcprov-jdk15on</i> correspondingly), if you want to be backward-compatible.</p><p class=3D"">A = nit: there's no JDK-1.9, so it might be better to rename your ...<i = class=3D"">jdk1.9... </i>to <i class=3D"">...jdk-9...</i> or <i = class=3D"">...jdk9...</i></p><p class=3D"">P.S. Thanks for including <i = class=3D"">add_module.sh</i>. It's helpful. May I suggest changing <i = class=3D"">export = JAVA_HOME=3D/usr/lib/jvm/java-11-openjdk-amd64</i> to something more dynamic, like <i = class=3D"">export JAVA_HOME=3D`/usr/libexec/java_home -v 11`</i><br class=3D""> </p> </div> </blockquote> </blockquote><p class=3D""><br class=3D""> </p> </div> </div> </blockquote> </div> <br class=3D""> </div> </div> </blockquote> </div> <br class=3D""> </div> </blockquote><p class=3D""><br class=3D""> </p> </div> </div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_65F23E96-4BD9-4CD9-B1F7-D3B6A390CD9E-- --Apple-Mail=_256AD213-B4D9-4877-8AC5-AB822CB56692 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDFcw ggO6MIICIqADAgECAgRdXDruMA0GCSqGSIb3DQEBCwUAMBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBS U0EgNDAeFw0xOTA4MjAxODI0NDZaFw0yMjA4MjAxODI0NDZaMBgxFjAUBgNVBAMMDVVyaSB0aGUg R3JlYXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCrm/Qckv0j3p3fgutQujd+On6j 7F39glKg15ZotSHpTk8Xv/xYJa8lEwWmCyFi7J19Soj2BYKB6VpthB/0eAlCiApOlJnzJ8nsosuB 0Y9TMl1VRLXl/6NZboXFV6cYQNQioRE6A45nbSITxSQNgnydflhq6oIWSOJYZDhbzH7kh2bgD2Ey hoNybc6ttakg7CmswjvtuKnJtYjRfH7Hg+E19uL1vMfAM8URRIfh8Ih2evzTeKHJxqT0a9JUbfxR LY5SlSoi8fXJBvLvUBCT57chZ1JihS2yLHWofRIhRVPGrgtaOLt92ZT4OIk+bHDPIiikfb3VazQc lW4QkU42BNGjAgMBAAGjgYkwgYYwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBSAwFgYDVR0R BA8wDYELdXJpQG1pdC5lZHUwHQYDVR0OBBYEFI+4HtpBG/H0lMsFmvZKC8BzEwxZMC8GA1UdJQQo MCYGCCsGAQUFBwMEBgorBgEEAYI3CgMEBggrBgEFBQcDBgYEVR0lADANBgkqhkiG9w0BAQsFAAOC AYEAQdPfOUER5cfr6q90yJ1tooYbnOFfwMUCtjaBJ5pNCaeQIT24f+xLQYDykkwZDVG+quGP/vH3 i4xqh5QS5BOVEoOC2Rm4SEW7c+27diwuJ3YoSDkXkjDMNc5YqYMBmHh+aktM4uQK0SDKuHCN4TNE zrf6UfvPhn7WgLtDp5d7wqaP/7Z8NbZt6ygIawlFQGF0hcQM4WL76jCEvakf/4y0IG7wmy+tzHIC ca0DADQ2SJdRysh+e05uXf16st1uK+QbgsDxTH5r5WR1pBJmhigItpoig7JZOItcSMvCqWfwwxcW nskWTsqD1rjs0/nCMTaYPUmwIWEsrseB9h2UUWczjBwpdIw/VbKKDBMqWN3KeNk1Q0TDub8NDLqL /PSMwJEGUD0RllGm/U3EKj/PDU7Im3CaFz7RcUb/tRGE8c7JftgDfq/NGMHzUoLRDTDmUoRon1xQ PGeqNBrGuC5+AwLT81RZa32v5dTZaY8cB5ExOVI5mOe67Kdyl87EsXQVC537MIIEHzCCAoegAwIB AgIEV46QmjANBgkqhkiG9w0BAQsFADAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQwHhcNMTYw NzE5MjA0NDAwWhcNMjUwNzE5MjA0NDAwWjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQwggGi MA0GCSqGSIb3DQEBAQUAA4IBjwAwggGKAoIBgQCLzmWmgdsgFFfQsiEXrgXYf3v38MG/cvUJ6iEd lTB5/j0L6FZzvP45dozeiAPhNP67y3uFQ2T2EtumZ0pMh2RQZoHv+BHjAgj+bGE81+mDrvYzBN7j TrQCbZRlk++lHlsal8R15mVXt8BhII7p2py9iWOw7uP4M/TPOX/P2WnuOL0CgUSOpGRi9jRQtWjQ ZtEEg82riTymJ2vTO2L8/Aul6AZhmTs10mkhxinZnNV+Mq+5fvfqMlWWKmYp9Htd9Jt3zrLu4j4N 45OQ+g/iJD/KMH4AZSHS5V12IaT03HRuJha+6OWPsfFyBotfCGxEgnR3q8P5mh+ZeAcLy4bEPbpd buXTmbiToPhKS1jw773rIFuRyQtYieozOMpEv7O8xmnQOP9pwrf4mTjaxUbGYBDXchr8WBDfayuv CEWuXCDRkoCtr9ywM7p5LMncXja3kpB+Q/YsTc6gHtUdzMbtC2qr108hiqLBY6GT5wZxSBct6GgP AVxAFeHXcPi/y+lTX48CAwEAAaNtMGswEgYDVR0TAQH/BAgwBgEB/wIBAjAOBgNVHQ8BAf8EBAMC AYYwRQYDVR0jBD4wPIAU7/uCc4t2fhUIaG6ajuyj5zEGl2yhHqQcMBoxGDAWBgNVBAMMD0ZvcmVz dCBDQSBSU0EgNIIEV46QmjANBgkqhkiG9w0BAQsFAAOCAYEAKGaFGYyqxxeQKs5/zAsc3YqjZrbV b9ikFVJkw4a1xbFTcMn4rKalsC8sThTFAcBkccos3QopQifTHow/PEWtUamif6k/4sfUgUGMd2d+ It8QA2000FqVmlyXRzkWotUPm3Q9FCszhcBYyS9u23gEYx0atsysEy4OYo/VUMDoB4nRAxpFCPe8 +nxL9IPa7P06/Rhjqqb9PydyI1I5DpDfsa1Umfr+1F8/l6wBL0caZqY9nmSPVCVmk2xC9gHXYV5X UgnbUbVoO2uFd1R6VX3at0uIZtlGtWydHwrgXV1Eop3FDkfQbc5HOQZtTEbONTiihgALuvgqefrm qmyWR3ekYN6ldGzoCuRoKUXla4jRTjRYOm4wKlTQ1GG7YI1KJ5kve7sASw0d1X4NgmDOq8Dr2UOU yh0XUQnyCCxNOmY4xwebkMYY/i5vj/7lFQPXF6wrzdTySNaQ2anAYX/h4cwvpipbSki0d82TwcyA RIjK2Q8gRrZ96Sc8LmCibUI2H6LaMIIEcjCCAtqgAwIBAgIEXVw4szANBgkqhkiG9w0BAQsFADAa MRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQwHhcNMTkwODIwMTgxNTE1WhcNMjIwODIwMTgxNTE1 WjAYMRYwFAYDVQQDDA1VcmkgdGhlIEdyZWF0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAvwNvlFZWidGRix31Y3+PXJQJDWcNxKizq22UTANnTk22HTsqVZsThkmWn8EOrmVwUUj94utM Mx2fOld1ij1fDjT6doUxQ/yH8dRrBCr+VD+FwaIarZM6ipQivZ9KIOr7lzSJlrnIRLLCasjmckBV +8+/0IlRlXpwH2uUC6CWSK3G4oC6fWPBCGv0jJKtSOG/ZHbTbrx+EljqovpnIc+mPQfxs1TqlI8Q ZsB8MO1cQrCaFQIuccR3TtmfElYuGBULBaKEX3pn4BMsqIt3VBkgSMRaqNAXQkptc3Wvl9FxRH35 +KjY5TRJwPsyN66mYPVKUu3s6peDRtkKNFEZYL1e6wIDAQABo4IBQDCCATwwDAYDVR0TAQH/BAIw ADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0RBA8wDYELdXJpQG1pdC5lZHUwgaQGA1UdIwSBnDCBmYAU Fn16h/mFtTJ6zR845WEHWXRZjX6hfaR7MHkxGDAWBgNVBAMMD0ZvcmVzdCBDQSBFQ0MgNDETMBEG A1UECgwKVGhlIEJ1cnJvdzESMBAGA1UECwwJR2F0aGVyZXJzMQswCQYDVQQIDAJNQTELMAkGA1UE BhMCVVMxGjAYBgkqhkiG9w0BCQEWC3VyaUBtaXQuZWR1ggIGxzAdBgNVHQ4EFgQUdTXSo0eioSCs o5DdFcKllnMrdZ0wPgYDVR0lBDcwNQYIKwYBBQUHAwIGCCsGAQUFBwMDBgorBgEEAYI3CgMMBgkq hkiG9y8BAQUGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBgQA5/dJEb401FdYtoaGucCOLqe7Y 2AlKVEPdxt0bkMPtsC85mPScaKdRlP71DnCCNJDGfkvxIHZUq7ezFN6Y4qQD/4MX0sHTtXe4Swpg OBbKwHk6aUiPvutb8+TEKP0QorJyEtOZ/xrU1TqixAGQPyKz3PKjuxrE35MpRvJ/iWQU57FwPCGU QV5Jm4dzVc1AtSDeL3JyVsv8icnEZ7PAuZ++Ra4kHt34JnxQzhCkaqN/hAyO2w5X0xPKZIJaN9n5 7u8eKeh4EWFupSzSv37ZEpcs4hNEFQFSSQOjHbBzrPr6Gp7zd6Pxky3RPjdlNt9SFsYZ+6mkCEfC beleV2Z9xvdOpoZ0AYd32yiL4PogBXjLhqkjI2M6kGWjA0QrSDbuU44Pc3WBnXn1fzPNhwuhl/ui ZLLFG1AZQMXqInIpOReZOiuwNitWQJblssmUuP3cZTY6RlK374r+HvB5CjV6S81vkFsdFQPUxH3h dvYjpVeFHTNYfVcq6GN2Ww0iJ9FuVy4xggIhMIICHQIBATAiMBoxGDAWBgNVBAMMD0ZvcmVzdCBD QSBSU0EgNAIEXVw4szANBglghkgBZQMEAgEFAKCB0TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xOTA5MjQxNjAwMDhaMC8GCSqGSIb3DQEJBDEiBCAy8Sl0OIah37d+ yRd+RcSvZ9nYCpzUN10nFhXFGuH2kjAxBgkrBgEEAYI3EAQxJDAiMBoxGDAWBgNVBAMMD0ZvcmVz dCBDQSBSU0EgNAIEXVw67jAzBgsqhkiG9w0BCRACCzEkoCIwGjEYMBYGA1UEAwwPRm9yZXN0IENB IFJTQSA0AgRdXDruMA0GCSqGSIb3DQEBAQUABIIBALx/lIu5KMZ368WkjlGdn2tmvtiM0s2+4FE+ SdZl4qjS5+O+ejm4ECR8O5bmmOUugLymvTzs65MqgQrzEKKQCZPgzZx/0MlfDqaQtaO1mZyPSTce IEImeSPk6F9OK6+X538E53UtAA5h7Fa+llOTe7ED0HUw3H+5GybzvfizMQlBBdJ6KUQP3DxuAxIZ 7PeDfw6AxsNHcVBTiC8gevrB3QxufkaKrzN2kit3kIybKev2T2KyqE/j+x4JJwzx4AZhmhLg+Psg TL+blpOMRXZzTnJtwifiRX62cdTk0+WVlaNGZQ9HboY0eBq/+LJxMFLUgvV39ceLGuDgKOVBaSIf 6UQAAAAAAAA= --Apple-Mail=_256AD213-B4D9-4877-8AC5-AB822CB56692--