[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13640355#comment-13640355
]
Thomas Mueller commented on JCR-3534:
-------------------------------------
I was chatting with Tommaso Teofili about the basic data structures, features,
and security protocols. There are still a few open questions regarding the API,
but here what we have so far:
DataIdentifier: The (unencryptged and unsigned) identifier of the binary, as
already used by the Jackrabbit DataStore. Please note it could be a reference
to a file, or, for small binaries, contain the data itself.
DataStoreSecret: a secret value that needs to be configured to be the same
value in all repositories that share the same physical data store. It is used
as the basis to encrypt and decrypt the DataIdentifier, and to sign and verify
the signature. This could be a configuration parameter of the DataStore element
in the repository.xml, but then we would probably need to change each DataStore
implementation were we want support for the new feature? To avoid that, should
be add a new element to the repository.xml? Not sure what is the easiest.
BinaryReferenceMessage: The encrypt DataIdentifier, the random salt, the expiry
time. Plus the signature of all of that. The encryption key for the
DataIdentifier is the (SHA-1) hash of the random salt combined with the
DataStoreSecret (this is to avoid re-using the same encryption key for all
BinaryReferenceMessages). The random salt is per message. The expiry time is
the maximum system time up to when to accept the BinaryReferenceMessage (same
as for time limited S3 URLs), for example the system time the message was
generated plus 2 hours or so. The signature is the HMAC of the rest of the
message, with the DataStoreSecret as the key. To simplify development/support,
the message should readable, for example JSON or an URL. Example (shortened):
"{encryptedDataId:0123456789abcd, salt:1234, expiry:3456, signature:4567}".
This will also allow to change the algorithms in the future. For now, we could
use the following algorithms / formats: 128 bit DataStoreSecret and salt
(generated with a SecureRandom); AES-256 encryption / AES-CTR mode; expiry:
milliseconds since 1970 UTC; signature: HMAC-SHA-1.
> Add JackrabbitSession.getValueByContentId method
> ------------------------------------------------
>
> Key: JCR-3534
> URL: https://issues.apache.org/jira/browse/JCR-3534
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api, jackrabbit-core
> Affects Versions: 2.6
> Reporter: Felix Meschberger
> Attachments: JCR-3534.patch
>
>
> we have a couple of use cases, where we would like to leverage the global
> data store to prevent sending around and copying around large binary data
> unnecessarily: We have two separate Jackrabbit instances configured to use
> the same DataStore (for the sake of this discussion assume we have the
> problems of concurrent access and garbage collection under control). When
> sending content from one instance to the other instance we don't want to send
> potentially large binary data (e.g. video files) if not needed.
> The idea is for the sender to just send the content identity from
> JackrabbitValue.getContentIdentity(). The receiver would then check whether
> the such content already exists and would reuse if so:
> String ci = contentIdentity_from_sender;
> try {
> Value v = session.getValueByContentIdentity(ci);
> Property p = targetNode.setProperty(propName, v);
> } catch (ItemNotFoundException ie) {
> // unknown or invalid content Identity
> } catch (RepositoryException re) {
> // some other exception
> }
> Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method
> would allow for round tripping the JackrabbitValue.getContentIdentity()
> preventing superfluous binary data copying and moving.
> See also the dev@ thread
> http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
