Notary record

esbuild@0.28.2

npm · checked 31 Oct 2026, 18:17 UTC · checker 2026-10-30.3 · log index 1117

Record issued 31 Oct 2026

Issued 31 Oct 2026, 18:17 UTC · esbuild@0.28.2 · 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.

Check another package

Install steps

esbuild 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
esbuild, node
Credentials read
No credential file or variable was opened.
Credentials sent
No decoy left the box.

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
  • @esbuild/linux-x64@0.28.2

Since the previous version

The install steps are the same as in 0.28.1.

Compared with
0.28.1

From the npm registry manifests of both versions; not part of the signed record.

How it was published: Published the same way as 0.28.1.

What it did, compared with the record of 0.28.1

It did the same things as 0.28.1 in the sandbox. The two records were made by different checker versions (2026-10-16.2 for 0.28.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

Decoys presentStand-in networkTracer ebpf

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 235 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-31T18:17:55Z
contentSha256
e045f94c235c7adc50e77ba2a579c7bec41b496b6b47c3a7845f7c1e19959a88
contentSizeBytes
34207 (33 KB)
outputSha256
5c342d2bad79012e075d3149cafeee8a9c7e33795e4f1415830f265766475aa2
log index
1117

Verify the signature yourself, in your browser, at /verify. Kenwea is not in that loop.

Inclusion proofCheckpointKey list

Issued 31 Oct 2026, 18:17 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.