Debian Patches

Status for mistral/23.0.0-4

Patch Description Author Forwarded Bugs Origin Last update
install-missing-files.patch Install missing files Thomas Goirand <zigo@debian.org> not-needed 2018-02-25
Load_defaults_from_oslo.concurrency.patch Load defaults from oslo.concurrency Under my env (ie: Debian packages), I've seen mistral-api trying to
write under:
.
/var/lock/nova/oslo_read_shm_<HOSTNAME>_mistral-api
.
Why /var/lock/nova is a mistery, but I want to fix this.
.
This patch:
.
Ensures oslo.concurrency lockutils uses the value from the parsed config.
oslo.concurrency registers its opts on import, so the option exists;
call set_defaults *after* CONF(...) so we pick up any value from files.
.
Sets the lockutils default to the configured path so external locks
(synchronized(external=True)) use the right directory.

===================================================================		 Thomas Goirand <zigo@debian.org> no 2025-10-03
CVE-2026-97147_Fix_create-or-update_of_definitions_hijacking_other_projects_rows.patch Fix create-or-update of definitions hijacking other projects' rows When several projects have a workflow or ad-hoc action definition with
the same name, create_or_update_workflow_definition() and
create_or_update_action_definition() looked the existing object up with
an unordered first() over a query that isn't scoped to a single project
(admin requests see all projects). The lookup could therefore return
another project's definition, and since project_id is always rewritten
to the current project on write (see
model_base.register_secure_model_hooks), updating that object moved it
into the caller's project. If the caller's project already had its own
definition with that name, the move violated the (name, namespace,
project_id) unique constraint and the resulting DBDuplicateEntry was
raised at commit time, surfacing as an HTTP 500.
.
This intermittently broke the python-mistralclient functional job:
the tests leaked 'wb.ac1' action definitions in two projects, after
which every 'workbook-create' of a definition containing actions failed
with a 500, depending on which project's row the DB returned first.
.
Look the existing definition up by the full unique key (name, namespace
and project id of the current security context), which is the only row
a subsequent write may collide with. Definitions of other projects are
no longer touched, and the update targets the definition by id so the
inner lookup is unambiguous.
.

diff --git a/mistral/db/v2/sqlalchemy/api.py b/mistral/db/v2/sqlalchemy/api.py
index 6fa439be..0836d5a3 100644		 Arnaud Morin <arnaud.morin@gmail.com> yes debian upstream upstream, pre-OSSA mailing list 2026-10-01
CVE-2026-97147_Enforce_access_control_when_updating_action_definitions.patch Enforce access control when updating action definitions update_action_definition() resolved the target by name with a query
that, for a non-admin caller, also matches public definitions of other
projects (the secure query includes scope=='public'). It then rewrote
project_id to the caller on write, so a non-admin could modify and
effectively steal another project's public ad-hoc action, and it had no
guard against modifying a system action at the DB layer -- unlike
update_workflow_definition(), which calls check_db_obj_access().
.
Look the definition up in the caller's own project first so that, when
several projects share a name, the caller's own object is updated, and
call check_db_obj_access() to reject cross-project and system-action
modifications by non-admins. The check is skipped when there is no
authentication context, since 'mistral-db-manage populate' re-registers
preinstalled ad-hoc actions through this path without one.
.

diff --git a/mistral/db/v2/sqlalchemy/api.py b/mistral/db/v2/sqlalchemy/api.py
index 0836d5a3..087643d4 100644		 Arnaud Morin <arnaud.morin@gmail.com> yes debian upstream upstream, pre-OSSA mailing list 2026-10-01
CVE-2026-97147_Enforce_access_control_when_updating_workbooks_and_environments.patch Enforce access control when updating workbooks and environments update_workbook() and update_environment()/create_or_update_environment()
resolved the target with a query that returns public resources of other
projects, and wrote to it without an ownership check. A non-admin project
member could therefore modify (and, since the update sends scope, unpublish)
another project's public workbook or environment.
.
Resolve the object within the caller's own project first and call
check_db_obj_access() before writing, consistently with workflow and action
definitions. The check is skipped when there is no authentication context.
.
update_workbook() was previously protected only transitively: a workbook
update cascades into update_workflow_definition(), which is guarded, so the
whole transaction rolled back. Making the workflow/action lookup
project-scoped (previous change) removes that incidental protection, so the
guard is now applied to the workbook row itself.
.

diff --git a/mistral/db/v2/sqlalchemy/api.py b/mistral/db/v2/sqlalchemy/api.py
index 087643d4..ad060b4b 100644		 Arnaud Morin <arnaud.morin@gmail.com> yes debian upstream upstream, pre-OSSA mailing list 2026-10-01
CVE-2026-97147_Resolve_own-project_object_when_updating_code_sources_dynamic_actions.patch Resolve own-project object when updating code sources / dynamic actions update_code_source() and update_dynamic_action_definition() resolved the
target with a lookup that can return an object of another project (admins
get an insecure cross-project lookup, and public objects are visible to any
caller), then rewrote project_id to the caller on write. When several
projects have an object with the same name, this could clobber or move the
wrong one.
.
Resolve the object within the caller's own project first and apply
check_db_obj_access(), consistently with workflow/action/workbook/environment
updates. These resources are admin-only by default policy, so this is
hardening / data integrity rather than a cross-tenant escalation.
.

diff --git a/mistral/db/v2/sqlalchemy/api.py b/mistral/db/v2/sqlalchemy/api.py
index ad060b4b..fd536e34 100644		 Arnaud Morin <arnaud.morin@gmail.com> yes debian upstream upstream, pre-OSSA mailing list 2026-10-01
CVE-2026-97147_Resolve_own-project_object_Fix-test-DB-cleanup-for-code-sources-and-dynamic-actions.patch Clean up code sources and dynamic actions in test DB cleanup DbTestCase._clean_db() never deleted code_sources and
dynamic_action_definitions rows, so those two tables were not reset
between tests. With the serial test run used by pkgos-dh_auto_test,
rows left behind by the CVE-2026-97147 DB tests (a public code source
"cs1" and dynamic actions referencing class names that do not exist
in its content) leaked into later tests in the same process: listing
actions built descriptors for them and failed with 500 "module 'cs1'
has no attribute 'UpdatedClass'".
.
Delete both tables in _clean_db() for each of the two contexts it
already iterates, dynamic action definitions before code sources to
respect the foreign key order.

===================================================================		 Thomas Goirand <zigo@debian.org> no debian 2026-10-01
CVE-2026-97147_Resolve_own-project_cron_trigger_in_create_or_update_cron_trigger.patch Resolve own-project cron trigger in create_or_update_cron_trigger create_or_update_cron_trigger() looked the existing trigger up with a
cross-project-capable query (public triggers are visible to any caller,
admins get an insecure lookup), so it could update another project's trigger
and move it into the caller's project. Resolve it within the caller's own
project first, consistently with the other resources.
.
update_cron_trigger() is deliberately left unchanged: it is called by the
periodic scheduler to update next-execution bookkeeping of triggers across
all projects, and the cron trigger REST API exposes no update operation.

diff --git a/mistral/db/v2/sqlalchemy/api.py b/mistral/db/v2/sqlalchemy/api.py
index fd536e34..f6225ae9 100644		 Arnaud Morin <arnaud.morin@gmail.com> yes debian upstream upstream, pre-OSSA mailing list 2026-10-01
CVE-2026-93861_Only_allow_the_owner_of_a_resource_to_share_it.patch Only allow the owner of a resource to share it Sharing a workflow (POST /v2/workflows/<id>/members) only verified that
the caller could fetch the workflow definition and that its scope was
private. The secure query that fetches the definition also returns
resources shared with the caller through an accepted membership, so a
project that a workflow was shared with - once it accepted the share -
could re-share the owner's private workflow with an arbitrary third
project.
.
The resulting ResourceMember row is stamped with the re-sharing
project's id (the caller), not the owner's, so:
.
* the real owner can neither list nor delete that membership;
* the third project can accept it and thereby read and execute the
owner's private workflow, which the owner never shared with it;
* only the re-sharing project, not the owner, can revoke it.
.
Reject the share unless the caller is the owner of the resource
(wf_db.project_id == security.get_project_id()), with a 403. This does
not affect the previously reported "pending" case, where the member
cannot see the workflow yet and the fetch already fails with 404.
.

diff --git a/mistral/api/controllers/v2/member.py b/mistral/api/controllers/v2/member.py
index 7dc0c805..1e22e7ba 100644		 Arnaud Morin <arnaud.morin@gmail.com> yes debian upstream upstream, pre-OSSA mailing list 2026-10-01
CVE-2026-93858_Fix_RCE_via_std.ssh_proxied_proxy_command.patch Fix RCE via std.ssh_proxied proxy_command The std.ssh_proxied action passed a caller-supplied proxy_command
straight to paramiko.ProxyCommand in execute_command_via_gateway.
paramiko.ProxyCommand runs the string as a local subprocess on the
executor host from its constructor - before any SSH authentication and
independently of the SSH credentials, gateway or target supplied (a bad
or empty key does not stop it). std.ssh_proxied is a built-in action, so
any authenticated, project-scoped user could run arbitrary commands on
every Mistral executor by submitting it through the action-execution
API. This is a remote code execution vulnerability.
.
Gate proxy_command behind a new '[action_std_ssh] allowed_proxy_commands'
allow-list (empty by default). execute_command_via_gateway now rejects,
with an ActionException, any proxy_command whose exact value is not
listed, before paramiko is invoked - so by default proxy_command is
disabled and no local subprocess can be spawned. Operators who rely on
it must add the exact command string to the option. The rejection reason
reaches the caller thanks to the preceding change.
.

===================================================================		 Arnaud Morin <arnaud.morin@gmail.com> yes debian upstream upstream, pre-OSSA mailing list 2026-10-01
CVE-2026-93860_Restrict_the_maintenance_endpoint_to_admins.patch Restrict the maintenance endpoint to admins The root-level /maintenance resource read and changed Mistral's cluster
maintenance state with no policy enforcement: the controller cleared
the request context and called the service/DB layer directly. Switching
the status to PAUSED is a cluster-wide operation that pauses running
executions across every project, and reading the status exposes
cluster-wide operational state, yet any authenticated token holder
could reach both methods.
.
Add 'maintenance:get' and 'maintenance:update' policies (both default
rule:admin_only) and enforce them in MaintenanceController.get() and
put() before the request context is cleared, so only administrators can
read or change the maintenance status. Operators can relax the rules in
policy.yaml if needed.
.

diff --git a/mistral/api/controllers/maintenance.py b/mistral/api/controllers/maintenance.py
index c24ef014..60a5fc05 100644		 Arnaud Morin <arnaud.morin@gmail.com> yes debian upstream upstream, pre-OSSA mailing list 2026-10-01
Fix_lock_tests_counting_all_named_locks.patch Make the named lock unit tests assert on their own records The unit tests share one in-memory database per worker process, and
the cleanup running after each test does not remove the rows of the
named locks table. Engine tests process tasks asynchronously in
background threads that hold named locks, so when such a thread is
still running, the lock row exists while the next test runs. The
LockTest tests count all the named lock records, so under a scheduler
that dispatches tests to workers dynamically (stestr --dynamic) a
leftover lock row from a previous engine test makes them fail. Assert
on the records of the lock the test actually created instead, so that
unrelated rows cannot affect them.

===================================================================		 Thomas Goirand <zigo@debian.org> yes 2026-10-15
Run_unit_tests_against_the_fake_RPC_transport.patch Run unit tests against the fake RPC transport A post-transaction engine operation, e.g. starting the next workflow
of a task with items, runs in its own thread and performs an RPC cast.
In unit tests that don't set up the fake transport (any test not based
on EngineTestCase, e.g. the trigger service tests), such a cast lands
on a real rabbit transport with no broker configured, and kombu
retries the connection forever in the background. The thread being
non-daemon, this blocks the exit of a dynamically dispatched test
worker process even though every test already passed, hanging stestr
run --dynamic at the end of the run. Engine tests already switch to
the fake transport in EngineTestCase: do it once for every unit test
in the shared test base instead, so that no test process can ever
attempt a real RPC connection. This replaces the previous
daemonization of the post-transaction thread, which the upstream
reviewer declined, as it could leave an execution in a middle state at
restart.

===================================================================		 Thomas Goirand <zigo@debian.org> yes upstream 2026-10-23
Fix_leakage_of_auth_enable_state_in_unit_tests.patch Fix leakage of auth_enable state in unit tests TestMembersController.setUp() sets auth_enable to True twice: once via
override_config(), which restores the previous value on cleanup, and
once via CONF.set_default(), which is never restored. Drop the latter,
the override_config() call is enough, so that tests running later in
the same process don't inherit the enabled authentication. Likewise,
test_start_workflow() sets auth_enable with set_default() twice, once
to create the trigger with authentication enabled and once to process
it with authentication disabled, without ever restoring either: use
override_config() for both, so that the state is restored on cleanup
even when the test fails in the middle. A test relying on auth being
disabled then misbehaves: the cron trigger service tests (whose module
disables authentication at import time) end up calling
security.add_trust_id() -> keystone.client(), which reads
CONF.keystone_authtoken.auth_url. Those options are only registered
when the WSGI pipeline instantiates the auth_token middleware, so the
run fails with NoSuchOptError as soon as tests are dispatched to
workers dynamically (e.g. with stestr --dynamic) and a worker that ran
the leaking tests is handed such a test afterwards.

===================================================================		 Thomas Goirand <zigo@debian.org> yes 2026-10-23
Enable_the_profiler_only_for_the_profiler_test.patch Enable the profiler only for the profiler test The profiler tests enable profiling worker-wide with a module-level
set_default: every worker process importing the module (which happens
at discovery time in each dynamically dispatched worker) runs all its
engine operations with profiling on. The engine operations run in
background threads that may outlive their test, and whenever one of
them traces after a later test set up its own notifier mock, that test
observes the traces: test_no_profile_trace fails with a mock call
count like "84 != 0" under stestr --dynamic, depending on which tests
the worker ran before it. Enable the profiler with override_config in
test_profile_trace only, so that no unrelated test ever initializes a
profiler, and test_no_profile_trace only counts the traces of its own
workflow, which are none, its profiler being disabled.

===================================================================		 Thomas Goirand <zigo@debian.org> yes 2026-10-23
Restore_the_YAQL_engine_cached_by_the_disabled-c.patch Restore the YAQL engine cached by the disabled-conversion tests The tests that disable the YAQL data conversion re-create the engine
so that it picks up the overridden config options, and leave that
engine cached in the yaql_expression module: it keeps serving the
tests running after them in the same worker process, with the
convertOutputData option still disabled, even though the per-test
config overrides are restored on cleanup. A later test evaluating an
expression then gets an unconverted result:
DataFlowTest.test_context_view_eval_values fails with
"'ValuesView(...)' is not an instance of list" under a scheduler
dispatching tests to workers dynamically (stestr --dynamic), depending
on which tests the worker ran before it. Restore the engine on
cleanup, so that it is re-created with the restored options upon the
next use.

===================================================================		 Thomas Goirand <zigo@debian.org> no 2026-10-23

All known versions for source package 'mistral'

Links