JDK-4833034 : Obfuscation is changing variable names for serialization
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 1.4.2
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2003-03-14
  • Updated: 2003-12-11
  • Resolved: 2003-12-11
Related Reports
Relates :  
JDK-4632653 - Finish crypto reworking - Tighter JSSE/JCE integration
Relates :  
JDK-4532506 - Serializing KeyPair on one VM (Sun) then Deserializing on another (IBM) fails
Description
For some of the serializable classes, during obfuscation the private field names will have changed.  Looking at the current jar file:

com.sun.net.ssl.internal.ssl.JS_KeyPairGenerator
    private String algorithm;
    private int keyPairState;

    /* Ignoring the static INITIALIZED/NOT_INITIALIZED fields */

Dumping the contents of an obfuscated jar.

-------------------------------
Fields (count = 6)

*IGNORING the protected and serialVersionUID*

3) Field:       Name (45): a    Type (39): Ljava/lang/String;   Access Flags: pr
ivate
Attributes:             Attributes (count = 0)

4) Field:       Name (46): b    Type (35): I    Access Flags: private
Attributes:             Attributes (count = 0)

*IGNORING the final static ints.*
-------------------------

And in a *non-obfuscated*

-------------------------
3) Field:       Name (48): algorithm    Type (49): Ljava/lang/String; Access F
lags: private
Attributes:             Attributes (count = 0)

4) Field:       Name (50): keyPairState Type (51): I    Access Flags: private
Attributes:             Attributes (count = 0)
-------------------------

Currently, Dasho is renaming the first variable as "a", second as "b" but that can't be guaranteed.  If anyone reorders/adds any new fields, this will break quite nicely!  :)

For compatibity reasons in tiger, we should look at what the fields were renamed to, rename the variables to this, and then include the classes unconditionally.

As of 3/14/03, the classes that have private members include:

com.sun.net.ssl.internal.ssl.JS_KeyFactory
    private String transformation;

com.sun.net.ssl.internal.ssl.JS_KeyPairGenerator
    private String algorithm;
    private int keyPairState;

com.sun.net.ssl.internal.ssl.JS_Signature
    private String keyAlgorithm;
    private boolean signing;

###@###.### 2003-03-14
Comments
EVALUATION See Description ###@###.### 2003-03-14 Most of these classes will be going away when we remove RSA provider, but still exist for now. Will need to update Provider for sure. ###@###.### 2003-03-14 I think given the amount this has been in the field, we probably should rename these variables in the source (ugh), and then include them unconditionally. On the other hand, we never pass instances of these variables back to the user. This is probably a non-issue. ###@###.### 2003-03-14 Obfusction may be going away in tiger soon, so this will need to be addressed. ###@###.### 2003-10-24 In a separate email discussion, Andreas wrote: ============= The options seem to be: . close as will-not-fix . reintroduce the Jsafe classes (to the extent necessary). That may affect our export classification and support/licensing arrangements with RSA . reimplement enough of the Jsafe classes ourselves to allow deserialization of the old keys. This may be difficult and could possibly violate RSA copyright (IANAL). Andreas. ============= I'm of the same opinion. Will close as "will not fix". ###@###.### 2003-12-11
11-12-2003
SUGGESTED FIX See Description ###@###.### 2003-03-14
14-03-2003