Re: [HELP?] [RESULT] [VOTE] Release Apache Sling Hypermedia API tools 1.1.0

[Andrei Dulvac]

Thanks Karl!

On Mon, Nov 13, 2017, 21:29 Karl Pauls  wrote:

> 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

[Jason Bailey]

Ok, switching to CBC and then adding an additional property to store the IV for 
that resource. 

From: Antonio Sanso 
Sent: 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

[Karl Pauls]

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 Maret  wrote:
> 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

[Karl Pauls (JIRA)]

 [ 
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

[ASF GitHub Bot (JIRA)]

[ 
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

[GitBox]

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

[Karl Pauls (JIRA)]

 [ 
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 (JIRA)]

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

[Karl Pauls (JIRA)]

 [ 
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

[Karl Pauls (JIRA)]

 [ 
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

[Karl Pauls (JIRA)]

 [ 
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

[Karl Pauls (JIRA)]

 [ 
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

[Karl Pauls (JIRA)]

 [ 
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

[ASF GitHub Bot (JIRA)]

[ 
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

[GitBox]

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

[Karl Pauls (JIRA)]

 [ 
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

[Karl Pauls]

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 
 > 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

[Karl Pauls]

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

Re: [HELP?] [RESULT] [VOTE] Release Apache Sling Hypermedia API tools 1.1.0

[Andrei Dulvac]

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
>>
>

[jira] [Created] (SLING-7239) LogbackManager may miss out some OSGi config at time of startup

[Chetan Mehrotra (JIRA)]

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

[Jason Bailey]

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 Bailey  wrote:

> 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

[Jason Bailey]

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

[Stefan Seifert (JIRA)]

 [ 
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

[Stefan Seifert (JIRA)]

 [ 
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

[Robert Munteanu]

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

[Stefan Seifert]

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 (JIRA)]

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)