Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <989701548.1252916337469.JavaMail.jira@brutus>
Date: Mon, 14 Sep 2009 01:18:57 -0700 (PDT)
From: =?utf-8?Q?Alexander_Gr=C3=A4f_=28JIRA=29?= <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Updated: (CODEC-87) DigestUtils: MD5 checksum is not
 calculated correctly on linux64-platforms
In-Reply-To: <1542341794.1252672737490.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/CODEC-87?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Gr=C3=A4f updated CODEC-87:
--------------------------------

    Attachment: md5test.jar

Sorry!
As you guessed my testcase provided was not entirely  correct. The provided=
 string that shows the problematic behaviour was not the right one.
As you confirmed, the string a9P,+$ is calculated correctly on all platform=
s with hash f13ba39d06128b53b2bd238dfd357bcf (i could reproduce this with t=
he provided testcase Codec87.
However, if you use the string a9P,+=C2=A7 you get the odd behaviour I was =
talking about.
Here are my results, using the code of testcase Codec87 with the problemati=
c string:

79c28faa4fec5ceb98137f548f1d6fe3 Windows XP x86 5.1
3194078c1fa327f9856b5b54628f2a39 Linux amd64 2.6.16.46-0.12-smp

I attached the jar that I was using for the test. The jar contains all clas=
ses needed for execution, so you can start it with java -jar mdtest.jar.

> DigestUtils: MD5 checksum is not calculated correctly on linux64-platform=
s
> -------------------------------------------------------------------------=
-
>
>                 Key: CODEC-87
>                 URL: https://issues.apache.org/jira/browse/CODEC-87
>             Project: Commons Codec
>          Issue Type: Bug
>    Affects Versions: 1.3, 1.4
>         Environment: Suse Enterprise Linux 10 (64bit)
>            Reporter: Alexander Gr=C3=A4f
>         Attachments: md5test.jar
>
>
> Actual behaviour:=20
> The class DigesterUtils calculates different md5-hashes depending on plat=
tform.
> I used jdk1.5.0_19-32bit on win32 and jdk1.5.0_19-64bit on SLES 10 (64-bi=
t) for testing.=20
> The effect depends on the charactersequence that is used for the calculat=
ion of the hash. There are some charactersequences that are calculated corr=
ectly. I think that the hash that is calculated on Windows 32 is the correc=
t one since we have checked it by using an other library for calculating md=
5-hashes (Tagish-Auth-1.0.3). Since both of the tested libraries internally=
 make use of the class java.security.MessageDigest but differ in the way th=
e calculated byte[] is transformed in a hex-string, I think that the proble=
m is located in the Hex.encodeHex(byte[] hashedBytes) method.
> Expected behaviour:=20
> The md5-hash should should not depend on the platform and should be equal=
 for all platforms.
> Testcase:
> System.out.println(DigestUtils.md5Hex("a9P,+$"));=20
> produces the hash 79c28faa4fec5ceb98137f548f1d6fe3 on Windows XP (32bit).
> The same instruction produces 3191078c1fa327f9856b5b54628f2a39 on Suse En=
terprise Linux 10 (64bit).

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.