Re: Problem with Java-9+

Uri Blumenthal <[email protected]> Mon, 23 Sep 2019 22:16:25 +0000
Newsgroups gmane.comp.encryption.bouncy-castle.devel
Message-ID <[email protected]>
--Apple-Mail=_687C8A84-4E33-4D83-BE5D-7A49D166C342
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_9F327787-C051-4686-8526-E7CB6DF7B9C2"


--Apple-Mail=_9F327787-C051-4686-8526-E7CB6DF7B9C2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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
[email protected]



> On Sep 16, 2019, at 8:26 AM, Uri Blumenthal <[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


--Apple-Mail=_9F327787-C051-4686-8526-E7CB6DF7B9C2
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"">Any =
comment regarding my proposal/request? &nbsp;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); color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; =
text-decoration: none;">Uri Blumenthal</div><div style=3D"caret-color: =
rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; text-decoration: none;"><a =
href=3D"mailto:[email protected]" class=3D"">[email protected]</a></div><div =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><br =
class=3D""></div><br class=3D"Apple-interchange-newline">
</div>
<div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Sep 16, 2019, at 8:26 AM, Uri Blumenthal &lt;<a =
href=3D"mailto:[email protected]" class=3D"">[email protected]</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><meta =
http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8" =
class=3D""><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 &lt;<a href=3D"mailto:dgh-rTAZ0PM/[email protected]" =
class=3D"">dgh-rTAZ0PM/[email protected]</a>&gt; 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"">
   =20
    <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=99=
s added only to <b class=3D"">bcprov-jdk15on</b>, and <b =
class=3D"">not</b>&nbsp;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>
   =20
    <div class=3D"moz-cite-prefix">You might want to use the&nbsp; =
*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"">
   =20
    <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"">
     =20
      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 &lt;<a =
href=3D"mailto:[email protected]" moz-do-not-send=3D"true" =
class=3D"">[email protected]</a>&gt;
        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></body></html>=

--Apple-Mail=_9F327787-C051-4686-8526-E7CB6DF7B9C2--

--Apple-Mail=_687C8A84-4E33-4D83-BE5D-7A49D166C342
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
MBwGCSqGSIb3DQEJBTEPFw0xOTA5MjMyMjE2MjBaMC8GCSqGSIb3DQEJBDEiBCCmJrh8YntgLB7m
GzAJ3NJ1JjYNvFygOzJ1sh/SQqEr2TAxBgkrBgEEAYI3EAQxJDAiMBoxGDAWBgNVBAMMD0ZvcmVz
dCBDQSBSU0EgNAIEXVw67jAzBgsqhkiG9w0BCRACCzEkoCIwGjEYMBYGA1UEAwwPRm9yZXN0IENB
IFJTQSA0AgRdXDruMA0GCSqGSIb3DQEBAQUABIIBACFSWkXjLydBkw2xtZFSLQwYZAsp3l267tE4
aaulmt8C5tCIlXK6fUlY3tLbDUjVS0IzBpdlnijdO0aBVuyTkVJnVcQ6iC3AA26BK+xDu5WDpHfV
8srm8z2TlOm4bk8HljrtIOLv6zIootBw42Xx0M1SBO1XUVmfh6r6sznBREP7T+vp3bM1dqsUpo62
yCwx+nMXewKZricrsIe+ynB4xfXvuz5W+FcCcdzfdSyZdEQ2LQ2jnz8LcYo/71pgc7DKNwSZQat1
yqGsycOQBZoaKNJ6aVGimfAqzzH+y+9QSbyKtD1tMAQSB1EOqlzzBawc4O5dpoUkfUNW7UFCLJ1D
fYMAAAAAAAA=

--Apple-Mail=_687C8A84-4E33-4D83-BE5D-7A49D166C342--