mirror of https://github.com/rustfs/rustfs.git synced 2026-09-17 16:15:43 +00:00

Files

T

Chris 5eee2aaead fix(auth): reject unsigned x-amz headers on header-signed SigV4 requests (#7796 )

* fix(auth): reject unsigned x-amz headers on header-signed SigV4 requests

A SigV4 request authenticated with an Authorization header only binds the headers named in its SignedHeaders list, but RustFS acted on every x-amz-* header that arrived, so a replayed header-signed PutObject carrying an unsigned x-amz-copy-source became a CopyObject run as the signer that could copy any object the signer can read (GHSA-xm99-m3gq-83g8). The presigned form was already closed by GHSA-g8w9-qw9q-fghr.

reject_unsigned_amz_headers_on_sigv4_request now guards S3Access::check and S3Router::check_access: every SigV4 signed-header list the request carries must cover every x-amz-* header, the Authorization header is parsed with the verifier's own s3s-sigv4 parser and compared case-insensitively, the algorithm token is pinned to AWS4-HMAC-SHA256 because the upstream header path accepts any token, and the exempt set mirrors the upstream s3s fix (x-amz-content-sha256, x-amz-decoded-content-length, x-amz-trailer, x-amz-checksum-algorithm) plus x-amz-cf-id. Adds ghsa_xm99 unit, router and e2e regressions, raises the security smoke floor to 28, and records the advisory in docs/testing/security-regressions.md and CHANGELOG.md.

* chore(deps): switch s3s and s3s-sigv4 to crates.io 0.16.0

* fix(server): enforce the SigV4 header guard ahead of s3s dispatch

s3s 0.16 verifies the claimed algorithm as the first step of its own
signature flow, so a request whose Authorization header swaps the
AWS4-HMAC-SHA256 token was answered with 501 NotImplemented before
RustFS's access layer could rule on the unsigned x-amz-copy-source
(GHSA-xm99-m3gq-83g8). Add the SigV4HeaderGuardLayer as the innermost
external stack layer, running reject_unsigned_amz_headers_on_sigv4_request
in front of s3s and serializing its rejections as the same AccessDenied
S3 error document the access layer produces.

---------

Co-authored-by: Hauser <housemecn@gmail.com>

2026-09-14 21:08:45 +08:00

architecture

revert: remove M1 gateway git dependency until CI can access rustfs/gateway (#7787 )

2026-09-14 04:12:35 +08:00

operations

fix(kms): refuse key ids that leave the key prefix on the Vault backends (#7727 )

2026-09-14 12:37:45 +00:00

postmortems

fix(replication): send an integrity header on Object Lock PUTs (#7097 )

2026-09-03 20:26:44 +08:00

testing

fix(auth): reject unsigned x-amz headers on header-signed SigV4 requests (#7796 )

2026-09-14 21:08:45 +08:00

README.md

chore(release): merge release into main for rc.6 (#7638 )

2026-09-10 18:24:20 +08:00

README.md

Documentation

Use the focused indexes rather than treating this directory as an unordered collection:

Operations

Operational runbooks live under operations/. Replication operators should start with:

Runbook	Use it for
Site replication operations	Health fields, pending operations, outage recovery, re-pair admission, IAM/SSE boundaries, and upgrades.
Replication target check	Validating an S3 destination and version fidelity before enabling replication.
Replication object size limits	Multipart routing, large-object limits, and retry characteristics.
Replication outbound transport	Integrity headers, generic target behavior, and transport knobs.

Other runbooks remain grouped by filename in operations/; architecture pages link to the relevant runbook where a cross-boundary procedure is required.

For storage dashboards, see Storage metrics and observer selection: drive ownership, snapshot freshness, counter queries, and rolling upgrades.