Skip to content

v0.6.0 — Object lock

Choose a tag to compare

View all tags
@incognick incognick released this 16 Jun 05:13
· 56 commits to main since this release
Immutable release. Only release title and notes can be modified.
v0.6.0
bddc3bc

The sixth Hamster release: object lock — WORM retention and legal holds over the versioned keyspace, on both the single-node store and the erasure-coded cluster. This is the compliance heart of Hamster's positioning, and the release where the "no override for COMPLIANCE" invariant stops being a promise and becomes a tested guarantee.

Dev preview, and read the limits below. Object lock is implemented and the COMPLIANCE guarantee is real, but the surrounding v0.x limits hold: on the cluster path writes commit only on the Raft leader (a non-leader answers 503 SlowDown), multipart and server-side copy are still not on the cluster path, and on-disk/on-wire formats may still change between v0 releases. Hamster is not assessed or certified for any retention regulation (see "What this is not"). Please don't trust real regulated data to it yet.

What's in v0.6

The metadata has carried the lock fields since v0.1, so this release is the S3 surface that exposes them — no schema migration to turn object lock on.

  • Lock-enabled buckets and default retention. Create a bucket with x-amz-bucket-object-lock-enabled: true (it enables versioning, which object lock requires). Put/GetObjectLockConfiguration sets an optional bucket default retention — a mode plus a duration in days or years, the S3 shape — applied to new objects that arrive without their own.
  • Per-object retention. Put/GetObjectRetention and the x-amz-object-lock-mode / x-amz-object-lock-retain-until-date headers on PUT, surfaced back on GET/HEAD. Retention expires on its date; until then the version is WORM-protected.
  • Legal holds. Put/GetObjectLegalHold (Status ON/OFF) and the x-amz-object-lock-legal-hold PUT header. A hold blocks deletion with no expiry, independent of retention.
  • Two modes, honestly. GOVERNANCE yields to x-amz-bypass-governance-retention; COMPLIANCE does not — no header, no flag, no operator, no "root" can delete or shorten a COMPLIANCE-locked version before its retention expires. The guard lives in the metadata apply layer, the one layer no request path can bypass.
  • All of it on the cluster. The same surface runs over cluster run -s3: the lock headers thread through the erasure-coded write path, and reads carry the lock state.

How it's verified

  • Invariant 4 is now executable. An adversarial metadata test drives every delete-or-shorten path against a COMPLIANCE-locked version — delete by id, delete with a governance bypass, shorten, remove with bypass, downgrade to GOVERNANCE, drop the bucket — and proves each one refuses, the version's retention surviving untouched, while a later date (strengthening) is allowed.
  • A gateway test enforces the same 403 over the HTTP surface, and a cluster end-to-end test proves it over real processes and the erasure-coded data path: an object stored under COMPLIANCE retention reads back with its lock headers and refuses deletion across the cluster.
  • The real aws CLI under task compat exercises create-bucket --object-lock-enabled-for-bucket, put/get-object-lock-configuration, put-object with retention, get-object-retention, and put/get-object-legal-hold. rclone, restic, s3cmd, the race detector, and the deterministic simulation harness keep passing.

What this is not

Object lock is a WORM mechanism; describe it precisely. AWS's S3 Object Lock has been assessed for SEC Rule 17a-4(f), FINRA 4511, and CFTC 1.31 — Hamster has not, by anyone. It implements the building block those rules require, which is necessary but not sufficient. And GOVERNANCE mode is not access-controlled: Hamster has no per-user authorization yet, so the governance bypass header is honored for any authenticated request — real soft-delete protection, but not AWS's IAM-gated gradient. (COMPLIANCE is unaffected; it has no bypass at all.) See S3-API.md for the full boundary.

Binaries below are static (CGO_ENABLED=0), version-stamped (hamster version), with SHA-256 checksums in SHA256SUMS. Next up, v0.7: encryption at rest — envelope encryption over the framed object stream (SSE-S3), with the cluster CA's custody and rotation riding along as the keys problem they are.

Assets 8
Loading