[
https://issues.apache.org/jira/browse/RIVER-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904272#comment-16904272
]
Peter Firmstone commented on RIVER-49:
--------------------------------------
We might be able to address this with atomic serialization, which has a
security hardened subset of features of Java Serialization, it is serial form
compatible with Java. Because Collection classes in java are not safe to
de-serialize, their serial form is replaced by standard serial form for Set,
List, and Map. The Set, List and Map interfaces have equals contracts that
can be replicated in serial form, provided the serial form of the contents is
also equal.
Developers are required to defensively copy the de-serialized Collections and
check the type of their contents, there are also tools to make this easy.
> LS spec should emphasize importance of consistent serial forms
> --------------------------------------------------------------
>
> Key: RIVER-49
> URL: https://issues.apache.org/jira/browse/RIVER-49
> Project: River
> Issue Type: Bug
> Components: net_jini_core
> Affects Versions: jtsk_1.2
> Reporter: Mark Brouwer
> Priority: Major
>
> Bugtraq ID
> [4696460|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4696460]
> EN.1.5 states that {{MarshalledObject.equals}} is used for match operations,
> but does not make explicit that the declared types of fields, and the actual
> types of objects stored in those fields (including any objects nested within
> them) must be designed to produce consistent serial forms to make match
> operations reliable. Consistent serial forms means that a given instance
> always serializes the same, and a given instance that is serialized,
> deserialized, and then reserialized produces the same form as the initial
> serialization. A particular example where this has broken down is in the
> Service UI spec, where a field is declared to be of type java.util.Set, but
> existing Set implementations are not specified to (and in fact are not
> implemented to) produce consistent serial forms. Anyone designing an entry
> class needs to think hard about what fields might be used for matching, and
> worry about consistent serial forms.
> In the case of the Lookup spec LU.2.2 is the relevant section which contains
> a discussion on {{Entries}} and {{Entry}} matching. The bug could be
> addressed by adding a note on the importance of consistent serial forms, or
> by replacing the entry discussion with a reference to the {{Entry}} spec
> (which once
> [4696449|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4696449] is fixed
> will talk about constant
> serial forms).
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
