The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build
#868)
Status: Still Failing
Check console output at
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/868/ to view
the results.
Changes:
[chetanm] OAK-4144 - Expose PropertyIndex stats
[chetanm] OAK-
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build
#867)
Status: Still Failing
Check console output at
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/867/ to view
the results.
Changes:
[chetanm] OAK-4144 - Expose PropertyIndex stats
[chetanm] OAK-
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build
#866)
Status: Still Failing
Check console output at
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/866/ to view
the results.
Changes:
[chetanm] OAK-4173 - Add log message when a custom tika config
On Thu, May 5, 2016 at 5:07 PM, Francesco Mari
wrote:
>
> This is a totally different thing. The change to the node will be committed
> with the privileges of the session that retrieved the node. If the session
> doesn't have enough privileges to delete that node, the node will be
> deleted, Ther
Hi,
Dont forget.
Unless the JVM is running a JVM security manager, any attempts to enforce
security implemented in Java even in an OSGi environment will be futile
once malicious byte code is loaded. I won't share how, but it's obvious
when you start to think maliciously, especially if you can trigg
I think that the same approach could be used for the BlobStore, too. This
would force the customer to specify two URIs, one for the NodeStore and one
for the BlobStore.
2016-05-05 13:41 GMT+02:00 Tomek Rekawek :
> Hi Francesco,
>
> it will be useful in the oak-upgrade too. Do you think it’d possi
Hi Francesco,
it will be useful in the oak-upgrade too. Do you think it’d possible to provide
a similar schema for the blob store configuration?
Best regards,
Tomek
--
Tomek Rękawek | Adobe Research | www.adobe.com
reka...@adobe.com
> On 05 May 2016, at 10:42, Francesco Mari wrote:
>
> Hi a
2016-05-05 13:22 GMT+02:00 Chetan Mehrotra :
> On Thu, May 5, 2016 at 4:38 PM, Francesco Mari
> wrote:
>
> > The security concern is quite easy to explain: it's a bypass of our
> > security model. Imagine that, using a session with the appropriate
> > privileges, a user accesses a Blob and adapts
On Thu, May 5, 2016 at 4:38 PM, Francesco Mari
wrote:
> The security concern is quite easy to explain: it's a bypass of our
> security model. Imagine that, using a session with the appropriate
> privileges, a user accesses a Blob and adapts it to a file handle, an S3
> bucket or a URL. This code
Hi Francesco
+1 for centralizing logic for creating a NodeStore instance.
I like the idea of encoding the description of a NodeStore instance in
a URI. This is both concise and extensible. We need to also consider
how to express the use of different DataStores as well. I.e. the URI
should ideally
The security concern is quite easy to explain: it's a bypass of our
security model. Imagine that, using a session with the appropriate
privileges, a user accesses a Blob and adapts it to a file handle, an S3
bucket or a URL. This code passes this reference to another piece of code
that modifies the
> This proposal introduces a huge leak of abstractions and has deep security
implications.
I understand the leak of abstractions concern. However would like to
understand the security concern bit more.
One way I can think of that it can cause security concern is you have some
malicious code runni
In my opinion, all of those issues can be postponed to a later release. The
three issues are introduced by the introduction of the oak-segment-tar
module and their resolution affects oak-segment-tar and no other module in
Oak.
Two solutions are possible. First, we could lower their priority to
cri
On Thu, May 5, 2016 at 1:31 PM, Davide Giannella wrote:
> Would it be possible to avoid the `instaceof`? Which means, in my
> opinion, all our binaries should be Adaptable.
>
The Binary interface is part of JCR API so cannot be be modified to extend
Adaptable. Hence the client code would need to
+1 to Francesco's concerns, exposing the location of a binary at the
application level doesn't sound good from a security perspective.
To me sounds like breaching the JCR and NodeState layers to directly
manipulate NodeStore binaries (from the DataStore), e.g. to perform smart
replication across di
On Wed, May 4, 2016 at 10:07 PM, Ian Boston wrote:
> If the File or URL is writable, will writing to the location cause issues
> for Oak ?
>
Yes that would cause problem. Expectation here is that code using a direct
location needs to behave responsibly.
Chetan Mehrotra
Hello team,
I'm planning to cut Oak 1.5.2 next Monday the 9th of May.
There are currently 3 blocking issues. If they will stay so, the load
will be delayed. If they are not really blockers, please set them as
something else.
https://issues.apache.org/jira/browse/OAK-4246
https://issues.apache.or
This proposal introduces a huge leak of abstractions and has deep security
implications.
I guess that the reason for this proposal is that some users of Oak would
like to perform some operations on binaries in a more performant way by
leveraging the way those binaries are stored. If this is the ca
Hi all,
While looking into OAK-4246 I figured out that many commands in oak-run
implement the same logic over and over to create instance of NodeStore from
command line arguments and options.
Thus, I created OAK-4349 to propose another approach to the problem. A
connection to a specific NodeStore
On 04/05/2016 17:37, Ian Boston wrote:
> Hi,
> If the File or URL is writable, will writing to the location cause issues
> for Oak ?
> IIRC some Oak DS implementations use a digest of the content to determine
> the location in the DS, so changing the content via Oak will change the
> location, but
On 03/05/2016 15:36, Chetan Mehrotra wrote:
> ...
> //Check if Binary is of type AdaptableBinary
> if (binProp instanceof AdaptableBinary){
Would it be possible to avoid the `instaceof`? Which means, in my
opinion, all our binaries should be Adaptable. In case the
implementation is not it can retu
21 matches
Mail list logo
