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
Hi,

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

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