harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stepan Mishura <stepan.mish...@gmail.com>
Subject Re: Contribution of beans, math and regex libraries
Date Tue, 31 Jan 2006 08:25:28 GMT
>
>Certainly the Bouncy Castle jar contains an implementation of the SHA
>algorithm. Assuming that you have an uncorrupted BC provider jar in
><HARMONY_JRE>/lib/ext, does this failure get fixed by "unsigning" the BC
>jar ?
>

Well, there is a cyclic dependency here: to verify a signed jar we need
already verified provider that has all required algorithms for jar
verification. To avoid this we can define a 'trusted' provider, for example,
currently a signed provider's jar is not verified if it was added to the
bootclasspath. Or we can create an unsigned provider's jar intended for jar
verification.
BTW, all tests from security2 passed because ant script used to run tests
explicitly adds the required provider to the bootclasspath.

Thanks,
Stepan Mishura
Intel Middleware Products Division




On 1/30/06, George Harley <george.c.harley@googlemail.com> wrote:
>
> Hi Andrey,
>
> Certainly the Bouncy Castle jar contains an implementation of the SHA
> algorithm. Assuming that you have an uncorrupted BC provider jar in
> <HARMONY_JRE>/lib/ext, does this failure get fixed by "unsigning" the BC
> jar ?
>
> I hit something similar a few days ago (NoSuchAlgorithmException even
> though BC was providing it) and it got fixed by unsigning the provider
> jar. Maybe there is a bootstrapping problem verifying the signed BC
> provider jar ? I'm not sure if there is an open JIRA issue on this.
>
>
> Best regards,
> George
> IBM UK
>
>
> Andrey Chernyshev wrote:
> >> java.beans.PropertyChangeSupportTest
> >>
> >> First two tests were mentioned in the contribution's README.txt that
> they
> >> may fail. The last one failed on serialization.
> >>
> >
> > Yes, you are right. As far as I can see the PropertyChangeSupportTest
> > fails with the following message:
> >
> >         java.security.NoSuchAlgorithmException: SHA
> >
> > Serialization code has to compute the default SUID. To do that, it
> > requests message digest with SHA algorithm, e.g. does something like:
> >
> >       digest = java.security.MessageDigest.getInstance("SHA");
> >
> > and then fails to get SHA with the default provider package. Could it
> > be related to the new security code integration? Were you able to pass
> > security2 tests which utilize SHA?
> >
> >
> > Thank you,
> > Andrey Chernyshev
> > Intel Middleware Products Division
> >
> >
> > On 1/30/06, Stepan Mishura <stepan.mishura@gmail.com> wrote:
> >
> >> I tried this contribution in the following way: I've substituted the
> current
> >> java.math stub implementation with implementation from the
> contribution. And
> >> I run all security2 tests - most of tests that depend on
> >> java.math.BigInteger class passed.
> >>
> >> Also I run tests from the contribution. All tests passed except
> >> java.beans.EventHandlerTest
> >> java.beans.SimpleBeanInfoTest
> >> java.beans.PropertyChangeSupportTest
> >>
> >> First two tests were mentioned in the contribution's README.txt that
> they
> >> may fail. The last one failed on serialization.
> >>
> >> Thanks,
> >> Stepan Mishura
> >> Intel Middleware Products Division
> >>
> >>
> >>
> >> On 1/23/06, Andrey Chernyshev <a.y.chernyshev@gmail.com> wrote:
> >>
> >>> I'm happy to announce one more contribution to Harmony on behalf of
> >>> Intel. The archive with the contribution is uploaded to the following
> >>> location:
> >>>
> >>> http://issues.apache.org/jira/browse/HARMONY-39
> >>>
> >>> The contribution includes the following class library packages:
> >>>
> >>> 1) java.beans
> >>> 2) java.math
> >>> 3) java.util.regex
> >>>
> >>> Note that this contribution includes stubs for certain classes from
> the
> >>> java.awt and java.applet packages as well to enable compilation of
> >>> java.beans. The stub classes do not yet include the complete method
> >>> signatures
> >>> or their fully-functional implementations. Please be prepared to
> observe
> >>> some
> >>> unit test failures in the beans package because of that.
> >>>
> >>> The code is a result of efforts of Intel Middleware Product Division
> team.
> >>> One
> >>> should be able to compile and run this code with the Harmony Execution
> >>> Environment available at
> >>> http://www-128.ibm.com/developerworks/java/jdk/harmony,
> >>> Harmony Class Libraries and Eclipse compiler. The code included with
> the
> >>> contribution is pure Java, we tested it with the Harmony Execution
> >>> Environment
> >>> on Windows and Linux. The implementation is done according to the Java
> 5
> >>> API
> >>> specification, though the Java 5 specific language features such as
> >>> generics
> >>> were not utilized. One should be able to run this code with a
> 1.4+compatible
> >>> JRE/VM.
> >>>
> >>> The build provided with the contribution doesn't include the
> documentation
> >>> target yet until we work out the approach to handling the references
> to
> >>> J2SE
> >>> spec (we haven't yet removed the com.intel.drl.spec_ref tags from the
> >>> code).
> >>>
> >>> We hope that the proposed regex package would allow developing the
> fully-
> >>> functional build makefiles for Ant. The detailed documentation
> regarding
> >>> the
> >>> regex framework can be found under the 'doc' directory.
> >>>
> >>> The archive contains the README file that explains the things doable
> with
> >>> this
> >>> code. But, should any additional clarifications be required, I'll be
> happy
> >>> to
> >>> provide them. You are welcome to try it out!
> >>>
> >>> Thank you,
> >>> Andrey Chernyshev
> >>> Intel Middleware Products Division
> >>>
> >>>
> >>
> >> --
> >> Thanks,
> >> Stepan Mishura
> >> Intel Middleware Products Division
> >>
> >>
> >>
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message