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: 2023-09-28
  • Resolved: 2014-11-11
Related Reports
Relates :  
JDK-8056174 - New APIs for jar signing
Relates :  
JDK-8304556 - Add public API for generating self signed X.509 certificates
Relates :  
JDK-8058778 - New APIs for creating certificates and certificate requests
Description
We need to provide developers a way to programatically call the keytool and jarsigner tools.
Requirements:

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
Comments
Rethink about this. If we need to expose them as tools, these things need to be taken care of: 1. Static states. No tool should have static states, all states must be in the instance. Jarsigner uses Event which is global. Each event should be bound to a jarsigner instance. 2. Error handling. The tool must not call System.exit() when running as a tool, esp, System.exit(non-zero) must be translated into an exception. 3. User interaction. User interaction (password prompt, name prompt, etc) should be disabled by default when running as a tool. Maybe add new options to turn it on or off. 4. Password cleanup. Passwords should be zeroed out after a run. Seems this is already supported now. Double check. 5. Use the in/out of the tool, not always System.in/System.out. Another thing, keytool and jarsigner always operate on a keystore which is in an external file (or device). It will be super cool if they can operate on a keystore object when running as a tool. The only way I can think of is to create a public interface that extends ToolProvider so that you can pass the object into a customized run method. If we really want to go this way, a lot of code change is needed so when an object is provided we don't need to do the load/store thing.
28-09-2023
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.
11-11-2014
New enhancement JDK-8056174 filed to pursue a simpler/cleaner solution.
29-08-2014
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.
28-08-2007
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.
28-08-2007