Hello,
I've made an investigation and found out the root of the problem.
It seems that "eclipse" test in DaCapo benchmarks canges value of *
java.home* system property to ".\scratch\dummyjre". It affects
initialization of Security class in java.security module which loads
java.security file from *java.home*/lib/security directory.
This is potential security gap since a person could change *java.home* value
before Security class initialization and load malicious java.security file.
The following test demonstrates the described behavior:
import java.security.MessageDigest;
public class Test {
public static void main (String[] args) {
try {
System.setProperty("java.home", "foo/path");
MessageDigest md = MessageDigest.getInstance ("SHA-1");
} catch (Exception e) {
e.printStackTrace();
}
}
}
Yuri Dolgov
On 11/10/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Robin Garner wrote:
> Stefano Mazzocchi wrote:
>> from Robin's latest runs
>>
http://cs.anu.edu.au/people/Robin.Garner/dacapo/regression/results-20061110/DRLVM/eclipse.small.log
>>
>>
>> there are a bunch of log messages that indicate that harmony doesn't
>> implement SHA-1.
>>
>> Is that true?
>>
>
> It can't be true, because _all_ the DaCapo benchmarks rely on SHA-1 for
> validation. I raised JIRA Harmony-2135 on this issue. Looks like after
> eclipse has run, drlvm forgets how to access the SHA-1 algorithm :(
Yep, the SHA-1 code is still there [1].
[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/security/src/main/java/common/org/apache/harmony/security/provider/crypto/SHA1Impl.java?view=markup
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
