v1.8.0

Ignore packages with abnormal dist plugins

Some Composer plugins install multiple dist archives under a single package@version. The clearest example is statamic/cms, which uses pixelfear/composer-dist-plugin to fetch both dist.tar.gz and dist-frontend.tar.gz — both presenting as statamic/cms@dist. Because the integrity model records one set of metadata per package@version, the second archive looked exactly like a drifted dist URL and hard-failed:

[Soak Time] Integrity metadata drift for statamic/cms@dist.
  Field:     dist URL
  Recorded:  …/v5.73.24/dist.tar.gz
  Candidate: …/v5.73.24/dist-frontend.tar.gz

New: soak-time-integrity-ignore

There is no safe way to auto-support this — accepting a new dist URL under an already-pinned version on a package's say-so is precisely the altered-historical-release surface the plugin exists to close. Instead, you can now manually greenlight a package after verifying its installs:

{
    "extra": {
        "soak-time-integrity-ignore": ["statamic/cms"]
    }
}

Or as a comma-separated env var for a one-run override:

SOAK_TIME_INTEGRITY_IGNORE=statamic/cms composer update

A listed package is exempt from all integrity checks (drift, hash, and recording). Patterns follow the same rules as the whitelist — the vendor must be a literal, * is allowed only in the name half. A warning naming the ignored package(s) prints on every run so the weakened coverage stays visible, and the soak/freshness filter is unaffected.

See SECURITY_MODEL.md for why this is an explicit operator opt-in rather than automatic behaviour.

Full changelog: v1.7.0...v1.8.0