-
Bug
-
Resolution: Fixed
-
P4
-
1.3.1, 6
-
tiger
-
generic, x86
-
generic, windows_xp
Name: jl125535 Date: 11/28/2001
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.3.1-FCS)
Java HotSpot(TM) Client VM (build Blackdown-1.3.1-FCS, mixed mode)
I have a service based application which downloads code to access the application
remotely. If the client VM is say IBM but the VM which runs the application is Sun then
I cannot send a KeyPair (or any object which contains PublicKey,PrivateKey) down a
socket using Serialization.
Because KeyPair uses the default serialization then when it comes to serialize the
public and private components of the pair (which are only interfaces PublicKey & PrivateKey)
then the real objects are serialized. On a Sun VM this is com.sun.xxx but on an IBM this
is com.ibm.xxx.
If the application uses some rpc type communication then any remote interfaces
cannot contain any methods which contains these objects in their declaration:
public void verify(PublicKey key) - could not be an rpc method.
There is a work around (described later) but this still means the rpc method has to
change and really if I use something in any java. packages then I should really expect
this to work on other VMs (Write once run anywhere?) and I thought this may of been
the reason for the provider pattern in the security architecture.
public void verify(ManuallyEncodedPublicKey key)
- manually serializes the key using X.509EncodedKeySpec
This has impact on any serialization of these classes accross multiple providers.
(Review ID: 135083)
======================================================================
- duplicates
-
JDK-6536046 Serialization and javax.security interface classes (e.g. PublicKey)
- Closed
- relates to
-
JDK-4833034 Obfuscation is changing variable names for serialization
- Closed