workerd@1.20261031.1
npm · checked 31 Oct 2026, 01:01 UTC · checker 2026-10-30.3 · log index 1096
Record issued 31 Oct 2026
Issued 31 Oct 2026, 01:01 UTC · workerd@1.20261031.1 · npm
quiet
Its install steps ran with decoy credentials in reach and touched nothing we watch.
Its install steps ran here, with decoy credentials in reach, and touched nothing we watch: no network, no credential files. That is evidence, not proof: code can wait for a different machine or run later, when it is used. Loading it once, as an application would, touched nothing we watch either.
The trace shows what a step attempted. A quiet trace is evidence, not proof.
Install steps
workerd runs this install step of its own:
- postinstall
No dependency runs anything at install.
What the install steps reached
No install step reached anything we watch.
- Programs
- node
- Credentials read
- No credential file or variable was opened.
- Credentials sent
- No decoy left the box.
- Looked for
- workerd
The record keeps what all the install steps reached together; it does not say which step did which.
First import
It was imported once, as an application would, and exited 0.
It reached nothing we watch.
- Programs
- node
- Credentials read
- No credential file or variable was opened.
- Credentials sent
- No decoy left the box.
Dependencies
1 of 1 installed, as npm would on linux x64 musl.
Show all 1
- @cloudflare/workerd-linux-64@1.20261031.1
Since the previous version
The install steps are the same as in 1.20261030.1.
- Compared with
- 1.20261030.1
From the npm registry manifests of both versions; not part of the signed record.
How it was published: Published the same way as 1.20261030.1.
What it did, compared with the record of 1.20261030.1
It did the same things as 1.20261030.1 in the sandbox. The two records were made by different checker versions (2026-10-19.2 for 1.20261030.1, 2026-10-30.3 for this one), so a difference may come from the checker rather than the package.
- Level
- quiet
A comparison of the notary's signed records of both versions, made when this page is read; not part of either signature. A difference is a lead, not a verdict: two runs can differ for the sandbox's reasons too.
Sandbox
network=none; capabilities=all-dropped; rootfs=read-only; user=nobody; harness=separate-user
The kernel tracer attached every probe before the steps started and saw 225 events across 3 traced steps, with none lost.
image sha256:affcfb39dcdfcd08dedf907b2ab5f89da46fc2ddbf1a237f2e498f03d892c208
Signature and transparency log
- level
- quiet
- verdict
- approved
- reasonCode
- ran_ok
- keyId
- 322a2536e0d5ec8e
- algorithm
- ed25519
- checker
- 2026-10-30.3
- issuedAt
- 2026-10-31T01:01:37Z
- contentSha256
- f2a3aa9400f280822bd02e2cd2fc157b84b96f5e17c0939ac96e30e5fb23c00d
- contentSizeBytes
- 1289203 (1.2 MB)
- outputSha256
- 83fcf7bc59bff7d5cf44978308554d8ba80206ad2cceb23e0ad4c735218145da
- log index
- 1096
Verify the signature yourself, in your browser, at /verify. Kenwea is not in that loop.
Inclusion proofCheckpointKey list
Issued 31 Oct 2026, 01:01 UTC
What this does and does not say
The claim is about the bytes, not the name.
The signature covers these exact bytes. Another version is another check.
A quiet trace is evidence, not proof.
Code that only runs later, when your app calls it, is out of reach.
A signature is not an endorsement.
It says what happened, not that the code is good.
Twenty checks an hour for each network address. When a limit is ours, the record says unfinished and names it.