Debian Patches

Status for swift/2.30.1-0+deb12u3

Patch Description Author Forwarded Bugs Origin Last update
syslog_log_name.patch Set log_name for Swift services in default configs
===================================================================		 Ondřej Nový <novy@ondrej.org> not-needed 2016-07-05
disable_sphinxcontrib_rsvgconverter.patch Disable sphinxcontrib.rsvgconverter extension
===================================================================		 Ondřej Nový <novy@ondrej.org> not-needed 2020-02-12
set-default-workers-value.patch Set default workers value Since the package switched to uwsgi and now reads this value, it can't be
left as "auto" an commented out.		 Thomas Goirand <zigo@debian.org> not-needed 2020-10-30
Add_tempurl_path_prefix_configuration_option.patch Add [filter:tempurl]/path_prefix configuration option If swiftproxy endpoint is something like /object, with URL rewriting
by haproxy, then the hmac calculation is wrong.
.
This patch adds a new path_prefix directive which is stripped away
in the URLs before calculating the tempurl hmac.

===================================================================		 Kevin Allioli <kevin@linit.io> yes 2021-11-18
Fix_DB_tests_on_py311.patch Fix DB tests on py311 Tim Burke <tim.burke@gmail.com> no 2022-11-29
swift-recon-only-query-object-servers-once.patch swift-recon: only query object servers once Thomas Goirand <zigo@debian.org> no 2023-04-28
Change_getting_major_minor_of_blkdev.patch Change getting major:minor of blkdev Replace method for determine major:minor of block device
because stat can't detect major:minor in some cases.

===================================================================		 Philippe SERAPHIN <philippe.seraphin@infomaniak.com> no Upstream, https://review.opendev.org/c/openstack/swift/+/887021 2023-06-29
drive-full-checker.patch drive-full-checker The admin documentation provides a documentation on how to "prevent[ing]
disk full scenarios" over here:
https://docs.openstack.org/swift/latest/admin_guide.html#preventing-disk-full-scenarios
.
Even if the doc provides an actual example, this example is written in
Python 2, and its implementation is incomplete.
.
This patch intend to fill the gap, and allow administrator to use an
official implementation of a new "swift-drive-full-checker" tool from
/usr/bin directly. Once done, we intend to also patch puppet-swift to
use this new tool.

===================================================================		 Thomas Goirand <zigo@debian.org> yes 2024-02-11
kms_keymaster-allow-specifying-barbican_endpoint.patch kms_keymaster: allow specifying barbican_endpoint Under a multi-region deployment with a single Keystone server,
specifying the Keystone auth credentials isn't enough. Indeed,
Castellan succeeds when logging-in, but may use the wrong
Barbican endpoint (if there are 2 Barbican deployed). This is
what happened to us, when deploying our 2nd region.
.
They way to fix it would be to tell Castellan what region to use,
unfortunately, there's no such option in Castellan. Though we may
specify the barbican_endpoint, which is what this patch allows.

diff --git a/swift/common/middleware/crypto/kms_keymaster.py b/swift/common/middleware/crypto/kms_keymaster.py
index f9a542e..4c0b250 100644		 Thomas Goirand <zigo@debian.org> yes 2024-06-13
bug-2119646-swift.patch Swift patch for LP: 2119646
===================================================================		 Tim Burke no upstream, https://bugs.launchpad.net/keystone/+bug/2119646 comment 28 2025-10-31
CVE-2026-50221-stable-2025.1_Block-internal-update-headers-at-the-gatekeeper.patch CVE-2026-50221: Block internal update headers at the gatekeeper The proxy-server's gatekeeper middleware did not strip internal
container and expiry update headers (X-Container-Host,
X-Container-Device, X-Delete-At-Host, X-Delete-At-Device, and
related headers) from client requests. An authenticated user with
write access could inject these headers to redirect container
update requests, enabling server-side request forgery.
.
Strip these headers at the gatekeeper before they reach any
downstream middleware or the proxy-server application.

diff --git a/swift/common/middleware/gatekeeper.py b/swift/common/middleware/gatekeeper.py
index dfb5ef04b..8e2583202 100644		 Goutham Pacha Ravi <gouthampravi@gmail.com> yes debian upstream upstream, pre-OSSA mailing list 2026-06-10
CVE-2026-71190_OSSA-2026-031_swob_avoid_excessive_backtracking_in_Accept_parser.patch swob: avoid excessive backtracking in Accept parser Python's regex engine uses backtracking: when a later part of a match
fails, it goes back and tries other ways of matching earlier alternatives.
.
Swift parses Accept headers on account and container requests before
authentication. A small malformed header can keep a proxy worker at
100% CPU, with processing time growing roughly as phi^n for n consecutive
backslashes. One request per worker can make the proxy unavailable, and
disconnecting does not stop the ongoing regex evaluation.
.
In a quoted Accept parameter, backslashes could match either as normal
characters or as parts of escaped pairs. If the closing quote was missing,
Python tried every possible partition before rejecting the header.
.
Exclude backslashes from normal quoted text so they can only start an
escaped character. This removes the ambiguity and makes malformed
headers fail quickly while preserving valid escaped characters.

===================================================================		 Christian Schwede <cschwede@mailbox.org> yes debian upstream upstream, https://review.opendev.org/c/openstack/swift/+/998953 2026-07-22
CVE-2026-97149_OSSA-2026-041_tempurl_Disallow_X-Copy-From_on_tempurl_requests.patch CVE-2026-97149 / OSSA-2026-041: tempurl: Disallow X-Copy-From on tempurl requests Disallow clients using the X-Copy-From header to make a copy of any
object within the account using a PUT tempurl by adding the x-copy-from
header to DISALLOWED_INCOMING_HEADERS. Requests that use the header now
get a 400 response, like the requests that use X-Object-Manifest or
X-Symlink-Target.
.
X-Copy-From-Account is not in the list, similar to
X-Symlink-Target-Account. These headers have no effect without
X-Copy-From or X-Symlink-Target.

===================================================================		 Christian Schwede <cschwede@mailbox.org> yes debian upstream Upstream, https://review.opendev.org/c/openstack/swift/+/1007050 2026-09-24
CVE-2026-71191_OSSA-2026-030-stable-2025.1-s3api_drop_native_Swift_control_headers_from_client_requests.patch [PATCH 2/2] s3api: drop native Swift control headers from client requests Strip client-supplied X-Copy-From(-Account), X-Symlink-Target(-Account),
X-Object-Manifest and X-Static-Large-Object before the Swift subrequest,
so they can't bypass S3 ACL checks. Headers s3api sets itself (e.g.
X-Copy-From from x-amz-copy-source) are added later and stay trusted.

===================================================================		 Christian Schwede <cschwede@mailbox.org> yes debian upstream upstream, https://review.opendev.org/c/openstack/swift/+/998949 2026-07-22
CVE-2026-71191_OSSA-2026-030-stable-2025.1-s3api_require_signing_of_sensitive_SigV4_x-amz_headers.patch CVE-2026-pending1 s3api: require signing of sensitive SigV4 x-amz headers SigV4 accepted unsigned x-amz-* headers alongside a valid signature, so a
presigned URL could be extended with e.g. an unsigned x-amz-copy-source.
Reject unsigned x-amz-* headers that change request semantics: copy, acl,
grant and meta (also covers x-amz-metadata-directive).
.
Narrow denylist for now; full x-amz-* signing (AWS parity) can follow.

===================================================================		 Christian Schwede <cschwede@mailbox.org> yes debian upstream upstream, https://review.opendev.org/c/openstack/swift/+/998948 2026-07-22

All known versions for source package 'swift'

Links