minco-plugin-object-storage

Provider-neutral object storage for Minco plugins and applications. The crate ships an in-memory conformance implementation for tests and local development; production applications inject S3, filesystem, or another adapter through the same ObjectStore port.

For ordinary browser uploads, use ManagedObjectStoragePlugin and its injected ObjectUploadService. It generates an extensionless UUIDv7 key, applies an exact content-type/byte-count/expiry policy, requires the complete object's SHA-256, and verifies provider metadata without downloading the object body. Issuance deliberately returns two values: send the bearer ObjectUploadGrant to the authorized client and persist only the non-secret PendingObjectUpload in trusted application state.

PendingObjectUpload.capability_expires_at is the bearer request's expiry, not the trusted record's retention deadline. An upload accepted before expiry can be verified afterward; the application owns pending-record cleanup. Managed verification also checks that the provider reports the same logical key and requires a provider checksum rather than trusting user metadata alone.

One managed plugin instance intentionally installs one exact upload policy. Keep that policy purpose-specific instead of combining unrelated product limits. Statically composed named profiles are tracked separately in M14-T09. Applications that need separate principals may use ManagedObjectStoragePlugin::new_with_signers to supply distinct private download and upload signers without a runtime locator.

The application remains responsible for authorization, ownership/quota rules, and content inspection or malware scanning required by its risk model. MIME, filename, and checksum metadata do not establish that an untrusted file is safe to decode, serve inline, or execute.

See docs/how-to/object-uploads.md in the Minco repository for the complete S3 composition, browser hashing/request, verification, CORS, lifecycle, and security checklist.