date:20191119

Hi Dan,

> On 19 Nov 2019, at 16:18, Daniel Klco  wrote:
> 
> I've seen issues with this in the wild. A client was attempting to link to
> external URLs containing colons (bad practice I know, but you get health
> care web services to get out of the 1990's) in a HTL script which was
> getting mangled even though the URL was not a JCR path.

Cough… I might have seen this problem last week… Cough...

> 
> My concern is that if this gets removed could the converse become a
> problem?

Anything can happen, but it doesn’t mean that the API should work like one of 
its implementations and the API definitely doesn’t mention anything about JCR 
namespaces.

> How would implementers know when to mangle the paths correctly

If you refer to developers trying to expose Resource paths as URLs, then they 
should ALWAYS use ResourceResolver#map, since this takes care of not only 
namespace mangling, but also of the mapping configurations. I obviously cannot 
be the one throwing the stone, since I could also be guilty of not using the 
correct mechanism to expose a URL for a Resource, but the API has been there 
for ages (the very beginning of Sling, so 10 years?!).

> and
> does this place the burden on the end developer to support this and thus
> potentially lead to errors in the implementation?
> 

I might be too young to have the context why this was needed, but I suspect 
it’s something related to some user agents not being able to cope with “:” in 
the path segment of the URI, although the latest RFC [3] definitely allows this 
and the browsers we use nowadays also have no issues any more. At this point 
I’d strongly argue that it’s not needed any more to do any kind of mangling.

Regards,
Radu

[3] - https://tools.ietf.org/html/rfc3986

RE: [org.apache.sling.xss] namespace mangling

2019-11-19 Thread Stefan Seifert

in my understanding the namespace mangling was only introduced in the olden 
days of sling to work around problems in some old browsers that did not support 
URLs with colons in it. i think those old browsers are no longer in use for 
many, many years. so i assume it is no problem to not mangle the URLs nowadays, 
and +1 to remove the mangling from the XSS handling.

stefan

>-Original Message-
>From: Radu Cotescu [mailto:r...@apache.org]
>Sent: Tuesday, November 19, 2019 4:02 PM
>To: Sling Dev
>Subject: [org.apache.sling.xss] namespace mangling
>
>Hi,
>
>From the very beginning the org.apache.sling.xss code was donated to Sling
>it provided an implementation of the XSSAPI.getValidHref that mangles JCR
>namespaces from the passed URLs (let’s not comment on the naming). However,
>the code that does this has no information about the registered namespaces
>that one can see when accessing the "/system/console/status-
>JCR%20Namespaces” console and, instead, works with patterns. Brittle, I
>know.
>
>Now, if we check the ResourceResolver API, specifically the
>org.apache.sling.api.resource.ResourceResolver#map(java.lang.String) method
>[0], we see that namespace mangling should be performed here [1].
>
>In my opinion we should completely remove the mangling functionality from
>the XSS implementation, since it’s the caller’s responsibility to provide a
>correct request path. We cannot assume all URLs passed to the
>XSSAPI.getValidHref are JCR paths and I wouldn’t like to add more context
>in the implementation.
>
>Are there different opinions? I’d like to consult the dev list before
>opening an issue and removing the code in question [2].
>
>Thanks,
>Radu
>
>
>[0] - https://github.com/apache/sling-org-apache-sling-
>api/blob/11bf3603155af21201b0fced2c6968d2223254b9/src/main/java/org/apache/
>sling/api/resource/ResourceResolver.java#L294
>api/blob/11bf3603155af21201b0fced2c6968d2223254b9/src/main/java/org/apache/
>sling/api/resource/ResourceResolver.java#L294>
>[1] - https://sling.apache.org/documentation/the-sling-engine/mappings-for-
>resource-resolution.html#namespace-mangling
>resource-resolution.html#namespace-mangling>
>[2] - https://github.com/apache/sling-org-apache-sling-
>xss/blob/8ec9cf33080fbbb70dc6a51dea92533946295db8/src/main/java/org/apache/
>sling/xss/impl/XSSAPIImpl.java#L194 apache-sling-
>xss/blob/master/src/main/java/org/apache/sling/xss/impl/XSSAPIImpl.java#L19
>4>

Re: [org.apache.sling.xss] namespace mangling

2019-11-19 Thread Daniel Klco

I've seen issues with this in the wild. A client was attempting to link to
external URLs containing colons (bad practice I know, but you get health
care web services to get out of the 1990's) in a HTL script which was
getting mangled even though the URL was not a JCR path.

My concern is that if this gets removed could the converse become a
problem? How would implementers know when to mangle the paths correctly and
does this place the burden on the end developer to support this and thus
potentially lead to errors in the implementation?

Regards,
Dan

On Tue, Nov 19, 2019 at 10:01 AM Radu Cotescu  wrote:

> Hi,
>
> From the very beginning the org.apache.sling.xss code was donated to Sling
> it provided an implementation of the XSSAPI.getValidHref that mangles JCR
> namespaces from the passed URLs (let’s not comment on the naming). However,
> the code that does this has no information about the registered namespaces
> that one can see when accessing the
> "/system/console/status-JCR%20Namespaces” console and, instead, works with
> patterns. Brittle, I know.
>
> Now, if we check the ResourceResolver API, specifically the
> org.apache.sling.api.resource.ResourceResolver#map(java.lang.String) method
> [0], we see that namespace mangling should be performed here [1].
>
> In my opinion we should completely remove the mangling functionality from
> the XSS implementation, since it’s the caller’s responsibility to provide a
> correct request path. We cannot assume all URLs passed to the
> XSSAPI.getValidHref are JCR paths and I wouldn’t like to add more context
> in the implementation.
>
> Are there different opinions? I’d like to consult the dev list before
> opening an issue and removing the code in question [2].
>
> Thanks,
> Radu
>
>
> [0] -
> https://github.com/apache/sling-org-apache-sling-api/blob/11bf3603155af21201b0fced2c6968d2223254b9/src/main/java/org/apache/sling/api/resource/ResourceResolver.java#L294
> <
> https://github.com/apache/sling-org-apache-sling-api/blob/11bf3603155af21201b0fced2c6968d2223254b9/src/main/java/org/apache/sling/api/resource/ResourceResolver.java#L294
> >
> [1] -
> https://sling.apache.org/documentation/the-sling-engine/mappings-for-resource-resolution.html#namespace-mangling
> <
> https://sling.apache.org/documentation/the-sling-engine/mappings-for-resource-resolution.html#namespace-mangling
> >
> [2] -
> https://github.com/apache/sling-org-apache-sling-xss/blob/8ec9cf33080fbbb70dc6a51dea92533946295db8/src/main/java/org/apache/sling/xss/impl/XSSAPIImpl.java#L194
> <
> https://github.com/apache/sling-org-apache-sling-xss/blob/master/src/main/java/org/apache/sling/xss/impl/XSSAPIImpl.java#L194
> >

[org.apache.sling.xss] namespace mangling

Hi,

From the very beginning the org.apache.sling.xss code was donated to Sling it
provided an implementation of the XSSAPI.getValidHref that mangles JCR
namespaces from the passed URLs (let’s not comment on the naming). However, the
code that does this has no information about the registered namespaces that one
can see when accessing the "/system/console/status-JCR%20Namespaces” console
and, instead, works with patterns. Brittle, I know.

Now, if we check the ResourceResolver API, specifically the
org.apache.sling.api.resource.ResourceResolver#map(java.lang.String) method
[0], we see that namespace mangling should be performed here [1].

In my opinion we should completely remove the mangling functionality from the
XSS implementation, since it’s the caller’s responsibility to provide a correct
request path. We cannot assume all URLs passed to the XSSAPI.getValidHref are
JCR paths and I wouldn’t like to add more context in the implementation.

Are there different opinions? I’d like to consult the dev list before opening
an issue and removing the code in question [2].

Thanks,
Radu

[0] -
https://github.com/apache/sling-org-apache-sling-api/blob/11bf3603155af21201b0fced2c6968d2223254b9/src/main/java/org/apache/sling/api/resource/ResourceResolver.java#L294

[1] -
https://sling.apache.org/documentation/the-sling-engine/mappings-for-resource-resolution.html#namespace-mangling

[2] -
https://github.com/apache/sling-org-apache-sling-xss/blob/8ec9cf33080fbbb70dc6a51dea92533946295db8/src/main/java/org/apache/sling/xss/impl/XSSAPIImpl.java#L194

Re: Sling FM Starter Module

On Tue, 2019-11-19 at 06:47 -0800, Ruben Reusser wrote:
> Robert,
> 
> would we not want each module to produce it's own feature file and
> then 
> have an aggregation somewhere?

Depends on what you define as a module. I see multiple options here:

1. A bundle produces its own feature file.

For instance, slingshot - single bundle, single feature file.

2. A set of bundles define their own feature file in a shared project

This would be for example composum, defining all bundles + configs they
need to start up in the Composum project. Then we import it in the
application we are running.

3. A set of bundles are included in a feature file of the application
project.

This would be the Sling starter defining its own feature files and
including e.g. composum Sling scripting bundles + configs in its own
repository.

Which is the one under discussion?

Robert

> 
> Ruben
> 
> On 11/19/2019 6:41 AM, Robert Munteanu wrote:
> > On Fri, 2019-11-15 at 11:47 -0800, Andreas Schaefer wrote:
> > > Hi
> > > 
> > > I started to get the pieces into place for a build up of
> > > Peregrine
> > > CMS based on Sling 11 using FMs.
> > > 
> > > First I updated the Sling Feature Converter Maven Plugin to
> > > install
> > > the generated slingosgifeature into my local Maven repo and then
> > > use
> > > these dependencies to assemble and launch Peregrine. This works
> > > fine
> > > for most parts (content does not deploy but that is another
> > > story).
> > > 
> > > Next step is to install FMs from Bundles into the local Maven
> > > repo
> > > which will be used for bundles or content bundles like Sling.
> > > 
> > > My question is: is it expected for the developer to write its own
> > > slingosgiffeature file or is there a way to generate that from a
> > > POM
> > > ?
> > Do you want to generate feature files for individual bundles? I
> > would
> > expect that you have a feature file that groups related bundles
> > together, similar to what we do with the provisioning model.
> > 
> > Robert
> > 
> > > As far as I can see the Sling Feature Maven Plugin does not
> > > provide
> > > that.
> > > 
> > > Cheers - Andy
> > > 
> > > > On Nov 11, 2019, at 2:11 AM, Robert Munteanu <
> > > > romb...@apache.org>
> > > > wrote:
> > > > 
> > > > Hi Andreas,
> > > > 
> > > > On Fri, 2019-11-08 at 09:51 -0800, Andreas Schaefer wrote:
> > > > > Hi
> > > > > 
> > > > > I am wondering how a Sling FM Starter Module would look like
> > > > > and
> > > > > how
> > > > > it is used by clients like Peregrine.
> > > > > 
> > > > > It is my assumption that any FM slingosgifeature project will
> > > > > install
> > > > > that file on release on a public Maven repository like all of
> > > > > our
> > > > > Sling Module.
> > > > > 
> > > > > Then the Sling FM Starter Module will select the appropriate
> > > > > slingosgifeature files and assemble it into a Sling release
> > > > > slingosgifeature which is then also installed on a public
> > > > > Maven
> > > > > repo.
> > > > > This enables anyone to build the latest Sling instance w/o
> > > > > having
> > > > > any
> > > > > other Sling Module checked out / built like right now it is
> > > > > done
> > > > > in
> > > > > PM based Sling Starter.
> > > > > 
> > > > > A customer will then do the same by taking the Sling
> > > > > slingosgifeature
> > > > > file and assembly it with their own project and external
> > > > > projects
> > > > > slingosgifeature files to build the final Sling / Customer
> > > > > instance.
> > > > Overall that sounds reasonable to me. The only note that I want
> > > > to
> > > > make
> > > > is that since we are doing releases at best once per year,
> > > > downstream
> > > > projects would either need to depend on SNAPSHOT versions of
> > > > the
> > > > Sling
> > > > Starter, or depend on older versions.
> > > > 
> > > > Thanks,
> > > > Robert
> > > >

Re: Sling FM Starter Module

2019-11-19 Thread Ruben Reusser


Robert,

would we not want each module to produce it's own feature file and then 
have an aggregation somewhere?


Ruben

On 11/19/2019 6:41 AM, Robert Munteanu wrote:

On Fri, 2019-11-15 at 11:47 -0800, Andreas Schaefer wrote:

Hi

I started to get the pieces into place for a build up of Peregrine
CMS based on Sling 11 using FMs.

First I updated the Sling Feature Converter Maven Plugin to install
the generated slingosgifeature into my local Maven repo and then use
these dependencies to assemble and launch Peregrine. This works fine
for most parts (content does not deploy but that is another story).

Next step is to install FMs from Bundles into the local Maven repo
which will be used for bundles or content bundles like Sling.

My question is: is it expected for the developer to write its own
slingosgiffeature file or is there a way to generate that from a POM
?

Do you want to generate feature files for individual bundles? I would
expect that you have a feature file that groups related bundles
together, similar to what we do with the provisioning model.

Robert


As far as I can see the Sling Feature Maven Plugin does not provide
that.

Cheers - Andy


On Nov 11, 2019, at 2:11 AM, Robert Munteanu 
wrote:

Hi Andreas,

On Fri, 2019-11-08 at 09:51 -0800, Andreas Schaefer wrote:

Hi

I am wondering how a Sling FM Starter Module would look like and
how
it is used by clients like Peregrine.

It is my assumption that any FM slingosgifeature project will
install
that file on release on a public Maven repository like all of our
Sling Module.

Then the Sling FM Starter Module will select the appropriate
slingosgifeature files and assemble it into a Sling release
slingosgifeature which is then also installed on a public Maven
repo.
This enables anyone to build the latest Sling instance w/o having
any
other Sling Module checked out / built like right now it is done
in
PM based Sling Starter.

A customer will then do the same by taking the Sling
slingosgifeature
file and assembly it with their own project and external projects
slingosgifeature files to build the final Sling / Customer
instance.

Overall that sounds reasonable to me. The only note that I want to
make
is that since we are doing releases at best once per year,
downstream
projects would either need to depend on SNAPSHOT versions of the
Sling
Starter, or depend on older versions.

Thanks,
Robert

Re: Sling FM Starter Module

On Fri, 2019-11-15 at 11:47 -0800, Andreas Schaefer wrote:
> Hi
> 
> I started to get the pieces into place for a build up of Peregrine
> CMS based on Sling 11 using FMs.
> 
> First I updated the Sling Feature Converter Maven Plugin to install
> the generated slingosgifeature into my local Maven repo and then use
> these dependencies to assemble and launch Peregrine. This works fine
> for most parts (content does not deploy but that is another story).
> 
> Next step is to install FMs from Bundles into the local Maven repo
> which will be used for bundles or content bundles like Sling.
> 
> My question is: is it expected for the developer to write its own
> slingosgiffeature file or is there a way to generate that from a POM
> ?

Do you want to generate feature files for individual bundles? I would
expect that you have a feature file that groups related bundles
together, similar to what we do with the provisioning model.

Robert

> 
> As far as I can see the Sling Feature Maven Plugin does not provide
> that.
> 
> Cheers - Andy
> 
> > On Nov 11, 2019, at 2:11 AM, Robert Munteanu 
> > wrote:
> > 
> > Hi Andreas,
> > 
> > On Fri, 2019-11-08 at 09:51 -0800, Andreas Schaefer wrote:
> > > Hi
> > > 
> > > I am wondering how a Sling FM Starter Module would look like and
> > > how
> > > it is used by clients like Peregrine.
> > > 
> > > It is my assumption that any FM slingosgifeature project will
> > > install
> > > that file on release on a public Maven repository like all of our
> > > Sling Module.
> > > 
> > > Then the Sling FM Starter Module will select the appropriate
> > > slingosgifeature files and assemble it into a Sling release
> > > slingosgifeature which is then also installed on a public Maven
> > > repo.
> > > This enables anyone to build the latest Sling instance w/o having
> > > any
> > > other Sling Module checked out / built like right now it is done
> > > in
> > > PM based Sling Starter.
> > > 
> > > A customer will then do the same by taking the Sling
> > > slingosgifeature
> > > file and assembly it with their own project and external projects
> > > slingosgifeature files to build the final Sling / Customer
> > > instance.
> > 
> > Overall that sounds reasonable to me. The only note that I want to
> > make
> > is that since we are doing releases at best once per year,
> > downstream
> > projects would either need to depend on SNAPSHOT versions of the
> > Sling
> > Starter, or depend on older versions.
> > 
> > Thanks,
> > Robert
> >

Re: [VOTE] Release Apache Sling CMS 0.14.0

On Tue, 2019-11-19 at 12:58 +, Dan Klco wrote:
> Please vote to approve this release:

+1
Robert


signature.asc
Description: This is a digitally signed message part

Re: [VOTE] Release Apache Sling XSS Protection API 2.1.16

2019-11-19 Thread Daniel Klco

+1

On Tue, Nov 19, 2019 at 7:08 AM Robert Munteanu  wrote:

> On Mon, 2019-11-18 at 14:16 +, Radu Cotescu wrote:
> > Please vote to approve this release:
>
> +1
>
> Robert
>
>

[VOTE] Release Apache Sling CMS 0.14.0

2019-11-19 Thread Dan Klco

Hi,

We solved 14 issues in this release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12345614

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

You can use this UNIX script to download the release and verify the signatures:
https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD

Usage:
sh check_staged_release.sh 2159 /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,
Dan Klco

[Jenkins] Sling » sling-org-apache-sling-launchpad-testing » master #402 is FIXED

2019-11-19 Thread Apache Jenkins Server

Please see 
https://builds.apache.org/job/Sling/job/sling-org-apache-sling-launchpad-testing/job/master/402/
 for details.

No further emails will be sent until the status of the build is changed.

[Jenkins] Sling » sling-org-apache-sling-launchpad-testing » master #401 is BROKEN

2019-11-19 Thread Apache Jenkins Server

Please see 
https://builds.apache.org/job/Sling/job/sling-org-apache-sling-launchpad-testing/job/master/401/
 for details.

No further emails will be sent until the status of the build is changed.
Build log follows below:

[...truncated 5476 lines...]
https://sling.apache.org/project-information.html#mailing-lists; 
target="_blank" rel="noopener" 
   title="View available Apache Sling mailing 
lists">Mailing Lists
https://sling.apache.org/documentation/tutorials-how-tos.html; 
target="_blank" rel="noopener" 
   title="View Apache Sling Developer 
Tutorials">Tutorials
https://github.com/apache?utf8=%E2%9C%93=sling-=source; 
target="_blank" rel="noopener" 
   title="View the Apache Sling source code on 
Github">Source Code
https://github.com/apache/sling-samples; 
target="_blank" rel="noopener" 
   title="View Apache Sling sample applications on 
Github">Sample Applications






]
at 
org.apache.sling.launchpad.webapp.integrationtest.RequestAttributeTest.setUp(RequestAttributeTest.java:59)

[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.VersionInfoServletTest
[DEBUG] [ServiceReference 149 from bundle 59 : 
org.apache.sling.launchpad.test-services:12.0.0.SNAPSHOT 
ref=[javax.servlet.Servlet] properties={component.id=52, 
component.name=org.apache.sling.launchpad.testservices.servlets.R6WhiteboardServlet,
 objectClass=[javax.servlet.Servlet], 
osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=org.apache.sling),
 osgi.http.whiteboard.servlet.pattern=/whiteboard_r6, service.bundleid=59, 
service.id=149, 
service.pid=org.apache.sling.launchpad.testservices.servlets.R6WhiteboardServlet,
 service.scope=bundle, service.vendor=The Apache Software Foundation}] Ignoring 
unmatching Servlet service
[DEBUG] [ServiceReference 357 from bundle 143 : org.apache.sling.engine:2.6.20 
ref=[javax.servlet.Servlet] properties={component.id=250, 
component.name=org.apache.sling.engine.impl.SlingMainServlet, 
objectClass=[javax.servlet.Servlet], 
osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=org.apache.sling),
 osgi.http.whiteboard.servlet.pattern=/, service.bundleid=143, 
service.description=Apache Sling Engine Main Servlet, service.id=357, 
service.scope=singleton, service.vendor=The Apache Software Foundation, 
servlet-name=ApacheSling/2.6, 
sling.additional.response.headers=[Ljava.lang.String;@51d9a3be, 
sling.max.calls=1000, sling.max.inclusions=50, sling.max.record.requests=20, 
sling.trace.allow=false}] Ignoring unmatching Servlet service
[DEBUG] [ServiceReference 375 from bundle 143 : org.apache.sling.engine:2.6.20 
ref=[javax.servlet.Filter] properties={component.id=255, 
component.name=org.apache.sling.engine.parameters, file.max=-1, 
file.threshold=256000, objectClass=[javax.servlet.Filter], 
osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=org.apache.sling),
 osgi.http.whiteboard.filter.pattern=/, request.max=-1, service.bundleid=143, 
service.id=375, service.ranking=2147483647, service.scope=bundle, 
sling.default.max.parameters=1, 
sling.default.parameter.checkForAdditionalContainerParameters=false, 
sling.default.parameter.encoding=ISO-8859-1}] Ignoring unmatching Filter service
[DEBUG] [ServiceReference 588 from bundle 143 : org.apache.sling.engine:2.6.20 
ref=[javax.servlet.Filter] properties={component.id=254, 
component.name=org.apache.sling.engine.impl.log.RequestLoggerFilter, 
objectClass=[javax.servlet.Filter], 
osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=org.apache.sling),
 osgi.http.whiteboard.filter.pattern=/, service.bundleid=143, 
service.description=Request Logger Filter, service.id=588, 
service.ranking=32768, service.scope=bundle, service.vendor=The Apache Software 
Foundation}] Ignoring unmatching Filter service
[INFO] Apachde Felix Http Whiteboard Service stopped
[DEBUG] [ServiceReference 1154 from bundle 38 : 
org.apache.felix.healthcheck.core:2.0.6 ref=[javax.servlet.Servlet] 
properties={objectClass=[javax.servlet.Servlet], 
osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name=internal.http.serviceunavailablefilter),
 osgi.http.whiteboard.servlet.pattern=/, service.bundleid=38, service.id=1154, 
service.ranking=0, service.scope=singleton}] Ignoring unmatching Servlet service
[INFO] Stopped Jetty.
[ERROR] Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 3.82 s 
<<< FAILURE! - in 
org.apache.sling.launchpad.webapp.integrationtest.VersionInfoServletTest
[ERROR] 
testDisabledServlet(org.apache.sling.launchpad.webapp.integrationtest.VersionInfoServletTest)
  Time elapsed: 3.813 s  <<< ERROR!
java.net.ConnectException: Connection refused (Connection refused)
at

Re: [VOTE] Release Apache Sling API 2.21.0

On Mon, 2019-11-18 at 16:44 +, Radu Cotescu wrote:
> Please vote to approve this release:

+1

Robert


signature.asc
Description: This is a digitally signed message part

Re: [VOTE] Release Apache Sling XSS Protection API 2.1.16

On Mon, 2019-11-18 at 14:16 +, Radu Cotescu wrote:
> Please vote to approve this release:

+1

Robert

Re: [VOTE] Release Apache Sling XSS Protection API 2.1.12

On Tue, 2019-11-19 at 11:13 +0100, Radu Cotescu wrote:
> some of the dependencies’ classes used
> APIs not available in the JRE, but provided by Sling and this made
> the build fail on Java 8

Ah, that was the missing piece for me. All clear now, thank you.

Robert

Re: [VOTE] Release Apache Sling XSS Protection API 2.1.12

Hi Konrad,

> On 19 Nov 2019, at 11:30, Konrad Windszus  wrote:
> 
> This is not exactly true. Maybe you can use the 
> https://bnd.bndtools.org/instructions/conditionalpackage.html 
>  
>  > instruction? 
> That can be used for embedding with bnd-maven-plugin.

TIL! It’s funny how the wording on that page completely avoids the word embed.

I’m not sure I want to touch the configs again, now that I finally made them 
work. I would probably just have to move the list of private packages that we 
have now into this -conditionalpackage instruction, but I’m afraid to do it 
given the complexity of this bundle in particular. Problem for future Radu or 
another Sling committer. :D

Thanks for the pointer, though!

Regards,
Radu

RE: [VOTE] Release Apache Sling API 2.21.0

2019-11-19 Thread Stefan Seifert

+1

RE: [VOTE] Release Apache Sling XSS Protection API 2.1.16

2019-11-19 Thread Stefan Seifert

+1

Re: [VOTE] Release Apache Sling XSS Protection API 2.1.12

2019-11-19 Thread Konrad Windszus

Hi Radu,
regarding

> 
> the bnd-maven-plugin doesn’t provide an embed / inline feature. 
This is not exactly true. Maybe you can use the 
https://bnd.bndtools.org/instructions/conditionalpackage.html 
 instruction? 
That can be used for embedding with bnd-maven-plugin.
Thanks,
Konrad

Re: [VOTE] Release Apache Sling XSS Protection API 2.1.12

Hi Robert,

> On 19 Nov 2019, at 10:22, Robert Munteanu  wrote:
> 
> Sorry for the late reply. I'm not sure I follow. If you inline classes
> that require Java 11, doesn't the bundle effectively require Java 11?

We haven’t inlined classes that require Java 11 APIs.

Let me try to describe again what the issue was. Before switching to building 
the bundle with the bnd-maven-plugin, some of the project’s dependencies were 
embedded and inlined with the maven-bundle-plugin. The animal sniffer plugin’s 
job, though, was to make sure that the project’s classes don’t use APIs not 
available on the target JRE.

With the switch to the sling-bundle-parent, we don’t use the 
maven-bundle-plugin any more and the bnd-maven-plugin doesn’t provide an embed 
/ inline feature. So I delegated this to the maven-dependency-plugin for 
unpacking the “to embed” dependencies into ${project.build.outputDirectory} and 
the default maven-jar-plugin for packing. However, I was running the 
maven-dependency-plugin in the generate-resources phase. The sniffer plugin 
runs its checks in the process-classes phase by default. That led to the 
sniffer plugin checking also the dependencies’ classes (on Java 8 only; it’s 
disabled on Java 11 since the javac does the same checks better). However, like 
you noticed, some of the dependencies’ classes used APIs not available in the 
JRE, but provided by Sling and this made the build fail on Java 8. By default, 
the animal sniffer plugin doesn’t check dependencies. Even if the build failed 
with Java 8, the same module built with Java 11 will run without any issues on 
JRE 1.8, since that’s the target platform.

In version 2.1.16 I’ve corrected how the dependencies are inlined and, when 
building with Java 8, the animal sniffer plugin will only check the project’s 
source code, like before.

Cheers,
Radu

[jira] [Closed] (SLING-8798) AclLine.getRestrictions should not return null



 [ 
https://issues.apache.org/jira/browse/SLING-8798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu closed SLING-8798.
--

> AclLine.getRestrictions should not return null
> --
>
> Key: SLING-8798
> URL: https://issues.apache.org/jira/browse/SLING-8798
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Reporter: Angela Schreiber
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Repoinit Parser 1.3.2
>
> Attachments: SLING-8798.patch
>
>
> while trying to add nullable/notnull annotations in _sling-jcr-repoinit_ to 
> improve overall readability and maintainability of the code base, i noticed 
> that {{AclLine.getRestrictions}} may return null. I would recommend to change 
> this to be consistent with {{AclLine.getProperty}}, which returns an empty 
> list in case no values exist for a given property name.
> Proposed patch attached (including replacing a private static final 
> EMPTY_LIST field by {{Collections.emptyList}}, which afaik is also defined to 
> be immutable.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (SLING-8740) The repoinit IT is flaky



 [ 
https://issues.apache.org/jira/browse/SLING-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu closed SLING-8740.
--

> The repoinit IT is flaky
> 
>
> Key: SLING-8740
> URL: https://issues.apache.org/jira/browse/SLING-8740
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.14
>Reporter: Radu Cotescu
>Assignee: Bertrand Delacretaz
>Priority: Major
> Fix For: Repoinit JCR 1.1.16
>
>
> The repoinit IT are flaky, consistently failing on Jenkins [0][1][2][3][4] 
> but only occasionally on my machine:
> {noformat}
> Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 45.993 sec 
> <<< FAILURE! - in org.apache.sling.jcr.repoinit.it.ProvisioningModelIT
> namespaceAndCndRegistered(org.apache.sling.jcr.repoinit.it.ProvisioningModelIT)
>   Time elapsed: 14.793 sec  <<< ERROR!
> java.lang.IllegalStateException: unable to get a service reference, 
> class=org.apache.sling.jcr.api.SlingRepository, filter='null'
>   at 
> org.apache.sling.junit.rules.ServerSideTeleporter.getService(ServerSideTeleporter.java:83)
>   at 
> org.apache.sling.junit.rules.TeleporterRule.getService(TeleporterRule.java:136)
>   at 
> org.apache.sling.jcr.repoinit.it.ProvisioningModelIT.setup(ProvisioningModelIT.java:48)
> userDisabled(org.apache.sling.jcr.repoinit.it.ProvisioningModelIT)  Time 
> elapsed: 10.826 sec  <<< ERROR!
> java.lang.IllegalStateException: unable to get a service reference, 
> class=org.apache.sling.jcr.api.SlingRepository, filter='null'
>   at 
> org.apache.sling.junit.rules.ServerSideTeleporter.getService(ServerSideTeleporter.java:83)
>   at 
> org.apache.sling.junit.rules.TeleporterRule.getService(TeleporterRule.java:136)
>   at 
> org.apache.sling.jcr.repoinit.it.ProvisioningModelIT.setup(ProvisioningModelIT.java:48)
> usersCreated(org.apache.sling.jcr.repoinit.it.ProvisioningModelIT)  Time 
> elapsed: 10.156 sec  <<< ERROR!
> java.lang.IllegalStateException: unable to get a service reference, 
> class=org.apache.sling.jcr.api.SlingRepository, filter='null'
>   at 
> org.apache.sling.junit.rules.ServerSideTeleporter.getService(ServerSideTeleporter.java:83)
>   at 
> org.apache.sling.junit.rules.TeleporterRule.getService(TeleporterRule.java:136)
>   at 
> org.apache.sling.jcr.repoinit.it.ProvisioningModelIT.setup(ProvisioningModelIT.java:48)
> userAclSet(org.apache.sling.jcr.repoinit.it.ProvisioningModelIT)  Time 
> elapsed: 10.166 sec  <<< ERROR!
> java.lang.IllegalStateException: unable to get a service reference, 
> class=org.apache.sling.jcr.api.SlingRepository, filter='null'
>   at 
> org.apache.sling.junit.rules.ServerSideTeleporter.getService(ServerSideTeleporter.java:83)
>   at 
> org.apache.sling.junit.rules.TeleporterRule.getService(TeleporterRule.java:136)
>   at 
> org.apache.sling.jcr.repoinit.it.ProvisioningModelIT.setup(ProvisioningModelIT.java:48)
> Running org.apache.sling.jcr.repoinit.it.RepoInitTextIT
> Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 30.593 sec 
> <<< FAILURE! - in org.apache.sling.jcr.repoinit.it.RepoInitTextIT
> anotherUserAcl(org.apache.sling.jcr.repoinit.it.RepoInitTextIT)  Time 
> elapsed: 10.198 sec  <<< ERROR!
> java.lang.IllegalStateException: unable to get a service reference, 
> class=org.apache.sling.jcr.api.SlingRepository, filter='null'
>   at 
> org.apache.sling.junit.rules.ServerSideTeleporter.getService(ServerSideTeleporter.java:83)
>   at 
> org.apache.sling.junit.rules.TeleporterRule.getService(TeleporterRule.java:136)
>   at 
> org.apache.sling.jcr.repoinit.it.RepoInitTextIT.setup(RepoInitTextIT.java:55)
> fredWilmaAcl(org.apache.sling.jcr.repoinit.it.RepoInitTextIT)  Time elapsed: 
> 10.212 sec  <<< ERROR!
> java.lang.IllegalStateException: unable to get a service reference, 
> class=org.apache.sling.jcr.api.SlingRepository, filter='null'
>   at 
> org.apache.sling.junit.rules.ServerSideTeleporter.getService(ServerSideTeleporter.java:83)
>   at 
> org.apache.sling.junit.rules.TeleporterRule.getService(TeleporterRule.java:136)
>   at 
> org.apache.sling.jcr.repoinit.it.RepoInitTextIT.setup(RepoInitTextIT.java:55)
> serviceUserCreated(org.apache.sling.jcr.repoinit.it.RepoInitTextIT)  Time 
> elapsed: 10.182 sec  <<< ERROR!
> java.lang.IllegalStateException: unable to get a service reference, 
> class=org.apache.sling.jcr.api.SlingRepository, filter='null'
>   at 
> org.apache.sling.junit.rules.ServerSideTeleporter.getService(ServerSideTeleporter.java:83)
>   at 
> org.apache.sling.junit.rules.TeleporterRule.getService(TeleporterRule.java:136)
>   at 
> org.apache.sling.jcr.repoinit.it.RepoInitTextIT.setup(RepoInitTextIT.java:55)
> Results :
> Tests in error: 
>   ProvisioningModelIT.setup:48 »

[jira] [Closed] (SLING-8766) AclVisitor.setPrincipalAcl: be more lenient with unsupported principals



 [ 
https://issues.apache.org/jira/browse/SLING-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu closed SLING-8766.
--

> AclVisitor.setPrincipalAcl: be more lenient with unsupported principals 
> 
>
> Key: SLING-8766
> URL: https://issues.apache.org/jira/browse/SLING-8766
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Reporter: Angela Schreiber
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Repoinit JCR 1.1.16
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> i noticed the following potential for improvement with 
> {{AclVisitor.setPrincipalAcl}} when testing it in an AEM upgrade scenario. 
> due to the fact that repo-init doesn't verify the _intermedidatePath_ when a 
> user/group to be created already exists but happens to be located at the 
> different subtree, {{AclVisitor.setPrincipalAcl}} may fail upon upgrade _if_ 
> the existing principal turns out to be not supported. this happens 
> irrespective of the fact that the repo init statements were perfectly fine if 
> run initially.
> example with filter configured with supported path 
> _/home/users/system/principalbased_
> {code}
> create service user foo with path system/principalbased
> set principal ACL for foo
> allow jcr:read,rep:write on /content
> end
> {code}
> if 'foo' already existed at _/home/users/system/elsewhere_ the repo init code 
> does not make an attempt to move 'foo' to the new location and is fine with 
> 'foo' existing. however, the ac-setup will fail.
> i would suggest to improve this by log.INFO that no 
> {{PrincipalAccessControlList}} can be found instead of throwing 
> {{IllegalStateException}}. In the subsequent access control setup verify if 
> an equivalent effective {{AccessControlEntry}} is present and only throw the 
> exception if no such entry exists, meaning that the effective access control 
> setup resulting from repo-init is incomplete.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (SLING-8778) Missing tests for user/group creation with absolute path



 [ 
https://issues.apache.org/jira/browse/SLING-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Munteanu closed SLING-8778.
--

> Missing tests for user/group creation with absolute path
> 
>
> Key: SLING-8778
> URL: https://issues.apache.org/jira/browse/SLING-8778
> Project: Sling
>  Issue Type: Test
>  Components: Repoinit
>Reporter: Angela Schreiber
>Assignee: Robert Munteanu
>Priority: Minor
> Fix For: Repoinit JCR 1.1.16
>
> Attachments: SLING-8778.patch
>
>
> the jcr repo init implementation currently provides tests for user/group 
> creation without extra path and with a relative path. attached patch 
> additionally provides tests for creation with an absolute path.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[RESULT] [VOTE] Release Apache Sling Repoinit Parser 1.3.2, Apache Sling Repoinit JCR 1.1.16

Hi,

The vote has passed with the following result:

+1 (binding): Robert Munteanu, Radu Cotescu, Dan Klco, Bertrand
Delacretaz, Timothée Maret
+1 (non-binding): Andreas Schaefer

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

Regards,
Robert Munteanu

Re: [VOTE] Release Apache Sling XSS Protection API 2.1.12