Details

    • Type: Task
    • Status: Closed
    • Priority: Minor
    • Resolution: Invalid
    • Affects Version/s: 3.0.0
    • Fix Version/s: 2.3.0
    • Component/s: None
    • Labels:
      None

      Description

      Probably only performance improvement on base64 encoding/decoding.
      Most of the other changes are around IMAP (client) and we don't use it.

        Activity

        Hide
        bago Stefano Bagnara added a comment -

        I hope this upgrade doesn't break Gump.

        Show
        bago Stefano Bagnara added a comment - I hope this upgrade doesn't break Gump.
        Hide
        bago Stefano Bagnara added a comment -

        I'm reopening this because we should downgrade to 1.3.2 before an official release.
        ------------------------------------------------------------------------------

        Well good questions, I read your entry on the upgrade, wher you state:

        "Probably only performance improvement on base64 encoding/decoding.
        Most of the other changes are around IMAP (client) and we don't use it. "

        So our main reason is the performance improvement in base64 handling, and this is exactly what seams broken. So I suggest reverting to JavaMail 1.3.2 until a bugfix-release from Sun is available.

        --Søren

        On Thursday 08 September 2005 11:25, Stefano Bagnara wrote:
        > > Just saw this on the BouncyCastle mailinglist, as we provide mailets
        > > using BouncyCastle we should perhaps revise upgrading to JavaMail
        > > 1.3.3.
        > >
        > > --Søren
        >
        > Hi Søren,
        >
        > Thank you for pointing this out. What should we do?
        > I haven't tested S/MIME stuff since the upgrade to javamail 1.3.3.
        > Should I revert the upgrade to mail-1.3.3? Should we add a FAQ?
        > Should we add a note in the config.xml just before the SMIME stuff?
        >
        > Stefano
        >
        > > Subject: [dev-crypto] warning about JavaMail 1.3.3
        > > Date: Thursday 08 September 2005 00:25
        > > From: David Hook <dgh@bund.com.au>
        > > To: dev-crypto@bouncycastle.org
        > >
        > > We're not sure exactly what's happening still, but it appears that
        > > on some platforms, under some circumstances, Base64 decoding, or
        > > something underlying it, in JavaMail 1.3.3 breaks horribly and
        > > produces data with lots of extra bytes of the value 0x00 and 0xff.
        > > The upshot of this is that messages containing Base64 encoded data,
        > > such as S/MIME messages will no longer work as the data stream
        > > containing the encoded message has become corrupted.
        > >
        > > If S/MIME starts causing exceptions we recommend moving back to 1.3.2.

        Show
        bago Stefano Bagnara added a comment - I'm reopening this because we should downgrade to 1.3.2 before an official release. ------------------------------------------------------------------------------ Well good questions, I read your entry on the upgrade, wher you state: "Probably only performance improvement on base64 encoding/decoding. Most of the other changes are around IMAP (client) and we don't use it. " So our main reason is the performance improvement in base64 handling, and this is exactly what seams broken. So I suggest reverting to JavaMail 1.3.2 until a bugfix-release from Sun is available. --Søren On Thursday 08 September 2005 11:25, Stefano Bagnara wrote: > > Just saw this on the BouncyCastle mailinglist, as we provide mailets > > using BouncyCastle we should perhaps revise upgrading to JavaMail > > 1.3.3. > > > > --Søren > > Hi Søren, > > Thank you for pointing this out. What should we do? > I haven't tested S/MIME stuff since the upgrade to javamail 1.3.3. > Should I revert the upgrade to mail-1.3.3? Should we add a FAQ? > Should we add a note in the config.xml just before the SMIME stuff? > > Stefano > > > Subject: [dev-crypto] warning about JavaMail 1.3.3 > > Date: Thursday 08 September 2005 00:25 > > From: David Hook <dgh@bund.com.au> > > To: dev-crypto@bouncycastle.org > > > > We're not sure exactly what's happening still, but it appears that > > on some platforms, under some circumstances, Base64 decoding, or > > something underlying it, in JavaMail 1.3.3 breaks horribly and > > produces data with lots of extra bytes of the value 0x00 and 0xff. > > The upshot of this is that messages containing Base64 encoded data, > > such as S/MIME messages will no longer work as the data stream > > containing the encoded message has become corrupted. > > > > If S/MIME starts causing exceptions we recommend moving back to 1.3.2.
        Hide
        hilmer@apache.org Soren Hilmer added a comment -

        Downgraded to 1.3.2

        Show
        hilmer@apache.org Soren Hilmer added a comment - Downgraded to 1.3.2
        Hide
        bago Stefano Bagnara added a comment -

        I think we should keep this open to remember why we didn't upgrade by now.

        Show
        bago Stefano Bagnara added a comment - I think we should keep this open to remember why we didn't upgrade by now.
        Hide
        bago Stefano Bagnara added a comment -

        We won't upgrade for 2.3.0 because of known issues with javamail 1.3.3 and smime.
        We'll wait for javamail 1.3.4

        Show
        bago Stefano Bagnara added a comment - We won't upgrade for 2.3.0 because of known issues with javamail 1.3.3 and smime. We'll wait for javamail 1.3.4
        Hide
        sbrewin@apache.org Steve Brewin added a comment -

        "Most of the other changes are around IMAP (client) and we don't use it. " - Stefano
        Just a reminder that fetchmail can be configured to use Javamail's IMAP support, though it uses POP3 out of the box. Not a reason to switch to the broken 1.3.3 release. When we do switch to 1.3.4 or whatever, we should remember to test fetchmail using both IMAP and POP3.

        Show
        sbrewin@apache.org Steve Brewin added a comment - "Most of the other changes are around IMAP (client) and we don't use it. " - Stefano Just a reminder that fetchmail can be configured to use Javamail's IMAP support, though it uses POP3 out of the box. Not a reason to switch to the broken 1.3.3 release. When we do switch to 1.3.4 or whatever, we should remember to test fetchmail using both IMAP and POP3.
        Hide
        bago Stefano Bagnara added a comment -

        Javamail 1.4EA has been release a few weeks ago. It seems to fix the Base64 encoding problems encountered with 1.3.3 so we probably better upgrade from 1.3.2 to 1.4 when the 1.4 final will be released (hopefully before our final release of 2.3.0).

        Show
        bago Stefano Bagnara added a comment - Javamail 1.4EA has been release a few weeks ago. It seems to fix the Base64 encoding problems encountered with 1.3.3 so we probably better upgrade from 1.3.2 to 1.4 when the 1.4 final will be released (hopefully before our final release of 2.3.0).
        Hide
        bago Stefano Bagnara added a comment -

        Here is the bug reference in the sun's bug database:
        http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6332559

        Show
        bago Stefano Bagnara added a comment - Here is the bug reference in the sun's bug database: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6332559
        Hide
        bago Stefano Bagnara added a comment -

        We just upgraded to 1.4.0 so this is no more valid.

        Show
        bago Stefano Bagnara added a comment - We just upgraded to 1.4.0 so this is no more valid.
        Hide
        danny@apache.org Danny Angus added a comment -

        Closing issue fixed in released version.

        Show
        danny@apache.org Danny Angus added a comment - Closing issue fixed in released version.

          People

          • Assignee:
            bago Stefano Bagnara
            Reporter:
            bago Stefano Bagnara
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development