[jira] [Updated] (JCRVLT-858) Prevent persistent writes during dry runs

["Konrad Windszus (Jira)" <ji...@apache.org>]

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

Konrad Windszus updated JCRVLT-858:
-----------------------------------
    Security:     (was: Private)

> Prevent persistent writes during dry runs
> -----------------------------------------
>
>                 Key: JCRVLT-858
>                 URL: https://issues.apache.org/jira/browse/JCRVLT-858
>             Project: Jackrabbit FileVault
>          Issue Type: Bug
>            Reporter: Konrad Windszus
>            Assignee: Rishabh Daim
>            Priority: Major
>             Fix For: 4.3.0
>
>
> The dry-run design relies on AutoSave substituting {{session.refresh(false)}} for
> {{session.save()}} — which only reverts transient changes. Three code paths make
> immediately persistent changes during the "simulation":
> * Vector A — namespaces: the full content parse runs under dryRun, and
> DocViewImporter.startPrefixMapping registers every unknown xmlns of every parsed
> .content.xml via NamespaceRegistry.registerNamespace — a workspace-level change Oak
> effectively cannot unregister, fired even for filter-excluded content (parse-time event).
> The importer had no way to know it was in a dry run: the flag lived in ImportOptions and
> was consumed by Importer/AutoSave only.
> * Vector B — sub-package relocation/metadata: JcrPackageImpl.extract's sub-package
> block runs unguarded: s.getNode(path).remove(); s.save(), s.getWorkspace().move(...)
> (both immediate), plus def.clearLastUnpacked(false)/def.setDependencies(...,false)/
> def.setSubPackages(subIds) — transient, but persisted by the block's own unguarded
> s.save().
> * Vector C — nested registration: extractSubpackage calls mgr.register(input, true)
> unconditionally, really registering nested packages into /etc/packages under dryRun.
> https://github.com/apache/jackrabbit-filevault-private/issues/16



--
This message was sent by Atlassian Jira
(v8.20.10#820010)