Re: [HELP?] [RESULT] [VOTE] Release Apache Sling Hypermedia API tools 1.1.0
Thanks Karl! On Mon, Nov 13, 2017, 21:29 Karl Paulswrote: > Done. > > regards, > > Karl > > On Mon, Nov 13, 2017 at 5:48 PM, Karl Pauls wrote: > > I can do it tonight. > > > > regards, > > > > Karl > > > > On Mon, Nov 13, 2017 at 5:43 PM, Andrei Dulvac > wrote: > >> Hi, > >> > >> Can a PMC member help me with adding the release to the dist directory > and > >> promote the artifact to central? > >> > >> - Andrei > >> On Fri, Nov 10, 2017 at 3:33 PM Andrei Dulvac > wrote: > >> > >>> Hi, > >>> > >>> The vote has passed with the following result : > >>> > >>> +3 (binding): Carsten, Stefan, Karl > >>> +1 (non binding): Andrei Dulvac > >>> > >>> Can someone in the PMC help me with putting this release to the Sling > dist directory and > >>> promote the artifacts to maven central? > >>> > >>> - Andrei > >>> > >>> > >>> On Fri, Nov 10, 2017 at 1:22 PM Karl Pauls > wrote: > >>> > +1 > > regards, > > Karl > > On Fri, Nov 10, 2017 at 11:33 AM, Andrei Dulvac > wrote: > > Hi, > > > > Thanks for the votes. > > Anybody else can have a look? > > > > - Andrei > > > > On Wed, Nov 8, 2017 at 2:04 AM Stefan Seifert < > sseif...@pro-vision.de> > > wrote: > > > >> +1 > >> > > > > -- > Karl Pauls > karlpa...@gmail.com > > >>> > > > > > > > > -- > > Karl Pauls > > karlpa...@gmail.com > > > > -- > Karl Pauls > karlpa...@gmail.com >
Re: value level encryption
Ok, switching to CBC and then adding an additional property to store the IV for that resource. From: Antonio SansoSent: Monday, November 13, 2017 1:34 AM To: dev@sling.apache.org Subject: Re: value level encryption EXTERNAL hi Jason, leaving aside the API design for a second and focusing on the mere crypto. I would really be careful on what you are defining as default. AES ECB is almost = to no encryption. Same as providing a fixed IV… just saying….. regards antonio
Re: [RESULT] [VOTE] Release Apache Sling Event Support version 4.2.10
I think Carsten did add it to dist but he didn't release the repository - are you taking care of pushing this to central yourself or do you want me to release the maven repo for you? regards, Karl On Fri, Nov 10, 2017 at 9:55 AM, Timothee Maretwrote: > Hi, > > The vote has passed with the following result : > > +1 : Stefan Seifert, Carsten Ziegeler, Tommaso Teofili, Ian Boston > > > Could a member of the PMC please push the release to > https://dist.apache.org/repos/dist/release/sling ? > > I'll take care of the remaining steps once this is done. > > Regards, > > Timothee -- Karl Pauls karlpa...@gmail.com
[jira] [Resolved] (SLING-7232) Remove http.bridge from launchpad base
[ https://issues.apache.org/jira/browse/SLING-7232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved SLING-7232. --- Resolution: Fixed I merged the removal and created SLING-7240 to remember to add it back in when we have a launchpad.base release. [~cziegeler], if you give me the thumbs-up I would go ahead and call a launchpad.base release now (please although have another look at SLING-7186, just to make sure). > Remove http.bridge from launchpad base > -- > > Key: SLING-7232 > URL: https://issues.apache.org/jira/browse/SLING-7232 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Reporter: Carsten Ziegeler >Assignee: Karl Pauls > Fix For: Launchpad Base 2.6.26 > > > Currently launchpad base embedds the http.bridge bundle for the webapp setup. > So whenever the http bridge needs an update, we need to release a new > launchpad version. As this is just a bundle which needs to be available in > the webapp scenario we can move this to the provisioning model and bind it to > the webapp runmode. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7232) Remove http.bridge from launchpad base
[ https://issues.apache.org/jira/browse/SLING-7232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250298#comment-16250298 ] ASF GitHub Bot commented on SLING-7232: --- karlpauls closed pull request #2: SLING-7232: Remove the http.bridge bundle from the webapp base URL: https://github.com/apache/sling-org-apache-sling-launchpad-base/pull/2 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Remove http.bridge from launchpad base > -- > > Key: SLING-7232 > URL: https://issues.apache.org/jira/browse/SLING-7232 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Reporter: Carsten Ziegeler >Assignee: Karl Pauls > Fix For: Launchpad Base 2.6.26 > > > Currently launchpad base embedds the http.bridge bundle for the webapp setup. > So whenever the http bridge needs an update, we need to release a new > launchpad version. As this is just a bundle which needs to be available in > the webapp scenario we can move this to the provisioning model and bind it to > the webapp runmode. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] karlpauls closed pull request #2: SLING-7232: Remove the http.bridge bundle from the webapp base
karlpauls closed pull request #2: SLING-7232: Remove the http.bridge bundle from the webapp base URL: https://github.com/apache/sling-org-apache-sling-launchpad-base/pull/2 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (SLING-7232) Remove http.bridge from launchpad base
[ https://issues.apache.org/jira/browse/SLING-7232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated SLING-7232: -- Fix Version/s: (was: Launchpad Testing War 10) (was: Launchpad Builder 10) > Remove http.bridge from launchpad base > -- > > Key: SLING-7232 > URL: https://issues.apache.org/jira/browse/SLING-7232 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Reporter: Carsten Ziegeler >Assignee: Karl Pauls > Fix For: Launchpad Base 2.6.26 > > > Currently launchpad base embedds the http.bridge bundle for the webapp setup. > So whenever the http bridge needs an update, we need to release a new > launchpad version. As this is just a bundle which needs to be available in > the webapp scenario we can move this to the provisioning model and bind it to > the webapp runmode. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SLING-7240) Add the http.bridge bundle to the webapp
Karl Pauls created SLING-7240: - Summary: Add the http.bridge bundle to the webapp Key: SLING-7240 URL: https://issues.apache.org/jira/browse/SLING-7240 Project: Sling Issue Type: Bug Components: Launchpad Reporter: Karl Pauls Assignee: Karl Pauls Fix For: Launchpad Builder 10 If we update to that next launchpad.base release 5.6.10-2.6.26 we need to add the http.bridge in the webapp as it has been removed from the base in SLING-7232. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SLING-7240) Update to launchpad.base 5.6.10-2.6.26 and add the http.bridge bundle to the webapp
[ https://issues.apache.org/jira/browse/SLING-7240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated SLING-7240: -- Summary: Update to launchpad.base 5.6.10-2.6.26 and add the http.bridge bundle to the webapp (was: Add the http.bridge bundle to the webapp) > Update to launchpad.base 5.6.10-2.6.26 and add the http.bridge bundle to the > webapp > --- > > Key: SLING-7240 > URL: https://issues.apache.org/jira/browse/SLING-7240 > Project: Sling > Issue Type: Bug > Components: Launchpad >Reporter: Karl Pauls >Assignee: Karl Pauls > Fix For: Launchpad Builder 10 > > > If we update to that next launchpad.base release 5.6.10-2.6.26 we need to add > the http.bridge in the webapp as it has been removed from the base in > SLING-7232. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (SLING-7098) Bootdelegate jdk.* by default to avoid issues on java9
[ https://issues.apache.org/jira/browse/SLING-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed SLING-7098. - > Bootdelegate jdk.* by default to avoid issues on java9 > -- > > Key: SLING-7098 > URL: https://issues.apache.org/jira/browse/SLING-7098 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Affects Versions: Launchpad Base 2.6.24 >Reporter: Karl Pauls >Assignee: Karl Pauls > > Java9 requires to bootdelegate jdk.* packages. We should add it to the list > of default bootdelegations similar to what we do for sun.* and com.sun.* -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SLING-7098) Bootdelegate jdk.* by default to avoid issues on java9
[ https://issues.apache.org/jira/browse/SLING-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated SLING-7098: -- Fix Version/s: (was: Launchpad Base 2.6.26) > Bootdelegate jdk.* by default to avoid issues on java9 > -- > > Key: SLING-7098 > URL: https://issues.apache.org/jira/browse/SLING-7098 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Affects Versions: Launchpad Base 2.6.24 >Reporter: Karl Pauls >Assignee: Karl Pauls > > Java9 requires to bootdelegate jdk.* packages. We should add it to the list > of default bootdelegations similar to what we do for sun.* and com.sun.* -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-7098) Bootdelegate jdk.* by default to avoid issues on java9
[ https://issues.apache.org/jira/browse/SLING-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved SLING-7098. --- Resolution: Won't Fix I don't think we should do this by default. With the improved java9 support in Felix we hopefully don't need this anymore (at least not by default). > Bootdelegate jdk.* by default to avoid issues on java9 > -- > > Key: SLING-7098 > URL: https://issues.apache.org/jira/browse/SLING-7098 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Affects Versions: Launchpad Base 2.6.24 >Reporter: Karl Pauls >Assignee: Karl Pauls > Fix For: Launchpad Base 2.6.26 > > > Java9 requires to bootdelegate jdk.* packages. We should add it to the list > of default bootdelegations similar to what we do for sun.* and com.sun.* -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-7186) Update to Felix Framework 5.6.10 and limit system bundle exports to available packages on java9
[ https://issues.apache.org/jira/browse/SLING-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved SLING-7186. --- Resolution: Fixed I updated to Felix Framework 5.6.10 and set the system bundle exports to match what we have on older jre's (if they java9 modules are available). > Update to Felix Framework 5.6.10 and limit system bundle exports to available > packages on java9 > --- > > Key: SLING-7186 > URL: https://issues.apache.org/jira/browse/SLING-7186 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Affects Versions: Launchpad Base 2.6.24 >Reporter: Karl Pauls >Assignee: Karl Pauls > Fix For: Launchpad Base 2.6.26 > > > We need to revisit the packages we export from the system bundle as well as > the extension bundles we add when running with java9. The issue is that by > default, starting with java9, we only have java.se modules on the module > path. Our current packages list + extension bundles assumes java.se.ee to be > present (which is not the case unless it is specifically requested via > --add-modules). > We have to investigate what we want to do to remedy this situation - I'll > create subtasks for the actual work (which probably has to include updating > to a Felix 5.6.10 when it is released). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7186) Update to Felix Framework 5.6.10 and limit system bundle exports to available packages on java9
[ https://issues.apache.org/jira/browse/SLING-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250287#comment-16250287 ] ASF GitHub Bot commented on SLING-7186: --- karlpauls closed pull request #1: SLING-7186: Improve java9 system package handling URL: https://github.com/apache/sling-org-apache-sling-launchpad-base/pull/1 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Update to Felix Framework 5.6.10 and limit system bundle exports to available > packages on java9 > --- > > Key: SLING-7186 > URL: https://issues.apache.org/jira/browse/SLING-7186 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Affects Versions: Launchpad Base 2.6.24 >Reporter: Karl Pauls >Assignee: Karl Pauls > Fix For: Launchpad Base 2.6.26 > > > We need to revisit the packages we export from the system bundle as well as > the extension bundles we add when running with java9. The issue is that by > default, starting with java9, we only have java.se modules on the module > path. Our current packages list + extension bundles assumes java.se.ee to be > present (which is not the case unless it is specifically requested via > --add-modules). > We have to investigate what we want to do to remedy this situation - I'll > create subtasks for the actual work (which probably has to include updating > to a Felix 5.6.10 when it is released). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] karlpauls closed pull request #1: SLING-7186: Improve java9 system package handling
karlpauls closed pull request #1: SLING-7186: Improve java9 system package handling URL: https://github.com/apache/sling-org-apache-sling-launchpad-base/pull/1 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (SLING-7186) Update to Felix Framework 5.6.10 and limit system bundle exports to available packages on java9
[ https://issues.apache.org/jira/browse/SLING-7186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls updated SLING-7186: -- Summary: Update to Felix Framework 5.6.10 and limit system bundle exports to available packages on java9 (was: System bundle + extension bundles should only export available packages on java9) > Update to Felix Framework 5.6.10 and limit system bundle exports to available > packages on java9 > --- > > Key: SLING-7186 > URL: https://issues.apache.org/jira/browse/SLING-7186 > Project: Sling > Issue Type: Improvement > Components: Launchpad >Affects Versions: Launchpad Base 2.6.24 >Reporter: Karl Pauls >Assignee: Karl Pauls > Fix For: Launchpad Base 2.6.26 > > > We need to revisit the packages we export from the system bundle as well as > the extension bundles we add when running with java9. The issue is that by > default, starting with java9, we only have java.se modules on the module > path. Our current packages list + extension bundles assumes java.se.ee to be > present (which is not the case unless it is specifically requested via > --add-modules). > We have to investigate what we want to do to remedy this situation - I'll > create subtasks for the actual work (which probably has to include updating > to a Felix 5.6.10 when it is released). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Re: [HELP?] [RESULT] [VOTE] Release Apache Sling Hypermedia API tools 1.1.0
Done. regards, Karl On Mon, Nov 13, 2017 at 5:48 PM, Karl Paulswrote: > I can do it tonight. > > regards, > > Karl > > On Mon, Nov 13, 2017 at 5:43 PM, Andrei Dulvac wrote: >> Hi, >> >> Can a PMC member help me with adding the release to the dist directory and >> promote the artifact to central? >> >> - Andrei >> On Fri, Nov 10, 2017 at 3:33 PM Andrei Dulvac wrote: >> >>> Hi, >>> >>> The vote has passed with the following result : >>> >>> +3 (binding): Carsten, Stefan, Karl >>> +1 (non binding): Andrei Dulvac >>> >>> Can someone in the PMC help me with putting this release to the Sling dist >>> directory and >>> promote the artifacts to maven central? >>> >>> - Andrei >>> >>> >>> On Fri, Nov 10, 2017 at 1:22 PM Karl Pauls wrote: >>> +1 regards, Karl On Fri, Nov 10, 2017 at 11:33 AM, Andrei Dulvac wrote: > Hi, > > Thanks for the votes. > Anybody else can have a look? > > - Andrei > > On Wed, Nov 8, 2017 at 2:04 AM Stefan Seifert > wrote: > >> +1 >> -- Karl Pauls karlpa...@gmail.com >>> > > > > -- > Karl Pauls > karlpa...@gmail.com -- Karl Pauls karlpa...@gmail.com
Re: [HELP?] [RESULT] [VOTE] Release Apache Sling Hypermedia API tools 1.1.0
I can do it tonight. regards, Karl On Mon, Nov 13, 2017 at 5:43 PM, Andrei Dulvacwrote: > Hi, > > Can a PMC member help me with adding the release to the dist directory and > promote the artifact to central? > > - Andrei > On Fri, Nov 10, 2017 at 3:33 PM Andrei Dulvac wrote: > >> Hi, >> >> The vote has passed with the following result : >> >> +3 (binding): Carsten, Stefan, Karl >> +1 (non binding): Andrei Dulvac >> >> Can someone in the PMC help me with putting this release to the Sling dist >> directory and >> promote the artifacts to maven central? >> >> - Andrei >> >> >> On Fri, Nov 10, 2017 at 1:22 PM Karl Pauls wrote: >> >>> +1 >>> >>> regards, >>> >>> Karl >>> >>> On Fri, Nov 10, 2017 at 11:33 AM, Andrei Dulvac >>> wrote: >>> > Hi, >>> > >>> > Thanks for the votes. >>> > Anybody else can have a look? >>> > >>> > - Andrei >>> > >>> > On Wed, Nov 8, 2017 at 2:04 AM Stefan Seifert >>> > wrote: >>> > >>> >> +1 >>> >> >>> >>> >>> >>> -- >>> Karl Pauls >>> karlpa...@gmail.com >>> >> -- Karl Pauls karlpa...@gmail.com
Re: [HELP?] [RESULT] [VOTE] Release Apache Sling Hypermedia API tools 1.1.0
Hi, Can a PMC member help me with adding the release to the dist directory and promote the artifact to central? - Andrei On Fri, Nov 10, 2017 at 3:33 PM Andrei Dulvacwrote: > Hi, > > The vote has passed with the following result : > > +3 (binding): Carsten, Stefan, Karl > +1 (non binding): Andrei Dulvac > > Can someone in the PMC help me with putting this release to the Sling dist > directory and > promote the artifacts to maven central? > > - Andrei > > > On Fri, Nov 10, 2017 at 1:22 PM Karl Pauls wrote: > >> +1 >> >> regards, >> >> Karl >> >> On Fri, Nov 10, 2017 at 11:33 AM, Andrei Dulvac >> wrote: >> > Hi, >> > >> > Thanks for the votes. >> > Anybody else can have a look? >> > >> > - Andrei >> > >> > On Wed, Nov 8, 2017 at 2:04 AM Stefan Seifert >> > wrote: >> > >> >> +1 >> >> >> >> >> >> -- >> Karl Pauls >> karlpa...@gmail.com >> >
[jira] [Created] (SLING-7239) LogbackManager may miss out some OSGi config at time of startup
Chetan Mehrotra created SLING-7239: -- Summary: LogbackManager may miss out some OSGi config at time of startup Key: SLING-7239 URL: https://issues.apache.org/jira/browse/SLING-7239 Project: Sling Issue Type: Bug Components: Commons Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Fix For: Commons Log 5.0.4 {{LogbackManager}} currently upon construction reads all the OSGi config and configure them in Logback. Config which comes laters leads to logback reset. However during the time when its getting constructed it has a logic to ignore the reset flag initialization for startup. This may lead to a race condition where some OSGi configs are picked up while it is getting constructed and some OSGi config arriving later are not picked up. For e.g. # LogbackManager constructor is invoked # It constructs LogConfigManager which registers the managed services # ManagedServices receive some OSGi config and push them to LogConfigManager # LogbackManager picks them up and add them to Logback but still startup is not finished i.e. started = true is not called # Some more OSGi config arrive - These would get ignored as LogbackManager#configChanged would ignore the calls because started != true # LogbackManager startup completes and started = true So here configs at #5 would not be picked up unless at #7 some more OSGi config arrive. Or some one modifies the config post system start -- This message was sent by Atlassian JIRA (v6.4.14#64029)
RE: value level encryption
I hear what you are saying. Once I have all the working pieces in place I will be diving more into the encryption methodology. I believe there's going to be a limit to what can be implemented because of the use cases. Saying that, I'm open to feedback, ideas and pull requests. -Original Message- From: Antonio Sanso [mailto:asa...@adobe.com.INVALID] Sent: Monday, November 13, 2017 1:35 AM To: dev@sling.apache.org Subject: Re: value level encryption EXTERNAL hi Jason, leaving aside the API design for a second and focusing on the mere crypto. I would really be careful on what you are defining as default. AES ECB is almost = to no encryption. Same as providing a fixed IV... just saying. regards antonio On Nov 10, 2017, at 9:53 PM, Jason Baileywrote: > Wanted to give a heads up in the direction I'm going with this. > > https://github.com/JEBailey/sling-encrypt > > CipherProvider is a service interface to provide pre-initialized Cipher > Objects for encoding and decoding content. > EncryptionValueMap encompasses the functionality to encrypt and decrypt > specific fields, currently focusing on String and String[] value types. Put > and Get methods not implemented yet. > EncryptionValueMapDecorator to wrap a map. > > For the EncryptionValueMap, I'm recording the properties that are encrypted > in a separate property field, so that accessing those fields can be done > seamlessly from any place that you are instantiate the EncryptionValueMap. > > Feedback appreciated. > > -Original Message- > From: Justin Edelson [mailto:jus...@justinedelson.com] > Sent: Friday, November 03, 2017 3:37 PM > To: dev@sling.apache.org > Subject: Re: value level encryption > > EXTERNAL > > In AEM, posting encrypted properties to /etc/cloudservices is historically > the primary use case for @Encrypted, but the PostProcessor applies to all > post requests. > > I think this would be a useful addition to Sling. We may want to have some > kind of SPI to support different encryption schemes, but that's an > implementation detail. > > Regards, > Justin > > > On Fri, Nov 3, 2017 at 2:48 PM Jason Bailey wrote: > >> They only docs I can find on that, assuming we're talking AEM, >> mentions it only works for posting things into /etc/cloudservices. So that's >> out. >> It's been a while, but I'm under the impression that all >> implementations of the java platform now come with a certain level of >> crypto >> >> https://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html >> >> I'd probably add a configuration so you could define the level of >> cryptography, and then that would allow people who needed a higher >> level to install their own providers. Is this something that Sling >> would be interested in? Since I'm going to be writing this, if you're >> interested, I'd rather write it with the intent of directly donating it. >> >> >> >> -Original Message- >> From: Justin Edelson [mailto:jus...@justinedelson.com] >> Sent: Friday, November 03, 2017 1:35 PM >> To: dev@sling.apache.org >> Subject: Re: value level encryption >> >> EXTERNAL >> >> We have this in our commercial product. At a high level, the way it >> works is that there is a PostProcessor which looks for an @Encrypted >> postfixed property and, if that is present, the corresponding >> property is stored in an encrypted fashion. Decryption is all done >> manually, although personally the idea of an EncryptionValueMap seems really >> cool to me. >> >> I believe the challenge in bringing this into Sling relates to the >> encryption libraries. >> >> On Fri, Nov 3, 2017 at 8:45 AM Jason Bailey wrote: >> >>> Here's the use case >>> >>> My organization has decided that to conform to the GDPR, any >>> sensitive data should be encrypted while at rest. From a Sling >>> perspective that is a challenge since we've empowered the authors to >>> create forms the way they want. So to be on the safe side, we're >>> looking at encrypting all form fields as they are persisted, and >>> then decrypting the values from the resource when we need to processes >>> them. >>> >>> Now I'm thinking of an EncryptionValueMap that will simplify this >>> process and encapsulate the functionality. You guys are usually >>> ahead of me when I come up with this stuff and I don't like >>> replicating effort. So is there any functionality currently or >>> planned to handle encryption of resource values? >>> >>> Thanks >>> Jason >>> >>
RE: value level encryption
I'm debating the two possible solutions to this, since the original use case was encryption of form submitted data, it would be valid to return null object for a resource that can't be modified. However, I could see the potential for having a resource provider that contains encrypted information. Which would mean effectively returning a read only version, and throwing an UnsupportedOperationException on the methods that modify the underlying resource. I'm leaning towards the read only version. But open to feedback. -Original Message- From: Konrad Windszus [mailto:konra...@gmx.de] Sent: Friday, November 10, 2017 4:28 PM To: dev@sling.apache.org Subject: Re: value level encryption EXTERNAL Also EncryptionMapAdapterFactory.getAdapter() should be able to deal with resource providers not providing write access (i.e. adaptTo(ModifiableValueMap.class) returns null). > Am 10.11.2017 um 22:21 schrieb Konrad Windszus: > > Hi Jason, in general this looks good. But please add nullability annotations > to CipherProvider. Also using @CheckForNull on methods returning void is > useless. > Konrad > >> Am 10.11.2017 um 21:53 schrieb Jason Bailey : >> >> Wanted to give a heads up in the direction I'm going with this. >> >> https://github.com/JEBailey/sling-encrypt >> >> CipherProvider is a service interface to provide pre-initialized Cipher >> Objects for encoding and decoding content. >> EncryptionValueMap encompasses the functionality to encrypt and decrypt >> specific fields, currently focusing on String and String[] value types. Put >> and Get methods not implemented yet. >> EncryptionValueMapDecorator to wrap a map. >> >> For the EncryptionValueMap, I'm recording the properties that are encrypted >> in a separate property field, so that accessing those fields can be done >> seamlessly from any place that you are instantiate the EncryptionValueMap. >> >> Feedback appreciated. >> >> -Original Message- >> From: Justin Edelson [mailto:jus...@justinedelson.com] >> Sent: Friday, November 03, 2017 3:37 PM >> To: dev@sling.apache.org >> Subject: Re: value level encryption >> >> EXTERNAL >> >> In AEM, posting encrypted properties to /etc/cloudservices is historically >> the primary use case for @Encrypted, but the PostProcessor applies to all >> post requests. >> >> I think this would be a useful addition to Sling. We may want to have some >> kind of SPI to support different encryption schemes, but that's an >> implementation detail. >> >> Regards, >> Justin >> >> >>> On Fri, Nov 3, 2017 at 2:48 PM Jason Bailey wrote: >>> >>> They only docs I can find on that, assuming we're talking AEM, >>> mentions it only works for posting things into /etc/cloudservices. So >>> that's out. >>> It's been a while, but I'm under the impression that all >>> implementations of the java platform now come with a certain level >>> of crypto >>> >>> https://docs.oracle.com/javase/8/docs/api/javax/crypto/Cipher.html >>> >>> I'd probably add a configuration so you could define the level of >>> cryptography, and then that would allow people who needed a higher >>> level to install their own providers. Is this something that Sling >>> would be interested in? Since I'm going to be writing this, if >>> you're interested, I'd rather write it with the intent of directly donating >>> it. >>> >>> >>> >>> -Original Message- >>> From: Justin Edelson [mailto:jus...@justinedelson.com] >>> Sent: Friday, November 03, 2017 1:35 PM >>> To: dev@sling.apache.org >>> Subject: Re: value level encryption >>> >>> EXTERNAL >>> >>> We have this in our commercial product. At a high level, the way it >>> works is that there is a PostProcessor which looks for an @Encrypted >>> postfixed property and, if that is present, the corresponding >>> property is stored in an encrypted fashion. Decryption is all done >>> manually, although personally the idea of an EncryptionValueMap seems >>> really cool to me. >>> >>> I believe the challenge in bringing this into Sling relates to the >>> encryption libraries. >>> On Fri, Nov 3, 2017 at 8:45 AM Jason Bailey wrote: Here's the use case My organization has decided that to conform to the GDPR, any sensitive data should be encrypted while at rest. From a Sling perspective that is a challenge since we've empowered the authors to create forms the way they want. So to be on the safe side, we're looking at encrypting all form fields as they are persisted, and then decrypting the values from the resource when we need to processes them. Now I'm thinking of an EncryptionValueMap that will simplify this process and encapsulate the functionality. You guys are usually ahead of me when I come up with this stuff and I don't like replicating effort. So is there any functionality currently or planned to handle
[jira] [Closed] (SLING-7230) CAConfig Impl: Allow to configure alterantive lookup resource names for configuration collection properties
[ https://issues.apache.org/jira/browse/SLING-7230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-7230. - > CAConfig Impl: Allow to configure alterantive lookup resource names for > configuration collection properties > --- > > Key: SLING-7230 > URL: https://issues.apache.org/jira/browse/SLING-7230 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: Context-Aware Configuration Impl 1.4.6 >Reporter: Stefan Seifert >Assignee: Stefan Seifert > Labels: contextaware-config > Fix For: Context-Aware Configuration Impl 1.4.8 > > > when custom node structures are used to store configuration collection parent > nodes with storing the collection properties in a subnode (e.g. > {{jcr:content}}), this needs to be supported by the ConfigurationManager > implementation as well. > for the {{DefaultConfigurationInheritanceStrategy}} a configuration property > already exists (configPropertyInheritancePropertyNames), but not for the > ConfigurationManager implementation which returns the property map of a > configuration collection. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (SLING-7208) CAConfig Impl: Make ConfigurationResourceResolverConfig service accessible from outside
[ https://issues.apache.org/jira/browse/SLING-7208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-7208. - > CAConfig Impl: Make ConfigurationResourceResolverConfig service accessible > from outside > --- > > Key: SLING-7208 > URL: https://issues.apache.org/jira/browse/SLING-7208 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: Context-Aware Configuration Impl 1.4.6 >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Minor > Fix For: Context-Aware Configuration Impl 1.4.8 > > > the service interface > {{org.apache.sling.caconfig.impl.ConfigurationResourceResolverConfig}} is > currently available only to the internal implementation. > it should be made accessible from outside as part of the Management API. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Re: [VOTE] Release Apache Sling Context-Aware Configuration Impl 1.4.8
On Wed, 2017-11-08 at 11:59 +, Stefan Seifert wrote: > Please vote to approve this release: +1 Robert signature.asc Description: This is a digitally signed message part
RE: [VOTE] Release Apache Sling Context-Aware Configuration Impl 1.4.8
one (binding) vote is missing ... stefan >-Original Message- >From: Stefan Seifert [mailto:sseif...@pro-vision.de] >Sent: Wednesday, November 8, 2017 1:00 PM >To: 'dev@sling.apache.org' >Subject: [VOTE] Release Apache Sling Context-Aware Configuration Impl 1.4.8 > >Hi, > >We solved 2 issues in this release: >https://issues.apache.org/jira/browse/SLING/fixforversion/12341711 > >Staging repository: >https://repository.apache.org/content/repositories/orgapachesling-1809/ > >You can use this UNIX script to download the release and verify the >signatures: >http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh > >Usage: >sh check_staged_release.sh 1809 /tmp/sling-staging > >Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > >This majority vote is open for at least 72 hours. > >stefan >
[jira] [Created] (SLING-7238) Import fail if user does not have access to the root path
Timothee Maret created SLING-7238: - Summary: Import fail if user does not have access to the root path Key: SLING-7238 URL: https://issues.apache.org/jira/browse/SLING-7238 Project: Sling Issue Type: Bug Components: Content Distribution Affects Versions: Content Distribution Core 0.2.8 Reporter: Timothee Maret Assignee: Timothee Maret Fix For: Content Distribution Core 0.2.10 The current FileVault API used to import content is the following {code} org.apache.jackrabbit.vault.fs.io.Importer#run(archive,importRoot) {code} which fail to import content for sessions that don't have access to the root node. With JCRVLT-227, a new API signature has been added which does not require access to the root node anymore. This issue tracks leveraging JCRVLT-227 in SCD core. -- This message was sent by Atlassian JIRA (v6.4.14#64029)