mirror of
https://github.com/rustfs/rustfs.git
synced 2026-08-19 11:06:17 +00:00
overtrue
035a6f431a
The migration warning said RustFS cannot read MinIO-encrypted objects at all. That is no longer true for the shapes this branch fixes, and a blanket 'no' costs a migrating operator a full decrypt-and-recopy they may not need. It is replaced by a table that states support per object shape, with the test that establishes each row. The table's honesty depends on one caveat worth stating in code rather than prose: every interop reader test injected its master key through __RUSTFS_SSE_SIMPLE_CMK, which is #[cfg(test)]-only and never reaches LocalSseDekProvider::new_from_env. Those tests going green therefore said nothing about a deployment. A new case reads a fixture through RUSTFS_SSE_S3_MASTER_KEY alone — the sole production entry point — so the claim now rests on the path operators actually run. Single-part and SSE-C objects are listed as unverified rather than unsupported, because the fixture harness cannot yet load them (small objects live inline in xl.meta, sharded across disks) and they have never been read in a test either way. Conflating 'untested' with 'broken' in the other direction would be the same failure the old warning made. The reverse direction gets an explicit ruling: MinIO cannot read RustFS-written objects, and the MinIO-branded headers RustFS writes are RustFS-internal rather than a compatibility promise — no coexistence plan should assume two-way reads. StaticConfig's doc comment is corrected on the same basis: it described MinIO's ciphertext as the legacy JSON encoding, and claimed MinIO-written objects cannot be read at all, which now belongs to the object read path rather than to this backend. Refs rustfs/backlog#1638.