Hi Ian The new proposal looks a lot better to me.
The only concern from a security perspective I could come up with is the one we expressed already with the very first proposal (see initial word of caution mail sent by Francesco): applications built on top of Oak can up to now be sure that all access to the repository content is subject to the same permission evaluation as configured with the repository setup. This is no longer guaranteed when we offer the ability to plug application code that may or may not by-pass the evaluation by allowing it to directly access binaries. While I know that this is actually the goal of the whole exercise, we have to be aware that this also is a change in our Oak security model. As such this may look like a security breach and I have been told by my colleagues at Adobe that the 'single-way-to-access' is a relevant security question with a lot of potential customers. That doesn't mean that I am opposed to the patch in it's current form as I see the benefits from an Oak pov, I just want to highlight that we are going to make a fundamental change and we should treat and document it with the necessary care... maybe we should take this opportunity to finally create a threat model for Oak? Doing so at this stage would allow us to visualise the proposed change to all parties involved. wdyt? Kind regards Angela On 07/09/17 16:39, "Ian Boston" <[email protected]> wrote: >On 7 September 2017 at 14:41, Francesco Mari <[email protected]> >wrote: > >> On Thu, Sep 7, 2017 at 11:05 AM, Ian Boston <[email protected]> wrote: >> > On 7 September 2017 at 07:22, Ian Boston <[email protected]> wrote: >> > >> >> Hi, >> >> >> >> On 6 September 2017 at 22:43, Michael Dürig <[email protected]> >>wrote: >> >> >> >>> >> >>> >> >>> On 06.09.17 23:08, Michael Dürig wrote: >> >>> >> >>>> >> >>>> Hi, >> >>>> >> >>>> On 05.09.17 14:09, Ian Boston wrote: >> >>>> >> >>>>> Repeating the comment to on OAK-6575 here for further discussion. >>2 >> new >> >>>>> Patches exploring both options. >> >>>>> >> >>>> >> >>>> I would actually prefer the original patch ( >> >>>> https://github.com/ieb/jackrabbit-oak/compare/trunk...ieb:O >> >>>> AK-6575?expand=1) in most parts. However I have concerns regarding >>the >> >>>> generality of the new OakConversionService API as mentioned in my >> previous >> >>>> mail. I would be more comfortable if this could be restricted to >> something >> >>>> that resembles more like a "URIProvider", which given a blob >>returns >> an URI. >> >>>> >> >>>> On the implementation side, why do we need to introduce the >>adaptable >> >>>> machinery? Couldn't we re-use the Whiteboard and OSGiWhiteBoard >> mechanisms >> >>>> instead? I think these could be used to track URIProvider instances >> >>>> registered by the various blob stores. >> >>>> >> >>>> >> >>> See https://github.com/mduerig/jackrabbit-oak/commit/2709c097b01 >> >>> a006784b7011135efcbbe3ce1ba88 for a *really* quickly hacked together >> and >> >>> entirely untested POC. But it should get the idea across though. >> >> >> >> >> >> >> >> Thank you. >> >> That makes sense. >> >> I think it only needs the java/org/apache/jackrabbit/ >> >> oak/blob/cloud/aws/s3/CloudFrontS3SignedUrlAdapterFactory.java and >>the >> >> API to be inside Oak, everything else can be in Sling. >> >> I'll update my patch and do a 2 options for Sling. >> >> >> > >> > >> > >> > >> > https://github.com/ieb/jackrabbit-oak/compare/trunk.. >> .ieb:OAK-6575-3?expand=1 >> > >> > and >> > >> > >>https://github.com/apache/sling/compare/trunk...ieb:OAK-6575-3?expand=1 >> > >> > wdyt ? >> >> I like this a lot. It keeps Oak's side simple and cleanly integrates >> Oak's lower-level services in Sling. >> > > >Good news. >I think we should hold off committing the patch until Monday or Tuesday to >give those who may be offline this week a chance to comment. In particular >I have not seen a comment from Angela who I would expect to have a view as >this is acl/security related. That is assuming she is back online next >week. > >Best Regards >Ian > > >> >> > Obviously the second patch needs to be discussed with Sling dev, but >>is >> > should not be too contentious. >> > >> > Best Regards >> > Ian >> > >> > >> > >> >> >> >> I think that should address others concerns since it drops all signs >>of >> >> any generic object to object conversion from Oak (Francesco), and >> doesn't >> >> require wide scale fragile changes with implied requirements being >> placed >> >> on how intermediate classes are connected and behave (mine). >> >> >> >> Best Regards >> >> Ian >> >> >> >> >> >>> >> >>> Michael >> >>> >> >> >> >> >>
