Hi, >(a) Would such a method technically be possible (preventing actual large >binary data copy !) ?
Yes I think it's possible. Would this be needed for Oak or Jackrabbit 2.x or both? >(c) Can we and if yes, how can we control access ? Currently the content identifier is the content hash (SHA-1), so there is no risk of "enumeration" or "scanning" attack (not sure what is the right word for this - where the attacker blindly tries out many possible ids in the hope to find one). One risk is that an attacker can "prove" a certain document is stored in the repository, where the attacker already has the document or at least knows the hash code. For example he could prove the "wikileaks file x" is stored in the repository, which might be a problem if possession of the "wikileaks file x" is illegal. Not sure if we need protection against that; if yes, we might only allow this method to be called for admin sessions or so. Another risk is that an attacker that has a list of identifiers might be able to get the documents in that way, if they are stored in the repository. The question is how did the attacker get the identifier, but if it's a simple SHA-1 it might be a bigger risk. One way to protect against that might be to encrypt the SHA-1 hash code with a repository-wide, configurable "private key" or so. Regards, Thomas
