Hi, On Tue, Oct 15, 2013 at 11:28 AM, Jukka Zitting <[email protected]>wrote:
> 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. > sure. the current implementation compares the CND of the 2 nodetypes. > > > * 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). well, I think that's a bit far fetched :-) > 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. > that's more likely. I agree. Maybe the jcr:etags need to be handled in a commit hook that also can be configured to what to include in the etag-hash. for example, the jcr:lastModified or jcr:created does not need to be included in the hash. > 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. > ok. thanks. regards, toby
