From ace78918bd1568b8c9bbb8138eadd8c331d69807 Mon Sep 17 00:00:00 2001
From: James Rich <2199651+jamesarich@users.noreply.github.com>
Date: Tue, 15 Sep 2026 11:02:34 -0500
Subject: [PATCH] Record integrity hashes for the four @buf lockfile entries

The @buf packages resolve through buf.build's npm registry, whose packument
carries only a tarball URL - its `dist` has no `integrity` and no `shasum`.
pnpm 8, which wrote these entries, took that at face value and recorded no
hash. pnpm 10 turned a missing hash from a warning into a hard error, so any
install on pnpm 10 or 11 fails against this lockfile:

  pnpm 11.25.0  ERR  the lockfile contains entries that the active policies
                     reject (all four named)
  pnpm 10.34.4  ERR  ERR_PNPM_MISSING_TARBALL_INTEGRITY
  pnpm  9.15.9  ok   - which is why CI is green; it pins 9

Newer pnpm computes the hash from the downloaded tarball, but only on a fresh
resolution: it will not reuse an entry it has already rejected, so
`--no-frozen-lockfile` does not repair it and a full regeneration would move
every unrelated dependency at the same time.

So write just the hashes. Each is the sha512 of the tarball buf.build serves
today, which is byte-identical to what pnpm 11 computes when it resolves these
packages from scratch. No version changes, no resolution changes.

Verified against all three majors with the repo's own steps - `pnpm install
--ignore-scripts=false`, `pnpm build` (dist/index.js emitted), and
`pnpm validate:maintenance-uf2`. The lockfile is byte-stable after each.
---
 pnpm-lock.yaml | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml
index c169e4e..f842cf3 100644
--- a/pnpm-lock.yaml
+++ b/pnpm-lock.yaml
@@ -163,22 +163,22 @@ packages:
     os: [win32]
 
   '@buf/meshtastic_api.bufbuild_es@1.6.0-20240110092216-3a147af14302.1':
-    resolution: {tarball: https://buf.build/gen/npm/v1/@buf/meshtastic_api.bufbuild_es/-/meshtastic_api.bufbuild_es-1.6.0-20240110092216-3a147af14302.1.tgz}
+    resolution: {tarball: https://buf.build/gen/npm/v1/@buf/meshtastic_api.bufbuild_es/-/meshtastic_api.bufbuild_es-1.6.0-20240110092216-3a147af14302.1.tgz, integrity: sha512-Bp5y1CMJKbV7wdwbkt4RyIkKq/2+ZY75Wb0VJZs2b5uk1i5UvWRTmYflgPpc0RewXSSdyBYDfU82q2Y9upxQPQ==}
     peerDependencies:
       '@bufbuild/protobuf': ^1.6.0
 
   '@buf/meshtastic_api.bufbuild_es@1.7.2-20240110092216-3a147af14302.1':
-    resolution: {tarball: https://buf.build/gen/npm/v1/@buf/meshtastic_api.bufbuild_es/-/meshtastic_api.bufbuild_es-1.7.2-20240110092216-3a147af14302.1.tgz}
+    resolution: {tarball: https://buf.build/gen/npm/v1/@buf/meshtastic_api.bufbuild_es/-/meshtastic_api.bufbuild_es-1.7.2-20240110092216-3a147af14302.1.tgz, integrity: sha512-G1+PEr0XHM4s5y+poOkrveCysmnpPVdGCZjSAj62FsR5s93H3MO2jZNAbMp1DXq8/Wch9SpAzR/Hc2PK9jGIhA==}
     peerDependencies:
       '@bufbuild/protobuf': ^1.7.2
 
   '@buf/meshtastic_api.connectrpc_es@1.3.0-20240110092216-3a147af14302.1':
-    resolution: {tarball: https://buf.build/gen/npm/v1/@buf/meshtastic_api.connectrpc_es/-/meshtastic_api.connectrpc_es-1.3.0-20240110092216-3a147af14302.1.tgz}
+    resolution: {tarball: https://buf.build/gen/npm/v1/@buf/meshtastic_api.connectrpc_es/-/meshtastic_api.connectrpc_es-1.3.0-20240110092216-3a147af14302.1.tgz, integrity: sha512-vMF98Ky0u+rAYBh+8cUDB0DkPCtSeTzJypKCXIlCHYXnlwWSj3wfyHUkkHDLyKMueK0uzm6+MedpoexfXvl4jw==}
     peerDependencies:
       '@connectrpc/connect': ^1.3.0
 
   '@buf/meshtastic_protobufs.bufbuild_es@1.7.2-20240216123215-6b07c41c68c9.1':
-    resolution: {tarball: https://buf.build/gen/npm/v1/@buf/meshtastic_protobufs.bufbuild_es/-/meshtastic_protobufs.bufbuild_es-1.7.2-20240216123215-6b07c41c68c9.1.tgz}
+    resolution: {tarball: https://buf.build/gen/npm/v1/@buf/meshtastic_protobufs.bufbuild_es/-/meshtastic_protobufs.bufbuild_es-1.7.2-20240216123215-6b07c41c68c9.1.tgz, integrity: sha512-NwYqxFfKcbVL6pLWeNtA/680utPwdYfriEjo2FuFAa+GC6+Z92uYt2ePBcVugS9+mbwd8clPel4nbN2aCNfJbg==}
     peerDependencies:
       '@bufbuild/protobuf': ^1.7.2