Hi, On Tue, Oct 15, 2013 at 1:53 PM, Tobias Bocanegra <[email protected]> wrote: > * for example for NodeTypeImpl.equals() we could just compare the "hash" of > the substree storing the node type definition.
I'd just compare the names of the node types. Or alternatively do a deep compare of the nodes, as the relevant trees aren't that big. > * for example to provide jcr:etag That's a good idea, but unfortunately there's no easy way to expose content hashes without potentially breaking access controls. For example confidential information stored in a read-protected property could end up leaking through a content hash if the attacker knows the hashing algorithm, can read the rest of that node and has a list of likely alternatives for the confidential bits (or is just interested in the existence of such hidden details). As another example exposing content hashes would make it possible for someone to infer the existence of a hidden subtree or the fact that such a subtree has been modified. The best we can probably do is expose content hashes (or identifiers) on blobs, as there the partial access problem doesn't come up. The Blob interface actually already did expose a hash value, but I recently took it away since it wasn't yet used anywhere and its definition was too implementation-dependent. We can bring it back for example when we implement JackrabbitValue. BR, Jukka Zitting
