RE: [VOTE] Release Apache Sling Commons Scheduler 2.4.6

[Mike Müller]

+1

Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Sunday, March 01, 2015 3:34 PM
> To: Sling Developers
> Subject: [VOTE] Release Apache Sling Commons Scheduler 2.4.6
> 
> Hi,
> 
> We solved 1 issue in this release:
> https://issues.apache.org/jira/browse/SLING-4460
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1197/
> 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 1197 /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.
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

RE: [VOTE] Release Apache Sling Testing Resource Resolver Mock version 0.3.0

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Stefan Seifert [mailto:sseif...@pro-vision.de]
> Sent: Thursday, September 25, 2014 11:23 AM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Testing Resource Resolver Mock version 
> 0.3.0
> 
> Hi,
> 
> We solved 4 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12326159
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1131/
> 
> 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 1131 /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
> 
> p.s. this is my first apache sling release, hopefully PGP signing etc. is all 
> correct.

[RESULT] [VOTE] Sling Resource Access Security version 1.0.0

[Mike Müller]

Hi,

The vote has passed with the following result :

+1 (binding): Robert Munteanu, Carsten Ziegeler, Mike Müller

I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.

Best regards
mike

RE: [VOTE] Release Apache Sling Auth Core 1.3.0

[Mike Müller]

+1 best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Wednesday, September 17, 2014 3:23 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Auth Core 1.3.0
> 
> Hi,
> 
> We solved two issue:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12328549
> 
> 
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1124
> 
> 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 1124 /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.
> 
> Regards
> 
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

RE: [VOTE] Release Apache Sling DavEx Access to repositories 1.2.2

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Robert Munteanu [mailto:romb...@apache.org]
> Sent: Wednesday, September 17, 2014 8:34 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling DavEx Access to repositories 1.2.2
> 
> Hi,
> 
> We solved 1 issue in this release:
> https://issues.apache.org/jira/browse/SLING-3262
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1125/
> 
> 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 1125 /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.

RE: [VOTE] Release Apache Sling Resource Access Security version 1.0.0

[Mike Müller]

+1


> -Original Message-
> From: Mike Müller [mailto:mike...@mysign.ch]
> Sent: Wednesday, September 17, 2014 2:19 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Resource Access Security version 1.0.0
> 
> Hi,
> 
> It's time to make a first release of the Resource Access Security bundle.
> There's a lot of test coverage and the feature set includes access 
> controlling on all CRUD
> operations.
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1122/
> 
> 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 1122 /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.
> 
> Best regards
> mike

[VOTE] Release Apache Sling Resource Access Security version 1.0.0

[Mike Müller]

Hi,

It's time to make a first release of the Resource Access Security bundle. 
There's a lot of test coverage and the feature set includes access controlling 
on all CRUD
operations.

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1122/

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 1122 /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.

Best regards
mike

RE: [ANN] New Apache Sling Committer: Stefan Seifert

[Mike Müller]

Welcome on board Stefan!

Best regards
mike

> -Original Message-
> From: Stefan Seifert [mailto:sseif...@pro-vision.de]
> Sent: Monday, September 08, 2014 9:21 PM
> To: dev@sling.apache.org
> Subject: RE: [ANN] New Apache Sling Committer: Stefan Seifert
> 
> thank you very much!
> 
> a few introductory words about me:
> 
> i'm living (and was born) in berlin. i'm closely attached with apache 
> projects since nearly 15 years now. in the first years
> that was primarily the apache cocoon framework, but since 2009 my focus lies 
> at apache sling and felix. i've touched a
> lot of areas of sling in the past, currently i'm involved in the sling models 
> and testing subprojects. a new area where i see
> the need for adding important features to the sling frameworks is multi 
> tenancy and configuration support. i'm looking
> forward to further support sling in the future!
> 
> stefan
> 
> p.s. btw. my company is the host and sponsor (together with adobe) of the 
> yearly conference for Sling & Friends in
> Berlin: http://adapt.to
> 
> 
> >-Original Message-
> >From: Carsten Ziegeler [mailto:cziege...@apache.org]
> >Sent: Monday, September 08, 2014 6:21 PM
> >To: dev@sling.apache.org
> >Subject: [ANN] New Apache Sling Committer: Stefan Seifert
> >
> >Hi
> >
> >it's my pleasure to announce that the Apache Sling PMC has invited Stefan
> >Seifert as a new Sling committer...and Stefan accepted.

RE: [VOTE] Release Apache Sling API 2.8.0, take II

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Thursday, August 28, 2014 9:33 AM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling API 2.8.0, take II
> 
> Hi,
> 
> We solved 3 issues
> https://issues.apache.org/jira/browse/SLING/fixforversion/12326549
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1104
> 
> 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 1104 /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.
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

RE: [VOTE] Release Apache Sling Default POST Servlets 2.3.6

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Robert Munteanu [mailto:romb...@apache.org]
> Sent: Monday, August 25, 2014 6:35 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Default POST Servlets 2.3.6
> 
> Hi,
> 
> We solved 1 issue in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12326357
> 
> There are still some outstanding issues:
> https://issues.apache.org/jira/browse/SLING/component/12313028
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1097/
> 
> 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 1097 /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.

RE: [VOTE] Release Apache Sling JSON Library 2.0.8

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Robert Munteanu [mailto:romb...@apache.org]
> Sent: Monday, August 25, 2014 5:30 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling JSON Library 2.0.8
> 
> Hi,
> 
> On the road for the Sling 7 release ...
> 
> We solved 3 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12315999
> 
> There is one outstanding issue:
> https://issues.apache.org/jira/browse/SLING-3368
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1093
> 
> 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 1093 /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.

RE: [VOTE] Sling Auth Modules

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Friday, August 08, 2014 2:26 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Sling Auth Modules
> 
> Hi,
> 
> in order to get Launchpad 7 out, this is a vote to release
> 
> Auth Core 1.1.8
> https://issues.apache.org/jira/browse/SLING/fixforversion/12326055
> 
> Auth Selector 1.0.6
> https://issues.apache.org/jira/browse/SLING/fixforversion/12316095
> 
> Form Based Autentication 1.0.6
> https://issues.apache.org/jira/browse/SLING/fixforversion/12324551
> 
> OpenID Authentication 1.0.4
> https://issues.apache.org/jira/browse/SLING/fixforversion/12315994
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1089
> 
> 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 1089 /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.
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

RE: [VOTE] Release Apache Sling Parent version 20

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Robert Munteanu [mailto:romb...@apache.org]
> Sent: Tuesday, July 29, 2014 10:54 AM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Parent version 20
> 
> Hi,
> 
> We solved 3 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12326694
> 
> There are still some outstanding issues:
> https://issues.apache.org/jira/browse/SLING/component/12312329
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1086
> 
> 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 1086 /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.

RE: Launchpad 7 Release?

[Mike Müller]

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Wednesday, July 23, 2014 9:22 AM
> To: dev@sling.apache.org
> Subject: Re: Launchpad 7 Release?
> 
> I've updated the bundle list - it was pretty current. For three bundles we
> still have open issues before we can release:
> 
> Commons JSON
> https://issues.apache.org/jira/browse/SLING/fixforversion/12315999
> 
> Explorer
> https://issues.apache.org/jira/browse/SLING/fixforversion/12316190
> 
> JCR Jackrabbit Server
> https://issues.apache.org/jira/browse/SLING/fixforversion/12324840

I would like to include a 1.0.0 release of resourceaccesssecurity in Sling 7.
I think it's pretty mature, documentation is up to date [1] and I recently
Added a bunch of various tests. 

WDYT?

Best regards
mike

RE: Launchpad 7 Release?

[Mike Müller]

> 
> On Tue, 2014-07-22 at 15:30 +0200, Carsten Ziegeler wrote:
> >
> > Looking at the snapshot list of the builder project, I guess we could
> > just
> > release all of them and we're got with Sling 7 and then maybe have a
> > look
> > at how to change things after Sling 7?
> 
> +1, I think it's important to have a Sling 7 release soon.
> 
> It's going to be fun though, we have a large number of releases to
> perform :-)
> 
> $ grep -c -e SNAPSHOT src/main/bundles/list.xml
> 20
> 
> Robert

+1 for a speedy Sling 7 release and discuss how to increase the frequency of 
future Launchpad releases after the Sling 7 release.

Best regards
mike

RE: [VOTE] Release Apache Sling Scripting JSP 2.1.2 and Apache Sling Scripting Java 2.0.8

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Wednesday, July 02, 2014 1:51 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Scripting JSP 2.1.2 and Apache Sling 
> Scripting
> Java 2.0.8
> 
> Hi,
> 
> We solved two issues for each scripting bundle, especially with SLING-3724 
> these
> bundles now provide a better experience with Java 8 as they run without 
> configuration
> changes on Java 8 as well as previous versions.
> 
> Scripting JSP
> https://issues.apache.org/jira/browse/SLING/fixforversion/12326855
> Scripting Java
> https://issues.apache.org/jira/browse/SLING/fixforversion/12321863
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1073
> 
> 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 1073 /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.
> 
> Regards
> 
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

RE: [featureflags] Readding sling:features to resourceResolver

[Mike Müller]

Hi

Just my 2 cents to it: 
Why not defining a "featureflag-interface" which is internally implemented
with ResourceAccessGates. Personally I think ResourceAccessGates could do
the job but I can follow the fear, that such a mechanism mixing up with a 
security mechanism could lead to bad design. So the solution could really
be to wrap the ResourceAccessGates for the functionality of featureflags.

Best regards
mike

> -Original Message-
> From: Dominik Süß [mailto:dominik.su...@gmail.com]
> Sent: Tuesday, June 10, 2014 2:53 PM
> To: dev
> Subject: [featureflags] Readding sling:features to resourceResolver
> 
> Hi everyone,
> 
> although I know this touches an area with a lot of emotions involved I
> wanted to reopen the discussion around Featureflags support for the
> resourceresolver.
> The last thing that happend was removing it for a release due to  potential
> confusion and subtle issues. See http://markmail.org/thread/jgpso52iqiivpa5t
> 
> Here are my arguments why I think it would be good to readd it to the
> resourceResolver (or any other mechanism being able to filter the resource
> tree:
> - Currently writing frontend that needs to adapt to featureflags requires
> adding custom code to check and filter the ui to be rendered. This leads to
> a lot of boilerplate code written over and over again with minor differences
> - Mechanisms relying on the Default Get Servlet JSON output would need to
> implement the filterlogic in clientside code.
> - ACL based solutions complicate the security setup for administrators
> because each feature would require a group (if toggling should be achived
> by membership instead of complex permissionrewriting) and could potentially
> impact performance of acl checks (not my domain so some specialists might
> be able to tell if those additional groups and memberships have impact on
> performance)
> 
> The argument that developers might mistake feature flags with security is
> indicating that they don't read documentation (where potential security
> warnings should be written down in a prominent location) or do not care.
> But who does not care will not take care of proper ACLs anyways and
> assuming developers are using features without reading or respecting
> warnings in the documentation sounds a bit paranoid.
> 
> I still think Resource Access Gate might be viable but some people
> convinced me that solving such a mechanism with a security mechanism would
> probably make distinction between security and business based access
> constraints (such as featureflags that constraint the access to a feature).
> 
> Let's discuss this a bit so that everyone gets a clearer picture what
> issues where faced and why it was a better idea to remove this featureflag
> support and what would be the conditions under which no one would have an
> issue with readding a revamped featueflag support for the resource tree.
> 
> Best regards
> Dominik

RE: [VOTE] Release Apache Sling Service User Mapper 1.0.2

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Monday, May 26, 2014 4:38 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Service User Mapper 1.0.2
> 
> Hi,
> 
> We solved 1 issue in this release:
> https://issues.apache.org/jira/browse/SLING-3578
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1067
> 
> 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 1067 /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.
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release Apache Sling Servlet Archetype 1.0.2

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Robert Munteanu [mailto:romb...@apache.org]
> Sent: Thursday, May 15, 2014 11:03 AM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Servlet Archetype 1.0.2
> 
> Hi,
> 
> We solved 9 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12315454
> 
> There are still some outstanding issues:
> https://issues.apache.org/jira/browse/SLING/component/12311945
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1064/
> 
> 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 1064 /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.

RE: [VOTE] Release Apache Sling Scripting JSP 2.1.0 and Apache Sling Commons Compiler 2.2.0

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Thursday, May 15, 2014 2:20 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Scripting JSP 2.1.0 and Apache Sling 
> Commons Compiler 2.2.0
> 
> Hi,
> 
> this vote is about adding Java 8 support to our compilers/script engines:
> 
> Apache Sling Commons Compiler 2.2.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12323578
> 
> Apache Sling Scripting JSP 2.1.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12324445
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1066
> 
> 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 1066 /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.
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release Apache Sling Bundle Archetype 1.0.2

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Robert Munteanu [mailto:romb...@apache.org]
> Sent: Thursday, May 15, 2014 10:55 AM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Bundle Archetype 1.0.2
> 
> Hi,
> 
> We solved 5 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12326805
> 
> There are still some outstanding issues:
> https://issues.apache.org/jira/browse/SLING/component/12311945
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1062/
> 
> 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 1062 /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.

RE: [VOTE] Release Apache Sling Classloader Leak Detector 1.0.0

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Chetan Mehrotra [mailto:chetan.mehro...@gmail.com]
> Sent: Thursday, May 15, 2014 11:38 AM
> To: dev
> Subject: [VOTE] Release Apache Sling Classloader Leak Detector 1.0.0
> 
> Hi,
> 
> This is to vote for the Apache Sling Classloader Leak Detector 1.0.0
> release. This is the first release of this module
> 
> The docs are up to date at
> https://github.com/apache/sling/tree/trunk/contrib/extensions/leak-detector
> 
> Issues fixed
> https://issues.apache.org/jira/browse/SLING/fixforversion/12326854
> 
> Release Notes
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12326854&projectId=12310710
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1059
> 
> 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 1059 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> regards
> Chetan

RE: [VOTE] Release Apache Sling Resource Resolver 1.1.0

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Monday, March 31, 2014 2:25 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Resource Resolver 1.1.0
> 
> Hi,
> 
> We solved 17 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12324109
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1046
> 
> 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 1046 /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.
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release Apache Sling Parent POM 19

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Thursday, March 27, 2014 1:04 PM
> To: dev@sling.apache.org
> Subject: Re: [VOTE] Release Apache Sling Parent POM 19
> 
> Anyone else?
> 
> 
> 2014-03-24 14:33 GMT+01:00 Carsten Ziegeler :
> 
> > +1
> >
> >
> > 2014-03-24 14:32 GMT+01:00 Carsten Ziegeler :
> >
> > Hi,
> >>
> >> this vote is about the release of
> >>
> >> Apache Sling Parent POM 19
> >>
> >> Change List:
> >> https://issues.apache.org/jira/browse/SLING/fixforversion/12324982
> >>
> >> Staging repository:
> >> https://repository.apache.org/content/repositories/orgapachesling-1043
> >>
> >> 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 1043 /tmp/sling-staging
> >>
> >> Please vote to approve this release:
> >>
> >>  [ ] +1 Approve the release
> >>  [ ]  0 Don't care
> >>  [ ] -1 Don't release, because ...
> >>
> >> This vote will be open for 72 hours.
> >>
> >> Regards
> >> Carsten
> >>
> >>
> >> --
> >> Carsten Ziegeler
> >> cziege...@apache.org
> >>
> >
> >
> >
> > --
> > Carsten Ziegeler
> > cziege...@apache.org
> >
> 
> 
> 
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release Apache Sling Servlets Get 2.1.8

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Thursday, March 27, 2014 1:04 PM
> To: dev@sling.apache.org
> Subject: Re: [VOTE] Release Apache Sling Servlets Get 2.1.8
> 
> Anyone else?
> 
> 
> 2014-03-24 20:26 GMT+01:00 Oliver Lietz :
> 
> > On Monday 24 March 2014 11:55:59 Carsten Ziegeler wrote:
> > > Hi,
> > >
> > > this vote is about the release of
> > >
> > > Apache Sling Servlets Get 2.1.8
> >
> > +1
> >
> > O.
> >
> 
> 
> 
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release Apache Sling Servlets Resolver 2.3.2

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Thursday, March 27, 2014 1:03 PM
> To: dev@sling.apache.org
> Subject: Re: [VOTE] Release Apache Sling Servlets Resolver 2.3.2
> 
> Anyone else?
> 
> 
> 2014-03-24 20:26 GMT+01:00 Oliver Lietz :
> 
> > On Monday 24 March 2014 11:54:39 Carsten Ziegeler wrote:
> > > Hi,
> > >
> > > this vote is about the release of
> > >
> > > Apache Sling Servlets Resolver 2.3.2
> >
> > +1
> >
> > O.
> >
> 
> 
> 
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release Apache Sling Installer Factory Configuration 1.0.12

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Thursday, March 27, 2014 1:03 PM
> To: dev@sling.apache.org
> Subject: Re: [VOTE] Release Apache Sling Installer Factory Configuration 
> 1.0.12
> 
> Anyone else?
> 
> 
> 2014-03-24 10:56 GMT+01:00 Chetan Mehrotra :
> 
> > +1 (non binding)
> > Chetan Mehrotra
> >
> >
> > On Mon, Mar 24, 2014 at 2:52 PM, Oliver Lietz 
> > wrote:
> > > On Sunday 23 March 2014 12:00:09 Carsten Ziegeler wrote:
> > >> Hi,
> > >>
> > >> this vote is about the release of
> > >>
> > >> Apache Sling Installer Factory Configuration 1.0.12
> > >
> > > +1
> > >
> > > O.
> >
> 
> 
> 
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [RT] Make ResourceAccessSecurity always restrict access if installed and no ResourceAccessGate present

[Mike Müller]

...snipsnap
> 
> Ok, I see your point and yes, partially this is related to the name
> "DONTCARE". I'm fine with renaming it to CANTDECIDE and then implementing
> it the way you suggest :)
> 
> Regards
> Carsten

Okay, created SLING-3462.

Best regards
mike

RE: [RT] Make ResourceAccessSecurity always restrict access if installed and no ResourceAccessGate present

[Mike Müller]

> From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
> Subject: Re: [RT] Make ResourceAccessSecurity always restrict access if 
> installed and no ResourceAccessGate present
> 
> Hi,
> 
> On Tue, Mar 18, 2014 at 8:48 AM, Mike Müller  wrote:
> >... Maybe it would make sense to rename the DONTCARE to CANTDECIDE which 
> >would
> > explain the mechanism better
> 
> I'm only half-following those discussions - do we have a single place
> which explains how the RAG works?
> 
> As this stuff has security implications it would be nice to make sure
> we can get and review the complete picture somewhere.
> 
> Unless there's something already I'd suggest a new page under
> http://sling.apache.org/documentation/bundles.html which acts as the
> documentation for this feature once it's ready. For now that can be
> marked DRAFT while things are still in flux - or maybe start a draft
> at https://cwiki.apache.org/confluence/display/SLING

Good point.
+1
I will do a first draft, created SLING-3461.

Best regards
mike

RE: [RT] Make ResourceAccessSecurity always restrict access if installed and no ResourceAccessGate present

[Mike Müller]

> 2014-03-17 8:38 GMT-07:00 Mike Müller :
> 
> > Hi
> >
> > I think this is insecure by design and not correct:
> > The problem is not, that we do grant access if no ResourceAccessGate is
> > registered for application context. The problem is, that we grant access
> > also if there is a ResourceAccessGate registered for application level but
> > does return GateResult.DONTCARE. In this case no access should be granted
> > as we do on provider context.
> > To see that actual wrong implementation in action have a look at the
> > integration
> > Test in
> > SecuredProviderResourceAccessSecurityTest#testUpdateDeniedUpdateAllowedRead:
> > Here only READ is granted but not UPDATE. But because there are also
> > registered
> > ResourceAccessGates for application levels the access would be granted for
> > update anyway if no application ResourceAccessGate denies updates (per
> > default
> > they only return GateResult.DONTCARE).
> > There's no disadvantage if we do not grant access if no ResourceAccessGate
> > returns GateResult.GRANT. Because in the case if no ResourceAccessGate is
> > defined we do not have a registered ResourceAccessSecurity service for
> > the application level.
> > So IMHO we definitively have to change this behavour to act similar as in
> > the
> > provider context.
> >
> >
> ah, thanks, got it now. I think either way is a little bit strange. I guess
> we all agree that if there is no application RAG, the resource is
> accessible (leaving out the provider RAG for now).
> Then you add an application RAG which say "DONTCARE" and out of the sudden,
> the resource is not visible anymore. This seems a little bit contradicting
> the term "DONTCARE". I think DONTCARE means you get the same result as if
> this check wasn't done and in the case of the application RAG that's acess
> is granted.
> 
> Regards
> Carsten


I think in this case the concept of DONTCARE is not clear. DONTCARE doesn't mean
GRANT, it rather means "I can't decide". So if a RAG returns DONTCARE that means
NOT if nobody else handles the resource we can grant access. Maybe it's easier 
to
understand why this third answer (beside GRANT and DENY) should be possible at
all, here's a use case:
Think of a LockdownGate which locks down the whole site and only allows access 
to 
logged in users. To do that we implement a RAG with a canReadMethod like this

public GateResult canRead(Resource resource) {
if (resource.getResourceResolver().getUserID() != null  && ! 
resource.getResourceResolver().getUserID().equals("anonymous") )
{
return GateResult.DONTCARE;
}
else
{
return GateResult.DENIED;
}
}

and register the RAG with the property finaloperations=read.
This ensures that not logged in users do not have read access. But it also 
ensures
that logged in users do not have more access than before the registration of the
LockdownGate because with the returning DONTCARE the gate delegates giving
access here to the other existing gates. If no other gate grants access the 
logged
in user will not have additional access because of the LockdownGate, which is
what we really want. To allow access would be wrong.

We do exactly that with provider context RAGs so it would be wrong to do 
something
else in the application context. The only difference between these two is, that 
without
any RAG registered for the provider context access will be denied (because the 
resource
provider asked for with the setted flag). In application context access will be 
granted without
any RAG registered for application context (because in this case maybe you do 
not want
to use ResourceAccessSecurity). But as soon as a RAG is registered we do that 
because we
want to control the access and the registered RAGs have to grant access 
explicitly.

Maybe it would make sense to rename the DONTCARE to CANTDECIDE which would 
explain the mechanism better.

Best regards
mike

RE: [RT] Make ResourceAccessSecurity always restrict access if installed and no ResourceAccessGate present

[Mike Müller]

Hi

I think this is insecure by design and not correct:
The problem is not, that we do grant access if no ResourceAccessGate is
registered for application context. The problem is, that we grant access
also if there is a ResourceAccessGate registered for application level but
does return GateResult.DONTCARE. In this case no access should be granted
as we do on provider context.
To see that actual wrong implementation in action have a look at the integration
Test in 
SecuredProviderResourceAccessSecurityTest#testUpdateDeniedUpdateAllowedRead:
Here only READ is granted but not UPDATE. But because there are also registered
ResourceAccessGates for application levels the access would be granted for
update anyway if no application ResourceAccessGate denies updates (per default
they only return GateResult.DONTCARE).
There's no disadvantage if we do not grant access if no ResourceAccessGate
returns GateResult.GRANT. Because in the case if no ResourceAccessGate is
defined we do not have a registered ResourceAccessSecurity service for
the application level.
So IMHO we definitively have to change this behavour to act similar as in the
provider context.

Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Monday, March 17, 2014 3:35 PM
> To: dev@sling.apache.org
> Subject: Re: [RT] Make ResourceAccessSecurity always restrict access if
> installed and no ResourceAccessGate present
> 
> Yes, I think my first answer was wrong (Note to myself, don't answer mails
> after long distance travels...) and you're right. The difference between
> provider and application type is exactly that.
> If there is no provider RAS and the provider does not declare to require one,
> the resource is visible. Same with application type, but also if application 
> RAS
> is there but doesn't restrcit it.
> 
> Carsten
> 
> 
> 2014-03-17 3:09 GMT-07:00 Marius Petria :
> 
> > > > Furthermore the implementation of the ResourceAccessSecurity for
> > > > the provider context does not behave like the one for the
> > > > application
> > > > context: If we for example check the read access for a resource
> > > > the implementation calls all ResourceAccessGates till a gate is
> > > > found which grants read access. That's correct but only done in
> > > > the provider context.
> > > > In the application context the implementation also calls all
> > > > ResourceAccessGates till a gate is found which grants read access.
> > > > But if no gate is found which grants read access and there's also
> > > > no gate which denies access (returns GateResult.DONTCARE), access
> > > > will be granted. This seems wrong in terms of security. The two
> > > > implementations for provider context and application context
> > > > should behave the same. With the only difference that
> > > > ResourceResolver will ignore the application context if the service 
> > > > could
> not be found.
> >
> > I thought the difference in defaults between application scoped access
> > security and provider scoped is intended.
> > Provider scoped access security is requested by the resource provider
> > itself using USE_RESOURCE_ACCESS_SECURITY, so it makes sense to deny
> > access if no gate is present because the provider really cares about
> security.
> >
> > However, the application scoped access security is requested by the
> > one that installs a gate, so it should only restrict access if the
> > gate is present, as the provider does not really care about security.
> >
> > Or, am I understanding it wrong?
> >
> > Marius
> >
> >
> 
> 
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [RT] Make ResourceAccessSecurity always restrict access if installed and no ResourceAccessGate present

[Mike Müller]

> the current implementation does actually this (if I read the code
> correctly) :)

Yes you're right, the implementation for this case is correct. Sorry for the
confusion...

> If useRAS is set, but no Gate available, the resource is not returned. At 
> least
> ProviderHandler#getReadableResource does this.
> But of course if this is not the case, then you're totally right and we need 
> to
> change this.
> 
> And I totally agree that provider and application context should behave
> similar.
> 
> Regards
> Carsten
> 
> 
> 2014-03-16 12:54 GMT-07:00 Mike Müller :
> 
> > Hi
> >
> > As I worked on SLING-3435 [1] and added some more tests I noticed that
> > Even if resourceaccesssecurity is installed as a bundle the two
> > implementing classes ApplicationResourceAccessSecurityImpl (for
> > application context) and ProviderResourceAccessSecurityImpl (for
> > provider context) are only registered if there is at least one
> > ResourceAccessGate registered for the appropriate context.
> > The implementation of ResourceResolver itself only checks if there is
> > an implementation for ResourceAccessSecurity registered. If no such
> > service is available, ResourceResolver grants access for all
> > operations. That means, even if a ResourceProvider implementation sets
> > the useResourceAccessSecurity flag to true, access will be granted if
> > no ResourceAccessGate is registered for the provider context.
> >
> > I think this should be changed, because it makes
> > resourceaccesssecurity somewhat weak.
> > Imagine we do have a Mongo ResourceProvider with the
> > useResourceAccessSecurity flag set to true and we even have installed
> > the resourceaccesssecurity bundle.
> > Now
> > we either forgot to install also a ResourceAccessGate implementation
> > or the bundle containing the gate is not started properly. With the
> > actual behavour access will be granted on all resources from Mongo
> > ResourceProvider for all operations.
> > Even if the bundle with our ResourceAccessGate implementation is
> > started correctly But not the resourceaccesssecurity bundle we do have
> > the same problem.
> > It think this is wrong in terms of security.
> >
> > I suggest we should do the following:
> > - If a provider sets useResourceAccessSecurity flag to true we do not
> > grant access to any Resource from this provider (for any operation) if
> > ResourceAccessSecurity for the provider context can't be found.
> >
> > Furthermore the implementation of the ResourceAccessSecurity for the
> > provider context does not behave like the one for the application
> > context: If we for example check the read access for a resource the
> > implementation calls all ResourceAccessGates till a gate is found
> > which grants read access. That's correct but only done in the provider
> > context.
> > In the application context the implementation also calls all
> > ResourceAccessGates till a gate is found which grants read access. But
> > if no gate is found which grants read access and there's also no gate
> > which denies access (returns GateResult.DONTCARE), access will be
> > granted. This seems wrong in terms of security. The two
> > implementations for provider context and application context should
> > behave the same. With the only difference that ResourceResolver will
> > ignore the application context if the service could not be found.
> >
> > WDYT?
> >
> > Best regards
> > mike
> >
> > [1] https://issues.apache.org/jira/browse/SLING-3435
> >
> 
> 
> 
> --
> Carsten Ziegeler
> cziege...@apache.org

[RT] Make ResourceAccessSecurity always restrict access if installed and no ResourceAccessGate present

[Mike Müller]

Hi

As I worked on SLING-3435 [1] and added some more tests I noticed that
Even if resourceaccesssecurity is installed as a bundle the two implementing 
classes ApplicationResourceAccessSecurityImpl (for application context) and 
ProviderResourceAccessSecurityImpl (for provider context) are only registered
if there is at least one ResourceAccessGate registered for the appropriate 
context.
The implementation of ResourceResolver itself only checks if there is an 
implementation
for ResourceAccessSecurity registered. If no such service is available, 
ResourceResolver
grants access for all operations. That means, even if a ResourceProvider 
implementation 
sets the useResourceAccessSecurity flag to true, access will be granted if no 
ResourceAccessGate is registered for the provider context.

I think this should be changed, because it makes resourceaccesssecurity 
somewhat weak.
Imagine we do have a Mongo ResourceProvider with the useResourceAccessSecurity 
flag 
set to true and we even have installed the resourceaccesssecurity bundle. Now 
we either forgot to install also a ResourceAccessGate implementation or the 
bundle 
containing the gate is not started properly. With the actual behavour access 
will be 
granted on all resources from Mongo ResourceProvider for all operations.
Even if the bundle with our ResourceAccessGate implementation is started 
correctly
But not the resourceaccesssecurity bundle we do have the same problem.
It think this is wrong in terms of security.

I suggest we should do the following:
- If a provider sets useResourceAccessSecurity flag to true we do not grant 
access to any
Resource from this provider (for any operation) if ResourceAccessSecurity for 
the provider 
context can't be found.

Furthermore the implementation of the ResourceAccessSecurity for the provider 
context
does not behave like the one for the application context: If we for example 
check the
read access for a resource the implementation calls all ResourceAccessGates 
till a gate
is found which grants read access. That's correct but only done in the provider 
context.
In the application context the implementation also calls all 
ResourceAccessGates till a
gate is found which grants read access. But if no gate is found which grants 
read access
and there's also no gate which denies access (returns GateResult.DONTCARE), 
access
will be granted. This seems wrong in terms of security. The two implementations 
for
provider context and application context should behave the same. With the only 
difference
that ResourceResolver will ignore the application context if the service could 
not be 
found.

WDYT?

Best regards
mike

[1] https://issues.apache.org/jira/browse/SLING-3435

RE: [VOTE] Release Apache Sling Engine 2.3.2

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Tuesday, March 11, 2014 2:39 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Engine 2.3.2
> 
> Hi,
> 
> this vote is about the release of
> 
> Apache Sling Engine 2.3.2
> which contains an important bug fix:
> https://issues.apache.org/jira/browse/SLING-3439
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1034
> 
> 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 1034 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Carsten
> 
> 
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release Apache Sling Servlets Resolver 2.3.0

[Mike Müller]

+1
Checked sigantures

Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Tuesday, February 18, 2014 1:40 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Servlets Resolver 2.3.0
> 
> Hi,
> 
> this vote is about the release of
> 
> Apache Sling Servlets Resolver 2.3.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12324330
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1012
> 
> 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 1012 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Carsten
> 
> 
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release Apache Sling Resource Merger 1.0.0

[Mike Müller]

+1
Checked sigantures

Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Tuesday, February 18, 2014 11:37 AM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Resource Merger 1.0.0
> 
> Hi,
> 
> this vote is about the first release of the Resource Merger
> https://issues.apache.org/jira/browse/SLING/fixforversion/12326149
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1011
> 
> 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 1011 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Carsten
> 
> 
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Apache Sling Event 3.3.4

[Mike Müller]

+1
best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Tuesday, January 21, 2014 8:45 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Apache Sling Event 3.3.4
> 
> Hi,
> 
> I just discovery a regression bug in the eventing (SLING-3329). Therefore I
> would like to call for a vote with a fix:
> 
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1003/
> 
> 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 1003 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Carsten
> 
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Apache Sling API 2.5.0

[Mike Müller]

+1
best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Tuesday, January 21, 2014 2:57 AM
> To: dev@sling.apache.org
> Subject: [VOTE] Apache Sling API 2.5.0
> 
> Hi,
> 
> its finally time for a new API release, we didn't have one for a long time:
> 
>  https://issues.apache.org/jira/browse/SLING/fixforversion/12324378
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1002/
> 
> 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 1002 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release Apache Sling Event 3.3.2

[Mike Müller]

+1
best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Wednesday, January 15, 2014 5:15 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Event 3.3.2
> 
> Hi,
> 
> its time for a new Sling event release.
> 
> 
>  https://issues.apache.org/jira/browse/SLING/fixforversion/12325303
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1001/
> 
> 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 1001 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release Apache Sling Installer Core 3.5.0

[Mike Müller]

+1
best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Wednesday, January 15, 2014 4:56 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Installer Core 3.5.0
> 
> Hi,
> 
> its time for a new installer core release.
> 
> 
>  https://issues.apache.org/jira/browse/SLING/fixforversion/12324047
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1000/
> 
> 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 1000 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: Reconsidering when to apply resource access security

[Mike Müller]

Hi Bertrand

We do not have a complete implementation of the ResourceAccessSecurity 
at the moment. I stopped committing more code there because of the
ongoing discussions about this service in general.
The implementation by now can handle read operations on resource level
only.
But I strongly support your demand to have a good test suite for the
Functionality of this service (and I would like to have some support for
the integration tests as mentioned earlier, when it comes to the test
suite)

best regards
mike

> -Original Message-
> From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
> Sent: Wednesday, January 15, 2014 10:12 AM
> To: dev
> Subject: Re: Reconsidering when to apply resource access security
> 
> Hi Mike,
> 
> On Wed, Jan 15, 2014 at 10:02 AM, Mike Müller  wrote:
> > ...I think if
> > someone like to use ResourceAccessGate it should be as easy and logical
> > as possible. And that really would be without any flag to configure it. Just
> > write an ResourceAccessGate and it works...
> 
> Do we have tests that demonstrate that "it works" ?
> 
> I haven't checked, but if we accept it as a security feature we need a
> strong test suite that demonstrates it.
> 
> -Bertrand

RE: Reconsidering when to apply resource access security

[Mike Müller]

Although this seems to be another compromise, it has advantages to
the actual flag which must be set on every provider. Sorry to say it
again, but no configuration would be easier and logical. The writer
of the ResourceAccessGate can decide anyway on which Resource he 
will apply rules or not. That's one reason why the return value of the 
methods on ResourceAccessGate is GateResult which has three states:
GRANTED, DENIED, DONTCARE. The last means that the ResourceAccessGate
does not handle this resource.

So a +0.5 from my side. Which means it is better than the status quo.

The implementation of ResourceAccessSecurity respects already the
service ranking of the ResourceAccessGate implementations as suggested.


Best regards
mike


> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Wednesday, January 15, 2014 12:43 PM
> To: dev@sling.apache.org
> Subject: Re: Reconsidering when to apply resource access security
> 
> So to redefine my proposal, we define a service registration property
> "CONTEXT" for a ResourceAccessSecurity - if not set it defaults "provider",
> allowed values are "application" and "provider" - if an invalid value is
> used, the service is ignore (and this is logged as error).
> 
> All ResourceAccessSecurity services marked with context "provider" are
> chained with lowest service ranking first and invoked for all resurce
> providers which indicate they don't have own security checks.
> All ResourceAccessSecurity services marked with context "application" are
> chained with lowest service ranking first and are always invoked.
> 
> While I don't expect to have more than a single resource access security
> service for each context, chaining them makes imho sense and gives a well
> defined execution order.
> 
> WDYT?
> 
> Carsten
> 
> 
> 2014/1/15 Carsten Ziegeler 
> 
> > 2014/1/14 Felix Meschberger 
> >
> >> Hi
> >>
> >> Am 14.01.2014 um 00:27 schrieb Carsten Ziegeler :
> >>
> >> > Ok, so let's seprate the two things for the sake of th discussion - as
> >> soon
> >> > as someone wants to have a resource access gate applied to all resource
> >> > providers (for whatever reason), this really becomes tedious,
> >> especially as
> >> > you have to know and configure each and every resource provider and set
> >> the
> >> > flag accordingly.
> >>
> >> No that's not the right background for the configuration flag: The
> >> background was, that a ResourceResolver indicated with this flag, whether
> >> it does its own access control (as JCR Resource Provider does) or does not
> >> and thus would benefit from general service.
> >>
> >> Yes, right - and the flag defaults to "provider does own access control".
> >
> >
> >
> >>  > In the last 6 months we encountered at least two use cases where it
> >> would
> >> > make sense to enable the gate in front of the jcr provider as there is
> >> no
> >> > way to cover the use cases with ACLs (I would need to dig up the
> >> details)
> >> > And as has been discussed at length, the gate is an additional check, so
> >> > you can't make stuff visible which is not visible from the provider.
> >>
> >> The access gate is a general access controller. Visibility is another yet
> >> overlapping problem: One part of visibility is the access right to read (or
> >> list) something. Another part is an application decision to hide something
> >> even though access control would grant access.
> >>
> >> So, we have two cases where this surfaces: Which one (apart from the
> >> feature flags ?) ? Maybe we should come up with an additional model ?
> >>
> >
> > Ok, I see your point - you're saying we need one mechanism to apply access
> > control to resource provider which do not have their own access control -
> > this is kind of a "low level" mechanism.
> > And we have the application level which adds additional checks across the
> > whole resource tree, like hiding resources etc.
> >
> > If we're talking about the interface, I would assume that they both like
> > pretty similar - controlling visibility on the app level might be one use
> > case, but preventing write access might be another one etc.
> > Right now we use the ResourceAccessSecurity for the first case.
> >
> > What about defining a registration property for this service, something
> > like "context"? By default this is "provider" and the service is applied to
> > the providers indicating they need additional access control. And if its
> > set to "application", the checks are applied on top at a higher level?
> >
> > Regards
> > Carsten
> >
> 
> 
> 
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: Reconsidering when to apply resource access security

[Mike Müller]

Hi

In the hope not to raise dust again...
ResourceAccessGate could really help to harden existing Sling applications
even if they use JCR only as backend. As mentioned many times before
ResourceAccessGate does not interfere or cancel other ACLs like these from
JCR and it is not a substitution of the access controlling in JCR or any other
persistence layer with ACLs. But it could help to define things which you can't
define in the exiting ACLs. Just two examples:
- access only from 8am to 5pm on weekdays
- lockdown: Only give access to a preview site to authenticated users (no 
  matter what user). But the site is a public site
- hardening a system

For the last point: As we have seen the last months (an Carsten mentioned
it also), there are some cases where ResourceAccessGate could help to
harden an otherwise vulnerable Sling system where ACLs on JCR just do not 
work.  

But I think also in case of access control, it is worse that one has to enable
the flag that access control should take place on every resource provider.
Normally to get high security we have to turn of controlling and not on.

And last but not least: No one has to use ResourceAccessGate. But I think if 
someone like to use ResourceAccessGate it should be as easy and logical
as possible. And that really would be without any flag to configure it. Just
write an ResourceAccessGate and it works.

Best regard
Mike

> -Original Message-
> From: Felix Meschberger [mailto:fmesc...@adobe.com]
> Sent: Tuesday, January 14, 2014 6:58 PM
> To: dev@sling.apache.org
> Subject: Re: Reconsidering when to apply resource access security
> 
> Hi
> 
> Am 14.01.2014 um 00:27 schrieb Carsten Ziegeler :
> 
> > Ok, so let's seprate the two things for the sake of th discussion - as soon
> > as someone wants to have a resource access gate applied to all resource
> > providers (for whatever reason), this really becomes tedious, especially as
> > you have to know and configure each and every resource provider and set the
> > flag accordingly.
> 
> No that's not the right background for the configuration flag: The background 
> was,
> that a ResourceResolver indicated with this flag, whether it does its own 
> access
> control (as JCR Resource Provider does) or does not and thus would benefit 
> from
> general service.
> 
> > In the last 6 months we encountered at least two use cases where it would
> > make sense to enable the gate in front of the jcr provider as there is no
> > way to cover the use cases with ACLs (I would need to dig up the details)
> > And as has been discussed at length, the gate is an additional check, so
> > you can't make stuff visible which is not visible from the provider.
> 
> The access gate is a general access controller. Visibility is another yet 
> overlapping
> problem: One part of visibility is the access right to read (or list) 
> something.
> Another part is an application decision to hide something even though access
> control would grant access.
> 
> So, we have two cases where this surfaces: Which one (apart from the feature
> flags ?) ? Maybe we should come up with an additional model ?
> 
> >
> > Whether we should use the gate for the feature flag implementation is a
> > different thing then and can be discussed in another thread :)
> 
> Sure thing.
> 
> Regards
> Felix
> 
> >
> > Regards
> > Carsten
> >
> >
> > 2014/1/13 Felix Meschberger 
> >
> >> -.5
> >>
> >> Not exactly vetoing but: This creates and overlap in resource providers
> >> which effectively do access control (such as JCR Resource Provider) and as
> >> I said before: the feature flag is not a good candidate for the security
> >> system.
> >>
> >> After all the feature flag does visibility but no access control as in
> >> "can-write", "can-delete", "can-create", etc.
> >>
> >> Regards
> >> Felix
> >>
> >>
> >> Am 13.01.2014 um 06:24 schrieb Carsten Ziegeler :
> >>
> >>> Hi,
> >>>
> >>> after long discussions we have to the compromise to tag a resource
> >> provider
> >>> if a (optionally) available resource access security is used for this
> >>> provider.
> >>>
> >>> I think this was a wrong compromise with no real value - and we should
> >>> remove this additional flag and simply always apply the checks.
> >>> One main driver is the new feature flags implementation which requires
> >> the
> >>> additional checks for all providers to properly work - and it would be a
> >>> maintenance nightmare to enable the flag on all providers (default is
> >> off).
> >>>
> >>> So, if no one complains with a good reason I'll do the change
> >>>
> >>> Thanks
> >>> Carsten
> >>> --
> >>> Carsten Ziegeler
> >>> cziege...@apache.org
> >>
> >>
> >
> >
> > --
> > Carsten Ziegeler
> > cziege...@apache.org

RE: Reconsidering when to apply resource access security

[Mike Müller]

+1
That would be more consistent.
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Monday, January 13, 2014 2:24 PM
> To: dev@sling.apache.org
> Subject: Reconsidering when to apply resource access security
> 
> Hi,
> 
> after long discussions we have to the compromise to tag a resource provider
> if a (optionally) available resource access security is used for this
> provider.
> 
> I think this was a wrong compromise with no real value - and we should
> remove this additional flag and simply always apply the checks.
> One main driver is the new feature flags implementation which requires the
> additional checks for all providers to properly work - and it would be a
> maintenance nightmare to enable the flag on all providers (default is off).
> 
> So, if no one complains with a good reason I'll do the change
> 
> Thanks
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release Apache Sling Web Console Security Provider 1.1.2

[Mike Müller]

Here's my +1 

Best regards
mike

> -Original Message-
> From: Felix Meschberger [mailto:fmesc...@adobe.com]
> Sent: Monday, December 16, 2013 10:48 AM
> To: dev@sling.apache.org
> Subject: Re: [VOTE] Release Apache Sling Web Console Security Provider 1.1.2
> 
> Hi Carsten
> 
> Am 16.12.2013 um 10:34 schrieb Carsten Ziegeler :
> 
> > uh...sorry, I forgot to resolve them - both are done
> 
> Excellent. Thanks.
> 
> So here is my +1
> 
> Regards
> Felix
> 
> >
> > Thanks
> > Carsten
> >
> >
> > 2013/12/16 Felix Meschberger 
> >
> >> Hi Carsten
> >>
> >> Sorry for the delay.
> >>
> >> I just looked at the issues for this version and I am a bit confused as to
> >> SLING-3273 and SLING-3271: Both are tagged for this release, have commits
> >> but are unresolved. Is this an omission are they really incomplete ?
> >>
> >> Thanks
> >> Felix
> >>
> >> Am 15.12.2013 um 22:46 schrieb Carsten Ziegeler :
> >>
> >>> Anyone?
> >>>
> >>>
> >>> 2013/12/12 Carsten Ziegeler 
> >>>
>  +1
> 
> 
>  2013/12/12 Carsten Ziegeler 
> 
> > Hi,
> >
> > its time for a new release of the security provider
> >
> > Sling Web Console Security Provider 1.1.2
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12325305
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-046/
> >
> > 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 046 /tmp/sling-staging
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ]  0 Don't care
> > [ ] -1 Don't release, because ...
> >
> > This vote will be open for 72 hours.
> >
> > Regards
> > Carsten
> >
> > --
> > Carsten Ziegeler
> > cziege...@apache.org
> >
> 
> 
> 
>  --
>  Carsten Ziegeler
>  cziege...@apache.org
> 
> >>>
> >>>
> >>>
> >>> --
> >>> Carsten Ziegeler
> >>> cziege...@apache.org
> >>
> >>
> >
> >
> > --
> > Carsten Ziegeler
> > cziege...@apache.org

RE: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)

[Mike Müller]

Hi 

I'm not sure if it is a good idea that a ResourceDecorator could
return null. IMHO it's not what someone would expect from a 
Decorator. All the more that "decorator" is the name of a well known
pattern, which would never be a null object (only a null object could
be decorated but not vice versa).

best regards
mike

> -Original Message-
> From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
> Sent: Friday, December 06, 2013 11:49 AM
> To: dev
> Subject: Re: [OT] Feature flag influence on Resource access (Was: FYI: feature
> flags prototype)
> 
> Hi,
> 
> On Fri, Nov 15, 2013 at 8:40 AM, Felix Meschberger 
> wrote:
> > So, finally, I agree that baking the feature flag support directly into the
> ResourceResolver
> > implementation is suboptimal, it is probably still the most comprehensive 
> > and
> complete
> > solution to the requirements...
> 
> I had another look at this, and the existing ResourceDecorator already
> plays a similar role as an extension point to "do something" to each
> Resource while it's being resolved. That's already baked in the
> resource resolver, so we can leverage it without requiring much code
> changes.
> 
> ResourceDecorator.decorate(Resource r) returning null is currently
> only vaguely specified and certainly not used, as that causes NPEs in
> places - I think we just need to clarify that decorate returning null
> causes a Resource to be ignored, fix the code so that it's true and
> we're good.
> 
> I have created SLING-3267 to track that, I'll create a patch for review there.
> 
> -Bertrand

RE: [VOTE] Release Apache Sling discovery.impl 1.0.2

[Mike Müller]

+1
best regards
mike

> -Original Message-
> From: Stefan Egli [mailto:e...@adobe.com]
> Sent: Wednesday, November 27, 2013 3:03 PM
> To: dev@sling.apache.org
> Subject: Re: [VOTE] Release Apache Sling discovery.impl 1.0.2
> 
> Hi Ian,
> 
> It should be there now.
> 
> (It was 'in the pipeline somewhere'..)
> 
> Cheers,
> Stefan
> 
> On 11/27/13 2:47 PM, "Ian Boston"  wrote:
> 
> >Hi
> >Could you add your signing key to the KEYS file please.
> >Thanks
> >Ian
> >
> >On 27 November 2013 11:59, Amit.. Gupta.  wrote:
> >> +1
> >>
> >> -Amit
> >>
> >> -Original Message-
> >> From: Stefan Egli [mailto:e...@adobe.com]
> >> Sent: 27 November 2013 16:53
> >> To: dev@sling.apache.org
> >> Subject: [VOTE] Release Apache Sling discovery.impl 1.0.2
> >>
> >> Hi,
> >>
> >> We solved 4 issues in this release:
> >> https://issues.apache.org/jira/browse/SLING/fixforversion/12324866
> >>
> >> Staging repository:
> >> https://repository.apache.org/content/repositories/orgapachesling-013/
> >>
> >> 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 013 /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.
> >>
> >> Cheers,
> >>
> >> Stefan

RE: [VOTE] Release Apache Sling org.apache.sling.commons.testing 2.0.16

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
> Sent: Tuesday, November 19, 2013 5:28 PM
> To: dev
> Subject: [VOTE] Release Apache Sling org.apache.sling.commons.testing 2.0.16
> 
> Hi,
> 
> We solved 5 issues in this release:
> 
> https://issues.apache.org/jira/browse/SLING/fixforversion/12324059
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-151/
> 
> 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 151 /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.
> 
> -Bertrand

RE: FYI: feature flags prototype

[Mike Müller]

> On Thu, Nov 14, 2013 at 2:35 PM, Felix Meschberger
> wrote:
> 
> > Hi
> >
> > Sure you can do it, but it (a) doesn’t match the idea of an access gate
> > (at least not in my little brain cells) and (b) it is not comprehensive
> > since the JCR Resource Provider does not leverage that. (b) is IMHO the one
> > reason breaking the idea.
> >
> 
> Although I disagree on a (what else is this but restriction of access
> (don't mix it with permission by default) if b is the case (so it could not
> be granted to act on the global resource Tree I agree this would be a no go
> 

The ResourceAccessGate could be used for every resource provider, it's only 
not configured for JCRResourceProvider (but could by just setting a flag in
the OSGi configuration). The good reason for not enabling it is that ACLs of the
JCR shouldn't be mixed up with custom ACLs. But in the use case of
enabling features or not, ResourceAccessGate could be a lean solution
to hide some resources and does not mix up with ACLs.

best regards
mike

RE: FYI: feature flags prototype

[Mike Müller]

To confirm what Dominik mentioned:
The existing ResourceAccessGate would allow to grant or deny access
to resources. IMHO there's no need to implement another interface or
hook to achieve what is requested in the perspective of granting or denying
access to resources based on feature flag. Just implement a 
FeatureFlagResourceGate (or whatever name would make sense)..

best regards
Mike

> -Original Message-
> From: Dominik Süß [mailto:dominik.su...@gmail.com]
> Sent: Thursday, November 14, 2013 1:07 PM
> To: dev
> Subject: Re: FYI: feature flags prototype
> 
> +1 on extension hook in RR and adding this
> I had no closer look at Accessgate yet and thought it to behave that way
> from initial talks about this before implementation started. I just thought
> that Access Control is not just about permissions, it is about granting or
> denying access based on what ever logic you implement.
> 
> Best regards
> Dominik
> 
> 
> On Thu, Nov 14, 2013 at 12:12 PM, Julian Sedding  wrote:
> 
> > > Rather I could imagine backing this into the ResourceResolver itself ...
> >
> > I think we should avoid going down this route. The ResourceResolver is
> > a core feature of Sling, while feature-flags is (should be) an
> > optional feature.
> >
> > Baking feature-flags into the RR would violate modularity IMO.
> >
> > One way to achieve the same integration without baking that
> > functionality into the RR would be to create an extension hook that
> > allows decorating the RR. Then the FF bundle could provide such a
> > decorator and filter resources according to its needs.
> >
> > Regards
> > Julian
> >
> >
> > On Thu, Nov 14, 2013 at 1:30 AM, Felix Meschberger 
> > wrote:
> > > Hi
> > >
> > > I agree that it would be cool to also select resources based on
> > features. But I think the access gate is the wrong mechanism: Access
> > Control and Feature Selection are different beasts and should not be mixed.
> > >
> > > Rather I could imagine backing this into the ResourceResolver itself:
> > before returning a Resource it is checked for a feature flag property
> >  (e.g. sling:feature ?) and this being checked against the Feature service.
> > If not enabled, that resource is „hidden“ and not returned.
> > >
> > > WDYT ?
> > >
> > > Regards
> > > Felix
> > >
> > > —
> > > Felix Meschberger  |  Principal Scientist  |  Adobe
> > >
> > >
> > >
> > > Am 14.11.2013 um 02:21 schrieb Dominik Süß :
> > >
> > >> Hi Ruben,
> > >>
> > >> the intention is to disable features that are not should not be globally
> > >> available but might be activated under certain conditions. This reduces
> > the
> > >> need to branch non-production ready features away and merge them in
> > later
> > >> and opens the option to have something like a "Friendly user Test" or
> > >> softlaunch of a feature. Therefore this can be something big or
> > something
> > >> small. I think a solution should be capable of dealing with both. The
> > java
> > >> API would allow to hook in at any granularity level of the application
> > so
> > >> this already fullfills the requirements I'd have. Adding a corresponding
> > >> declarative logic to filter the resourcetree would give the same coarse
> > >> and/or finegrained filtermechanism to the resolutionprocess.
> > >>
> > >> What still would be missing is controlling updates and not just
> > additions.
> > >> e.g. when a resource should be rendered by a new version of a
> > resourceType
> > >> - in such case it might be an option to extend the searchpath from
> > >> /libs/../myresourcetype, /apps/../myresourcetype by featurespecific
> > >> overlaypaths that would either be searched when a feature is activated
> > or
> > >> hidden if the feature is deactivated. This would require refactoring
> > later
> > >> on but would allow parallel existance of multiple versions of a
> > >> resourceType.
> > >>
> > >> Best regards,
> > >> Dominik
> > >>
> > >>
> > >>
> > >>
> > >> On Wed, Nov 13, 2013 at 4:02 PM, Ruben Reusser 
> wrote:
> > >>
> > >>> Bertrand, Dominik,
> > >>>
> > >>> the feature flag may also have an impact on the nodes/properties that
> > you
> > >>> need to render the feature. Being able to handle this in the resource
> > tree
> > >>> directly without having to handle it in component code would be great.
> > >>> However, I am not sure if the intention of the feature flag was more to
> > >>> enable/change little features (code fragment) and not really change big
> > >>> things (leave that to test&target or other products?)
> > >>>
> > >>> Ruben
> > >>>
> > >>>
> > >>> On 11/13/2013 6:32 AM, Dominik Süß wrote:
> > >>>
> >  Hi Bertrand,
> > 
> >  the UI of an application based on Sling are often composed of existing
> >  resourceTypes so you cannot just decide in the code to display or not
> > to
> >  display so you have to "annotate"/"flag" the resources and then have
> > some
> >  code deciding if this resource should be rendered or not. For sure you
> >  could add code to each re

RE: [ANN] please welcome Chetan Mehrotra as a Sling committer!

[Mike Müller]

A warm welcome to the Sling committer team!

Best regards
mike

> -Original Message-
> From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
> Sent: Thursday, October 31, 2013 9:41 AM
> To: dev
> Subject: [ANN] please welcome Chetan Mehrotra as a Sling committer!
> 
> Hi,
> 
> Based on his ongoing and valuable contributions to the project, the
> Sling PMC has elected Chetan Mehrotra (chetanm) as a Sling committer,
> and he has accepted the invitation. Please join me in welcoming him!
> 
> Chetan, if you want to honor the old tradition of new committers
> briefly introducing themselves to the list, feel free.
> 
> If needed the new committers info is at
> http://www.apache.org/dev/new-committers-guide.html and generally
> under http://www.apache.org/dev/ - and feel free to ask if you have
> any questions.
> 
> Congrats and keep up the good work!
> 
> -Bertrand, for the Sling PMC
> 
> P.S. I have added Chetan at
> http://sling.apache.org/project-information/project-team.html

RE: [VOTE] Release Apache Sling Web Console Security Provider 1.1.0

[Mike Müller]

1+
sorry for being late...

best regards
Mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Monday, October 28, 2013 9:30 AM
> To: dev@sling.apache.org
> Subject: Re: [VOTE] Release Apache Sling Web Console Security Provider 1.1.0
> 
> Anyone else?
> 
> Thanks
> Carsten
> 
> 
> 2013/10/21 Carsten Ziegeler 
> 
> > +1
> >
> > Carsten
> >
> >
> > 2013/10/21 Bertrand Delacretaz 
> >
> >> Hi,
> >>
> >> On Monday, October 21, 2013, Carsten Ziegeler wrote:
> >> > ...Please vote to approve this release..
> >>
> >> +1 - checked signatures, svn tag consistency and build of the following
> >> archives:
> >>
> >> MD5
> >>
> >> (org.apache.sling.extensions.webconsolesecurityprovider-1.1.0-source-
> release.zip)
> >> = 6047b26741ad84f5a4d4aeb5d2f133bf
> >>
> >> -Bertrand
> >> >
> >> >
> >>
> >
> >
> >
> > --
> > Carsten Ziegeler
> > cziege...@apache.org
> >
> 
> 
> 
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release Apache Sling Health Check Core 1.0.6, Health Check JMX 1.0.6, and JMX Resource Provider 0.6.0

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Sunday, October 20, 2013 4:18 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Health Check Core 1.0.6, Health Check 
> JMX 1.0.6, and JMX Resource Provider 0.6.0
> 
> Hi,
> 
> it's time for some new releases, I've combined these three as they are
> related. They contain some important bug fixed and minor improvements
> 
> Sling Health Check Core 1.0.6
> https://issues.apache.org/jira/browse/SLING/fixforversion/12325148 version/12325253>
> 
> Sling Health Check JMX 1.0.6
> https://issues.apache.org/jira/browse/SLING/fixforversion/12325146 version/12315426>
> 
> Sling JMX Resource Provider 0.6.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12325252 version/12324870>
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-003/
> 
> 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 003 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release Apache Sling Commons Scheduler 2.4.2, Commons Threads 3.2.0, and Evenint 3.3.0

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Sunday, October 20, 2013 4:16 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Commons Scheduler 2.4.2, Commons Threads 
> 3.2.0, and Evenint 3.3.0
> 
> Hi,
> 
> it's time for some new releases, I've combined these three as they are
> related. They contain some important bug fixes and new features
> 
> Sling Commons Scheduler 2.4.2
> https://issues.apache.org/jira/browse/SLING/fixforversion/12325253
> 
> Sling Commons Threads 3.2.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12315426
> 
> Sling Eventing 3.3.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12324870
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-002/
> 
> 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 002 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Initial Release of the Apache Sling Health Check Tools

[Mike Müller]

+1, cool tools ;-)
Best regards
mike

> -Original Message-
> From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
> Sent: Thursday, September 26, 2013 5:39 PM
> To: dev
> Subject: [VOTE] Initial Release of the Apache Sling Health Check Tools
> 
> Hi,
> 
> This is a vote for the initial release of the following Health Check modules:
> 
> org.apache.sling.hc.core-1.0.4
> org.apache.sling.hc.it-1.0.4
> org.apache.sling.hc.jmx-1.0.4
> org.apache.sling.hc.samples-1.0.4
> org.apache.sling.hc.support-1.0.4
> org.apache.sling.hc.webconsole-1.0.4
> org.apache.sling.junit.healthcheck-1.0.6
> 
> Versions are not 1.0.0 as I messed up some releases along the way
> (it's mostly maven -pl's fault).
> 
> The docs are up to date at
> http://sling.apache.org/documentation/bundles/sling-health-check-tool.html
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-101
> 
> 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 101 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
> 
> This vote will be open for at least 72 hours.
> 
> -Bertrand

RE: [VOTE] Drop the time zone info from committers page

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Felix Meschberger [mailto:fmesc...@adobe.com]
> Sent: Wednesday, September 18, 2013 10:00 AM
> To: dev@sling.apache.org
> Subject: Re: [VOTE] Drop the time zone info from committers page
> 
> +1
> 
> Regards
> Felix
> 
> Am 17.09.2013 um 19:33 schrieb Carsten Ziegeler:
> 
> > Hi,
> >
> > I think we should drop the time zone information from the committers page.
> > I think it doesn't serve any real purpose.
> >
> > Carsten
> >
> > --
> > Carsten Ziegeler
> > cziege...@apache.org

RE: [DISCUSS] move healthcheck under bundles/extensions and release as 0.9.0

[Mike Müller]

+1 for releasing it as 1.0.0 as the API seems tob e pretty stable.

Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Tuesday, September 17, 2013 4:04 PM
> To: dev@sling.apache.org
> Subject: Re: [DISCUSS] move healthcheck under bundles/extensions and release 
> as 0.9.0
> 
> Hi,
> 
> I don't feel very strong for moving, but I'm not against it :)
> I think we can directly go with  1.0.0 release, at least for the modules
> who expose API.
> I'm +1 for releasing core and jmx and have no opinion about the others
> right now :)
> 
> Carsten
> 
> 
> 2013/9/17 Bertrand Delacretaz 
> 
> > Hi,
> >
> > Coming back to this, is anyone opposed to
> >
> > a) moving the contrib/extensions/healthcheck module under
> > bundles/extensions/healthcheck ?
> >
> > b) releasing those modules as V0.9.0 ?
> >
> > I'm presenting the tool at adaptTo next week, would be nice to have a
> > first release.
> >
> > I'm resyncing the docs at
> > http://sling.apache.org/documentation/bundles/sling-health-check-tool.html
> > now to be consistent with the recent changes.
> >
> > -Bertrand
> >
> 
> 
> 
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [GSoC2013] Access Control for Cassandra ResourceProvider

[Mike Müller]

> From: ianbos...@gmail.com [mailto:ianbos...@gmail.com] On Behalf Of Ian Boston
> 
> Hi Mike,
> Thanks for the pointer.
> 
> On 12 September 2013 14:58, Mike Müller  wrote:
> > Hi
> >
> > The common way to solve such an access control for a provider like
> > the Cassandra resource provider is the new ResourceAccessSecurity
> > service. This is implemented in the bundle resourceaccesssecurity
> > (at this time only read rights will be checked).
> 
> Incidentally, how will other rights be enforced ?
> the update pattern is resource.adaptTo(ModifiableValueMap.class)
> 
> would the adapter factory check that the current user has write access
> to the resource before they can get their hands on a
> ModifiableValueMap ?

Yes, the resource will be wrapped to enforce the rights and the 
ModifiableValueMap as well...
But as I said by now only read rights are enforced. The Cassandra
resource provider is a very good example of a use case for this 
service.

Best regards
mike

RE: [GSoC2013] Access Control for Cassandra ResourceProvider

[Mike Müller]

Hi

The common way to solve such an access control for a provider like
the Cassandra resource provider is the new ResourceAccessSecurity
service. This is implemented in the bundle resourceaccesssecurity 
(at this time only read rights will be checked). All you have to do is to 
implement the SPI ResourceAccessGate for the Cassandra provider
and set the provider.useResourceAccessSecurity property to true
for your ResourceProvider.
By time resourceaccesssecurity will also implement create, modify 
And delete rights.

Best regards
mike

> -Original Message-
> From: Dishara Wijewardana [mailto:ddwijeward...@gmail.com]
> Sent: Thursday, September 12, 2013 2:25 PM
> To: dev@sling.apache.org
> Subject: Re: [GSoC2013] Access Control for Cassandra ResourceProvider
> 
> Hi Ian
> 
> 
> On Thu, Sep 12, 2013 at 1:50 PM, Ian Boston  wrote:
> 
> > Hi Dishara,
> > To make the Cassandra Resource Provider really useful I think we need
> > to add access control. I think the best way of doing this is to borrow
> > some concepts from Jackrabbit access control.
> >
> >
> The following algorithms, and etc does sling already have any
> implementation of it. If so I can reuse them. Since sling has few providers
> I believe they probably have some common interface.
> 
> 
> > Take a deep breath, and you will see why I left this till last.
> >
> > I think we should provide path base access control, which inherits
> > from parent resources in the path. At every level there is a an
> > ordered list of access control entries each access control entry (ACE)
> > being either an allow entry or a deny entry. What is allowed or denied
> > is defined in a 32bit bitmap with each bit representing 1 permission,
> > so we can have upto 32 permissions. Each ACE specifies a single
> > principal. So an ACL consists of a ordered list of ACE's each one
> > bound to a principal.
> >
> > A user has a set of principals, so to resolve the ACL at any one path
> > for a user the global ACL is filtered to contain only the ACE's with
> > principals that the user has.
> >
> > Computing a final access control bitmap for a user at a location
> > requires ordered processing of all the ACEs relevant to the user at
> > the current path and then all ancestors.
> >
> > The pseudo algorithm to calculate the a grant bitmap and a deny bitmap
> > at any level is:
> >
> > function getCurrentLevelBitmaps(currentPath):
> >   int grants = 0;
> >   int denies = 0;
> >   for all ACEs in the ACL at the currentPath:
> > if the user has the principal of the current ACE:
> >   int toGrant = 0;
> >   int toDeny = 0;
> >   if the ACE is a grant:
> > toGrant = the ACE bitmap;
> >   else:
> > toDeny = the ACE bitmap;
> >   toGrant = toGrant & ~denies;
> >   toDeny = toDeny & ~grants;
> >   grants = grants | toGrant;
> >   denied = denies | toDenies;
> >   return (grants, denies);
> >
> 
> - Can you please tell me how to calculate the ACE bitmap ?
> - Also I will be more clear if you can provide a sample value for the input
> and output of this function ? i.e When currentPath=
> /content/cassandra/foo/bar  it returns grants=? denies=? some actual values
> just for my understanding.
> 
> 
> > To combine what is granted at the child level with what is granted at
> > a parent level we need to mask the parent level with the deny at the
> > child level.
> >
> > eg
> >  toGrant = grantedAtParent & ~denies;
> >  toDeny = deniedAtParent & ~grants;
> >  grants = grants | toGrant;
> >  denied = denies | toDenies;
> >
> > The simplest way of achieving this is to use recursion again in pseudo
> > code:
> >
> >function buildAtLevel():
> > if not root level:
> >  (grantedAtParent, deniedAtParent) =
> > buildAtLevel(getParentLevel(currentLevel));
> > (grants, denies) = getCurrentLevelBitmaps(currentLevel);
> > toGrant = grantedAtParent & ~denies;
> >toDeny = deniedAtParent & ~grants;
> >grants = grants | toGrant;
> >denied = denies | toDenies;
> >return (grants, denied);
> >
> >
> > There are some optimisations you can apply here, and there are plenty
> > of opportunities to cache intermediate bitmaps in memory. Just caching
> > the ACL reduces resolution to bitwise operations.
> >
> > Principals
> > 
> > Initially keep it simple.
> >
> > read = 0x01
> > write = 0x02
> > delete = 0x04
> >
> > Storage of ACLs.
> > -
> > I suggest you store ACLs in their own Column Family, where the rowID is
> > base64(sha1(path)) or whatever path -> rowid encoding you have currently.
> >
> > IIRC Cassandra columns come out in the natural order of Strings
> > __ and the value is the bitmap of
> > permissions.
> >
> > - If I understand you

RE: [VOTE] Parent POM 18

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Tuesday, September 03, 2013 8:20 AM
> To: dev@sling.apache.org
> Subject: [VOTE] Parent POM 18
> 
> Hi,
> 
> please vote for a release of our parent pom, it basically contains updates
> of the used plugin versions to their latest release:
> 
> https://issues.apache.org/jira/browse/SLING/fixforversion/12324745
> 
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-002/
> 
> 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 002 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Apache Commons Log 3.0.2

[Mike Müller]

+1
best regards
mike

> -Original Message-
> From: Felix Meschberger [mailto:fmesc...@adobe.com]
> Sent: Monday, August 26, 2013 10:11 AM
> To: dev@sling.apache.org
> Subject: [VOTE] Apache Commons Log 3.0.2
> 
> Hi
> 
> This is to vote for the Apache Commons Log 3.0.2 release. This is probably 
> the last
> release we are cutting with our home grown SLF4J API implementation embedded.
> The next release is planned to be 4.0.0 which will most probably be based on
> Logback (SLING-2024).
> 
> The following issues have been implemented and fixed in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12319554
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-115/
> 
> 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 115 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ]  0 Don't care
> [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Felix

RE: [VOTE] Release Discovery Modules, Settings and Eventing

[Mike Müller]

+1
best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Friday, August 09, 2013 9:52 AM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Discovery Modules, Settings and Eventing
> 
> Hi,
> 
> this vote is primarily about doing the first release of our discovery
> implementation modules (we already released the api some time ago). The
> implementation proofed to be stable/usable. In addition, we need to release
> a dependency, Sling Settigns 1.3.0 and I've also included the Sling Events
> as this makes heavy use of the discovery stuff.
> 
> So please vote for the release of
> 
> Sling Settings 1.3.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12323581
> 
> Sing Discovery Support 1.0.0
> Sling Discovery Standalone 1.0.0
> Sling Discovery Impl 1.0.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12324346
> 
> Sling Eventing 3.2.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12321291
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-079/
> 
> 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.sh079 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release Apache Sling JCR Jackrabbit Server 2.1.2

[Mike Müller]

+1
best regards
mike

> -Original Message-
> From: Felix Meschberger [mailto:fmesc...@adobe.com]
> Sent: Monday, August 05, 2013 2:47 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling JCR Jackrabbit Server 2.1.2
> 
> Hi,
> 
> This vote is to release the Apache Sling JCR Jackrabbit Server 2.1.2
> bundle.
> 
> We solved 10 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12315318
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-061/
> 
> 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 061 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Felix

RE: [VOTE] release org.apache.sling.auth.form version 1.0.4

[Mike Müller]

+1
best regards
mike

> -Original Message-
> From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
> Sent: Friday, May 24, 2013 12:06 PM
> To: dev
> Subject: [VOTE] release org.apache.sling.auth.form version 1.0.4
> 
> Hi,
> 
> We solved 3 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12315993
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-039/
> 
> 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 039 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
> 
> This vote will be open for at least 72 hours.
> 
> -Bertrand

RE: [VOTE] JCR Resource 2.2.8 and Servlets Post 2.3.0

[Mike Müller]

+1
best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Friday, May 03, 2013 12:51 PM
> To: dev@sling.apache.org
> Subject: [VOTE] JCR Resource 2.2.8 and Servlets Post 2.3.0
> 
> Hi,
> 
> we have some important bug fixes and improvements to release.
> 
> Please vote for the release of JCR Resource 2.2.8
> https://issues.apache.org/jira/browse/SLING/fixforversion/12324110
> 
> and Servlets Post 2.3.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12323498
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-165
> 
> 
> 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 165 /tmp/sling-staging
> 
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release API 2.4.2

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Tuesday, April 30, 2013 10:16 AM
> To: dev@sling.apache.org
> Subject: [VOTE] Release API 2.4.2
> 
> Hi,
> 
> I just fixed two errors in ResourceUtil (SLING-2844 and SLING-2845) which
> imho warrant a new release. So here we go
> 
> Please vote for the release of API 2.4.2
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-155
> 
> 
> 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 155 /tmp/sling-staging
> 
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> 
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release parent 16

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Tuesday, April 30, 2013 11:58 AM
> To: dev@sling.apache.org
> Subject: [VOTE] Release parent 16
> 
> Please vote for the release of a new parent pom. This contains a single
> change, the update to the latest Maven SCR plugin (
> https://issues.apache.org/jira/browse/SLING-2846)
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-156
> 
> 
> 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 156 /tmp/sling-staging
> 
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release Apache Sling Tenant 1.0.0 and Apache Sling javax.activation 0.1.0

[Mike Müller]

+1
best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Tuesday, April 23, 2013 1:02 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Tenant 1.0.0 and Apache Sling
> javax.activation 0.1.0
> 
> Hi,
> 
> this vote is about a the first release for two of our modules
> 
> So please vote for the release of:
> Apache Sling Tenant 1.0.0
> 
> Apache Sling javax.activation 0.1.0
> 
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-
> 127
> 
> 
> 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 127 /tmp/sling-staging
> 
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [ANN] Please welcome Dan Klco as a Sling committer

[Mike Müller]

Welcome and congrats Dan!

best regards
mike

> -Original Message-
> From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
> Sent: Tuesday, April 23, 2013 10:03 AM
> To: dev
> Subject: [ANN] Please welcome Dan Klco as a Sling committer
> 
> Hi,
> 
> Based on his ongoing and valuable contributions to the project, the
> Sling PMC has elected Dan Klco (dklco) as a Sling committer, and he
> has accepted the invitation. Please join me in welcoming him!
> 
> Dan, if you want to honor the old tradition of new committers briefly
> introducing themselves to the list, feel free. I assume you got this
> info already, but just in case the new committers info is at
> http://www.apache.org/dev/new-committers-guide.html and generally
> under http://www.apache.org/dev/ - and feel free to ask if you have
> any questions.
> 
> -Bertrand
> 
> P.S. I have added Dan and Stefan at
> http://sling.apache.org/project-information/project-team.html

RE: [ANN] New Committer : Stefan Egli

[Mike Müller]

Welcome and congrats Stefan!

best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Tuesday, April 23, 2013 8:57 AM
> To: dev@sling.apache.org
> Subject: [ANN] New Committer : Stefan Egli
> 
> The Project Management Committee (PMC) for Apache Slinghas asked
> Stefan Eglie to become a committer and we are pleased to announce that
> they have accepted.
> 
> 
> Being a committer enables easier contribution to theproject since
> there is no need to go via the patchsubmission process. This should
> enable better productivity.Being a PMC member enables assistance with
> the managementand to guide the direction of the project.
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release Apache Sling Security 1.0.4

[Mike Müller]

+1
best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Monday, April 22, 2013 10:14 AM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Apache Sling Security 1.0.4
> 
> Hi,
> 
> this vote is about a fix in the security module (SLING-2836)
> 
> So please vote for the release of:
> Apache Sling Security 1.0.4
> 
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-
> 124
> 
> 
> 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 124 /tmp/sling-staging
> 
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> 
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release Testing ResourceResolver Mock 0.1.0

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Thursday, April 18, 2013 8:14 AM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Testing ResourceResolver Mock 0.1.0
> 
> Hi,
> 
> this vote is about a first release of our new Testing ResourceResolver Mock
> 0.1.0 module.
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-
> 115
> 
> 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 115 /tmp/sling-staging
> 
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: Automated tests, at least under /bundles

[Mike Müller]

+1

To achieve that, it would be good, if there would be some
documentation available how testing stuff (especially integration
tests) should be done in the Sling project.

best regards
Mike

> -Original Message-
> From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
> Sent: Friday, April 05, 2013 11:11 AM
> To: dev@sling.apache.org
> Subject: Re: Automated tests, at least under /bundles
> 
> On Fri, Apr 5, 2013 at 10:56 AM, Carsten Ziegeler  
> wrote:
> > ...basically +1 - but I don't consider this a blocker
> >
> > We have the same situation with documentation...
> 
> The impact of incomplete documentation is way less than having
> untested code to our core.
> 
> Either we care about Sling being a high-quality framework, and we
> supply tests to demonstrate it and ensure it stays that way - or it's
> just a pile of code that's supposed to work.
> 
> I'm in favor of the former ;-)
> 
> -Bertrand

RE: Feedback on the current ResourceAccessSecurity API

[Mike Müller]

Thank you Bertrand for the more precise javadocs. I have also
changed to javadoc from AccessSecurityException to be more
generic. (commited in r1464476)

best regards
Mike

> -Original Message-
> From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
> Sent: Thursday, April 04, 2013 10:05 AM
> To: dev@sling.apache.org
> Subject: Re: Feedback on the current ResourceAccessSecurity API
> 
> Hi Mike,
> 
> On Wed, Apr 3, 2013 at 9:18 PM, Mike Müller  wrote:
> > ...I commited a last shot of the SPI API. The Sling API hasn't changed
> > anymore. I think the API is now complete and after all the discussions
> > enough mature
> 
> I have added/tweaked javadocs on the ResourceAccessSecurity interface
> in revision 1464342, could you cross-check?
> 
> Also, the AccessSecurityException javadoc says "Exception thrown by
> ResourceAccessGate#sanitizeQuery(String, String,
> org.apache.sling.auth.core.spi.AuthenticationInfo) if the query is not
> allowed or illegal.", I would move that info to the sanitizeQuery
> method instead, and make the exception description more generic - feel
> free to do that if you agree.
> 
> -Bertrand

RE: Feedback on the current ResourceAccessSecurity API

[Mike Müller]

I commited a last shot of the SPI API. The Sling API hasn't changed
anymore. I think the API is now complete and after all the discussions 
enough mature.

best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Wednesday, April 03, 2013 1:48 PM
> To: dev@sling.apache.org
> Subject: Re: Feedback on the current ResourceAccessSecurity API
> 
> We discussed this API in length and as I said, the impl is missing. So yes,
> we're not releasing until it's implemented
> 
> 
> 2013/4/3 Bertrand Delacretaz 
> 
> > On Wed, Apr 3, 2013 at 12:17 PM, Carsten Ziegeler 
> > wrote:
> > > ...I would like to cut some releases shortly, especially a new API,
> > > resourceresolver and jcr resource release...
> >
> > Do we really want to include Mike's new APIs in a release already?
> >
> > I'd feel more comfortable if we can look at them in parallel, and
> > release only once we have at least a basic implementation that
> > demonstrates the ideas.
> >
> > -Bertrand
> >
> 
> 
> 
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: Feedback on the current ResourceAccessSecurity API

[Mike Müller]

+1

> -Original Message-
> From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
> Sent: Wednesday, March 27, 2013 5:53 PM
> To: dev@sling.apache.org
> Subject: Re: Feedback on the current ResourceAccessSecurity API
> 
> On Wed, Mar 27, 2013 at 5:48 PM, Carsten Ziegeler 
> wrote:
> > ...What about a neutral name? It's up to the implementation whether it
> > optimizes or sanitizes - transformQuery maybe?...
> 
> Works for me, suggested javadoc:
> 
> **
> Allows the ResourceProvider to transform the query based on the
> current user's credentials. Can be used to narrow down queries to omit
> results that the current user is not allowed to see anyway, speeding
> up downstream access control.
> 
> Query transformations are not critical w.r.t access control as results
> are checked using the canRead.. methods anyway.
> ***
> 
> -Bertrand

RE: Feedback on the current ResourceAccessSecurity API

[Mike Müller]

> 
> So it is optimizeQuery really ;-)
> 
> -Bertrand

optimizeQuery in matters of performant security checks :-)
Maybe you are right in this case, that we rather should name the method 
optimizeQuery than sanitizeQuery.

mike

RE: Feedback on the current ResourceAccessSecurity API

[Mike Müller]

> > It's not really an optimization in the sense of a QueryOptimizer, that 
> > could be
> done
> > by every ResourceProvider by now, without any new API. The sanitizeQuery
> functionality
> > has to come with the ResourceAccessSecurity service: The query can be
> injected
> > (sanitized) only from a service which "knows" the security rules for the 
> > given
> user.
> > If you look at the example above with the injection "WHERE owner=":
> This
> > could only be injected by a service which knows that the given user only has
> access
> > to resources where the he is the owner. Maybe a different user with more 
> > rights
> > does not have any restrictions (or another restriction)
> 
> This sounds scary to me in terms of security, with many moving parts.
> I guess I'll need to see more concrete examples to make up my mind.


It shouldn't scare at all: With or without the use of sanitizeQuery, the 
resulting
list of resources (or the resulting resource) is checked against security 
anyway.
So sanitizeQuery does not disturb security. The use case is very simple as 
showed above:
If a query returns a lot of resources but the querying user does only have 
access
to a few of these resources, sanitizeQuery could change the query in a way that
only a few resources will be returned from the resource provider. Without 
sanitizeQuery it can take quite a long time to check each and every resource 
with
getReadableResource() if the querying user has read access to the resource.
We don't talk about some milliseconds here but about seconds or minutes if there
are a lot of similar resources but the user has access only to a few (and the 
persistence
does not have any ACLs - which is the use case for ResourceAccessSecurity).
So we really can gain a lot with this method in matters of performance for some
cases, but nobody who want's to use ResourceAccessSecurity in the future has
to implement it. The disadvantage could be (depends on the data) that applying
access rights is slow if someone decides not to impement it. So we only can win
with this additional method.

Best regards
Mike

RE: Feedback on the current ResourceAccessSecurity API

[Mike Müller]

> On Mon, Mar 25, 2013 at 8:14 PM, Mike Müller  wrote:
> ...
> > Bertrand wrote:
> >> // Calling that canRead would be more consistent with other names
> >> public Resource checkReadPermission( Resource resource );
> >
> > I choosed another naming because canCreate, canDelete, etc. returns a
> boolean,
> > but checkReadPermission returns a Resource. Maybe it's more visible with
> > a different methode name.
> 
> What's the goal of returning a Resource? Is one expected to use the
> returned one instead of the one that's passed into the method?
> 
> If yes I'd suggest getReadableResource(Resource).

Yes, that's exactly what it does - I will take with your method name.

 
> ...
> >> // Having to extract username as a String feels a bit funny - maybe
> >> // you need an opaque ResourceCredentials object...
> > ...At this time ResourceResolver has a method named getUserID() which
> > returns a String...
> 
> As Carsten says, passing the ResourceResolver in such cases is
> probably the best way to provide context.

That's okay for me


> 
> >>... Maybe canSetValue
> >> // can cover both cases, by first checking if the value exists..
> 
> > Yes good point, we could make this easier with just one method.
> 
> ok
> 
> >...
> >> public String sanitizeQuery( String query, String language, String
> >> user ) throws AccessSecurityException;
> > ...Think of a mongodb like persistence
> > layer with millions of resources saved. No we've got a user which has access
> > to only 10 resources. Now he makes a query like "SELECT * FROM allresources"
> > (just as an example in an SQL like language). This query would now return
> > millions of resources and every resource in the returning list would be 
> > checked
> > by ResourceAccessSecurity#canRead. With sanitizeQuery the query could
> > be injected with some limiting statements like "SELECT * FROM allresources
> > WHERE owner=". In this case a list of only 10 resources would
> > be returned. Nevertheless every returned resource would be checked by
> canRead,
> > but the performance would be much much better than in the first case
> 
> Could this be done by having the ResourceProvider implement a
> QueryOptimizer API instead? The ResourceResolver can then check if the
> provider implements this and call that method in that case. It doesn't
> feel right to me to mix that method with security stuff as it has
> nothing to do with security AFAICS.

It's not really an optimization in the sense of a QueryOptimizer, that could be 
done
by every ResourceProvider by now, without any new API. The sanitizeQuery 
functionality
has to come with the ResourceAccessSecurity service: The query can be injected 
(sanitized) only from a service which "knows" the security rules for the given 
user.
If you look at the example above with the injection "WHERE owner=": This
could only be injected by a service which knows that the given user only has 
access
to resources where the he is the owner. Maybe a different user with more rights
does not have any restrictions (or another restriction).
I do have experience with such a possibility of query injection for years now 
and 
can say that it speeds up access controlling a lot. 

best regards
Mike

RE: Feedback on the current ResourceAccessSecurity API

[Mike Müller]

> Notes on ResourceAccessSecurity:
> 
> 1) javadocs says "* - Expected to only be implemented once in the
> framework/application...", I'm not sure about that. If you have both a
> filesystem and an HBase resource providers, they might use very
> different implementations?
> 
> 2) Notes as comments in the interface:
> public interface ResourceAccessSecurity {
> 
> // Calling that canRead would be more consistent with other names
> public Resource checkReadPermission( Resource resource );

I choosed another naming because canCreate, canDelete, etc. returns a boolean,
but checkReadPermission returns a Resource. Maybe it's more visible with
a different methode name.

 
> // Having to extract username as a String feels a bit funny - maybe
> // you need an opaque ResourceCredentials object that the
> ResourceResolver can provide
> // based on a Request or Resource, similar to JCR Sessions.
> public boolean canCreate( String absPathName, String user );

At this time ResourceResolver has a method named getUserID() which
returns a String. The Javadoc of this method says:
 * Get the user ID, if any, associated with this resource resolver. The
 * meaning of this identifier is an implementation detail defined by the
 * underlying repository. This method may return null.

If we want to use something different, we should use AuthenticationInfo, but
This is not available in ResourceResolver interface. 


> 
> public boolean canUpdate( Resource resource );
> public boolean canDelete( Resource resource );
> public boolean canExecute( Resource resource );
> 
> public boolean canReadValue( Resource resource, String valueName );
> 
> // Do we need both canCreate and canUpdate? To use canCreate you first 
> need
> // to find out that the value doesn't exist, feels a bit weird.

We do need canCreate, because you could save a resource without a value on it.
The method canUpdate is the only way how a client of the ResourceAccessSecurity
service can determine if a user must not update a resource. Otherwise the client
has to check for every value which exists on the resource and also if the client
does that, it's not sure if the user can create a new value on this resource to 
update
it. canUpdate returns false if the user can't update any existing value and 
can't 
add a new value to the given resource.


> Maybe canSetValue
> // can cover both cases, by first checking if the value exists
> public boolean canCreateValue( Resource resource, String valueName );
> public boolean canUpdateValue( Resource resource, String valueName );

Yes good point, we could make this easier with just one method. 
 
> public boolean canDeleteValue( Resource resource, String valueName );
> 
> // Does that rather belong to a QuerySecurity interface, what's
> the use case?
> // Also, user vs. ResourceCredentials as above
> public String sanitizeQuery( String query, String language, String
> user ) throws AccessSecurityException;

This method is thought for special query languages where it is very easy
to inject some things in the query which limits the resulting list of resources.
This method delegates the call to the ResourceAccessGate#sanitizeQuery.
It hasen't to be used by implementations of ResourceAccessGate, but can
be used to speed up security checks a lot. Think of a mongodb like persistence
layer with millions of resources saved. No we've got a user which has access
to only 10 resources. Now he makes a query like "SELECT * FROM allresources"
(just as an example in an SQL like language). This query would now return
millions of resources and every resource in the returning list would be checked
by ResourceAccessSecurity#canRead. With sanitizeQuery the query could
be injected with some limiting statements like "SELECT * FROM allresources
WHERE owner=". In this case a list of only 10 resources would
be returned. Nevertheless every returned resource would be checked by canRead,
but the performance would be much much better than in the first case.

Best regards
mike

RE: [RT] ResourceAccessSecurity service for ResourceProvider without ACLs

[Mike Müller]

> From: Alexander Klimetschek [mailto:aklim...@adobe.com]
> On 25.03.2013, at 14:05, Carsten Ziegeler  wrote:
> 
> > 2013/3/25 Alexander Klimetschek :
> >>
> >> The crucial difference IMHO is that the sling API is meant for 
> >> applications. The
> resource access security is a sling internal and optional one since for 
> application
> code it is all transparent behind the resource resolver and resource API. 
> Therefore
> it should go into a separate API bundle.
> >
> > That's wrong - we already have resource provider and co there
> 
> Then this is IMHO bad design of the sling API bundle. I also note that the
> ResourceProvider is also in the generic org.apache.sling.api.resource package 
> so it
> can't be split out anymore - as a kind of SPI it should also package-wise be
> decoupled from the application level interfaces... But let's not continue 
> with that
> error for such an optional feature.
> 
> The point is that if some application stack does not want to expose the 
> resource
> access security stuff (because it uses JCR only and does not want application 
> devs
> to see and use those APIs accidentally), it should be able to ship a system 
> without
> them. By putting everything into the Sling API bundle this becomes impossible.

If the ResourceProvider interface is at the wrong place in the Sling API bundle 
and 
should be placed as an SPI somewhere in the resourceresolver bundle, that means
that Sling encourages other implementations of ResourceResolver to expose
their own different SPIs. I think the main goal here is, that Sling defines a 
simple
way how resource providers can be attached to Sling (and not the 
ResourceResolver) -
a Sling way which should be used. 

That's also the case with ResourceAccessSecurity. In this case if it is shipped 
with the 
Sling API and someone even implements this service, it is NOT used if the 
installation 
is only shiped with a JCR resouce provider. The ResourceAccessSecurity should 
it make
easy to use providers without any ACLs without having to pass on some security 
- and
that's a step forward for Sling. That's why I'm engaged to share here some code 
and
ideas.

I'm really a little bit confused about this occasionally offending discussion.
I haven't yet got some feedback to the main proposal of this thread - 
unfortunately.

Best regards
Mike

RE: [RT] ResourceAccessSecurity service for ResourceProvider without ACLs

[Mike Müller]

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Sunday, March 24, 2013 2:10 PM
> To: dev@sling.apache.org
> Subject: Re: [RT] ResourceAccessSecurity service for ResourceProvider without 
> ACLs
> 
> 2013/3/24 Mike Müller :
> > From: Carsten Ziegeler [mailto:cziege...@apache.org]
> >> This sounds like an interesting idea - what would it need in the
> >> resource resolver bundle to support this property?
> >
> > Not that much. The resource resolver bundle would route calls for
> > a resource provider with the new property set, through the 
> > ResourceAccessSecurity
> > service. If no resource provider has set the property, nothing changes.
> > If no ResourceAccessSecurity service is available but a resource provider
> > has set the property, access to resources of this provider will not be
> > allowed by default.
> > If we take the ResourceAccessSecurity interface out of the Sling API bundle 
> > -
> > as proposed by Alexander and Bertrand - we should make a 
> > resourcesecurity-api
> > bundle to separate the implementation from the API. Resource resolver bundle
> > then only imports the resourcesecurity-api.
> 
> If we add support for calling this service from within the resource
> resolver bundle, then the interface should definitely stay in the api.
> We already have different packages with different services implemented
> by different bundles, so I don't see why we should make a difference
> here and put it into a different bundle.

That was and would be my preference as well.

Best regards
Mike

RE: [RT] ResourceAccessSecurity service for ResourceProvider without ACLs

[Mike Müller]

From: Carsten Ziegeler [mailto:cziege...@apache.org]
> This sounds like an interesting idea - what would it need in the
> resource resolver bundle to support this property?

Not that much. The resource resolver bundle would route calls for 
a resource provider with the new property set, through the 
ResourceAccessSecurity
service. If no resource provider has set the property, nothing changes.
If no ResourceAccessSecurity service is available but a resource provider
has set the property, access to resources of this provider will not be
allowed by default.
If we take the ResourceAccessSecurity interface out of the Sling API bundle - 
as proposed by Alexander and Bertrand - we should make a resourcesecurity-api
bundle to separate the implementation from the API. Resource resolver bundle
then only imports the resourcesecurity-api.
The whole implementation of resourcesecurity-api will then stay in the
Resourceaccesssecurity bundle (or maybe we call it better resourcesecurity to
make it consistent to the api bundle). 

Best regards
Mike

[RT] ResourceAccessSecurity service for ResourceProvider without ACLs

[Mike Müller]

Hi

I'm coming up with a new thread concerning the use of the new
ResourceAccessSecurity service in implementations of ResourceProvider
which do not have uderlaying ACLs.

My first thought was that each ResourceProvider without any ACLs should
implement some lightweight access security through the use of the
ResourceAccessSecurity service. The disadvantage of this approach is that
every resource provider has to implement the same calls. We do have the
implementation separated into the resourceaccesssecurity bundle but it's
nevertheless quite an effort for the resource providers to actually use this
service. 

To make this easier I propose that we insert a new service parameter for
ResourceProviders, called "applyResourceAccessSecurity" (or similar).
With this parameter set (which defaults to false) the calls to the 
ResourceAccessSecurity are made automatically through the ResourceResolver
implementation. With this, it would be very easy for a resource provider
to use the ResourceAccessSecurity service. And it would be as easy as 
setting a service parameter to implement it on FSResourceProvider, 
BundleResourceProvider, MongoDBResourceProvider and future providers 
without ACLs.

WDYT?

best regards
Mike

RE: [RT] Access Control in ResourceProviders

[Mike Müller]

Hi

To be sure (and save some time coding ;-) ), I sum up our discussion:

We can keep the basic singleton service (ResourceAccessSecurity) in the API 
and document it like this:

  * Expected to only be implemented once in the framework/application
(much like the OSGi LogService or Configuration Admin Service)
  * ResourceProvider implementations are encouraged (or stronger)
to use this service for access control unless the underlying
storage already has it.

We implement the ResourceAccessSecurity service in a extension bundle.
There will be only one implementation of this service (singleton). 

The implementation of ResourceAccessSecurity will use the proposed 
ResourceAccessGate for it's own extensability.

We implement the use of the ResourceAccessSecurity service in FsResourceProvider
And BundleResourceProvider.

If that is okay I will come up with some new code.

Best regards
mike

RE: [RT] Access Control in ResourceProviders

[Mike Müller]

> From: Felix Meschberger [mailto:fmesc...@adobe.com]
> > Okay, as far as I understand we've got the consensus of separating my 
> > access gate
> > proposal from the Sling API. We should have something like a
> ResourceAccessSecurity
> > service in a extension bundle,
> 
> I think we can keep the basic singleton service (you call it 
> ResourceAccessSecurity
> now, right?) in the API and document it like this:
>
>   * Expected to only be implemented once in the framework/application
> (much like the OSGi LogService or Configuration Admin Service)
>   * ResourceProvider implementations are encouraged (or stronger)
> to use this service for access control unless the underlying
> storage already has it.
> 
> > I think we don't loose the goal of bringing Sling
> > forward to a frontend of resources from different providers than JCR without
> > any security built in (like MongoDB, file provider, bundle provider etc.) 
> > with this
> > new setup. If we go down this road I propose the following:
> >
> > Making a new bundle (extension) with a new service called 
> > ResourceAccessSecurity.
> 
> +1
> 
> > Taking the ResourceAccessGate interface out of the Sling API but keeping it 
> > as
> > a "access rule feeder" interface for the new ResourceAccessSecurity service.
> 
> So the actual ResourceAccessSecurity service implementation bundle will 
> define its own
> extensibility model, right ?

Yes, that's right, through the ResourceAccessGate interface.

Best regards
mike

RE: [RT] Access Control in ResourceProviders

[Mike Müller]

Hi

Okay, as far as I understand we've got the consensus of separating my access 
gate
proposal from the Sling API. We should have something like a 
ResourceAccessSecurity
service in a extension bundle, I think we don't loose the goal of bringing Sling
forward to a frontend of resources from different providers than JCR without
any security built in (like MongoDB, file provider, bundle provider etc.) with 
this 
new setup. If we go down this road I propose the following:

Making a new bundle (extension) with a new service called 
ResourceAccessSecurity.
Taking the ResourceAccessGate interface out of the Sling API but keeping it as
a "access rule feeder" interface for the new ResourceAccessSecurity service.

I think this is a good compromise, but we should then integrate the use of 
this service in existing providers without any ACLs like FsResourceProvider and
BundleResourceProvider.

WDYT?

best regards
Mike



> -Original Message-
> From: ianbos...@gmail.com [mailto:ianbos...@gmail.com] On Behalf Of Ian
> Boston
> Sent: Friday, March 08, 2013 9:59 PM
> To: dev@sling.apache.org
> Subject: Re: [RT] Access Control in ResourceProviders
> 
> Hi,
> Should the ResourceAccessGate be a service or a utility helper class the
> ResourceProvider can instance and configure? I can imagine generalising
> path+principal+permission assertions as utility helper class leaving the
> ResourceProvider with to implement an interface to provided data to feed
> that class.
> 
> Either way, I think Felix's proposal makes sense, but as Carsten says we
> need to hear from Mike.
> 
> Ian
> 
> 
> On Friday, March 8, 2013, Carsten Ziegeler wrote:
> 
> > Hi,
> >
> > just to clarify, the ResourceProviderDecorator is not a proposal for
> > security - it's a proposal for extensibility. Feature's like the
> > ResourceAccessGate can be implemented with them - but I think the
> > decorator makes sense regardless of that.
> >
> > While I agree that resource providers should implement access control
> > on their own (or use the one from the underlying storage), I'm not
> > sure if that is feasible or efficient in all cases. If we go down this
> > road, we should add the usage of such a service to all our resource
> > providers (file, servlet, mongo) except jcr.
> > And if we would do this, we would need an additional service which
> > keeps track of all ResourceAccessGate's and has all the logic to
> > handle them implemented and can easily be used by a provider - so
> > basically most of the stuff from Mike which is now in the resource
> > resolver.
> >
> > I'm not against this, but I don't have a strong perference either - so
> > let's hear from Mike what he thinks :)
> >
> > Carsten
> >
> > 2013/3/8 Felix Meschberger >:
> > > Hi all
> > >
> > > There have been a number of threads and proposal flying around recently
> > in an attempt to make the Resource API more secure: It started with Mike's
> > ResourceAccessGate and currently is at Carsten's ResourceProviderDecorator.
> > >
> > > I would like to promote a third strategy:
> > >
> > > * ResourceProviders are expected to implement access control at their
> > own level. They do so in their own implementation or they leverage access
> > control support of the underlying data store (as the JCR ResourceProvider
> > does).
> > >
> > > * The ResourceAccessGate is a helper service for ResourceProviders to
> > implement access control if they wish to do so.
> > >
> > > WDYT ?
> > >
> > > Regards
> > > Felix
> > >
> > > --
> > > Felix Meschberger | Principal Scientist | Adobe
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > --
> > Carsten Ziegeler
> > cziege...@apache.org 
> >

RE: [RT] ResourceProviderDecorator

[Mike Müller]

> Sorry for asking a stupid question, but why would a ResourceProvider
> that delivered resources subject to security, not implement it  that
> security and cover the use cases required as a part of its
> implementation ?
> 
> 1 Allowing insecure ResourceProviders to exist with the intention of
> decorating them feels to be like a dangerous path to take. If they are
> used without decoration they become unsafe.
> 
> 2 If the use case is an additional layer of security ontop of a secure
> resource provider (eg a rules based ACL), then I can see that there
> might be a genuine need, but I have to ask why isn't the security part
> of the resource provider itself because its too easy to circumvent
> when resources are navigable.


The use case is different: We will (or should) have ResourceProviders for 
non ACL aware  storages like MongoDB, Cassandra (or like Bertrand 
mentioned SolR) etc. in the future. I don't think it would make sense to
implement ACLs or some other security mechanism in each of these
ResourceProviders. And not using them because they do not have a
ACL mechanism is maybe not the right way to go. Sling should not be 
only a JCR frontend in the future, that's why I think we should be able to
deal with this new sort of non ACL aware ResourceProviders and at this
point the ResourceProviderDecorator or ResourceAccessGate (or whatever)
comes in. It is not designed to be used as a ACL layer on top of JCR,
there we don't need it.

best regards
mike

RE: ResourceAccessGate (SLING-2698)

[Mike Müller]

> 2013/3/6 Mike Müller :
> >> Just to throw in some more ideas :) what about a decorator for
> >> resource providers? This would also solve the use case of easily
> >> adding additional checks to resource providers who don't have their
> >> own access checks without needing to code this into  each and every
> >> provider.
> >>
> >> And a ResourceProviderDecorator would work for me much better than a
> >> ResourceResolverDecorator :)
> >
> > A ResourceProviderDecorator couldn't do the job, because some operations
> > are on the ResourceResolver at the moment (delete, create but also 
> > findResources
> > and queryResources).
> 
> All of them are on the provider: ModifyingResourceProvider and
> QueriableResourceProvider.
> 
> The resolver just deletages.

Yes, I have overseen that, Carsten is right. We could do it with a 
ResourceProviderDecorator.
If we do that, we could implement a service param (or something else) in a way 
that's easy
To only decorate some providers. So someone can decorate for example only 
providers without
ACLs...

Best regards
mike

RE: ResourceAccessGate (SLING-2698)

[Mike Müller]

> On Wed, Mar 6, 2013 at 4:32 PM, Mike Müller  wrote:
> > ...A ResourceProviderDecorator couldn't do the job, because some operations
> > are on the ResourceResolver at the moment (delete, create but also 
> > findResources
> > and queryResources)
> 
> Does that indicate that those operations should be on the
> ResourceProvider instead?

I don't think so. If someone changes a resource it's not important from which
provider the resource is provided. In addition with the methods revert and 
commit
on the ResourceResolver we could implement transactionality over more than one
provider (even if I don't think we want to do that).

The idea here is: The ResourceResolver selects the appropriate ResourceProvider 
using resource path best match in the same way as done for the accessing 
(reading) 
the resources. Clients/users never interact with ResourceProviders directly -- 
they 
can't, since they don't know them.

This is from [1]

[1] http://markmail.org/message/yj4strsk5eva7erd

Best regards
mike

RE: ResourceAccessGate (SLING-2698)

[Mike Müller]

> Many modern stores do not provide any security, they're just "stupid"
> key-value or column stores.
> 
> How about being able to promote Sling + HBase as a scalable web
> framework, for example? How about Sling as web layer for Solr?
> 
> That would be very cool IMO, and if you want ACLs in such a setup you
> need to provide them yourself. That's where I'm in favor of extension
> points for ACLs - as long as those are disabled for the default
> JCR-based use case.

Yes, that's really where we should move to!
It's not about abandon the JCR, it's about to embrace other new providers...

RE: ResourceAccessGate (SLING-2698)

[Mike Müller]

> Just to throw in some more ideas :) what about a decorator for
> resource providers? This would also solve the use case of easily
> adding additional checks to resource providers who don't have their
> own access checks without needing to code this into  each and every
> provider.
> 
> And a ResourceProviderDecorator would work for me much better than a
> ResourceResolverDecorator :)

A ResourceProviderDecorator couldn't do the job, because some operations
are on the ResourceResolver at the moment (delete, create but also findResources
and queryResources).

Best regards
mike

RE: ResourceAccessGate (SLING-2698)

[Mike Müller]

There are to main arguments which are repeatedly mentioned:
First we should not duplicate ACLs in a Sling layer and the second
that users of Sling can misunderstand the new service or abuse it.

For the first argument: One thing which was never taken in account
is that Sling is not only a frontend for JCR (maybe in the old days this
was the case). Sling has different resource providers beside the JCR 
provider like providers for files, bundles, servlets, etc. These providers
come without any possibilities of restrictions. But we do provide them
as extension bundles (not contrib!). 
Think of a sling application with different providers installed, say all 
registered somewhere under /mypath/...
Now, how should it be easily managed to restrict access to all resources
Under /mypath/... to be accessed only by logged in users or even better
only from 8am to 5pm based on the time zone of the logged in user.
Is the answer today to write the resource providers for files, bundles, 
servlets, etc. yourself. The ResourceAccessGate service would be an
answer to that.
It's not about JCR-ACLs or ResourceAccessGate and it doesn't weak 
any existing security rules, that's definitely not true. It is also not about
having ACLs on different layers. It's just about to give an easy to use 
service to sling users which do not only rely on JCR alone or want to
define a rule over different providers at a single place. 

For the second argument I do not have much sympathy: Only because
some users could abuse or misunderstand the purpose of a specific 
service we should not stop to introduce reasonable new stuff. And as
a side note: I personally think the very powerful adaptable feature
(which I like) is much more abused than ResourceAccessGate ever could 
be...

I think it's time to see Sling not only as JCR frontend. Why beeing afraid
seeing Sling as what it is: as a frontend for different providers and therefore 
provide the tools to make that easy. I sometimes miss the declared intention
to win some new users (which are all potential commiters) for sling.

So whatever solution we can agree on for implementing ResourceAccessGate
service, it shouldn't be something which takes place in a contrib bundle.


Best regards
mike

RE: [VOTE] Apache Sling Launchpad Base 2.5.0 and Apache Sling Scripting Console 1.0.0

[Mike Müller]

+1
best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Wednesday, February 27, 2013 11:28 AM
> To: dev@sling.apache.org
> Subject: [VOTE] Apache Sling Launchpad Base 2.5.0 and Apache Sling Scripting
> Console 1.0.0
> 
> Hi,
> 
> this vote is about a long outstanding release of launchpad base and
> a new module, the scripting console
> 
> So please vote for:
> 
> Launchpad Base 2.5.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12321244
> 
> Scripting Console 1.0.0
> 
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-3.0.9/
> 
> 
> 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 3.0.9 /tmp/sling-staging
> 
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Carsten
> 
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Drop Java 5 Support in General

[Mike Müller]

+1
Best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Thursday, January 31, 2013 5:48 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Drop Java 5 Support in General
> 
> Hi,
> 
> we see more and more problems with supporting Java 5 and we discussed
> this several times in the past year(s?). So let's finally call a vote
> and see where we all are.
> 
> I propose to drop Java 5 support in general - we should try to stick
> to it where possible for supporting existing installations, but each
> module should be free to set the base to Java 6 if it makes sense.
> 
> We should also mark the bundles which require Java 6 (I think Felix
> proposed a way for this some time ago).
> 
> Please cast your votes :)
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Five New Releases

[Mike Müller]

+1
best regards
Mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Saturday, December 15, 2012 4:16 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Five New Releases
> 
> Hi,
> 
> This vote is about five new releases
> 
> Parent 14
> https://issues.apache.org/jira/browse/SLING/fixforversion/12322482
> 
> Security 1.0.2
> https://issues.apache.org/jira/browse/SLING/fixforversion/12319518
> 
> Resource Resolver 1.0.2
> https://issues.apache.org/jira/browse/SLING/fixforversion/12323495
> 
> JCR Resource 2.2.2
> https://issues.apache.org/jira/browse/SLING/fixforversion/12323490
> 
> Installer Core 3.4.4
> https://issues.apache.org/jira/browse/SLING/fixforversion/12323583
> 
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-020/
> 
> 
> 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 020 /tmp/sling-staging
> 
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> 
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] Release Sling Servlet Resolver 2.2.2

[Mike Müller]

+1
best regards
mike

> -Original Message-
> From: Felix Meschberger [mailto:fmesc...@adobe.com]
> Sent: Wednesday, December 05, 2012 3:17 PM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Sling Servlet Resolver 2.2.2
> 
> Hi
> 
> I would like to call a vote on the Sling Servlet Resolver 2.2.2 release.
> 
> We fixed this issue:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12323497
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-116/
> 
> 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 116 /tmp/sling-staging
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ]  0 Don't care
> [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Felix

RE: [VOTE] Release Commons OSGi, Settings, Rewriter, Launchpad Installer and Maven Launchpad Plugin

[Mike Müller]

+1
best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Friday, November 16, 2012 9:32 AM
> To: dev@sling.apache.org
> Subject: [VOTE] Release Commons OSGi, Settings, Rewriter, Launchpad Installer
> and Maven Launchpad Plugin
> 
> Hi,
> 
> This vote is about five new releases:
> 
> Commons OSGi 2.2.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12317581
> 
> Settings 1.2.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12319340
> 
> Rewriter 1.0.4
> https://issues.apache.org/jira/browse/SLING/fixforversion/12319475
> 
> Launchpad Installer 1.2.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12322943
> 
> Maven Launchpad Plugin 2.2.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12322951
> 
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-041/
> 
> 
> 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 041 /tmp/sling-staging
> 
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: [VOTE] New API and related bundles

[Mike Müller]

+1 
proved the signatures...

best regards
mike

> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Monday, November 12, 2012 11:27 AM
> To: dev@sling.apache.org
> Subject: [VOTE] New API and related bundles
> 
> Hi,
> 
> This vote is about ten modules in total which is basically the new
> API, its implementation and related/required updates:
> 
> Commons Testing 2.0.12
> https://issues.apache.org/jira/browse/SLING/fixforversion/12319556
> 
> API 2.3.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12319514
> 
> Resource Resolver 1.0.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12321758
> 
> JCR Resource 2.2.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12321286
> 
> Bundleresource 2.1.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12316088
> 
> File System Resource Provider 1.1.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12316089
> 
> Adapter 2.1.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12322441
> 
> Servlets Get 2.1.4
> https://issues.apache.org/jira/browse/SLING/fixforversion/12316181
> 
> Servlets Post 2.2.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12319641
> 
> Servlets Resolver 2.2.0
> https://issues.apache.org/jira/browse/SLING/fixforversion/12319517
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-037/
> 
> 
> 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 037 /tmp/sling-staging
> 
> 
> Please vote to approve this release:
> 
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
> 
> This vote will be open for 72 hours.
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziege...@apache.org

RE: Integration tests fail because of SLING-2645

[Mike Müller]

> as I wrote :) the OSGi commons classes are inlined, therefore there
> shouldn't be any need to update the hard-coded version of commons osgi
> in the test classes. In fact it shouldn't even be needed.
> I've just committed a fix which inlines the new class as well.
> 
> Regards
> Carsten

thanks Carsten, looked at the wrong thing... ;-)

best regards
mike


 
> 2012/11/2 Mike Müller :
> >> I haven't followed all the changes, but so far the installer did
> >> inline the classes from OSGi commons. Maybe this new class needs to be
> >> added to be inlined?
> >>
> >> Carsten
> >>
> >> 2012/11/2 Bertrand Delacretaz :
> >> > On Fri, Nov 2, 2012 at 11:21 AM, Mike Müller  wrote:
> >> >> ...Is this the right list.xml which will be used by the integration 
> >> >> tests from
> >> installer/it?...
> >> >
> >> > Of course not, but you didn't say you had failures in the *installer*
> >> > integration tests ;-)
> >> >
> >> > AFAIK the bundles that the installer/it tests use are defined in java
> >> > code, in [1] - that's probably where you need to make changes.
> >> >
> >> > -Bertrand
> >> >
> >> > [1]
> >>
> https://svn.apache.org/repos/asf/sling/trunk/installer/it/src/test/java/org/apache/sling/
> >> installer/it/OsgiInstallerTestBase.java
> >
> > I must have something missed. I found the part were the bundles are 
> > declared inline
> > in the OsgiInstallerTestBase (lines 385ff).
> > I added
> > mavenBundle("org.apache.felix", "org.apache.felix.eventadmin", "1.2.14"),
> > mavenBundle("org.apache.sling", "org.apache.sling.commons.osgi", "2.1.1-
> SNAPSHOT"),
> > but nevertheless the moved SortingServiceTracker is not found:
> >
> > Exception in thread "OsgiInstallerImpl" java.lang.NoClassDefFoundError:
> org/apache/sling/commons/osgi/SortingServiceTracker
> > 02.11.2012 17:02:07.072 *INFO* [FelixStartLevel] 
> > org.apache.sling.installer.core
> Service [Apache Sling Installer Controller Service,19] ServiceEvent REGISTERED
> > at java.lang.ClassLoader.defineClass1(Native Method)
> > at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
> > at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
> > at
> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findClass(ModuleImpl.java:
> 1793)
> > at
> org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.j
> ava:688)
> > at 
> > org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61)
> > at
> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java
> :1656)
> > at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> > 02.11.2012 17:02:07.072 *INFO* [FelixDispatchQueue]
> org.apache.sling.installer.core BundleEvent STARTED
> > at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.init(OsgiInstallerImpl.java:203)
> > at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:229)
> > at java.lang.Thread.run(Thread.java:662)
> > Caused by: java.lang.ClassNotFoundException:
> org.apache.sling.commons.osgi.SortingServiceTracker
> > at
> org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.j
> ava:744)
> > at 
> > org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61)
> > at
> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java
> :1656)
> > at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> > ... 11 more
> >
> > by the way: We should find a way were at least always the actual released 
> > version
> will be tested,
> > without the need that someone remembers that there are some hardcoded 
> > versions
> in some tests.
> > But maybe that's not that easy ;-)
> >
> > best regards
> > mike
> 
> 
> 
> --
> Carsten Ziegeler
> cziege...@apache.org