Bouncy Castle's S/Mime library and the future of the JavaMail project

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Bouncy Castle's S/Mime library and the future of the JavaMail project

Paul Stanley-2
Hello.

I've been looking at the work going on with the Jakarta EE 9 platform which is due for release in a few weeks' time.  As part of that release they have had to change the package names of the Java Mail platform from javax.mail to jakarta.mail.  I assume that this is due to some legal issues as the management of the libraries has moved from Oracle to Eclipse. Of course, this creates all sorts of compatibility issues that will plague us for the next few years.  Most of these issues can be addressed automatically by editing the byte code as the classes are loaded into the various platforms.
However I don't expect that this technique will work on the Bouncy Castle's S/Mime library, as it is has been signed and sealed in such a way that prevents us from simply repacking the code.

As such I was wondering if there are any plans to produce a JEE9 version of the bc-mail library?

Cheers
Paul
Reply | Threaded
Open this post in threaded view
|

Re: Bouncy Castle's S/Mime library and the future of the JavaMail project

Lothar Kimmeringer-4


Am 28.08.2020 um 16:55 schrieb Paul Stanley:
> However I don't expect that this technique will work on the Bouncy Castle's S/Mime
> library, as it is has been signed and sealed in such a way that prevents us from
> simply repacking the code.

It's signed and sealed but you can actually remove that and do changes to it
becasue it's not a jar that contains provider classes that are added to
Java's security framework.

BTDT

Not that I see that as a longterm solution, though.


Cheers, Lothar

Reply | Threaded
Open this post in threaded view
|

Re: Bouncy Castle's S/Mime library and the future of the JavaMail project

Paul Stanley-2
Thanks Lorhar.  I will have a go at repacking the library next week and see if works.

Cheers
Paul

Lothar Kimmeringer <[hidden email]> wrote on 28/08/2020 16:56:01:

> Am 28.08.2020 um 16:55 schrieb Paul Stanley:
> > However I don't expect that this technique will work on the Bouncy
> Castle's S/Mime
> > library, as it is has been signed and sealed in such a way that
> prevents us from
> > simply repacking the code.
>
> It's signed and sealed but you can actually remove that and do changes to it
> becasue it's not a jar that contains provider classes that are added to
> Java's security framework.
>
> BTDT
>
> Not that I see that as a longterm solution, though.
>
>
> Cheers, Lothar
>
Reply | Threaded
Open this post in threaded view
|

Re: Bouncy Castle's S/Mime library and the future of the JavaMail project

Paul Stanley-2
Hello,

Just to to let you know that I have repackaged the bc-mail library to remove the code-signature and our S/Mime test suite has run without any issues.  However, I'm currently not in a position to test the library in a Jakarta EE9 container, however there doesn't appear to be any reason for this not to work.

I am not too sure what the long term plans are for the JEE9 platform.  I can image that it will take many years for it to be widely supported, as such I can only suggest that third party libraries such as bcmail, will need to start producing two versions or find an alternative Mime API.

Cheers
Paul

"Paul Stanley" <[hidden email]> wrote on 28/08/2020 17:32:31:

> From: "Paul Stanley" <[hidden email]>

> To: [hidden email], <[hidden email]>
> Date: 28/08/2020 17:33
> Subject: Re: [dev-crypto] Bouncy Castle's S/Mime library and the
> future of the JavaMail project

>
> Thanks Lorhar.  I will have a go at repacking the library next week
> and see if works.
>
> Cheers
> Paul
>
> Lothar Kimmeringer <[hidden email]> wrote on 28/08/2020 16:56:01:
>
> > Am 28.08.2020 um 16:55 schrieb Paul Stanley:
> > > However I don't expect that this technique will work on the Bouncy
> > Castle's S/Mime
> > > library, as it is has been signed and sealed in such a way that
> > prevents us from
> > > simply repacking the code.
> >
> > It's signed and sealed but you can actually remove that and do changes to it
> > becasue it's not a jar that contains provider classes that are added to
> > Java's security framework.
> >
> > BTDT
> >
> > Not that I see that as a longterm solution, though.
> >
> >
> > Cheers, Lothar
> >
Reply | Threaded
Open this post in threaded view
|

Re: Bouncy Castle's S/Mime library and the future of the JavaMail project

Martijn Brinkers (list)-2
On Tue, 2020-09-01 at 16:43 +0100, Paul Stanley wrote:

> Just to to let you know that I have repackaged the bc-mail library to
> remove the code-signature and our S/Mime test suite has run without
> any issues.  However, I'm currently not in a position to test the
> library in a Jakarta EE9 container, however there doesn't appear to
> be any reason for this not to work.
>
> I am not too sure what the long term plans are for the JEE9 platform.
>  I can image that it will take many years for it to be widely
> supported, as such I can only suggest that third party libraries such
> as bcmail, will need to start producing two versions or find an
> alternative Mime API.

I still don't understand why they decided to rename the packages
because it breaks a lot of existing products.

If BC decides to support the new Jakarta packages, it might be
worthwhile to see whether a wrapper API can be used which
translates the calls to the underlying implementation. The API provides
interfaces and two implementations, one for javamail and one for
jakarta. Then the application can decide which actual implementation
should be used. Since BC only uses a subset of javamail, this might
work.

Kind regards,

Martijn Brinkers



Reply | Threaded
Open this post in threaded view
|

Re: Bouncy Castle's S/Mime library and the future of the JavaMail project

mauromol
Il 02/09/20 11:38, Martijn Brinkers (list) ha scritto:
>
> I still don't understand why they decided to rename the packages
> because it breaks a lot of existing products.

They were forced by Oracle holding the exclusive ownership of the
original java.* and javax.* namespaces.

See, for instance: https://www.infoq.com/news/2019/05/end-of-javax-package/

--

Mauro Molinari
E-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Bouncy Castle's S/Mime library and the future of the JavaMail project

David Hook-3
In reply to this post by Martijn Brinkers (list)-2

Yes, I don't know, in this case it sounds like we're dammed if we do and
dammed if we don't.

Paul, with the changes required, is this something that could just be
accommodated with a script that's run on the source? If that's the case
having a bcmail-jak jar might be the way to go.

Thanks,

David

On 2/9/20 7:38 pm, Martijn Brinkers (list) wrote:

> On Tue, 2020-09-01 at 16:43 +0100, Paul Stanley wrote:
>> Just to to let you know that I have repackaged the bc-mail library to
>> remove the code-signature and our S/Mime test suite has run without
>> any issues.  However, I'm currently not in a position to test the
>> library in a Jakarta EE9 container, however there doesn't appear to
>> be any reason for this not to work.
>>
>> I am not too sure what the long term plans are for the JEE9 platform.
>>  I can image that it will take many years for it to be widely
>> supported, as such I can only suggest that third party libraries such
>> as bcmail, will need to start producing two versions or find an
>> alternative Mime API.
> I still don't understand why they decided to rename the packages
> because it breaks a lot of existing products.
>
> If BC decides to support the new Jakarta packages, it might be
> worthwhile to see whether a wrapper API can be used which
> translates the calls to the underlying implementation. The API provides
> interfaces and two implementations, one for javamail and one for
> jakarta. Then the application can decide which actual implementation
> should be used. Since BC only uses a subset of javamail, this might
> work.
>
> Kind regards,
>
> Martijn Brinkers
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Bouncy Castle's S/Mime library and the future of the JavaMail project

Paul Stanley-2
Hi David.

Yes it will be possible to script the source code changes, as it is only the package import statements that need to change.  It would appear that it was just a name change, as they haven't even removed the deprecated methods or classes.
As yet no one seems to know what the eclipse foundation plans are for these projects, so at some point we may see breaking changes made to these APIs.

Cheers
Paul




From:        David Hook <[hidden email]>
To:        [hidden email]
Date:        03/09/2020 06:02
Subject:        Re: [dev-crypto] Bouncy Castle's S/Mime library and the future of the JavaMail project





Yes, I don't know, in this case it sounds like we're dammed if we do and
dammed if we don't.

Paul, with the changes required, is this something that could just be
accommodated with a script that's run on the source? If that's the case
having a bcmail-jak jar might be the way to go.

Thanks,

David

On 2/9/20 7:38 pm, Martijn Brinkers (list) wrote:
> On Tue, 2020-09-01 at 16:43 +0100, Paul Stanley wrote:
>> Just to to let you know that I have repackaged the bc-mail library to
>> remove the code-signature and our S/Mime test suite has run without
>> any issues.  However, I'm currently not in a position to test the
>> library in a Jakarta EE9 container, however there doesn't appear to
>> be any reason for this not to work.
>>
>> I am not too sure what the long term plans are for the JEE9 platform.
>>  I can image that it will take many years for it to be widely
>> supported, as such I can only suggest that third party libraries such
>> as bcmail, will need to start producing two versions or find an
>> alternative Mime API.
> I still don't understand why they decided to rename the packages
> because it breaks a lot of existing products.
>
> If BC decides to support the new Jakarta packages, it might be
> worthwhile to see whether a wrapper API can be used which
> translates the calls to the underlying implementation. The API provides
> interfaces and two implementations, one for javamail and one for
> jakarta. Then the application can decide which actual implementation
> should be used. Since BC only uses a subset of javamail, this might
> work.
>
> Kind regards,
>
> Martijn Brinkers
>
>
>