@pierre/theme@1.1.0 missing npm provenance attestation

[Zihad550]

@pierre/theme@1.1.0 appears to have lost npm provenance attestation

mise/aube reports:

trust downgrade for @pierre/theme@1.1.0
earlier published version 0.0.20 had provenance attestation
but this version has no trust evidence

mise version: 2026.8.3
platform: Linux x64

command:
mise use -g npm:t3

[amadeus]

I'm sorry, i'm not sure what npm provenance attestation is? nor do i know what we need to fix here.

[Zihad550]

Hope this helps.
"An npm provenance attestation is basically a cryptographically verifiable record that tells you where and how an npm package was built and published."
https://docs.npmjs.com/generating-provenance-statements

npm can verify registry signatures and provenance using: npm audit signatures

[amadeus]

I don't think we've ever done this for any of our packages? Also we intentionally do not use any cloud based publishing.

[Zihad550]

Thanks for the clarification! I’ll close the issue.

[connorads]

Late to this and I may be missing context, but I think the premise it closed on doesn't quite hold. As far as I can tell @pierre/theme did ship provenance, on 13 of its 16 published versions, unbroken from 0.0.20 (2026-01-09) to 1.0.3 (2026-05-18).

curl -s 'https://registry.npmjs.org/-/npm/v1/attestations/@pierre%2ftheme@1.0.3'

Decoding the SLSA statement in that bundle:

externalParameters.workflow.repository : https://github.com/pierrecomputer/theme
externalParameters.workflow.path       : .github/workflows/publish.yml
externalParameters.workflow.ref        : refs/tags/v1.0.3
runDetails.builder.id                  : https://github.com/actions/runner/github-hosted

All 13 look like that, same repo, same workflow, tag ref each time. Provenance then stops: 1.1.0 (26 June) and 2.0.0 (24 July) have none, and the attestations endpoint 404s for both. Only 0.0.18, the very first publish, predates it.

My guess is that nobody chose this. #819 moved theme into the monorepo on 17 June, and 1.1.0 was the first release after, on 26 June. pierrecomputer/theme is still public and its .github/workflows/publish.yml still runs on release: [published] with npm publish --access public --provenance. The monorepo has no publish workflow, so the provenance looks like it was left behind by the move rather than turned off. Happy to be told I've read that wrong.

A question rather than a request, since I don't know how you split the repos. @pierre/storage@1.16.2 went out on 29 July from pierrecomputer/sdk via GitHub Actions with trusted publishing and provenance, so at least some of the scope is still publishing that way. Would it be reasonable for the monorepo to match it on future releases?

I should be clear that this isn't a flag you can just add. npm only issues provenance from CI, so a local publish can't produce one, and 2.0.0 can't gain an attestation after the fact. Anyone currently blocked stays blocked until a provenance-carrying theme release ships and @pierre/diffs bumps its exact pin.

The reason I care: @pierre/diffs pins @pierre/theme exactly, so anything depending on diffs fails aube's trust check out of the box, since aube defaults trustPolicy to no-downgrade. pnpm has the same check but ships it off, so it only bites people who turned it on. It isn't only t3, hunkdiff hits it too.

Not asking anyone to reopen this. Mostly leaving the data where the next person searching will find it.

[amadeus]

Storage and SDK stuff is run from a different repo completely and housed under another system.

Theme used to be under it's own private repo that did use github actions for publishing, but given all the new exploits coming out around npm/github/github actions and publishing, we've opted for only manual local publishes going forward for anything in this monorepo.

Also what I don't get is that @pierre/diffs has never had provenance to begin with, so why does a single dep matter?

Also please don't use AI to generate your responses, please hand write everything.

[sarendipitee]

I ran into this problem today too while trying to install an npm package called omniroute.

This IS a big issue. If a package that has attestation all the sudden gets a new version uploaded without it, it is a telltale sign of a malicious entity having gained control of the npm account and uploading an infected payload. So every npm security scanner out there flags it as a security breach.

I really do not think you should let this slide lest more and more companies move away from your packages due to security scanners flagging it as vendor risk.