go.mod advertises a minio/pkg v3.6.1 floor the source cannot honor

[Vonng]

Summary

go.mod declares require github.com/minio/pkg/v3 v3.6.1, but cmd/policy-validation.go needs the SILO package: policy.ParseConfigStrict first appears upstream in v3.11.0, and policy.Resource.IsBareARN exists in no upstream version at all.

mc's own builds are correct — its replace selects silo-pkg. The problem is the metadata a consumer reads, since replacements are not inherited.

Why the floor matters

Verified against the real modules:

symbol	upstream v3.6.1	upstream v3.11.0	silo-pkg v3.12.x
policy.ParseConfigStrict	absent	present	present
policy.Resource.IsBareARN	absent	absent	present

The compile-time sentinel is doing real work, and it is not merely cosmetic:

// Require the v3.12 policy implementation even when a consuming module
// overrides mc's module replacement with its own silo-pkg version.
var _ func(policy.Resource) bool = policy.Resource.IsBareARN

Removing it and building against upstream v3.11.0 compiles cleanly and then fails this repository's own test:

--- FAIL: TestParsePolicyForWriteRejectsBareARNs
    strict write parser accepted bare ARN policy:
    {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["s3:GetObject"],"Resource":["arn:aws:s3:::"]}]}

So upstream's ParseConfigStrict does not reject bare ARNs; only silo-pkg's does. Without the sentinel, a consumer that resolves upstream minio/pkg gets a silent downgrade of policy-write validation rather than a build error. That is the failure mode the sentinel converts into something loud, and it should not simply be deleted.

What is actually wrong

Only the advertised floor. require v3.6.1 cannot be made truthful by raising the number, because no upstream version provides the semantics mc depends on. Pick a contract and make the metadata and docs match it:

A. Fork-locked (matches today's source). Keep the sentinel, state in go.mod, README, and the compatibility notes that mc requires the SILO package's strict policy semantics and that the replacement is mandatory, and stop implying upstream-package portability. Raise require to v3.11.0 so at least the API floor is honest.

B. Upstream-portable. Apply the bare-ARN and strict-write checks locally, the way silo-console does in api/policy_validation.go using only ParseConfig, ResourceARNAll, and ARNPrefixToType. The sentinel then becomes unnecessary and require v3.6.1 becomes true again. Cost: a second implementation of the strict rules that can drift from the server's.

TestParsePolicyForWriteRejectsBareARNs already asserts the behavior either option must preserve, so whichever is chosen is covered.

Not release-gating

mc's shipped builds resolve silo-pkg and behave correctly. Raised while fixing the related silo-console compatibility gate (pgsty/silo-console#11), which is a separate defect and is fixed there.