Zhengchao An
34f1d2c0cd
* docs: state that MinIO-encrypted objects are not readable by RustFS Operators evaluating a MinIO migration had no warning that objects MinIO wrote with SSE-S3, SSE-KMS, or SSE-C cannot be read back. The container formats interoperate, so the limitation is easy to discover only after the data has moved. Document the limitation where a migration decision is actually made: - minio-file-format-compat.md gains Part C, covering which object classes transfer, the three seams that block each SSE mode with file:line evidence, the reverse direction, and the current workarounds. It also records that the `rio-v2` MinIO sealed-key parser does not close the gap: the feature is absent from released artifacts, and the managed-SSE detection gate is not feature-gated and returns before the parser runs. - kms-backend-security.md gains an operator-facing warning next to the backend comparison table, since configuring the static backend with MinIO's key material looks like it should work and does not. - s3-compatibility-matrix.md scopes its SSE row to RustFS's own round-trip. The read path treats an undetected MinIO-encrypted object as unencrypted rather than failing, so all three notes tell operators to verify migrated objects by content instead of by status code. Refs rustfs/backlog#1638. * docs: correct the failure mode for MinIO-encrypted objects The read path does fail closed; the earlier text claimed ciphertext was served as plaintext. MinIO's internal headers mark the object encrypted, so the reader refuses when no material resolves. What is actually wrong is the diagnosis: the refusal surfaces as a 500 InternalError.
4.8 KiB
S3 Compatibility Matrix
This matrix records the user-facing S3 compatibility claim for RustFS and ties
it to the executable Ceph s3tests lists under scripts/s3-tests/.
Current Claim
RustFS provides broad S3 API compatibility for supported features. It does not claim complete coverage of every standard or vendor-specific S3 behavior.
The root README should use the same wording: supported S3-compatible clients and features are covered by the compatibility matrix and test lists.
Test List Sources
| List | Purpose | Current count | Source |
|---|---|---|---|
| Implemented tests | Standard S3 tests expected to pass and used by the default local s3tests run. | 452 | scripts/s3-tests/implemented_tests.txt |
| Lifecycle behavior tests | Expiration behavior cases gated by the dedicated s3-lifecycle-behavior-tests lane (debug-accelerated day + scanner enabled). |
5 | scripts/s3-tests/lifecycle_behavior_tests.txt |
| Unimplemented tests | Standard S3 features planned but not yet implemented. | 17 | scripts/s3-tests/unimplemented_tests.txt |
| Excluded tests | Vendor-specific or intentionally unsupported behavior excluded from RustFS compatibility gating. | 273 | scripts/s3-tests/excluded_tests.txt |
Counts ignore blank lines and comments.
The lifecycle behavior lane runs real Days-based expiration cases that need
RUSTFS_ILM_DEBUG_DAY_SECS (Ceph lc_debug_interval equivalent) and an enabled
background scanner; it cannot share the default single-server gate because a
global debug day would also shrink the x-amz-expiration header asserted by the
test_lifecycle_expiration_header_* cases. See scripts/s3-tests/run.sh
(IMPLEMENTED_TESTS_FILE override) and the s3-lifecycle-behavior-tests job in
.github/workflows/ci.yml.
Supported Coverage
The implemented test list currently covers the common object-storage surface:
| Area | Status | Evidence |
|---|---|---|
| Bucket create/delete/list/head | Supported | implemented_tests.txt |
| Object put/get/delete/copy/head | Supported | implemented_tests.txt |
| CopyObject checksums (CRC32, CRC32C, CRC64NVME, SHA1, SHA256, MD5, SHA512, XXHASH3, XXHASH64, XXHASH128), including source preservation and explicit override | Supported in the first RustFS release containing this change | crates/e2e_test/src/copy_object_checksum_test.rs |
| ListObjects/ListObjectsV2 prefix, delimiter, marker, max-keys | Supported | implemented_tests.txt |
| Multipart upload create/upload/complete/abort and selected multipart copy/checksum/object-attribute behavior | Supported | implemented_tests.txt |
| Bucket and object tagging | Supported | implemented_tests.txt |
| Bucket policy put/get/delete | Supported | implemented_tests.txt |
| Public access block put/get/delete | Supported | implemented_tests.txt |
| Presigned GET and PUT URLs | Supported | implemented_tests.txt |
| Range and conditional reads | Supported | implemented_tests.txt |
| User metadata | Supported | implemented_tests.txt |
| SSE-C and selected SSE-KMS edge cases | Supported | implemented_tests.txt |
| Selected versioning, object-lock, checksum, CORS, raw request, and conditional write behavior | Supported | implemented_tests.txt |
"Supported" for the SSE row means RustFS encrypts and decrypts its own objects. It does not mean RustFS can read objects another implementation encrypted: objects MinIO wrote with SSE-S3, SSE-KMS, or SSE-C are not readable by RustFS today, which matters when migrating. See MinIO file-format interoperability, Part C and rustfs/backlog#1638.
Planned Standard Coverage
These are standard S3 areas that remain planned work and must not be described as already complete:
| Area | Status | Evidence |
|---|---|---|
| Bucket access logging | Planned | unimplemented_tests.txt |
| POST Object form upload checksum handling | Planned | unimplemented_tests.txt |
| Bucket ownership controls | Planned | unimplemented_tests.txt |
| Multipart upload listing and part lookup compatibility edge cases | Not part of default gate | excluded_tests.txt |
| IAM-account or multi-storage-class dependent cases | Not part of default gate | unimplemented_tests.txt |
| Tenanted bucket policy edge cases | Needs investigation | unimplemented_tests.txt |
Intentional Exclusions
excluded_tests.txt contains tests that should not block the RustFS
compatibility gate. They fall into two classes:
- vendor-specific or non-portable behavior not required for RustFS S3 compatibility;
- intentionally unsupported product behavior, such as ACL authorization.
Update Rule
When a planned S3 feature is implemented, move its passing test entries from
unimplemented_tests.txt to implemented_tests.txt, update this matrix, and
avoid changing README wording beyond the supported coverage.