-
Bug
-
Resolution: Fixed
-
P3
-
1.2.0
-
None
-
1.2beta4
-
generic
-
generic
-
Not verified
I have noticed that Spec's (Key and Algorithm) will copy references
to data, rather than data.
For example, I build a byte array that contains the PKCS8 encoding of
an RSA private key. When I instantiate PKCS8EncodedKeySpec, I pass in
that byte array to the constructor. The constructor then copies a
reference to that array. Now the calling routine and the Key Spec object
both have access to that array and both can change it.
It's similar for getting data out of a Spec.
For some fields of a Spec, that's not an issue. For instance an int
is copied or a BigInteger is immutable, so no one can change them
anyway. But I would like to suggest that for Spec's, if an internal
field is a mutable object (such as a byte array), copies are made of the
whole object, both when setting and getting the data.
I noticed this happens with the KeyPair class as well. As a provider,
we build a public and private key, instantiate the KeyPair class with
the pair and the new object now carries references to those objects. The
provider and the KeyPair object can change them. Later on, the user
calls getPublic and gets a reference as well.
Overall, I'm not sure this will ever really cause a problem. In many
cases it looks like it won't matter and if people use the product in a
normal way, they won't shoot themselves in the foot. But it simply seems
to me that it's safer to make copies in and out of things people can
alter.
--Steve Burnett
###@###.###
to data, rather than data.
For example, I build a byte array that contains the PKCS8 encoding of
an RSA private key. When I instantiate PKCS8EncodedKeySpec, I pass in
that byte array to the constructor. The constructor then copies a
reference to that array. Now the calling routine and the Key Spec object
both have access to that array and both can change it.
It's similar for getting data out of a Spec.
For some fields of a Spec, that's not an issue. For instance an int
is copied or a BigInteger is immutable, so no one can change them
anyway. But I would like to suggest that for Spec's, if an internal
field is a mutable object (such as a byte array), copies are made of the
whole object, both when setting and getting the data.
I noticed this happens with the KeyPair class as well. As a provider,
we build a public and private key, instantiate the KeyPair class with
the pair and the new object now carries references to those objects. The
provider and the KeyPair object can change them. Later on, the user
calls getPublic and gets a reference as well.
Overall, I'm not sure this will ever really cause a problem. In many
cases it looks like it won't matter and if people use the product in a
normal way, they won't shoot themselves in the foot. But it simply seems
to me that it's safer to make copies in and out of things people can
alter.
--Steve Burnett
###@###.###