mirror of
https://github.com/rustfs/rustfs.git
synced 2026-08-02 11:29:17 +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.