[jira] [Resolved] (OAK-8646) Clean up changes from orphaned branch commits
[ https://issues.apache.org/jira/browse/OAK-8646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rishabh Daim resolved OAK-8646. --- Resolution: Fixed > Clean up changes from orphaned branch commits > - > > Key: OAK-8646 > URL: https://issues.apache.org/jira/browse/OAK-8646 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Stefan Egli >Priority: Major > > The Revision Garbage Collector currently does not clean up changes from > orphaned branch commits. Those are branch commits that have not been merged > but are still present on documents in the DocumentStore. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OAK-8646) Clean up changes from orphaned branch commits
[ https://issues.apache.org/jira/browse/OAK-8646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771730#comment-17771730 ] Rishabh Daim edited comment on OAK-8646 at 10/4/23 6:54 AM: PR [|https://github.com/apache/jackrabbit-oak/pull/] had been merged into the integration branch [DetailedGC/OAK-10199|https://github.com/apache/jackrabbit-oak/tree/DetailedGC/OAK-10199] via [e9146154.|https://github.com/apache/jackrabbit-oak/commit/e914615459f97847deea9cc457d0fd8a3132c34b] was (Author: JIRAUSER299730): PR [|https://github.com/apache/jackrabbit-oak/pull/] had been merged into the integration branch [DetailedGC/OAK-10199|https://github.com/apache/jackrabbit-oak/tree/DetailedGC/OAK-10199] via https://github.com/apache/jackrabbit-oak/commit/e914615459f97847deea9cc457d0fd8a3132c34b commit. > Clean up changes from orphaned branch commits > - > > Key: OAK-8646 > URL: https://issues.apache.org/jira/browse/OAK-8646 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Stefan Egli >Priority: Major > > The Revision Garbage Collector currently does not clean up changes from > orphaned branch commits. Those are branch commits that have not been merged > but are still present on documents in the DocumentStore. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-8646) Clean up changes from orphaned branch commits
[ https://issues.apache.org/jira/browse/OAK-8646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771730#comment-17771730 ] Rishabh Daim commented on OAK-8646: --- PR [|https://github.com/apache/jackrabbit-oak/pull/] had been merged into the integration branch [DetailedGC/OAK-10199|https://github.com/apache/jackrabbit-oak/tree/DetailedGC/OAK-10199] via e914615459f97847deea9cc457d0fd8a3132c34b commit. > Clean up changes from orphaned branch commits > - > > Key: OAK-8646 > URL: https://issues.apache.org/jira/browse/OAK-8646 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Stefan Egli >Priority: Major > > The Revision Garbage Collector currently does not clean up changes from > orphaned branch commits. Those are branch commits that have not been merged > but are still present on documents in the DocumentStore. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OAK-8646) Clean up changes from orphaned branch commits
[ https://issues.apache.org/jira/browse/OAK-8646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771730#comment-17771730 ] Rishabh Daim edited comment on OAK-8646 at 10/4/23 6:52 AM: PR [|https://github.com/apache/jackrabbit-oak/pull/] had been merged into the integration branch [DetailedGC/OAK-10199|https://github.com/apache/jackrabbit-oak/tree/DetailedGC/OAK-10199] via https://github.com/apache/jackrabbit-oak/commit/e914615459f97847deea9cc457d0fd8a3132c34b commit. was (Author: JIRAUSER299730): PR [|https://github.com/apache/jackrabbit-oak/pull/] had been merged into the integration branch [DetailedGC/OAK-10199|https://github.com/apache/jackrabbit-oak/tree/DetailedGC/OAK-10199] via e914615459f97847deea9cc457d0fd8a3132c34b commit. > Clean up changes from orphaned branch commits > - > > Key: OAK-8646 > URL: https://issues.apache.org/jira/browse/OAK-8646 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Marcel Reutegger >Assignee: Stefan Egli >Priority: Major > > The Revision Garbage Collector currently does not clean up changes from > orphaned branch commits. Those are branch commits that have not been merged > but are still present on documents in the DocumentStore. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10424) Allow Fast Query Size and Insecure Facets to be selectively enabled with query options for permitted principals
[ https://issues.apache.org/jira/browse/OAK-10424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771536#comment-17771536 ] Angela Schreiber commented on OAK-10424: [~madamcin], i commented on the PR. expanding the list of built-in privileges/permissions is unfortunately not possible without calling collisions with custom privileges that have been defined for a given repository before (it would not impact newly created repositories). unless i am totally mistaken and my memory lets me down, we would need to tackle this differently. the patch in the current form cannot be merged without causing major regressions (and yes this is the fault of the way how custom privileges are handled/stored). let's discuss how we could do it. after all what you try to achieve is closer to what custom privileges are used for than true built-in privileges as you (as far as i could see) don't enforce them during the permission evaluation. > Allow Fast Query Size and Insecure Facets to be selectively enabled with > query options for permitted principals > > > Key: OAK-10424 > URL: https://issues.apache.org/jira/browse/OAK-10424 > Project: Jackrabbit Oak > Issue Type: Improvement >Affects Versions: 1.56.0 >Reporter: Mark Adamcin >Priority: Major > Labels: query > > Setting the global QueryEngineSettingsService.getFastQuerySize() value to > true is currently the only way to allow service users to leverage JCR query > for collecting accurate repository count metrics in a performant way. > However, doing so in a multiuser repository may be inadvisable because the > fast result size is returned to the caller without considering the caller's > read permissions over the paths returned in the result, which may allow less > privileged users to discover the presence of nodes that are not otherwise > visible to them. > See > [https://jackrabbit.apache.org/oak/docs/query/query-engine.html#result-size] > As an alternative to the global setting, Oak should provide a query option > alongside [TRAVERSAL, OFFSET / LIMIT, and INDEX > TAG|https://jackrabbit.apache.org/oak/docs/query/query-engine.html#query-options], > such as "INSECURE RESULT SIZE" . > Similarly, IndexDefinition.SecureFacetConfiguration.MODE.INSECURE (insecure > facets) can provide extremely valuable counts for property value distribution > in large repositories. At the moment, it can only be defined on an index > definition, even though it governs the facet counts at query time and has no > effect on the persisted content of the index at all. Like fastQuerySize, Oak > should provide a query option such as "INSECURE FACETS", for permitted system > users to leverage insecure facets even when the query execution plan uses an > index definition that only allows secure or statistical facet security. > For example, > select a.[jcr:path] from [nt:base] as a where contains(a.[text], 'Hello > World') option(insecure result size, insecure facets, offset 10) > To address the security risk, the application should also provide a > configuration of some kind to restrict the ability to effectively leverage > this option to permitted system users, which could be implemented as a JCR > repository privilege or an allowlist property in the > QueryEngineSettingsService configuration. > I have provided a PR that adds support for an INSECURE RESULT SIZE query > option and an INSECURE FACETS query option, as well as an > "rep:insecureQueryOptions" repository privilege. I think the JCR > privilege-based approach for configuration of this permission is more aligned > with how system users are defined in practice, but this approach requires a > minor version increase in the following oak-security-spi packages: > * org.apache.jackrabbit.oak.spi.security.authorization.permission > * org.apache.jackrabbit.oak.spi.security.privilege > Because all registered permissions are serialized into a long bitset, there > is clearly a premium on adding another built-in privilege, so I figured that > it would be better to choose a name for the privilege that would make it > applicable to both of these new options, and any future query options that > may involve a tradeoff between security and performance. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OAK-10424) Allow Fast Query Size and Insecure Facets to be selectively enabled with query options for permitted principals
[ https://issues.apache.org/jira/browse/OAK-10424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771536#comment-17771536 ] Angela Schreiber edited comment on OAK-10424 at 10/3/23 3:54 PM: - [~madamcin], i commented on the PR. expanding the list of built-in privileges/permissions is unfortunately not possible without causing collisions with custom privileges that have been defined for a given repository before (it would not impact newly created repositories). unless i am totally mistaken and my memory lets me down, we would need to tackle this differently. the patch in the current form cannot be merged without causing major regressions (and yes this is the fault of the way how custom privileges are handled/stored). let's discuss how we could do it. after all what you try to achieve is closer to what custom privileges are used for than true built-in privileges as you (as far as i could see) don't enforce them during the permission evaluation. was (Author: anchela): [~madamcin], i commented on the PR. expanding the list of built-in privileges/permissions is unfortunately not possible without calling collisions with custom privileges that have been defined for a given repository before (it would not impact newly created repositories). unless i am totally mistaken and my memory lets me down, we would need to tackle this differently. the patch in the current form cannot be merged without causing major regressions (and yes this is the fault of the way how custom privileges are handled/stored). let's discuss how we could do it. after all what you try to achieve is closer to what custom privileges are used for than true built-in privileges as you (as far as i could see) don't enforce them during the permission evaluation. > Allow Fast Query Size and Insecure Facets to be selectively enabled with > query options for permitted principals > > > Key: OAK-10424 > URL: https://issues.apache.org/jira/browse/OAK-10424 > Project: Jackrabbit Oak > Issue Type: Improvement >Affects Versions: 1.56.0 >Reporter: Mark Adamcin >Priority: Major > Labels: query > > Setting the global QueryEngineSettingsService.getFastQuerySize() value to > true is currently the only way to allow service users to leverage JCR query > for collecting accurate repository count metrics in a performant way. > However, doing so in a multiuser repository may be inadvisable because the > fast result size is returned to the caller without considering the caller's > read permissions over the paths returned in the result, which may allow less > privileged users to discover the presence of nodes that are not otherwise > visible to them. > See > [https://jackrabbit.apache.org/oak/docs/query/query-engine.html#result-size] > As an alternative to the global setting, Oak should provide a query option > alongside [TRAVERSAL, OFFSET / LIMIT, and INDEX > TAG|https://jackrabbit.apache.org/oak/docs/query/query-engine.html#query-options], > such as "INSECURE RESULT SIZE" . > Similarly, IndexDefinition.SecureFacetConfiguration.MODE.INSECURE (insecure > facets) can provide extremely valuable counts for property value distribution > in large repositories. At the moment, it can only be defined on an index > definition, even though it governs the facet counts at query time and has no > effect on the persisted content of the index at all. Like fastQuerySize, Oak > should provide a query option such as "INSECURE FACETS", for permitted system > users to leverage insecure facets even when the query execution plan uses an > index definition that only allows secure or statistical facet security. > For example, > select a.[jcr:path] from [nt:base] as a where contains(a.[text], 'Hello > World') option(insecure result size, insecure facets, offset 10) > To address the security risk, the application should also provide a > configuration of some kind to restrict the ability to effectively leverage > this option to permitted system users, which could be implemented as a JCR > repository privilege or an allowlist property in the > QueryEngineSettingsService configuration. > I have provided a PR that adds support for an INSECURE RESULT SIZE query > option and an INSECURE FACETS query option, as well as an > "rep:insecureQueryOptions" repository privilege. I think the JCR > privilege-based approach for configuration of this permission is more aligned > with how system users are defined in practice, but this approach requires a > minor version increase in the following oak-security-spi packages: > * org.apache.jackrabbit.oak.spi.security.authorization.permission > * org.apache.jackrabbit.oak.spi.security.privilege
[jira] [Updated] (OAK-10465) Embed netty-transport-native-unix-common dependency in oak-segment-tar
[ https://issues.apache.org/jira/browse/OAK-10465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rishabh Daim updated OAK-10465: --- Component/s: segment-tar > Embed netty-transport-native-unix-common dependency in oak-segment-tar > -- > > Key: OAK-10465 > URL: https://issues.apache.org/jira/browse/OAK-10465 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-tar >Reporter: Rishabh Daim >Assignee: Rishabh Daim >Priority: Major > > We need to embed netty-transport-native-unix-common jar to oak-segment-tar > which is now used by netty-handler. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OAK-10465) Embed netty-transport-native-unix-common dependency in oak-segment-tar
[ https://issues.apache.org/jira/browse/OAK-10465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rishabh Daim reassigned OAK-10465: -- Assignee: Rishabh Daim > Embed netty-transport-native-unix-common dependency in oak-segment-tar > -- > > Key: OAK-10465 > URL: https://issues.apache.org/jira/browse/OAK-10465 > Project: Jackrabbit Oak > Issue Type: Bug >Reporter: Rishabh Daim >Assignee: Rishabh Daim >Priority: Major > > We need to embed netty-transport-native-unix-common jar to oak-segment-tar > which is now used by netty-handler. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10465) Embed netty-transport-native-unix-common dependency in oak-segment-tar
Rishabh Daim created OAK-10465: -- Summary: Embed netty-transport-native-unix-common dependency in oak-segment-tar Key: OAK-10465 URL: https://issues.apache.org/jira/browse/OAK-10465 Project: Jackrabbit Oak Issue Type: Bug Reporter: Rishabh Daim We need to embed netty-transport-native-unix-common jar to oak-segment-tar which is now used by netty-handler. -- This message was sent by Atlassian Jira (v8.20.10#820010)
