Code review request for storing code signer info

[Mandy Chung]

  On 1/14/11 8:33 AM, Sean Mullan wrote:
> On 1/13/11 3:30 PM, Mandy Chung wrote:
>> On 01/13/11 07:52, Sean Mullan wrote:
>>> See 
>>> http://cr.openjdk.java.net/~mullan/jigsaw/webrevs/jigsaw-certs/webrev.00/
>>>
>>
>> org/openjdk/jigsaw/ModuleFileFormat.java
>> line 1744-1746: I think synchronization may not be an issue here as 
>> module
>> installation is done in a single thread.
>
> Ok, I'll leave the code as is for now, but I'll add a code comment 
> that we may need to synchronize this. There are actually several 
> CertificateFactory objects instantiated at different layers of the 
> code when verifying a signed module, so one of the things I also want 
> to look at is whether it is possible to reduce that number and reuse 
> the same CertificateFactory.
>
>> line 1843:
>> jpkg takes the -k <keystore> option. I wonder if jmod should also 
>> accept an
>> alternative keystore location rather than using a system property to 
>> override
>> it. Or it is a requirement to use the system-wise cacerts file?
>
> It is not a requirement to use a system-wide cacerts file, but that 
> should be the default in my opinion.
>
> I'm not thrilled about using a system property but I also don't want 
> to necessarily clutter the command line tool with additional options 
> that should be rarely used.
>

I agree that the system-wide cacerts should continue to be the default.  
As it rarely needs to override the location of cacerts file, a system 
property for the testing purpose would suffice.

> Have we given any thought as to whether we will add some sort of 
> configuration properties file to allow default settings to be 
> overridden? There are other security defaults that will likely need to 
> be overriden, such as revocation checking settings.
>
In JRE, there is a $JAVA_HOME/lib/security/java.security properties file 
that allows the default security settings to be overriden.  Do you mean 
whether we will add a new configuration properties file for the base 
module to use (replacing java.security one?)?  We haven't thought about 
that but I think it's something we should consider.

Reading a properties file for configuration has startup impact.  I found 
that some existing properties files in the JRE such as 
logging.properties incur unnecessary startup cost as most applications 
use the default configuration.  Generally if we add a new configuration 
properties file, I would propose to build in the default configuration 
in the runtime and we will just ship a template file (different name as 
the actual configuration file so that the file only exists if it's not 
the default).

>> line 1855-1858: it would be good to use try-with-resources.
>
> Ah, you mean the Project Coin enhancement? Is there an example of code 
> that uses this already that you can point me to?
>

I don't know off hand but the specification is here:
    http://blogs.sun.com/darcy/entry/project_coin_updated_arm_spec

I believe Stuart will modernize the JDK to use try-with-resources for 
JDK 7 after he finishes the diamond conversion.

Mandy