mirror of
https://github.com/rustfs/rustfs.git
synced 2026-08-06 05:17:42 +00:00
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.
83 lines
4.8 KiB
Markdown
83 lines
4.8 KiB
Markdown
# 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](minio-file-format-compat.md#part-c--server-side-encryption-sse) 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.
|