Proposed update will resolve the providers issue in the concrete case. But it is not resolve the problem completely.
The posibility to load malicious 'java.security' file still exist (after changing java.home system property before Security class initilaization). So, the application may replace any security property and policy file. On 11/24/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
+1 2006/11/24, Tim Ellison <[EMAIL PROTECTED]>: > Alexey Varlamov wrote: > > 2006/11/24, Tim Ellison <[EMAIL PROTECTED]>: > >> So how about we implement Security#registerDRLProviders() (maybe with a > >> method name change) to register: > >> > >> security.provider.1=org.apache.harmony.security.provider.cert.DRLCertFactory > >> > >> security.provider.2=org.apache.harmony.security.provider.crypto.CryptoProvider > >> > >> security.provider.3=org.apache.harmony.xnet.provider.jsse.JSSEProvider > >> security.provider.4=org.bouncycastle.jce.provider.BouncyCastleProvider > >> > >> Thoughts? > >> Tim > > > > Well, there is a number of other sensitive keys without hardcoded > > defaults, e.g. package.access, probably bunch of ssl.* keys. Therefore > > I presume it should be Security#defaultConfig() then. > > Sorry, I wasn't clear. There is already a method called > Security#registerDRLProviders() that does nothing. I suggest that we > implement it as I described above. > > There may well be other properties that need a default value, but they > would be fixed elsewhere -- presumably where they are used, in case the > file exists but does not define those properties any more. > > If you agree with the default providers I can make that change. > > Regards, > Tim > > -- > > Tim Ellison ([EMAIL PROTECTED]) > IBM Java technology centre, UK. >
-- Best regards, Boris Kuznetsov Intel Middleware Products Division
