JDK-6539136 : Add KeyTool and JarSigner as JSR 199 Tools
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 7
  • Priority: P4
  • Status: Resolved
  • Resolution: Withdrawn
  • OS: generic
  • CPU: generic
  • Submitted: 2007-03-27
  • Updated: 2017-05-19
  • Resolved: 2014-11-11
Related Reports
Relates :  
We need to provide developers a way to programatically call the keytool and jarsigner tools.

1. It works!
2. For keytool, no need to deal with files, only objects
3. No need to provide password in Strings
4. Some kind of thread-safe, instance level or class level

New enhancements JDK-8056174 and JDK-8058778 are filed to create cleaner APIs that attempt to fulfill the essential requirements of jar signing and certificate generation without duplicating all keytool/jarsigner functions, especially, user interaction, keystore manipulation, jar verification.

New enhancement JDK-8056174 filed to pursue a simpler/cleaner solution.

EVALUATION Item 6 for JarSigner is probably not needed, since the JarFile/JarEntry classes already provided methods to read signer info. The tools here are mainly used to perform actions that're not avaiable from other APIs in a thread-safe programmable fashion.

EVALUATION For both KeyTool and JarSigner ============================== Inner enum class: PasswordType, values are capitalized version of existing options, can be STOREPASS, KEYPASS, DESTSTOREPASS, SRCSTOREPASS, SRCKEYPASS, DESTKEYPASS, NEW. 1. Passwords need to be stored in char[] /* If passwd is set with this API, users need to clean them up (zero-fill) after calling run(). If users specify password in the command line, they'll override those set in this API, and will be automatically cleaned. Default null for all passwords. Some types of passwords are illegal for several commands (i.e. keypass for PKCS11), they must be reset to null (if it's set in a previous call).*/ setPassword(KeyTool$PasswordType, char[]) setPassword(KeyTool$PasswordType, SecureString) // Are we still doing SecureString? 2. Some user requests that keytool actions performed on a KeyStore object, not a file. /* If -keystore is not specified in command line options, this will be used. If keystore is changed (call isKeyStoreChanged() to find out), users need to manually store it. If -keystore is specified, it overrides the one set here and will be automatically saved if needed. If -keystore is not specified and this method is not called, the default keystore will be used. (See keytool.html#Somewhere). Default null.*/ void useKeyStore(KeyStore) 3. Currently keytool is too interactive. This method helps to make sure that when it's called pragramatically in a non-interactive mode, it won't hang. /* If false, throws an exception(type?) if user interactions are needed, for example, password input, DN input,... Default true. Note the difference between the following 2 options: setInteractive(false): throws exception if a prompt is needed. -noprompt: automatically answer YES if a YES/NO prompt is needed. */ void setInteractive(boolean) 4. This method is useful for dealing with errors. We can also use it to write a thin GUI wrapper around keytool. /* Do the same thing as run(), but throw exceptions instead of writing to err*/ void execute(in, out, err, args...) throws Exception For KeyTool only ================ 5. Co-op with useKeyStore(KeyStore) /* If -keystore is not specified and useKeyStore() is called, returns if there are any changes made to the keystore object. Otherwise, the returned value is not defined.*/ boolean isKeyStoreChanged() For JarSigner only ================== 6. Jar file signer info. I need to read more on 5079716. http://monaco.sfbay.sun.com/detail.jsf?cr=5079716 /* Returns the signers after -verify. Not sure about what kind of info are needed. */ SignerInfo[] getSignerInfo() I had planned to add a JarSignerOptions class because there are many options for jarsigner. Maybe this is not a good idea since the options may not be standard enough to be expressed in interface methods. A single instance of a tool cannot be used to perform several actions at the same time. Different instances can. This means there are no class level shared states.