jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: content hash of a tree
Date Tue, 15 Oct 2013 18:28:10 GMT
Hi,

On Tue, Oct 15, 2013 at 1:53 PM, Tobias Bocanegra <tripod@apache.org> 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

Mime
View raw message