Hi, This is a review of the links shared, clarifying OAK-6575 relationship to the discussion, where it is the same and where it is different. Apologies for the long email, there is a lot of material to cover, and it would be wrong to brush over the concerns of comitters with a few words.
--------------------------------------------------------------------- [1] http://markmail.org/thread/enmibgfwedypjnos#query:+page:1+mid:5cf7dkcvfhen7c7x+state:results I thread [1] a method to convert a binary to a File or URL which could perform any action on the binary was presented. The Value -> URI conversion in OAK-6575, performed by the blob-cloud bundle does not do this. It only allows CloudFront to perform a GET operation on the S3 bucket that the instance of CloudFront is granted access to. The URI has a well defined lifetime (60s by default, but could be 5s) and is signed with a shared private key. It does not give an attacker the ability to guess or forge other CloudFront URLs. It also does not allow any developer in the same JVM to use the URI to access any other binary, store the URI or use it in any other way. Obviously if the developer gets hold of the credentials to the S3 bucket or the private key, or is prepared to use ASM, they can do almost whatever they like. This approach builds on the AWS recommended way of serving private content via CloudFront. The patch does introduce a conversion service, owned and controlled by Oak, that will only allow Oak owned code to perform other conversions. This is *not* the Sling AdapterManager and does *not* permit code that does not have access to Oaks core-spi packages to add arbitrary conversions. It does open the door for Oak committers to support object conversions without a chain of API changes. OAK-6575 may or may not address the concerns raised in the thread [1]. I was a contributor to that thread, but had forgotten its outcome. I suspect the conversation there informed the work done in OAK-6575. It would be wrong to say OAK-6575 is a duplicate of [1]. [1] started the work of documenting the binary use cases, which informed OAK-6575. ------------------------------ [2] https://issues.apache.org/jira/browse/OAK-1963 OAK-1963 considered exposing an generic unsigned S3 URL of File object to give whatever access the holder of that URL could manage, either because they had credentials to access to the bucket or because the bucket was public to them. The URLs in OAK-1963 were long lived. OAK-6575 does not do this. It signs a URL with a canned AWS access policy that only allows GET and only by CloudFront. The S3 bucket is not public and cant be accesses. The CloudFront instance must be configured and granted access to the S3 bucket in the same way as any other AWS service. ------------------------ [3] https://lists.apache.org/thread.html/2efb1da82b9b93a3a394c3abccbac960175ffc7a13facaac79c9181a@%3Coak-dev.jackrabbit.apache.org%3E In particular https://lists.apache.org/thread.html/acc9eeef966916791c6073e76d3baa232f48abece4ae6b31f264a8ba@%3Coak-dev.jackrabbit.apache.org%3E posted by Tommaso, and I assume referenced in this thread in relation to using JWT. AFAIK, CloudFront does not support GET authorisations secured by JWT. It only supports access to S3 private content using the recommended AWS signed URLs approach. Although OAK-6575 provides an implementation emitting a CloudFront Signed URL, the same approach could be used for a JWT URL. ------------------------------------------ [1]: https://lists.apache.org/thread.html/8b0021987b824b096ea9b470a4edd5 edf1a246ef10548a2343ad4668@1462438837@%3Coak-dev.jackrabbit.apache.org%3E [2]: https://lists.apache.org/thread.html/4c352d247da81ca6ab05abfb7c5336 8fb88ed3c587fb09b42b87b6ae@1462439965@%3Coak-dev.jackrabbit.apache.org%3E [3]: https://lists.apache.org/thread.html/fbf28d5e864adbebd677a425cc915f 89cbd7e0ef85a589fb4f948b51@1462784316@%3Coak-dev.jackrabbit.apache.org%3E [4]: https://lists.apache.org/thread.html/77b05609b7e6f0deedbd3282f734f8 c606e6a7451db0698f29082d7b@1462891501@%3Coak-dev.jackrabbit.apache.org%3E [5]: https://lists.apache.org/thread.html/d8da865c1f971ff4c84c9616d9f09e a9369f3e0c6db20f98fbc6e4d3@%3Coak-dev.jackrabbit.apache.org%3E [6]: https://lists.apache.org/thread.html/ab1d40572467eeee4ef5855af0a0a9 e87255d1144fe40762ff8e9d47@%3Coak-dev.jackrabbit.apache.org%3E [7]: https://lists.apache.org/thread.html/acc9eeef966916791c6073e76d3baa 232f48abece4ae6b31f264a8ba@%3Coak-dev.jackrabbit.apache.org%3E AFAICT, all of these references are references to specific messages in the 2 threads which were read from start to end and already commented on. I dont think anyone would appreciate a comment on each link in turn. If there is a concern that has been missed, please point it out. -------------------------------------------------------------------------------------------------------------- In Summary: I believe OAK-6575 to be different to what was proposed under the thread of May 2016 and OAK-1963. It was informed by that discussion with the intention of addressing the concerns, even though I did not remember exactly which thread it was from the sha1 or the OAK issue number. While it does introduce a pattern that would allow other conversions which would, as Tommaso and Francesco (and others have pointed out) this can only be utilized to create conversions by code owned by Oak, giving Oak complete control over what, if anything can be converted. That assumes code outside Oak is not allowed to implement Oak SPI interfaces and register those implementations. This pattern was introduced at the request of other Oak committers to remove the need for any Oak API changes. It is fundamentally different from OAK-1963 because it provides a signed URL that only allows the action that the current Oak session has been granted and only for short period of time, just enough to perform a redirect. If Oak committers feel that the contribution can't be included. Please feel free to close OAK-6575 and I will delete the GitHub branch. (I am not a committer, so have nothing binding here, other than a desire to improve Oak.) Best Regards Ian On 4 September 2017 at 14:44, Ian Boston <i...@tfd.co.uk> wrote: > Hi Francesco and Tommaso, > I was not aware of the previous discussions and will now read those > threads and issues. I submitted the issue, patch and thread in good faith, > not having a detailed knowledge of everything that has been discussed on > oak-dev. I was not trying to ignore or circumvent any previous decisions or > opinions. If OAK-6575 brings nothing new and does not address those > concerns I would not be offended to have the patch and issue rejected and > deleted and for Oak not to have this capability, although obviously I feel > that Oak is weaker without the ability to offload bulk data streaming to > infrastructure designed for that purpose. > > Let me read the links you have shared and get back to you. > Best Regards > Ian > > On 4 September 2017 at 14:20, Tommaso Teofili <tommaso.teof...@gmail.com> > wrote: > >> I share Francesco's concerns, the same way I shared them when we first >> discussed this way back; I tried to express my doubts on the current >> proposal in the email thread for OAK-6575 (linked also in Francesco's >> email), which got ignored; that's fine as long as the majority of us is >> happy with the current solution, probably it's just me having this not so >> good feeling here with me, that some of us want this feature to be in a >> way >> or another. >> >> Tommaso >> >> >> >> Il giorno lun 4 set 2017 alle ore 14:45 Francesco Mari < >> mari.france...@gmail.com> ha scritto: >> >> > On Mon, Sep 4, 2017 at 2:13 PM, Chetan Mehrotra >> > <chetan.mehro...@gmail.com> wrote: >> > > Adaptable pattern in itself was not much discussed at that time. >> > >> > Concerns about the adaptable pattern and its implications in data >> > encapsulation were expressed in the old thread at [1], [2], [3], [4], >> > and in other messages in the same thread. In the new thread, it was >> > pointed out [5] that solving the problem discussed in OAK-6575 is >> > orthogonal to the introduction of the adaptable pattern. Moreover, in >> > the new thread some concerns were expressed about the adaptable >> > pattern as well at [6] and [7]. >> > >> > [1]: >> > https://lists.apache.org/thread.html/8b0021987b824b096ea9b47 >> 0a4edd5edf1a246ef10548a2343ad4668@1462438837@%3Coak-dev.jack >> rabbit.apache.org%3E >> > [2]: >> > https://lists.apache.org/thread.html/4c352d247da81ca6ab05abf >> b7c53368fb88ed3c587fb09b42b87b6ae@1462439965@%3Coak-dev.jack >> rabbit.apache.org%3E >> > [3]: >> > https://lists.apache.org/thread.html/fbf28d5e864adbebd677a42 >> 5cc915f89cbd7e0ef85a589fb4f948b51@1462784316@%3Coak-dev.jack >> rabbit.apache.org%3E >> > [4]: >> > https://lists.apache.org/thread.html/77b05609b7e6f0deedbd328 >> 2f734f8c606e6a7451db0698f29082d7b@1462891501@%3Coak-dev.jack >> rabbit.apache.org%3E >> > [5]: >> > https://lists.apache.org/thread.html/d8da865c1f971ff4c84c961 >> 6d9f09ea9369f3e0c6db20f98fbc6e4d3@%3Coak-dev.jackrabbit.apache.org%3E >> > [6]: >> > https://lists.apache.org/thread.html/ab1d40572467eeee4ef5855 >> af0a0a9e87255d1144fe40762ff8e9d47@%3Coak-dev.jackrabbit.apache.org%3E >> > [7]: >> > https://lists.apache.org/thread.html/acc9eeef966916791c6073e >> 76d3baa232f48abece4ae6b31f264a8ba@%3Coak-dev.jackrabbit.apache.org%3E >> > >> > >
