Hi Roger,
+1 for writeReplace
Personally I'd like to see some security classes break backward
compatibility and remove support for serialization as it allows someone
to get references to internal objects, especially since these classes
are cached by the JVM. Which makes PermissionCollection.setReadOnly()
very easy to bypass, by adding permissions to internal collections once
you have a reference to them.
Does anyone have any use cases for serializing these objects?
These objects are easy to re-create by sending or recieving and parsing
strings, because they are built from text based policy files, and when
you do that, you are validating input, so I never did fully understand
why they were made serializable.
Regards,
Peter.
On 16/08/2019 12:54 AM, Roger Riggs wrote:
Hi Claes,
I would recommend using writeReplace to serialize the
PermissionCollection so the serialized form does not change.
Though these are unlikely to be serialized, it will be less likely to
trigger some interoperability issue between different version. It may
need to be documented that serializing/deserializing does not retain
the lazyness.
Roger
On 8/15/19 10:30 AM, Claes Redestad wrote:
Hi Sean,
On 2019-08-15 15:07, Sean Mullan wrote:
Hi Claes,
I already reviewed an earlier version of this and this is pretty
similar. I did have a question about whether the default
serialization was ok - did you look into that more?
ah, yes.. all the constituents are serializable (whether we wrap the
CodeSource or its URL) so the new Lazy..Collection should be too. I was
entertaining the idea that we could writeReplace the lazy collection
with a PermissionCollection to avoid polluting serialization use cases
with new type, but couldn't think of any real upside to that.
/Clae
