2009/8/28 Max (Weijun) Wang <weijun.w...@sun.com>: > On Aug 28, 2009, at 10:17 PM, Andrew John Hughes wrote: > >> 2009/8/28 Max (Weijun) Wang <weijun.w...@sun.com>: >>> >>> On Aug 28, 2009, at 9:56 AM, Andrew John Hughes wrote: >>> >>>> 2009/8/28 Max (Weijun) Wang <weijun.w...@sun.com>: >>>>> >>>>> On Aug 27, 2009, at 9:52 PM, Andrew John Hughes wrote: >>>>> >>>>>> The problem is more the fact that it's an additional copy rather than >>>>>> using the system installation, which means it has to be patched for >>>>>> bugs and security fixes separately. For IcedTea, I'll look at >>>>>> providing and using the option of using the system NSS and will also >>>>>> submit this for review here if there is interest in providing such an >>>>>> option. >>>>> >>>>> Since Java security is already provider based, I guess you can simply >>>>> write >>>>> one provider named NSS and remove all other security.provider.<n> lines >>>>> in >>>>> jre/lib/security/java.security. >>>>> >>>>> Max >>>>> >>>>> >>>> >>>> Sounds like the JDK6 solution :) >>> >>> No, this is the real Java solution. :) >>> >> >> ? > > I mean if you really want 100% "Fedora Crypto Consolidation" so that every > app's crypto call goes to a single library, you need to create your own Java > security provider to bridge JCA/JCE calls to this library and remove all the > others. >
Yeah I got that, but I think that's a much more long term goal! :) What I'm immediately concerned about is not having a duplicate copy of NSS replete with separate bugs in OpenJDK. >> >>>> >>>> I think the simpler fix is to just provide an option for the calls to >>>> the native code to use the system library rather than the included >>>> copy (some of the new files appear to be verbatim copies of files from >>>> NSS AFAICS). But I need to look at this in more detail. >>> >>> This only redirects native calls to your centralized ones, but JRE >>> includes >>> a lot of pure Java providers. If they are still listed in the >>> java.security >>> file, your so called "Fedora Crypto Consolidation" is not 100% complete. >>> >> >> It's not mine, and I was merely referencing that as to why using NSS >> for ECC in the end was a good thing. > > OK. But that's a better thing (at least for Fedora). > > Max > >> >>> Thanks >>> Max >>> >>>> >>>> Thanks, >>>> -- >>>> Andrew :-) >>>> >>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> Support Free Java! >>>> Contribute to GNU Classpath and the OpenJDK >>>> http://www.gnu.org/software/classpath >>>> http://openjdk.java.net >>>> >>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>> >>> >> >> >> >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
