jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Bocanegra <tri...@apache.org>
Subject Re: content hash of a tree
Date Tue, 15 Oct 2013 18:41:55 GMT

On Tue, Oct 15, 2013 at 11:28 AM, Jukka Zitting <jukka.zitting@gmail.com>wrote:

> 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.

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message