Files
pgadmin4/pkg/publish/authorized_keys.paxsor
T
Dave Page 1545bcc91c Send snapshots to the download server, not to staging
I had the two flows conflated. Release candidates are staged on the
development server and promoted; snapshots are published straight to the
download server under snapshots/<date>, which is what every
*-snapshot job in the buildfarm targets.

So the publish job talks to the download server, the wrapper grows the
snapshot verbs it needed and loses snapshot-fetch, which existed only to
copy a staging build that is never made, and the variable is named for
the server it actually names.

It also reverses my advice about the upload key on the download server,
which I had said to drop on the reasoning that publication always pulls
from procyon. It does not, for snapshots. The key comes back, confined
to the snapshots tree, which is the right root on two counts: it is
where snapshots belong, and it is the one part of the download site that
the S3 sync excludes, so nothing written through it can reach the
archive or the mirrors.

snapshot-purge replaces the buildfarm's ls | tail | xargs rm. It is the
only verb that deletes anything, so it takes no argument: it cannot be
asked to remove a particular snapshot, only to enforce the retention the
server already has, and it ignores directories that do not look like a
snapshot.
2026-09-17 13:25:06 +01:00

53 lines
3.0 KiB
Plaintext

# ~pgaupload/.ssh/authorized_keys on paxsor (ftp.pgadmin.org)
#
# The same two keys as on procyon, with the same options and for the same
# reasons; read the annotations in authorized_keys.procyon first, since they
# are not repeated here. What differs is the blast radius, because this host
# serves the packages that end users install, and the yum and apt signing keys
# live here.
#
# Placeholders in angle brackets must be substituted at install time:
#
# <ROADIE-IPV4>, <ROADIE-IPV6> the runner's addresses
# <...KEY...> the public key, one line, no line breaks
#
# Note that these are the same two key pairs as on procyon, not four. One
# publishing key and one upload key, each trusted by both hosts, each confined
# differently on each host by the options below. Two more key pairs would mean
# two more things to rotate and no reduction in what a compromised runner can
# reach, since a compromised runner has both of them anyway.
# ---------------------------------------------------------------------------
# Key 1: publishing. Verbs only.
# ---------------------------------------------------------------------------
# What a holder of this key can do on paxsor: create a v<VERSION> or snapshot
# directory (refusing if it already exists), pull the matching staging content
# from procyon, rebuild and sign the apt and yum metadata for an allowlisted
# distribution, and run the four existing publication scripts with arguments
# that have been validated or allowlisted first.
#
# What it cannot do, and this is the point of the exercise: delete anything,
# name a file, name a path, name a host, name a signing key, choose which
# binary runs, or supply a single character that reaches a shell.
restrict,from="<ROADIE-IPV4>,<ROADIE-IPV6>",command="/usr/local/sbin/pga-publish" ssh-ed25519 <...PUBLISH-KEY...> pga-publish@roadie
# ---------------------------------------------------------------------------
# Key 2: upload. Bytes only, and only into the snapshots tree.
# ---------------------------------------------------------------------------
# Snapshots are built straight onto this server rather than staged on procyon
# and promoted, so unlike the release flow they do need an upload path here.
#
# The confinement root is the snapshots tree itself, which is the right place
# on two counts. It is where snapshots belong, and it is the one part of the
# download tree that sync-ftp-to-s3.py excludes, so nothing written through
# this key can reach the archive bucket or the PostgreSQL mirrors. A key
# confined anywhere else under /var/ftp would have both of those as a side
# effect of a single bad upload.
#
# Retention is not this key's business either: the wrapper's snapshot-purge
# verb enforces it, and -no-del means this key cannot remove a snapshot even
# if asked to.
#
# SITE: check `command -v rrsync`; the path moved between rsync packages.
restrict,from="<ROADIE-IPV4>,<ROADIE-IPV6>",command="/usr/bin/rrsync -wo -no-del -munge /var/ftp/pgadmin4/snapshots" ssh-ed25519 <...UPLOAD-KEY...> pga-upload@roadie