[jira] [Updated] (SLING-12124) Inconsistent handling of emtpy selectors
[ https://issues.apache.org/jira/browse/SLING-12124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sagar Miglani updated SLING-12124: -- Description: In accordance with the code found [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], empty selectors are explicitly disallowed. However, the [parsing of selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] is making request with all empty selector as valid. i.e: Requests will empty selectors like: "/test/resource/path..a...html" are invalid While requests with all empty selectos "/test/resource/path.html" are valid Which indicates an inconsistent behaviour. Attached tests to demonstrate the same ([^inconsistent_empty_selectors.patch]) was: In accordance with the code found [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], empty selectors are explicitly disallowed. However, the [parsing of selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] is making request with all empty selector as valid. i.e: Requests will empty selectors like: "/test/resource/path..a...html" are invalid While requests with all empty selectos "/test/resource/path.html" are valid Which indicates an inconsistent behaviour. Attached tests to demonstrate the same () > Inconsistent handling of emtpy selectors > > > Key: SLING-12124 > URL: https://issues.apache.org/jira/browse/SLING-12124 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.15.6 >Reporter: Sagar Miglani >Priority: Major > Attachments: inconsistent_empty_selectors.patch > > > In accordance with the code found > [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], > empty selectors are explicitly disallowed. However, the [parsing of > selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] > is making request with all empty selector as valid. > i.e: > Requests will empty selectors like: "/test/resource/path..a...html" are > invalid > While requests with all empty selectos "/test/resource/path.html" are > valid > Which indicates an inconsistent behaviour. > Attached tests to demonstrate the same ([^inconsistent_empty_selectors.patch]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12124) Inconsistent handling of emtpy selectors
[ https://issues.apache.org/jira/browse/SLING-12124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sagar Miglani updated SLING-12124: -- Attachment: inconsistent_empty_selectors.patch > Inconsistent handling of emtpy selectors > > > Key: SLING-12124 > URL: https://issues.apache.org/jira/browse/SLING-12124 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.15.6 >Reporter: Sagar Miglani >Priority: Major > Attachments: inconsistent_empty_selectors.patch > > > In accordance with the code found > [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], > empty selectors are explicitly disallowed. However, the [parsing of > selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] > is making request with all empty selector as valid. > i.e: > Requests will empty selectors like: "/test/resource/path..a...html" are > invalid > While requests with all empty selectos "/test/resource/path.html" are > valid > Which indicates an inconsistent behaviour. > Attached tests to demonstrate the same () -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12124) Inconsistent handling of emtpy selectors
[ https://issues.apache.org/jira/browse/SLING-12124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sagar Miglani updated SLING-12124: -- Attachment: (was: inconsistent_emtpy_selectors.patch) > Inconsistent handling of emtpy selectors > > > Key: SLING-12124 > URL: https://issues.apache.org/jira/browse/SLING-12124 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.15.6 >Reporter: Sagar Miglani >Priority: Major > > In accordance with the code found > [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], > empty selectors are explicitly disallowed. However, the [parsing of > selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] > is making request with all empty selector as valid. > i.e: > Requests will empty selectors like: "/test/resource/path..a...html" are > invalid > While requests with all empty selectos "/test/resource/path.html" are > valid > Which indicates an inconsistent behaviour. > Attached tests to demonstrate the same () -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12124) Inconsistent handling of emtpy selectors
[ https://issues.apache.org/jira/browse/SLING-12124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sagar Miglani updated SLING-12124: -- Description: In accordance with the code found [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], empty selectors are explicitly disallowed. However, the [parsing of selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] is making request with all empty selector as valid. i.e: Requests will empty selectors like: "/test/resource/path..a...html" are invalid While requests with all empty selectos "/test/resource/path.html" are valid Which indicates an inconsistent behaviour. Attached tests to demonstrate the same () was: In accordance with the code found [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], empty selectors are explicitly disallowed. However, the [parsing of selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] is making request with all empty selector as valid. i.e: Requests will emtpy selectors like: "/test/resource/path..a...html" are invalid While requests with all empty selectos "/test/resource/path.html" are valid Which indicates an inconsistent behaviour. Attached tests to demonstrate the same ([^inconsistent_emtpy_selectors.patch]) > Inconsistent handling of emtpy selectors > > > Key: SLING-12124 > URL: https://issues.apache.org/jira/browse/SLING-12124 > Project: Sling > Issue Type: Bug > Components: Engine >Affects Versions: Engine 2.15.6 >Reporter: Sagar Miglani >Priority: Major > > In accordance with the code found > [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], > empty selectors are explicitly disallowed. However, the [parsing of > selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] > is making request with all empty selector as valid. > i.e: > Requests will empty selectors like: "/test/resource/path..a...html" are > invalid > While requests with all empty selectos "/test/resource/path.html" are > valid > Which indicates an inconsistent behaviour. > Attached tests to demonstrate the same () -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12124) Inconsistent handling of emtpy selectors
Sagar Miglani created SLING-12124: - Summary: Inconsistent handling of emtpy selectors Key: SLING-12124 URL: https://issues.apache.org/jira/browse/SLING-12124 Project: Sling Issue Type: Bug Components: Engine Affects Versions: Engine 2.15.6 Reporter: Sagar Miglani Attachments: inconsistent_emtpy_selectors.patch In accordance with the code found [here|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/RequestData.java#L563], empty selectors are explicitly disallowed. However, the [parsing of selectors|https://github.com/apache/sling-org-apache-sling-engine/blob/master/src/main/java/org/apache/sling/engine/impl/request/SlingRequestPathInfo.java#L93-L95] is making request with all empty selector as valid. i.e: Requests will emtpy selectors like: "/test/resource/path..a...html" are invalid While requests with all empty selectos "/test/resource/path.html" are valid Which indicates an inconsistent behaviour. Attached tests to demonstrate the same ([^inconsistent_emtpy_selectors.patch]) -- This message was sent by Atlassian Jira (v8.20.10#820010)
Call for Presentations now open: Community over Code EU 2024
(Note: You are receiving this because you are subscribed to the dev@ list for one or more projects of the Apache Software Foundation.) It's back *and* it's new! We're excited to announce that the first edition of Community over Code Europe (formerly known as ApacheCon EU) which will be held at the Radisson Blu Carlton Hotel in Bratislava, Slovakia from June 03-05, 2024! This eagerly anticipated event will be our first live EU conference since 2019. The Call for Presentations (CFP) for Community Over Code EU 2024 is now open at https://eu.communityovercode.org/blog/cfp-open/, and will close 2024/01/12 23:59:59 GMT. We welcome submissions on any topic related to the Apache Software Foundation, Apache projects, or the communities around those projects. We are specifically looking for presentations in the following categories: * API & Microservices * Big Data Compute * Big Data Storage * Cassandra * CloudStack * Community * Data Engineering * Fintech * Groovy * Incubator * IoT * Performance Engineering * Search * Tomcat, Httpd and other servers Additionally, we are thrilled to introduce a new feature this year: a poster session. This addition will provide an excellent platform for showcasing high-level projects and incubator initiatives in a visually engaging manner. We believe this will foster lively discussions and facilitate networking opportunities among participants. All my best, and thanks so much for your participation, Ryan Skraba (on behalf of the program committee) [Countdown]: https://www.timeanddate.com/countdown/to?iso=20240112T2359=1440
[jira] [Updated] (SLING-12061) Make event admin dependency optional
[ https://issues.apache.org/jira/browse/SLING-12061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated SLING-12061: - Fix Version/s: (was: Resource Resolver 1.11.2) > Make event admin dependency optional > > > Key: SLING-12061 > URL: https://issues.apache.org/jira/browse/SLING-12061 > Project: Sling > Issue Type: Improvement > Components: ResourceResolver >Reporter: Carsten Ziegeler >Priority: Major > > The event admin service is optional for the resourceresolver bundle, however, > the API is not - which means an event admin api needs to be available at > runtime. And that effectively means the event admin needs to be deployed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-10899) Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached
[ https://issues.apache.org/jira/browse/SLING-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780986#comment-17780986 ] Carsten Ziegeler commented on SLING-10899: -- Sounds ok to me, however I think we should add a kill switch to disable in case it creates problems somewhere. > Result of JcrNodeResource#adaptTo(ValueMap.class) should be cached > -- > > Key: SLING-10899 > URL: https://issues.apache.org/jira/browse/SLING-10899 > Project: Sling > Issue Type: Improvement > Components: JCR >Affects Versions: JCR Resource 3.0.22 >Reporter: Henry Kuijpers >Priority: Major > > I was performance testing our application. There is a specific part of the > code where we have a set of ~500 resources and we sort them based on a few > properties of the resources. Multiple properties are used (which results in > multiple calls to getValueMap). The sorting is done using a comparator, so > the logic that determines the order is accessed numerous times. > We've seen quite a decrease in performance when doing this with Resources > that are of type JcrNodeResource. Turns out that the result of getValueMap > (or adaptTo((Value)Map.class)) is not cached. > As you can see in the adaptTo()-method implementation: > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L136 > this call bypasses the AdapterFactory framework and also bypasses any > caching that happens over there. > What's even more unfortunate, is that JcrValueMap is implementing caching via > https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/6e13f4d315ddf2804d2e16c55faee18e805b618e/src/main/java/org/apache/sling/jcr/resource/internal/JcrValueMap.java#L49 > . That caching is not leveraged properly, because every call to getValueMap > returns a new JcrValueMap, instead of reusing a previously created one. > One change that can be done is maybe converting the logic inside the > adaptTo()-method to a dedicated AdapterFactory implementation, so that > caching is done by default? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12107) JCR Repoinit executes operations out of order
[
https://issues.apache.org/jira/browse/SLING-12107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780984#comment-17780984
]
Carsten Ziegeler commented on SLING-12107:
--
Do we have a summary of what actually gets reordered and why? I find it rather
surprising that statements are reordered.
> JCR Repoinit executes operations out of order
> -
>
> Key: SLING-12107
> URL: https://issues.apache.org/jira/browse/SLING-12107
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: Repoinit JCR 1.1.46
>
>
> When applying ACLs, repoinit checks if the referenced authorizable exists,
> and it fails if it doesn't.
> However, my goal was to set up ACLs with my deployment for a group that was
> to be sync'ed from an {{ExternalIdentityProvider}} once the first member of
> that group logs in.
> To work around this limitation, I tried running the following repoinit script:
> {noformat}
> create group testGroup
> set ACL for testGroup
> allow jcr:read on /content/foo
> deny jcr:write on /content/foo
> end
> delete group testGroup
> {noformat}
> It turned out that the statements were executed in the following order:
> {noformat}
> create group testGroup
> delete group testGroup
> set ACL for testGroup
> allow jcr:read on /content/foo
> deny jcr:write on /content/foo
> end
> {noformat}
> Of course that caused the script to fail just as if no group was created.
> The incorrect ordering may also cause other scenarios to fail.
> The {{ExecutionOrderTest}} suggests that some re-ordering is done on purpose.
> E.g. namespaces and nodetypes should be created before e.g. paths are created.
> I would expect that registration of custom privileges should also be executed
> before other operations. I don't see how that could be harmful.
> But for all other statements, I would expect the execution order to match the
> order of the statements within the repoinit script.
> cc [~bdelacretaz], [~cziegeler], [~angela]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12123) Unexpected new requirements for the XSS bundle
[ https://issues.apache.org/jira/browse/SLING-12123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-12123: Priority: Critical (was: Major) > Unexpected new requirements for the XSS bundle > -- > > Key: SLING-12123 > URL: https://issues.apache.org/jira/browse/SLING-12123 > Project: Sling > Issue Type: Bug > Components: XSS Protection API >Reporter: Robert Munteanu >Priority: Critical > Fix For: XSS Protection API 2.3.12 > > > With the 2.3.10 release candidate: > [ERROR] [bundle-packages] org.apache.sling:org.apache.sling.xss:2.3.10: > Bundle is importing packages [javax.annotation.meta, android.os] with start > order 20 but no bundle is exporting these for that start order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-11921) Building javadoc with Java 11 fails
[
https://issues.apache.org/jira/browse/SLING-11921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-11921:
Fix Version/s: XSS Protection API 2.3.12
(was: XSS Protection API 2.3.10)
> Building javadoc with Java 11 fails
> ---
>
> Key: SLING-11921
> URL: https://issues.apache.org/jira/browse/SLING-11921
> Project: Sling
> Issue Type: Bug
> Components: XSS Protection API
>Affects Versions: XSS Protection API 2.3.8
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: XSS Protection API 2.3.12
>
>
> After the fix for 11610, building javadoc with Java 11 or newer fails
> {noformat}[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.4.0:jar (default-cli) on
> project org.apache.sling.xss: MavenReportException: Error while generating
> Javadoc:
> [ERROR] Exit code: 1 -
> /home/robert/sources/apache/sling/org-apache-sling-xss/src/main/java/org/apache/sling/xss/impl/AntiSamyPolicyAdapter.java:39:
> error: package sun.misc does not exist
> [ERROR] import sun.misc.Unsafe;
> [ERROR]^
> [ERROR]
> [ERROR] Command line was: /usr/lib64/jvm/java-11-openjdk-11/bin/javadoc
> @options @packages{noformat}
> As a direct consequence, releasing must be done with Java 8
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12005) XSS bundle should not embed org.owasp.encoder
[ https://issues.apache.org/jira/browse/SLING-12005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-12005: Fix Version/s: XSS Protection API 2.3.12 (was: XSS Protection API 2.3.10) > XSS bundle should not embed org.owasp.encoder > - > > Key: SLING-12005 > URL: https://issues.apache.org/jira/browse/SLING-12005 > Project: Sling > Issue Type: New Feature > Components: XSS Protection API >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: XSS Protection API 2.3.12 > > > Currently the XSS bundle embeds the OSGi bundle org.owasp.encoder:encoder . > As that is already a bundle, it is better to not embed it. This makes > updating that code easier and if other modules use it avoids duplicate > deployments (in potentially different versions) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12116) Update transative google-guava dependency to version 32.1.3-jre
[ https://issues.apache.org/jira/browse/SLING-12116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-12116: Fix Version/s: XSS Protection API 2.3.12 (was: XSS Protection API 2.3.10) > Update transative google-guava dependency to version 32.1.3-jre > --- > > Key: SLING-12116 > URL: https://issues.apache.org/jira/browse/SLING-12116 > Project: Sling > Issue Type: Bug > Components: XSS Protection API >Reporter: Tatyana Vogel >Assignee: Tatyana Vogel >Priority: Critical > Fix For: XSS Protection API 2.3.12 > > > The sling XSS library has a transitive dependency which embeds vulnerable > google-guava. > Upgrade to a vulnerability-free version of the embedded library is needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-11882) XSS Protection API: Apply shading/package relocation to embedded Guava+Co Libraries
[ https://issues.apache.org/jira/browse/SLING-11882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-11882: Fix Version/s: XSS Protection API 2.3.12 (was: XSS Protection API 2.3.10) > XSS Protection API: Apply shading/package relocation to embedded Guava+Co > Libraries > --- > > Key: SLING-11882 > URL: https://issues.apache.org/jira/browse/SLING-11882 > Project: Sling > Issue Type: Improvement > Components: XSS Protection API >Affects Versions: XSS Protection API 2.3.0 >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: XSS Protection API 2.3.12 > > > with version 2.3.0 of the XSS Protection API the internal implementation was > switched to OWASP sanitizer library (esapi) in SLING-7231. > with this new implementation comes a load of 3rdparty libraries including a > guava version, which is embedded as private packages in the OSGi bundle. this > is completely fine from an OSGi bundle perspective and works. > however, in unit test contexts this can lead to problems, because depending > on the dependency order the embedded guava classes may overlay other guava > classes references in the same POM with a different version, leading to > problems running code in the unit test context. to prevent problems like > this, we usually apply a shading and relocation of the package names to > ensure such clashes in classpath does no happen. > the same problem may affect other libraries embedded in the bundle. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12118) Update Batik XML utility library to version 1.17
[ https://issues.apache.org/jira/browse/SLING-12118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-12118: Fix Version/s: XSS Protection API 2.3.12 (was: XSS Protection API 2.3.10) > Update Batik XML utility library to version 1.17 > > > Key: SLING-12118 > URL: https://issues.apache.org/jira/browse/SLING-12118 > Project: Sling > Issue Type: Bug > Components: XSS Protection API >Reporter: Tatyana Vogel >Assignee: Tatyana Vogel >Priority: Critical > Fix For: XSS Protection API 2.3.12 > > > The sling XSS library uses a vulnerable Batik XML utility library version. > Upgrade to a vulnerability-free version of the embedded library is needed. > [CVE-2022-44729|https://www.cvedetails.com/cve/CVE-2022-44729/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12070) Migrate sling.xss to jakarta.json
[ https://issues.apache.org/jira/browse/SLING-12070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-12070: Fix Version/s: XSS Protection API 2.3.12 (was: XSS Protection API 2.3.10) > Migrate sling.xss to jakarta.json > - > > Key: SLING-12070 > URL: https://issues.apache.org/jira/browse/SLING-12070 > Project: Sling > Issue Type: Sub-task >Reporter: Ashok Pelluru >Assignee: Ashok Pelluru >Priority: Minor > Fix For: XSS Protection API 2.3.12 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[CANCELLED] [VOTE] Release Apache Sling XSS Protection API 2.3.10
Hi, This vote is cancelled because of the extra OSGi requirements that were unintentionally added. The fix is tracked in https://issues.apache.org/jira/browse/SLING-12123 . Thanks, Robert
[jira] [Created] (SLING-12123) Unexpected new requirements for the XSS bundle
Robert Munteanu created SLING-12123: --- Summary: Unexpected new requirements for the XSS bundle Key: SLING-12123 URL: https://issues.apache.org/jira/browse/SLING-12123 Project: Sling Issue Type: Bug Components: XSS Protection API Reporter: Robert Munteanu Fix For: XSS Protection API 2.3.12 With the 2.3.10 release candidate: [ERROR] [bundle-packages] org.apache.sling:org.apache.sling.xss:2.3.10: Bundle is importing packages [javax.annotation.meta, android.os] with start order 20 but no bundle is exporting these for that start order. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [VOTE] Release Apache Sling XSS Protection API 2.3.10
Hi Eric, On Sat, 2023-10-28 at 14:23 -0700, Eric Norman wrote: > -1 for me. This version doesn't appear to resolve when I plug it > into the > starter project. Were there additional new dependencies required to > use > it? Good catch, I will cancel the vote. I don't think any of the new requirements are intentional. We did some work around dependencies, upgrading version and also started using org.owasp.encoder as a bundle ( SLING-12005 ), but none of the changes should result in the requirements that you reported. Thanks, Robert
