mirror of
https://github.com/pgadmin-org/pgadmin4.git
synced 2026-11-02 08:10:03 -06:00
The install-pgbuild-deps action fetched PostgreSQL, OpenSSL, Kerberos, zstd and lz4 from pgbuild release tags ending in -latest, whose assets are replaced in place on every rebuild, and unpacked them with no checksum or signature check anywhere in between. Since the resulting build is Authenticode signed on Windows and Developer ID signed and notarised on macOS, that made write access to pgbuild equivalent to write access to what pgAdmin ships, and it meant a build was not reproducible either, the same commit producing different binaries depending on the day it was built. This is pgadmin-org/pgbuild issue 1. pkg/pgbuild-deps.lock now records, for every dependency the action can fetch on either macOS architecture and on Windows, the per-version release tag to download from and the SHA-256 its archive must hash to. The action fetches that tag, checks the digest before unpacking, and fails on a mismatch or on a dependency the lock does not mention, since an unpinned dependency reaching a signing build is the thing this is meant to prevent. pgbuild publishes a .sha256 beside each archive, which is deliberately not consulted: whoever rebuilds an archive rebuilds that too, so the lock is the only thing here that pins anything. Being out of date is a different matter from being wrong, so once an archive is verified the action asks pgbuild what it has published since, and warns rather than fails when the pinned build is no longer the newest. That check is best effort and never fails a build whose downloads have already been verified. tools/refresh_pgbuild_lock.py rewrites the lock, taking the version to pin from pgbuild's own manifest.json and working one package at a time so that bumping OpenSSL does not restate every other digest. The diff it produces, with the upstream version visible in the tag column, is the audit trail the previous arrangement had none of. The digests were taken from the archives pgbuild publishes today, which are the same archives its per-version releases will carry, but those releases do not exist yet, so the tags in the lock cannot be fetched until pgbuild's own change lands.