Retry stapler validate in the macOS build and acceptance checks. (#10686)

It looks the notarisation ticket up in Apple's CloudKit, and a dropped
connection there has failed both the arm64 build's verification step,
skipping the rest of a release candidate, and the acceptance test, on
bundles that were notarised and accepted by Gatekeeper.

.gitattributes

@@ -1,2 +1,7 @@
 # Auto detect text files and normalize end of lines to LF (\n)
 * text=auto eol=lf
+
+# Make.bat has always been stored with CRLF; the blanket eol=lf above would
+# silently rewrite the whole file the first time anything touches it.
+Make.bat -text
+pkg/win32/*.bat text eol=crlf

.github/actions/install-pgbuild-deps/action.yml

@@ -0,0 +1,338 @@
+# Installs the PostgreSQL build dependencies published by pgadmin-org/pgbuild.
+#
+# Four workflows need these — the QA and snapshot builds on each of macOS and
+# Windows — and keeping the logic in one place is not merely tidiness: the
+# first version used the gh CLI, which turned out not to exist on the
+# self-hosted Windows runner, and that same fix had to be made twice.
+#
+# On macOS the archives must land in /opt/pgbuild specifically, because the
+# install names inside them are absolute: pg_dump asks for
+# /opt/pgbuild/zstd/lib/libzstd.1.dylib and libpq for
+# /opt/pgbuild/krb5/lib/libgssapi_krb5.2.2.dylib, among others. _fixup_imports
+# copies from those paths into the bundle and rewrites the references, so they
+# have to resolve at build time. On Windows there are no absolute references,
+# so the location only has to avoid colliding with anything else, which is why
+# it goes under the runner's temp directory rather than the C:\build64 the
+# buildfarm's Jenkins worker manages.
+#
+# Everything is fetched over plain HTTPS. pgbuild is public and its asset URLs
+# are predictable, so this needs neither a CLI nor authentication, and both
+# curl --fail and Invoke-WebRequest fail on a 404 rather than writing an error
+# page to disk and failing later at the unpack.
+#
+# What gets downloaded is decided by pkg/pgbuild-deps.lock rather than by the
+# rolling -latest tags, whose assets pgbuild replaces in place on every
+# rebuild. Building from those means that what is Authenticode signed on
+# Windows and Developer ID signed and notarised on macOS is whatever pgbuild
+# happened to be publishing that morning, which is neither reproducible nor
+# something anybody reviewed. The lock names a per-version tag and the SHA-256
+# of its archive, and an archive that does not hash to the recorded digest, or
+# that has no lock entry at all, fails the build rather than being unpacked
+# unverified. pgbuild publishes a .sha256 beside each archive, which is
+# deliberately not consulted: whoever rebuilds an archive rebuilds that too, so
+# it is a convenience rather than a source of trust, and the lock is the only
+# thing here that pins anything.
+#
+# Being out of date is a different thing from being wrong, so once an archive
+# has been verified, pgbuild's releases are consulted to see whether a newer
+# build of that dependency exists, and if one does the job carries a warning
+# naming it. It stays a warning, because the build goes on to ship the pinned
+# version and a dependency published overnight is no reason to turn pgAdmin
+# red, and the check is best effort, so an API that will not answer leaves a
+# build whose downloads are already verified alone.
+# tools/refresh_pgbuild_lock.py is what turns such a warning into a reviewed
+# commit.
+
+name: Install pgbuild dependencies
+description: Download and unpack the PostgreSQL build dependencies from pgadmin-org/pgbuild
+
+inputs:
+  arch:
+    description: Architecture as pgbuild names it, e.g. arm64, x86_64
+    required: true
+  postgres-major:
+    description: PostgreSQL major version to install
+    required: false
+    default: '18'
+
+outputs:
+  prefix:
+    description: Directory the dependencies were unpacked into
+    # Whichever of the two platform steps ran. Merging these in a shell step
+    # instead would mean picking a shell that exists on every runner, and the
+    # Windows signing host has no bash.
+    value: ${{ steps.install-macos.outputs.prefix || steps.install-windows.outputs.prefix }}
+
+runs:
+  using: composite
+  steps:
+    - name: Install the pgbuild dependencies (macOS)
+      id: install-macos
+      if: runner.os == 'macOS'
+      shell: bash
+      env:
+        PGBUILD_ARCH: ${{ inputs.arch }}
+        POSTGRES_MAJOR: ${{ inputs.postgres-major }}
+        # Only so that the out-of-date check does not run into the
+        # unauthenticated rate limit, which is shared with everything else
+        # coming from a hosted runner's address and would leave the warning
+        # firing only sometimes. Nothing else here needs authentication,
+        # pgbuild being public.
+        GH_TOKEN: ${{ github.token }}
+      run: |
+        set -euo pipefail
+        BASE=https://github.com/pgadmin-org/pgbuild/releases/download
+        RELEASES=https://api.github.com/repos/pgadmin-org/pgbuild/releases
+
+        # GITHUB_ACTION_PATH rather than the workspace, so that the lock is
+        # found even where a workflow checks the repository out somewhere
+        # other than the default directory.
+        LOCK="${GITHUB_ACTION_PATH}/../../../pkg/pgbuild-deps.lock"
+
+        # The hosted macOS images have shasum, which comes with the system
+        # perl, but not sha256sum, whereas a Linux-alike self-hosted runner is
+        # the other way about, so take whichever is there.
+        if command -v shasum > /dev/null; then
+            sha256() { shasum -a 256 "$1" | cut -d' ' -f1; }
+        else
+            sha256() { sha256sum "$1" | cut -d' ' -f1; }
+        fi
+
+        # Column 2 of a lock line is the tag to fetch and column 3 the digest
+        # its archive must hash to. Trailing comments are stripped first,
+        # which also rebuilds awk's idea of the fields.
+        lock_field() {
+            awk -v key="$1" -v col="$2" '
+                { sub(/#.*/, "") }
+                $1 == key { print $col; exit }
+            ' "${LOCK}"
+        }
+
+        # pgbuild's tags, newest first, for the out-of-date check below. This
+        # is deliberately best effort: a build whose downloads have been
+        # verified must not fail because GitHub would not say what else has
+        # been published since.
+        TAGS="${RUNNER_TEMP}/pgbuild-tags.txt"
+        : > "${TAGS}"
+
+        if ! curl --fail --silent --location --max-time 30 \
+                -H "Accept: application/vnd.github+json" \
+                ${GH_TOKEN:+-H "Authorization: Bearer ${GH_TOKEN}"} \
+                "${RELEASES}?per_page=100" \
+                | grep -o '"tag_name": *"[^"]*"' \
+                | sed 's/.*"\(.*\)"/\1/' > "${TAGS}"; then
+            echo "Could not list pgbuild's releases, so this build will not"
+            echo "report whether its pinned dependencies are still current."
+        fi
+
+        sudo mkdir -p /opt/pgbuild
+        sudo chown "$(id -u):$(id -g)" /opt/pgbuild
+
+        for PKG in openssl krb5 zstd lz4 "postgresql-${POSTGRES_MAJOR}"; do
+            KEY="${PKG}-macos-${PGBUILD_ARCH}"
+            TAG=$(lock_field "${KEY}" 2)
+            EXPECTED=$(lock_field "${KEY}" 3)
+
+            if [ -z "${TAG}" ] || [ -z "${EXPECTED}" ]; then
+                echo "ERROR: ${KEY} has no entry in pkg/pgbuild-deps.lock"
+                echo
+                echo "An unpinned dependency must not reach a build we sign,"
+                echo "so this is a failure rather than a warning. Add it with:"
+                echo
+                echo "    tools/refresh_pgbuild_lock.py ${PKG%%-*}"
+                echo
+                echo "If this is a PostgreSQL major the lock has never seen,"
+                echo "add it to POSTGRES_MAJORS in that script first."
+                exit 1
+            fi
+
+            ARCHIVE="${TAG}.tar.gz"
+            echo "Fetching ${ARCHIVE}..."
+            curl --fail --silent --show-error --location \
+                -o "${RUNNER_TEMP}/${ARCHIVE}" "${BASE}/${TAG}/${ARCHIVE}"
+
+            ACTUAL=$(sha256 "${RUNNER_TEMP}/${ARCHIVE}")
+
+            if [ "${ACTUAL}" != "${EXPECTED}" ]; then
+                echo "ERROR: checksum mismatch for ${ARCHIVE}"
+                echo "    expected: ${EXPECTED}"
+                echo "    actual:   ${ACTUAL}"
+                echo
+                echo "The bytes behind ${TAG} are not the"
+                echo "ones that were reviewed when the lock was written."
+                echo "Usually that means pgbuild rebuilt the tag in place,"
+                echo "which it does for PostgreSQL whenever a new minor comes"
+                echo "out, that tag carrying only the major. Satisfy yourself"
+                echo "that a rebuild is what happened before re-running,"
+                echo "because this is also the one check standing between a"
+                echo "tampered dependency and a signed pgAdmin build, and then"
+                echo "record the new archive, read the diff and commit it:"
+                echo
+                echo "    tools/refresh_pgbuild_lock.py ${PKG%%-*}"
+                exit 1
+            fi
+
+            echo "Verified ${ARCHIVE} (sha256 ${ACTUAL})"
+
+            # The first tag of the right shape is the newest, the listing
+            # coming back in reverse chronological order. The rolling tag is
+            # skipped because it names no version.
+            NEWEST=""
+
+            while read -r CANDIDATE; do
+                case "${CANDIDATE}" in
+                    *-latest)
+                        continue
+                        ;;
+                    ${PKG}*-macos-${PGBUILD_ARCH})
+                        NEWEST="${CANDIDATE}"
+                        break
+                        ;;
+                esac
+            done < "${TAGS}"
+
+            if [ -n "${NEWEST}" ] && [ "${NEWEST}" != "${TAG}" ]; then
+                echo "::warning title=pgbuild dependency out of date::${KEY} is pinned to ${TAG}, but pgbuild has since published ${NEWEST}. This build is using the pinned version, which is what the lock file is for, and nothing is broken. To move to the newer build, run tools/refresh_pgbuild_lock.py ${PKG%%-*}, review the change to pkg/pgbuild-deps.lock and commit it."
+            fi
+
+            tar -xzf "${RUNNER_TEMP}/${ARCHIVE}" -C /opt/pgbuild
+        done
+
+        ls -l /opt/pgbuild
+        echo "prefix=/opt/pgbuild" >> "${GITHUB_OUTPUT}"
+
+    - name: Install the pgbuild dependencies (Windows)
+      id: install-windows
+      if: runner.os == 'Windows'
+      shell: powershell
+      env:
+        PGBUILD_ARCH: ${{ inputs.arch }}
+        POSTGRES_MAJOR: ${{ inputs.postgres-major }}
+        # See the macOS step: this is for the out-of-date check's rate limit
+        # alone, and the downloads themselves need no authentication.
+        GH_TOKEN: ${{ github.token }}
+      run: |
+        # Without this, Invoke-WebRequest spends most of a 90 MB download
+        # rendering a progress bar into a log nobody will read.
+        $ProgressPreference = 'SilentlyContinue'
+
+        $base = 'https://github.com/pgadmin-org/pgbuild/releases/download'
+        $releases = 'https://api.github.com/repos/pgadmin-org/pgbuild/releases'
+
+        # GITHUB_ACTION_PATH rather than the workspace, so that the lock is
+        # found even where a workflow checks the repository out somewhere
+        # other than the default directory.
+        $lock = Join-Path $env:GITHUB_ACTION_PATH '..\..\..\pkg\pgbuild-deps.lock'
+
+        # Column 2 of a lock line is the tag to fetch and column 3 the digest
+        # its archive must hash to; anything after a # is a comment.
+        function Get-LockEntry($key) {
+            foreach ($line in Get-Content $lock) {
+                $text = ($line -split '#', 2)[0].Trim()
+
+                if ($text -eq '') { continue }
+
+                $fields = $text -split '\s+'
+
+                if ($fields.Count -eq 3 -and $fields[0] -eq $key) {
+                    return @{ Tag = $fields[1]; Digest = $fields[2] }
+                }
+            }
+
+            return $null
+        }
+
+        # pgbuild's tags, newest first, for the out-of-date check below. This
+        # is deliberately best effort: a build whose downloads have been
+        # verified must not fail because GitHub would not say what else has
+        # been published since.
+        $tags = @()
+
+        try {
+            $headers = @{ 'Accept' = 'application/vnd.github+json' }
+
+            if ($env:GH_TOKEN) {
+                $headers['Authorization'] = "Bearer $env:GH_TOKEN"
+            }
+
+            $tags = (Invoke-RestMethod -Uri "${releases}?per_page=100" -Headers $headers -UseBasicParsing) | ForEach-Object { $_.tag_name }
+        } catch {
+            Write-Output "Could not list pgbuild's releases, so this build will not"
+            Write-Output "report whether its pinned dependencies are still current."
+        }
+
+        # The first tag of the right shape is the newest, the listing coming
+        # back in reverse chronological order. The rolling tag is skipped
+        # because it names no version.
+        function Get-NewestTag($pattern) {
+            foreach ($tag in $tags) {
+                if ($tag -like '*-latest') { continue }
+
+                if ($tag -like $pattern) { return $tag }
+            }
+
+            return $null
+        }
+
+        $depsDir = Join-Path $env:RUNNER_TEMP 'pgbuild-deps'
+        New-Item -ItemType Directory -Force -Path $depsDir | Out-Null
+
+        foreach ($pkg in @("postgresql-$env:POSTGRES_MAJOR", 'krb5')) {
+            $key = "$pkg-windows-$env:PGBUILD_ARCH"
+            $pin = Get-LockEntry $key
+            $family = ($pkg -split '-')[0]
+
+            if (-not $pin) {
+                Write-Output "ERROR: $key has no entry in pkg/pgbuild-deps.lock"
+                Write-Output ""
+                Write-Output "An unpinned dependency must not reach a build we sign,"
+                Write-Output "so this is a failure rather than a warning. Add it with:"
+                Write-Output ""
+                Write-Output "    tools/refresh_pgbuild_lock.py $family"
+                Write-Output ""
+                Write-Output "If this is a PostgreSQL major the lock has never seen,"
+                Write-Output "add it to POSTGRES_MAJORS in that script first."
+                exit 1
+            }
+
+            $archive = "$($pin.Tag).zip"
+            $zip = Join-Path $env:RUNNER_TEMP $archive
+            Write-Output "Fetching $archive..."
+            Invoke-WebRequest -Uri "$base/$($pin.Tag)/$archive" -OutFile $zip -UseBasicParsing
+
+            $actual = (Get-FileHash -Algorithm SHA256 -Path $zip).Hash.ToLower()
+
+            if ($actual -ne $pin.Digest) {
+                Write-Output "ERROR: checksum mismatch for $archive"
+                Write-Output "    expected: $($pin.Digest)"
+                Write-Output "    actual:   $actual"
+                Write-Output ""
+                Write-Output "The bytes behind $($pin.Tag) are not the"
+                Write-Output "ones that were reviewed when the lock was written."
+                Write-Output "Usually that means pgbuild rebuilt the tag in place,"
+                Write-Output "which it does for PostgreSQL whenever a new minor comes"
+                Write-Output "out, that tag carrying only the major. Satisfy yourself"
+                Write-Output "that a rebuild is what happened before re-running,"
+                Write-Output "because this is also the one check standing between a"
+                Write-Output "tampered dependency and a signed pgAdmin build, and then"
+                Write-Output "record the new archive, read the diff and commit it:"
+                Write-Output ""
+                Write-Output "    tools/refresh_pgbuild_lock.py $family"
+                exit 1
+            }
+
+            Write-Output "Verified $archive (sha256 $actual)"
+
+            $newest = Get-NewestTag "$pkg*-windows-$env:PGBUILD_ARCH"
+
+            if ($newest -and $newest -ne $pin.Tag) {
+                Write-Output "::warning title=pgbuild dependency out of date::$key is pinned to $($pin.Tag), but pgbuild has since published $newest. This build is using the pinned version, which is what the lock file is for, and nothing is broken. To move to the newer build, run tools/refresh_pgbuild_lock.py $family, review the change to pkg/pgbuild-deps.lock and commit it."
+            }
+
+            Expand-Archive -Path $zip -DestinationPath $depsDir -Force
+        }
+
+        Get-ChildItem $depsDir
+        # Out-File in Windows PowerShell defaults to UTF-16, which the runner
+        # cannot parse, so the encoding is explicit.
+        "prefix=$depsDir" | Out-File -FilePath $env:GITHUB_OUTPUT -Encoding utf8 -Append

.github/dependabot.yml

@@ -1,4 +1,11 @@
 version: 2
+
+# A note on the "groups" blocks below: minor and patch updates are batched into
+# a single PR per manifest per week, whilst major updates continue to arrive
+# individually. Majors are where the breakage lives and each one wants its own
+# review, whereas a dozen separate PRs for patch bumps is pure overhead.
+# Grouping applies to version updates only, so Dependabot security updates are
+# unaffected and still arrive as their own PRs.
 updates:
   - package-ecosystem: "docker"
     directory: "/"
@@ -17,6 +24,20 @@ updates:
       - "Dependencies"
     commit-message:
       prefix: "Python dependency"
+    groups:
+      python-minor-and-patch:
+        patterns:
+          - "*"
+        update-types:
+          - "minor"
+          - "patch"
+    # paramiko 5.0 removed DSSKey, which sshtunnel 0.4.0 still references in
+    # SSHTunnelForwarder.get_keys(); a major bump therefore breaks every SSH
+    # tunnelled connection at construction time. sshtunnel has had no release
+    # since 2019, so this stays put until it is fixed or replaced. See #9927.
+    ignore:
+      - dependency-name: "paramiko"
+        update-types: ["version-update:semver-major"]
 
   - package-ecosystem: "pip"
     directory: "/tools"
@@ -26,7 +47,17 @@ updates:
       - "Dependencies"
     commit-message:
       prefix: "Python dependency"
+    groups:
+      tools-python-minor-and-patch:
+        patterns:
+          - "*"
+        update-types:
+          - "minor"
+          - "patch"
 
+  # Note that web/regression/requirements.txt begins with
+  # "-r ../../requirements.txt", so this entry also sees everything pinned in
+  # the root file and the paramiko exclusion has to be repeated here.
   - package-ecosystem: "pip"
     directory: "/web/regression"
     schedule:
@@ -35,6 +66,16 @@ updates:
       - "Dependencies"
     commit-message:
       prefix: "Python dependency"
+    groups:
+      regression-python-minor-and-patch:
+        patterns:
+          - "*"
+        update-types:
+          - "minor"
+          - "patch"
+    ignore:
+      - dependency-name: "paramiko"
+        update-types: ["version-update:semver-major"]
 
   - package-ecosystem: "npm"
     directory: "/runtime"
@@ -44,6 +85,13 @@ updates:
       - "Dependencies"
     commit-message:
       prefix: "Javascript dependency"
+    groups:
+      runtime-javascript-minor-and-patch:
+        patterns:
+          - "*"
+        update-types:
+          - "minor"
+          - "patch"
 
   - package-ecosystem: "npm"
     directory: "/web"
@@ -53,3 +101,37 @@ updates:
       - "Dependencies"
     commit-message:
       prefix: "Javascript dependency"
+    groups:
+      web-javascript-minor-and-patch:
+        patterns:
+          - "*"
+        update-types:
+          - "minor"
+          - "patch"
+    ignore:
+      # @testing-library/jest-dom 7 requires Node >= 22, whilst Node 20 is the
+      # minimum we support and what most of the buildfarm runs. Revisit once
+      # the buildfarm moves to Node 22. See #10271 and #10210.
+      - dependency-name: "@testing-library/jest-dom"
+        update-types: ["version-update:semver-major"]
+
+      # Babel 8 requires Node ^22.18.0 || >=24.11.0, and every 8.x package
+      # peer-depends on @babel/core ^8.0.0 whilst we are on 7.x. Taking any of
+      # them individually leaves an unsatisfiable peer requirement and a mixed
+      # 7/8 tree, so Babel 8 needs a coordinated migration across all ten
+      # @babel/* packages once we are on Node 22. See #10283, #10284, #10285.
+      - dependency-name: "@babel/*"
+        update-types: ["version-update:semver-major"]
+
+      # pickr 1.10 switched to a dual CJS/ESM build whose CommonJS entry point
+      # exports a namespace object rather than the class, so Babel's interop
+      # leaves _pickr.default as an object and every dialog with a colour field
+      # dies on mount. That took master's feature tests down for three days
+      # (#10264, reverted in #10278). Note 1.9 -> 1.10 is a *minor* bump, so it
+      # otherwise rejoins the grouped PR and comes back around; minor updates
+      # are excluded here as well as majors until withColorPicker.js is adapted
+      # to the new export shape.
+      - dependency-name: "@simonwep/pickr"
+        update-types:
+          - "version-update:semver-major"
+          - "version-update:semver-minor"

.github/workflows/acceptance-test.yml

@@ -0,0 +1,431 @@
+# Install pgAdmin from a published tree, exactly as the README tells a user to.
+#
+# Everything else in this pipeline checks that files exist, that indexes parse
+# and that signatures validate. All three can be true of a repository apt still
+# refuses, and two bugs found during the migration were of precisely that
+# shape: packages one directory too deep, and noarch RPMs filed where no dnf
+# client looks. Neither failed a build.
+#
+# So this does not inspect anything. It follows the instructions in the
+# repository README, in a clean container, and installs the package. No
+# --allow-unauthenticated, no --nogpgcheck, no pinning: if the signature is
+# wrong or the architecture is missing from Release, the install fails, which
+# is the point.
+#
+# It runs against a release candidate on the development server, which serves
+# its tree the moment it is written. The download server sits behind an hourly
+# sync to the mirrors, so testing there would mostly measure the sync.
+
+name: Acceptance test
+
+on:
+  workflow_call:
+    inputs:
+      base-url:
+        description: The tree to install from, without a trailing slash
+        required: true
+        type: string
+
+  workflow_dispatch:
+    inputs:
+      base-url:
+        description: >-
+          The tree to install from, for example
+          https://developer.pgadmin.org/builds/2026-09-21-1
+        required: true
+        type: string
+
+concurrency:
+  group: 'acceptance-test @ ${{ inputs.base-url }}'
+  cancel-in-progress: true
+
+permissions:
+  contents: read
+
+jobs:
+  # The URL is fetched from, installed from and, in the apt job, written into
+  # a file, so it is checked once here rather than trusted in nine places. The
+  # host allowlist is the point: everything below downloads and then installs
+  # as root whatever that host serves, so this is what decides who gets to ask
+  # for that.
+  check:
+    runs-on: ubuntu-24.04
+
+    steps:
+      - name: Check the base URL
+        env:
+          BASE_URL: ${{ inputs.base-url }}
+        run: |
+          set -euo pipefail
+          case "${BASE_URL}" in
+              https://developer.pgadmin.org/builds/*) ;;
+              https://ftp.postgresql.org/pub/pgadmin/pgadmin4/*) ;;
+              *)
+                  echo "Not a tree this test will install from: ${BASE_URL}" >&2
+                  echo "Expected developer.pgadmin.org or ftp.postgresql.org." >&2
+                  exit 1 ;;
+          esac
+          # No trailing slash, no shell metacharacters, nothing that could be
+          # read as a second word: the value is interpolated into commands.
+          printf '%s' "${BASE_URL}" | grep -Eq '^https://[A-Za-z0-9./_-]+[A-Za-z0-9]$' || {
+              echo "The base URL may contain only letters, digits, dot, slash, underscore and hyphen." >&2
+              exit 1; }
+
+  apt:
+    needs: check
+    runs-on: ubuntu-24.04
+
+    # The images default to sh, which has no pipefail, so every step that set
+    # it died on the first line. All of these carry bash.
+    defaults:
+      run:
+        shell: bash
+    strategy:
+      fail-fast: false
+      matrix:
+        include:
+          - { name: 'bookworm', image: 'debian:12' }
+          - { name: 'trixie',   image: 'debian:13' }
+          - { name: 'jammy',    image: 'ubuntu:22.04' }
+          - { name: 'noble',    image: 'ubuntu:24.04' }
+          - { name: 'resolute', image: 'ubuntu:26.04' }
+    container: ${{ matrix.image }}
+
+    steps:
+      # Only what a user would already have or would obviously need. lsb-release
+      # is here because the README's own sources.list line calls lsb_release,
+      # and following the instruction is the test.
+      - name: Install the prerequisites
+        env:
+          DEBIAN_FRONTEND: noninteractive
+        run: |
+          apt-get update
+          apt-get install -y --no-install-recommends ca-certificates curl gnupg lsb-release
+
+      - name: Follow the README
+        env:
+          BASE_URL: ${{ inputs.base-url }}
+          DEBIAN_FRONTEND: noninteractive
+        run: |
+          set -euo pipefail
+
+          curl -fsS https://www.pgadmin.org/static/packages_pgadmin_org.pub \
+              | gpg --dearmor -o /usr/share/keyrings/packages-pgadmin-org.gpg
+
+          # Written by this shell rather than handed to `sh -c`, which
+          # re-parsed the expanded URL as source and was the one place in the
+          # pipeline where a caller-supplied value reached a shell.
+          CODENAME=$(lsb_release -cs)
+          echo "deb [signed-by=/usr/share/keyrings/packages-pgadmin-org.gpg] ${BASE_URL}/apt/${CODENAME} pgadmin4 main" \
+              > /etc/apt/sources.list.d/pgadmin4.list
+          cat /etc/apt/sources.list.d/pgadmin4.list
+
+          # A repository apt will not verify makes this fail here, before any
+          # package is considered.
+          apt-get update
+
+      - name: Install pgAdmin
+        env:
+          DEBIAN_FRONTEND: noninteractive
+        run: |
+          set -euo pipefail
+          apt-get install -y pgadmin4-server
+
+          # The version proves what installed is this build rather than
+          # something the distribution happened to carry, and the file list
+          # proves the package actually delivered its payload.
+          dpkg-query -W -f '${Package} ${Version}\n' pgadmin4-server
+          # grep without -q, deliberately: -q exits on the first match, the
+          # command feeding it then dies of SIGPIPE, and pipefail turns that
+          # into a failed pipeline even though the match succeeded.
+          dpkg -L pgadmin4-server | grep '^/usr/pgadmin4/' >/dev/null || {
+              echo "pgadmin4-server installed no files under /usr/pgadmin4" >&2
+              exit 1; }
+
+  yum:
+    needs: check
+    runs-on: ubuntu-24.04
+
+    # The images default to sh, which has no pipefail, so every step that set
+    # it died on the first line. All of these carry bash.
+    defaults:
+      run:
+        shell: bash
+    strategy:
+      fail-fast: false
+      matrix:
+        include:
+          - { name: 'rhel-9',    image: 'almalinux:9',  family: 'redhat' }
+          - { name: 'rhel-10',   image: 'almalinux:10', family: 'redhat' }
+          - { name: 'fedora-43', image: 'fedora:43',    family: 'fedora' }
+          - { name: 'fedora-44', image: 'fedora:44',    family: 'fedora' }
+    container: ${{ matrix.image }}
+
+    steps:
+      - name: Follow the README
+        env:
+          BASE_URL: ${{ inputs.base-url }}
+          FAMILY: ${{ matrix.family }}
+        run: |
+          set -euo pipefail
+
+          # The repository RPM carries the .repo file and the packaging key, and
+          # points at the tree it shipped in, so nothing here names a URL twice.
+          # It sets gpgcheck=1 and repo_gpgcheck=1, which is why no --nogpgcheck
+          # appears below: a wrongly signed repository fails at this step.
+          RPM=$(curl -fsS "${BASE_URL}/yum/" \
+              | grep -oE "pgadmin4-${FAMILY}-repo-[0-9.-]+\.noarch\.rpm" \
+              | sort -u | tail -1)
+          echo "Repository package: ${RPM}"
+          rpm -i "${BASE_URL}/yum/${RPM}"
+          cat /etc/yum.repos.d/pgadmin4.repo
+
+      - name: Install pgAdmin
+        run: |
+          set -euo pipefail
+          dnf install -y pgadmin4-server
+          rpm -q pgadmin4-server
+          # grep without -q, deliberately: -q exits on the first match, the
+          # command feeding it then dies of SIGPIPE, and pipefail turns that
+          # into a failed pipeline even though the match succeeded.
+          rpm -ql pgadmin4-server | grep '^/usr/pgadmin4/' >/dev/null || {
+              echo "pgadmin4-server installed no files under /usr/pgadmin4" >&2
+              exit 1; }
+
+  # The Windows installer, actually installed. Nothing else in the pipeline
+  # runs it, and until now nothing verified the signature on the executable
+  # inside it either: Make.bat's own check tested a stale %ERRORLEVEL%, and the
+  # workflow step that claimed to cover the gap only re-verified the installer.
+  windows:
+    needs: check
+    runs-on: windows-2025
+    steps:
+      - name: Download and install
+        shell: pwsh
+        env:
+          BASE_URL: ${{ inputs.base-url }}
+        run: |
+          $ErrorActionPreference = 'Stop'
+          $listing = Invoke-WebRequest -Uri "$env:BASE_URL/" -UseBasicParsing
+          $name = ([regex]'pgadmin4-[0-9.]+-x64\.exe').Matches($listing.Content) |
+                    ForEach-Object { $_.Value } | Sort-Object -Unique | Select-Object -Last 1
+          if (-not $name) { throw "No installer found at $env:BASE_URL" }
+          Write-Output "Installer: $name"
+
+          Invoke-WebRequest -Uri "$env:BASE_URL/$name" -OutFile installer.exe -UseBasicParsing
+
+          # The installer's own signature, before running anything from it.
+          $sig = Get-AuthenticodeSignature installer.exe
+          Write-Output "Installer signature: $($sig.Status) / $($sig.SignerCertificate.Subject)"
+          if ($sig.Status -ne 'Valid') { throw "Installer signature is $($sig.Status)" }
+
+          # Inno Setup's silent switches. /DIR is given so the check below does
+          # not depend on the default install location.
+          $p = Start-Process -FilePath .\installer.exe -Wait -PassThru `
+              -ArgumentList '/VERYSILENT','/SUPPRESSMSGBOXES','/NORESTART','/DIR=C:\pgadmin4-test'
+          if ($p.ExitCode -ne 0) { throw "Installer exited with $($p.ExitCode)" }
+
+      - name: Check what was installed
+        shell: pwsh
+        run: |
+          $ErrorActionPreference = 'Stop'
+          $root = 'C:\pgadmin4-test'
+
+          # The components that carry no signature of ours, and so are only
+          # checked for presence. Everything we do sign is covered by the step
+          # below, which checks that it is there as a side effect of verifying
+          # it.
+          foreach ($f in @("$root\python\python.exe", "$root\web\pgAdmin4.py")) {
+              if (-not (Test-Path $f)) { throw "Missing from the installation: $f" }
+              Write-Output "present: $f"
+          }
+
+      # Everything Make.bat's :SIGN_COMPONENTS signs, verified where it lands.
+      # None of it exists outside the installer until the installer has run, so
+      # this is the only place a published build can be checked: the runtime
+      # executable, and the PostgreSQL and Kerberos binaries we ship alongside
+      # it. The Electron, Python and VC++ runtime components are deliberately
+      # not signed by us and so are not listed here.
+      - name: Check the component signatures
+        shell: pwsh
+        run: |
+          $ErrorActionPreference = 'Stop'
+          $root = 'C:\pgadmin4-test'
+
+          # The publisher is taken from the installer rather than hard coded,
+          # so that a component signed by somebody else is caught without this
+          # needing an edit every time the certificate is renewed.
+          $expected = (Get-AuthenticodeSignature installer.exe).SignerCertificate.Subject
+          Write-Output "Expected publisher: $expected"
+
+          # winpgbuild does not always ship these four, and Make.bat copies them
+          # only when they are present, so an empty match is not a failure.
+          $optional = @('libintl-*.dll', 'libiconv-*.dll', 'liblz4.dll', 'libzstd.dll')
+
+          foreach ($pattern in @(
+              'pgAdmin4.exe',
+              'libpq.dll', 'libcrypto-*-x64.dll', 'libssl-*-x64.dll', 'zlib1.dll',
+              'pg_dump.exe', 'pg_dumpall.exe', 'pg_restore.exe', 'psql.exe',
+              'kinit.exe', 'krb5_64.dll', 'comerr64.dll', 'k5sprt64.dll',
+              'gssapi64.dll', 'krbcc64.dll', 'ccapiserver.exe') + $optional) {
+
+              $files = @(Get-ChildItem -Path "$root\runtime\$pattern" -ErrorAction SilentlyContinue)
+              if ($files.Count -eq 0) {
+                  if ($optional -contains $pattern) {
+                      Write-Output "absent, and optional: $pattern"
+                      continue
+                  }
+                  throw "Missing from the installation: $root\runtime\$pattern"
+              }
+
+              foreach ($f in $files) {
+                  $sig = Get-AuthenticodeSignature $f.FullName
+                  Write-Output "$($f.Name): $($sig.Status) / $($sig.SignerCertificate.Subject)"
+                  if ($sig.Status -ne 'Valid') {
+                      throw "$($f.Name) signature is $($sig.Status)"
+                  }
+                  if ($sig.SignerCertificate.Subject -ne $expected) {
+                      throw "$($f.Name) was signed by $($sig.SignerCertificate.Subject)"
+                  }
+              }
+          }
+
+  # The macOS disk image as published, rather than the bundle as built. The
+  # snapshot workflow checks the bundle it has just made; this checks what a
+  # user downloads, which has been through a DMG, a web server and a browser's
+  # quarantine attribute.
+  macos:
+    needs: check
+    runs-on: ${{ matrix.runner }}
+    strategy:
+      fail-fast: false
+      matrix:
+        include:
+          - { name: 'arm64', runner: 'macos-15' }
+          - { name: 'x64',   runner: 'macos-26-intel' }
+    steps:
+      - name: Download, mount and check
+        env:
+          BASE_URL: ${{ inputs.base-url }}
+          ARCH: ${{ matrix.name }}
+        run: |
+          set -euo pipefail
+          name=$(curl -fsS "${BASE_URL}/" \
+              | grep -oE "pgadmin4-[0-9.]+-${ARCH}\.dmg" | sort -u | tail -1)
+          [ -n "${name}" ] || { echo "No ${ARCH} disk image found" >&2; exit 1; }
+          echo "Disk image: ${name}"
+          curl -fsS -o image.dmg "${BASE_URL}/${name}"
+
+          # Quarantine it as a browser would, so Gatekeeper is actually
+          # consulted rather than bypassed because the file arrived by curl.
+          xattr -w com.apple.quarantine \
+              "0081;$(printf '%x' "$(date +%s)");Safari;" image.dmg
+
+          hdiutil attach image.dmg -nobrowse -readonly -mountpoint /tmp/pga
+          app="/tmp/pga/pgAdmin 4.app"
+
+          test -d "${app}"
+          test -x "${app}/Contents/MacOS/pgAdmin 4"
+          test -x "${app}/Contents/SharedSupport/pg_dump"
+          test -f "${app}/Contents/Resources/web/pgAdmin4.py"
+
+          # Gatekeeper first, because that is what decides whether a user can
+          # open this. codesign --strict comes after and is allowed to have its
+          # own opinion: the disk image deliberately carries a FinderInfo xattr
+          # on the bundle, set by SetFile -a E in _create_dmg to hide the .app
+          # extension in the window, and --strict rejects any xattr at all.
+          echo "=== notarisation and Gatekeeper ==="
+          # stapler looks the ticket up in Apple's CloudKit, and a dropped
+          # connection there fails the step with error 68, so it is retried.
+          # A genuinely broken ticket still fails all three attempts.
+          for attempt in 1 2 3; do
+              xcrun stapler validate "${app}" && break
+              [ "${attempt}" -lt 3 ] || exit 1
+              echo "stapler validate failed; retrying in $((attempt * 30))s"
+              sleep $((attempt * 30))
+          done
+          spctl --assess --type execute --verbose=4 "${app}"
+
+          echo "=== signature ==="
+          codesign -dvvv "${app}" 2>&1 | grep -E 'Authority|TeamIdentifier'
+          codesign --verify --deep --verbose=2 "${app}"
+
+          # Reported rather than enforced. If this ever starts failing whilst
+          # spctl still passes, it is the extension-hiding attribute and not a
+          # broken signature; if spctl fails too, the build is broken.
+          if ! codesign --verify --deep --strict --verbose=2 "${app}" 2>/tmp/strict.log; then
+              echo "note: --strict verification failed, Gatekeeper having passed:"
+              tail -2 /tmp/strict.log
+          fi
+
+          # Nothing in the bundle may reference a build machine. This is what
+          # catches a dependency that was linked but not relocated, which is
+          # how an ICU or OpenSSL path would escape.
+          echo "=== linkage of the bundled client binaries ==="
+          for b in pg_dump pg_dumpall pg_restore psql; do
+              echo "--- ${b} ---"
+              otool -L "${app}/Contents/SharedSupport/${b}" | tail -n +2
+          done
+          if otool -L "${app}/Contents/SharedSupport/"* \
+                  | grep -E '/opt/pgbuild|/opt/homebrew|/usr/local/(lib|opt)'; then
+              echo "A bundled binary still points outside the bundle" >&2
+              exit 1
+          fi
+
+          hdiutil detach /tmp/pga
+
+  # The downloads nobody installs: the wheel, the tarballs and the documents.
+  # Shallow by design, but it does verify every detached signature from the
+  # published URL rather than on the server, which is what a user would get.
+  artefacts:
+    needs: check
+    runs-on: ubuntu-24.04
+    steps:
+      - name: Fetch and check
+        env:
+          BASE_URL: ${{ inputs.base-url }}
+        run: |
+          set -euo pipefail
+          mkdir -p dl && cd dl
+
+          listing=$(curl -fsS "${BASE_URL}/")
+          fetch() {
+              local pattern=$1 name
+              name=$(printf '%s' "${listing}" | grep -oE "${pattern}" | sort -u | tail -1)
+              [ -n "${name}" ] || { echo "Nothing matching ${pattern}" >&2; exit 1; }
+              curl -fsS -O "${BASE_URL}/${name}"
+              echo "${name}"
+          }
+
+          tarball=$(fetch 'pgadmin4-[0-9.]+\.tar\.gz')
+          wheel=$(fetch 'pgadmin4-[0-9.]+-py3-none-any\.whl')
+          docs=$(fetch 'pgadmin4-[0-9.]+-docs\.tar\.gz')
+          pdf=$(fetch 'pgadmin4-[0-9.]+\.pdf')
+          epub=$(fetch 'pgadmin4-[0-9.]+\.epub')
+
+          echo "=== signatures, as a user would verify them ==="
+          export GNUPGHOME=$(mktemp -d); chmod 700 "${GNUPGHOME}"
+          curl -fsS https://www.pgadmin.org/static/packages_pgadmin_org.pub | gpg --import
+          for f in "${tarball}" "${wheel}" "${docs}" "${pdf}" "${epub}"; do
+              curl -fsS -O "${BASE_URL}/${f}.asc"
+              gpg --verify "${f}.asc" "${f}"
+          done
+
+          echo "=== the documents are what they claim to be ==="
+          file "${pdf}" | grep -q 'PDF document'
+          file "${epub}" | grep -q 'EPUB'
+          # A truncated PDF still says PDF, so size is checked too.
+          [ "$(stat -c%s "${pdf}")" -gt 1000000 ] || { echo "PDF is implausibly small" >&2; exit 1; }
+
+          echo "=== the tarballs contain what they should ==="
+          tar tzf "${tarball}" | grep -E '/web/pgAdmin4\.py$' >/dev/null
+          tar tzf "${tarball}" | grep -E '/requirements\.txt$' >/dev/null
+          tar tzf "${docs}" | grep -E 'index\.html$' >/dev/null
+
+      - name: Install the wheel
+        run: |
+          set -euo pipefail
+          cd dl
+          python3 -m venv /tmp/wheeltest
+          /tmp/wheeltest/bin/pip install --quiet pgadmin4-*-py3-none-any.whl
+          /tmp/wheeltest/bin/python -c 'import pgadmin4; print("imported", pgadmin4.__file__)'

.github/workflows/check-container-build.yml

@@ -1,28 +1,175 @@
 name: Check container build
 
 on:
+  # Callable, so that a workflow which needs a container build gets this one
+  # rather than a second definition of it that can drift. Snapshot does not
+  # call it today, the image not being part of the download tree.
+  workflow_call:
+    inputs:
+      publish:
+        description: >-
+          Build for both architectures and push to the registry, tagged
+          with the location below. A build check does neither: it proves
+          the Dockerfile still works and throws the image away.
+        type: boolean
+        required: false
+        default: false
+      location:
+        description: The tag to push, normally the build's date
+        type: string
+        required: false
+        default: ''
+    secrets:
+      DOCKERHUB_USERNAME:
+        required: false
+      DOCKERHUB_TOKEN:
+        required: false
+
   push:
     branches: [ "master" ]
+    paths:
+      - 'Dockerfile'
+      - 'pkg/docker/**'
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'requirements.txt'
+      - 'docs/**'
+      - '.dockerignore'
+      - 'LICENSE'
+      - '.github/workflows/check-container-build.yml'
   pull_request:
     branches: [ "master" ]
+    paths:
+      - 'Dockerfile'
+      - 'pkg/docker/**'
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'requirements.txt'
+      - 'docs/**'
+      - '.dockerignore'
+      - 'LICENSE'
+      - '.github/workflows/check-container-build.yml'
 
   workflow_dispatch:
+    inputs:
+      publish:
+        description: Build for both architectures and push to the registries
+        type: boolean
+        required: false
+        default: false
+      location:
+        description: The tag to push, normally the build's date
+        type: string
+        required: false
+        default: ''
 
 concurrency:
-  group: '${{ github.workflow }} @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }}'
+  # The workflow's own name, spelled out rather than taken from
+  # github.workflow, because in a reusable workflow that expression is
+  # the CALLER's name. Every workflow Snapshot calls would otherwise
+  # share one group and, with cancel-in-progress, cancel each other.
+  # github.event_name is in the key because a called workflow inherits the
+  # caller's ref: once this is on master, the nightly Snapshot's deb build
+  # and an ordinary push's deb build would otherwise share a group and,
+  # with cancel-in-progress, kill each other. A push landing mid-nightly
+  # would cancel the snapshot's build and skip the publish entirely.
+  group: 'check-container-build @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }} @ ${{ github.event_name }}'
   cancel-in-progress: true
 
+# Read-only by default, as everywhere else here. The publish job below names
+# the wider set it genuinely needs, and a job-level block replaces this one
+# rather than adding to it, so its packages: write is unaffected.
+permissions:
+  contents: read
+
 jobs:
+  # The check. No environment, and so no access to the registry credentials:
+  # this runs on every pull request, and a build check has no business being
+  # able to push anything.
   build-container:
+    if: ${{ !inputs.publish }}
     runs-on: ubuntu-22.04
 
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v7
         with:
           fetch-depth: 2
 
-      - name: Build the container
-        uses: docker/build-push-action@v6
+      - name: Check the container builds
+        uses: docker/build-push-action@c3c9e263c25d99ce0380d002d59b67737d91b0dc  # v7.4.0
         with:
           push: false
           context: .
+
+  # The publish. Declared on the publishing environment, which is where the
+  # Docker Hub credentials live: an environment secret is not available to a
+  # job that does not name the environment, which is what secrets: inherit
+  # alone does not solve.
+  publish-container:
+    if: inputs.publish
+    runs-on: ubuntu-22.04
+    environment: publishing
+
+    permissions:
+      contents: read
+      # For GHCR, which takes the workflow's own token rather than a stored
+      # registry credential.
+      packages: write
+
+    steps:
+      # Before anything is logged in to, because this value becomes a tag in
+      # a job holding the Docker Hub credentials, and the tags input is
+      # newline separated: an unchecked value could name a second tag, and a
+      # tag can name another repository. The shape is the one the wrapper
+      # requires of a build location.
+      - name: Check the location
+        env:
+          LOCATION: ${{ inputs.location }}
+        run: |
+          set -euo pipefail
+          printf '%s' "${LOCATION}" \
+              | grep -Eq '^[0-9]{4}-[0-9]{2}-[0-9]{2}(-([1-9][0-9]?|[A-Za-z][A-Za-z0-9]*))?$' || {
+              echo "Not a build location: ${LOCATION}" >&2; exit 1; }
+
+      - uses: actions/checkout@v7
+        with:
+          fetch-depth: 2
+
+      # Emulation is slow, so only the publishing path pays for it.
+      - name: Set up QEMU
+        uses: docker/setup-qemu-action@c7c53464625b32c7a7e944ae62b3e17d2b600130  # v3
+
+      - name: Set up Buildx
+        uses: docker/setup-buildx-action@8d2750c68a42422c14e847fe6c8ac0403b4cbd6f  # v3
+
+      - name: Log in to Docker Hub
+        uses: docker/login-action@c94ce9fb468520275223c153574b00df6fe4bcc9  # v3
+        with:
+          username: ${{ secrets.DOCKERHUB_USERNAME }}
+          password: ${{ secrets.DOCKERHUB_TOKEN }}
+
+      - name: Log in to GHCR
+        uses: docker/login-action@c94ce9fb468520275223c153574b00df6fe4bcc9  # v3
+        with:
+          registry: ghcr.io
+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}
+
+      # Tagged with the build's location rather than a version. Promotion
+      # re-tags this exact image, so what ships is the manifest that was
+      # tested rather than a rebuild of the same source.
+      - name: Build and push the container
+        uses: docker/build-push-action@c3c9e263c25d99ce0380d002d59b67737d91b0dc  # v7.4.0
+        with:
+          push: true
+          context: .
+          platforms: linux/amd64,linux/arm64
+          tags: |
+            dpage/pgadmin4:${{ inputs.location }}
+            ghcr.io/pgadmin-org/pgadmin4:${{ inputs.location }}

.github/workflows/check-deb-build.yml

@@ -0,0 +1,140 @@
+# Replaces the pgadmin4-deb-qa Jenkins job. That job runs `make debian` on a
+# dedicated EC2 VM per distribution; here each distribution is a container on a
+# hosted runner instead, which is the same build in a reproducible environment
+# and no VMs to maintain.
+#
+# Triggered on master and by hand rather than on pull requests, matching what
+# the Jenkins job does today (it polls git every five minutes). Running the
+# full matrix on every PR is a separate decision.
+
+name: Check DEB builds
+
+on:
+  # Callable from snapshot.yml, so that what gets published is the
+  # same build that runs on every push rather than a second
+  # definition of it that can drift.
+  workflow_call:
+
+  push:
+    branches: [ "master" ]
+    paths:
+      - 'pkg/debian/**'
+      - 'pkg/linux/**'
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'docs/**'
+      - 'requirements.txt'
+      - 'Makefile'
+      - 'tools/setup-python-env.sh'
+      - '.github/workflows/check-deb-build.yml'
+
+  workflow_dispatch:
+
+concurrency:
+  # The workflow's own name, spelled out rather than taken from
+  # github.workflow, because in a reusable workflow that expression is
+  # the CALLER's name. Every workflow Snapshot calls would otherwise
+  # share one group and, with cancel-in-progress, cancel each other.
+  # github.event_name is in the key because a called workflow inherits the
+  # caller's ref: once this is on master, the nightly Snapshot's deb build
+  # and an ordinary push's deb build would otherwise share a group and,
+  # with cancel-in-progress, kill each other. A push landing mid-nightly
+  # would cancel the snapshot's build and skip the publish entirely.
+  group: 'check-deb-build @ ${{ github.ref }} @ ${{ github.event_name }}'
+  cancel-in-progress: true
+
+permissions:
+  contents: read
+
+jobs:
+  build-deb:
+    runs-on: ubuntu-24.04
+
+    strategy:
+      fail-fast: false
+      matrix:
+        include:
+          # "name" exists only because artifact names may not contain a colon.
+          - { name: 'debian-12',   image: 'debian:12' }
+          - { name: 'debian-13',   image: 'debian:13' }
+          - { name: 'ubuntu-2204', image: 'ubuntu:22.04' }
+          - { name: 'ubuntu-2404', image: 'ubuntu:24.04' }
+          - { name: 'ubuntu-2604', image: 'ubuntu:26.04' }
+
+    container: ${{ matrix.image }}
+
+    steps:
+      # Before checkout, so the action has git available and the container has
+      # the certificates it needs to fetch anything.
+      - name: Install the build environment
+        env:
+          DEBIAN_FRONTEND: noninteractive
+        run: |
+          apt-get update
+          apt-get install -y --no-install-recommends \
+              build-essential \
+              ca-certificates \
+              curl \
+              dh-exec \
+              dpkg-dev \
+              fakeroot \
+              git \
+              libffi-dev \
+              libkrb5-dev \
+              libpq-dev \
+              libreadline-dev \
+              libssl-dev \
+              lsb-release \
+              python3-dev \
+              python3-pip \
+              python3-sphinx \
+              python3-venv \
+              python3-wheel \
+              unzip \
+              wget \
+              zlib1g-dev
+
+      # sphinxcontrib-youtube has no distro package. --break-system-packages is
+      # needed from Debian 12 and Ubuntu 24.04 onwards (PEP 668), and is
+      # harmless before that, but the flag itself only exists on newer pip, so
+      # fall back rather than fail.
+      - name: Install the Sphinx extensions
+        run: |
+          python3 -m pip install --break-system-packages sphinxcontrib-youtube \
+              || python3 -m pip install sphinxcontrib-youtube
+
+      - name: Install syft
+        run: curl -sSfL https://raw.githubusercontent.com/anchore/syft/v1.52.0/install.sh | sh -s -- -b /usr/local/bin v1.52.0
+
+      - uses: actions/setup-node@v7
+        with:
+          node-version: '20.x'
+
+      - uses: actions/checkout@v7
+
+      # The container runs as root while the workspace is owned by the runner
+      # user, so git refuses to operate on it ("detected dubious ownership").
+      # The build shells out to git for the commit hash during `yarn run
+      # bundle`, which fails with exit 128 without this.
+      - name: Mark the workspace as a safe git directory
+        run: git config --global --add safe.directory "${GITHUB_WORKSPACE}"
+
+      # Corepack provisions the pinned Yarn from the packageManager field,
+      # matching run-javascript-tests.yml. The distro nodejs packages are
+      # avoided entirely: on Ubuntu 26.04 the distro node ships without npm,
+      # which is why the buildfarm has to pin NodeSource above it.
+      - name: Enable Corepack
+        run: corepack enable
+
+      - name: Check the DEB build
+        run: make debian
+
+      - name: Archive the packages
+        uses: actions/upload-artifact@v7
+        with:
+          name: pgadmin4-deb-build-output-${{ matrix.name }}
+          if-no-files-found: error
+          path: dist/*.deb

.github/workflows/check-doc-builds.yml

@@ -1,15 +1,47 @@
 name: Check documentation builds
 
 on:
+  # Callable from snapshot.yml, so that what gets published is the
+  # same build that runs on every push rather than a second
+  # definition of it that can drift.
+  workflow_call:
+
   push:
     branches: [ "master" ]
+    paths:
+      - 'docs/**'
+      - 'web/version.py'
+      - 'web/branding.py'
+      - 'requirements.txt'
+      - 'Makefile'
+      - 'web/config.py'
+      - 'tools/setup-python-env.sh'
+      - '.github/workflows/check-doc-builds.yml'
   pull_request:
     branches: [ "master" ]
+    paths:
+      - 'docs/**'
+      - 'web/version.py'
+      - 'web/branding.py'
+      - 'requirements.txt'
+      - 'Makefile'
+      - 'web/config.py'
+      - 'tools/setup-python-env.sh'
+      - '.github/workflows/check-doc-builds.yml'
 
   workflow_dispatch:
 
 concurrency:
-  group: '${{ github.workflow }} @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }}'
+  # The workflow's own name, spelled out rather than taken from
+  # github.workflow, because in a reusable workflow that expression is
+  # the CALLER's name. Every workflow Snapshot calls would otherwise
+  # share one group and, with cancel-in-progress, cancel each other.
+  # github.event_name is in the key because a called workflow inherits the
+  # caller's ref: once this is on master, the nightly Snapshot's deb build
+  # and an ordinary push's deb build would otherwise share a group and,
+  # with cancel-in-progress, kill each other. A push landing mid-nightly
+  # would cancel the snapshot's build and skip the publish entirely.
+  group: 'check-doc-builds @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }} @ ${{ github.event_name }}'
   cancel-in-progress: true
 
 jobs:
@@ -17,7 +49,7 @@ jobs:
     runs-on: ubuntu-22.04
 
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v7
 
       - name: Install platform dependencies
         run: |
@@ -33,9 +65,10 @@ jobs:
           make docs
 
       - name: Archive HTML
-        uses: actions/upload-artifact@v4
+        uses: actions/upload-artifact@v7
         with:
           name: pgadmin4-html-build-output
+          if-no-files-found: error
           path: docs/en_US/_build/html/*
 
       - name: Check the ePub build
@@ -44,9 +77,10 @@ jobs:
           make docs-epub
 
       - name: Archive ePub
-        uses: actions/upload-artifact@v4
+        uses: actions/upload-artifact@v7
         with:
           name: pgadmin4-epub-build-output
+          if-no-files-found: error
           path: docs/en_US/_build/epub/pgAdmin4.epub
 
       - name: Check the PDF build
@@ -55,7 +89,8 @@ jobs:
           make docs-pdf
 
       - name: Archive PDF
-        uses: actions/upload-artifact@v4
+        uses: actions/upload-artifact@v7
         with:
           name: pgadmin4-pdf-build-output
+          if-no-files-found: error
           path: docs/en_US/_build/latex/pgadmin4.pdf

.github/workflows/check-helm-build.yml

@@ -0,0 +1,59 @@
+# Replaces the pgadmin4-helm-buildx-qa Jenkins job, which runs
+# `helm package pkg/helm` and nothing else. Helm is installed explicitly rather
+# than relied upon from the runner image, since what the images ship changes
+# between versions.
+
+name: Check Helm chart build
+
+on:
+  # Callable from snapshot.yml, so that what gets published is the
+  # same build that runs on every push rather than a second
+  # definition of it that can drift.
+  workflow_call:
+
+  push:
+    branches: [ "master" ]
+    paths:
+      - 'pkg/helm/**'
+      - '.github/workflows/check-helm-build.yml'
+
+  workflow_dispatch:
+
+concurrency:
+  # The workflow's own name, spelled out rather than taken from
+  # github.workflow, because in a reusable workflow that expression is
+  # the CALLER's name. Every workflow Snapshot calls would otherwise
+  # share one group and, with cancel-in-progress, cancel each other.
+  # github.event_name is in the key because a called workflow inherits the
+  # caller's ref: once this is on master, the nightly Snapshot's deb build
+  # and an ordinary push's deb build would otherwise share a group and,
+  # with cancel-in-progress, kill each other. A push landing mid-nightly
+  # would cancel the snapshot's build and skip the publish entirely.
+  group: 'check-helm-build @ ${{ github.ref }} @ ${{ github.event_name }}'
+  cancel-in-progress: true
+
+permissions:
+  contents: read
+
+jobs:
+  build-chart:
+    runs-on: ubuntu-24.04
+
+    steps:
+      - uses: actions/checkout@v7
+
+      - name: Install Helm
+        run: |
+          curl -fsSL https://raw.githubusercontent.com/helm/helm/v4.3.0/scripts/get-helm-3 -o get-helm-3
+          chmod 700 get-helm-3
+          ./get-helm-3
+
+      - name: Check the chart build
+        run: helm package pkg/helm
+
+      - name: Archive the chart
+        uses: actions/upload-artifact@v7
+        with:
+          name: pgadmin4-helm-build-output
+          if-no-files-found: error
+          path: pgadmin4-helm-*.tgz

.github/workflows/check-javascript-style.yml

@@ -3,8 +3,24 @@ name: Check Javascript style
 on:
   push:
     branches: [ "master" ]
+    paths:
+      - 'web/**/*.js'
+      - 'web/**/*.jsx'
+      - 'web/package.json'
+      - 'web/yarn.lock'
+      - 'web/.eslintrc.js'
+      - 'web/.yarnrc.yml'
+      - '.github/workflows/check-javascript-style.yml'
   pull_request:
     branches: [ "master" ]
+    paths:
+      - 'web/**/*.js'
+      - 'web/**/*.jsx'
+      - 'web/package.json'
+      - 'web/yarn.lock'
+      - 'web/.eslintrc.js'
+      - 'web/.yarnrc.yml'
+      - '.github/workflows/check-javascript-style.yml'
 
   workflow_dispatch:
 
@@ -17,17 +33,18 @@ jobs:
     runs-on: ubuntu-22.04
 
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v7
 
-      - name: Upgrade yarn
-        run: |
-          yarn set version berry
-          yarn set version 4
+      # Corepack reads packageManager from web/package.json and provisions
+      # exactly that Yarn: a single pinned download, with nothing written
+      # into the checkout.
+      - name: Enable Corepack
+        run: corepack enable
 
       - name: Install Node modules
         run: |
           cd web
-          yarn install
+          yarn install --immutable
 
       - name: Run the linter
         run: |

.github/workflows/check-macos-build.yml

@@ -0,0 +1,126 @@
+# Replaces the pgadmin4-macos-qa Jenkins job. That job runs `make appbundle` on
+# the two EC2 Mac workers; this runs the same build on hosted runners, which
+# cover both architectures.
+#
+# The build is unsigned and unnotarised: pkg/mac/build.sh sets CODESIGN=0 and
+# NOTARIZE=0 when pkg/mac/codesign.conf and pkg/mac/notarization.conf are
+# absent, so this needs no secrets. Signing belongs to the release and snapshot
+# builds.
+#
+# PostgreSQL comes from Homebrew for pg_config (psycopg builds against it) and
+# for the four client binaries copied into the bundle. The release build uses
+# a PostgreSQL built against its own OpenSSL and Kerberos; that difference
+# does not matter for a build check, and _fixup_imports relocates Homebrew's
+# libraries into the bundle correctly (verified by _verify_bundle_linkage,
+# which fails the build if anything still points outside it).
+
+name: Check macOS builds
+
+on:
+  push:
+    branches: [ "master" ]
+    paths:
+      - 'pkg/mac/**'
+      - '.github/actions/install-pgbuild-deps/action.yml'
+      # Which build of each dependency this compiles against, so a
+      # change to it changes what the installer contains.
+      - 'pkg/pgbuild-deps.lock'
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'docs/**'
+      - 'requirements.txt'
+      - 'Makefile'
+      - 'tools/setup-python-env.sh'
+      - '.github/workflows/check-macos-build.yml'
+
+  workflow_dispatch:
+
+concurrency:
+  # The workflow's own name, spelled out rather than taken from
+  # github.workflow, because in a reusable workflow that expression is
+  # the CALLER's name. Every workflow Snapshot calls would otherwise
+  # share one group and, with cancel-in-progress, cancel each other.
+  group: 'check-macos-build @ ${{ github.ref }}'
+  cancel-in-progress: true
+
+permissions:
+  contents: read
+
+jobs:
+  build-appbundle:
+    runs-on: ${{ matrix.runner }}
+
+    strategy:
+      fail-fast: false
+      matrix:
+        include:
+          # "arch" is pgbuild's spelling of the architecture, which differs
+          # from the one this build uses internally (x64 rather than x86_64).
+          - { name: 'arm64', arch: 'arm64', runner: 'macos-15' }
+          # macos-26-intel rather than macos-15-intel: create-dmg's unmount
+          # scales with how much real Mach-O content lands on the volume, and
+          # the macos-15-intel image is slow enough that the real bundle
+          # crosses hdiutil's 120-second DiskArbitration timeout. Measured with
+          # an identical payload, unmount to "Disk image done": 19s on arm64,
+          # 41s on macos-26-intel, 82s on macos-15-intel, and that was with a
+          # lighter stand-in than the real bundle. It is also the newer image,
+          # which we would move to regardless since macOS 15 retires first.
+          - { name: 'x64',   arch: 'x86_64', runner: 'macos-26-intel' }
+
+    timeout-minutes: 120
+
+    steps:
+      - uses: actions/checkout@v7
+
+      - uses: actions/setup-node@v7
+        with:
+          node-version: '20.x'
+
+      - name: Enable Corepack
+        run: corepack enable
+
+      # syft generates the SBOM, wget fetches Electron. PostgreSQL and its
+      # dependencies no longer come from Homebrew; see below.
+      - name: Install the build dependencies
+        run: brew install syft wget
+
+      # The dependencies come from pgadmin-org/pgbuild, built against each
+      # other with --with-zstd --with-lz4 and a 14.0 deployment target, which
+      # is what the release build ships. Homebrew's PostgreSQL was only ever a
+      # stand-in: it has no zstd or lz4 support (issue #9425), links Homebrew's
+      # OpenSSL rather than ours, and carries whatever minimum OS Homebrew
+      # happened to build for.
+      - name: Install the PostgreSQL build dependencies
+        uses: ./.github/actions/install-pgbuild-deps
+        with:
+          arch: ${{ matrix.arch }}
+
+      - name: Show what pg_dump expects
+        run: otool -L /opt/pgbuild/postgresql/bin/pg_dump
+
+      - name: Check the appbundle build
+        run: |
+          export PGADMIN_POSTGRES_DIR=/opt/pgbuild/postgresql
+
+          # cryptography publishes arm64-only macOS wheels (checked against
+          # 50.0.1), so on Intel pip builds it from the sdist and its
+          # openssl-sys crate links whatever OpenSSL it finds on the build
+          # host. _fixup_imports deliberately skips _rust.abi3.so, so that
+          # reference would survive into the bundle and _verify_bundle_linkage
+          # would fail the build. Linking statically leaves no external
+          # reference at all, and against our own OpenSSL rather than a
+          # different one from Homebrew. See issue #10123.
+          export OPENSSL_DIR=/opt/pgbuild/openssl
+          export OPENSSL_STATIC=1
+
+          make appbundle
+
+      - name: Archive the disk image
+        uses: actions/upload-artifact@v7
+        with:
+          name: pgadmin4-macos-build-output-${{ matrix.name }}
+          if-no-files-found: error
+          path: dist/*.dmg

.github/workflows/check-python-build.yml

@@ -1,15 +1,57 @@
 name: Check Python build
 
 on:
+  # Callable from snapshot.yml, so that what gets published is the
+  # same build that runs on every push rather than a second
+  # definition of it that can drift.
+  workflow_call:
+
   push:
     branches: [ "master" ]
+    paths:
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'pkg/pip/**'
+      - 'requirements.txt'
+      - 'Makefile'
+      - 'docs/**'
+      - 'LICENSE'
+      - 'README.md'
+      - 'tools/setup-python-env.sh'
+      - '.github/workflows/check-python-build.yml'
   pull_request:
     branches: [ "master" ]
+    paths:
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'pkg/pip/**'
+      - 'requirements.txt'
+      - 'Makefile'
+      - 'docs/**'
+      - 'LICENSE'
+      - 'README.md'
+      - 'tools/setup-python-env.sh'
+      - '.github/workflows/check-python-build.yml'
 
   workflow_dispatch:
 
 concurrency:
-  group: '${{ github.workflow }} @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }}'
+  # The workflow's own name, spelled out rather than taken from
+  # github.workflow, because in a reusable workflow that expression is
+  # the CALLER's name. Every workflow Snapshot calls would otherwise
+  # share one group and, with cancel-in-progress, cancel each other.
+  # github.event_name is in the key because a called workflow inherits the
+  # caller's ref: once this is on master, the nightly Snapshot's deb build
+  # and an ordinary push's deb build would otherwise share a group and,
+  # with cancel-in-progress, kill each other. A push landing mid-nightly
+  # would cancel the snapshot's build and skip the publish entirely.
+  group: 'check-python-build @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }} @ ${{ github.event_name }}'
   cancel-in-progress: true
 
 jobs:
@@ -17,7 +59,7 @@ jobs:
     runs-on: ubuntu-22.04
 
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v7
 
       - name: Install platform dependencies
         run: |
@@ -33,7 +75,8 @@ jobs:
           make pip
 
       - name: Archive Python wheel
-        uses: actions/upload-artifact@v4
+        uses: actions/upload-artifact@v7
         with:
           name: pgadmin4-python-build-output
+          if-no-files-found: error
           path: dist/*

.github/workflows/check-python-style.yml

@@ -3,8 +3,16 @@ name: Check Python style
 on:
   push:
     branches: [ "master" ]
+    paths:
+      - '**.py'
+      - '.pycodestyle'
+      - '.github/workflows/check-python-style.yml'
   pull_request:
     branches: [ "master" ]
+    paths:
+      - '**.py'
+      - '.pycodestyle'
+      - '.github/workflows/check-python-style.yml'
 
   workflow_dispatch:
 
@@ -17,7 +25,7 @@ jobs:
     runs-on: ubuntu-22.04
 
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v7
 
       - name: Install Python dependencies
         run: |

.github/workflows/check-rpm-build.yml

@@ -0,0 +1,173 @@
+# Replaces the pgadmin4-rpm-qa Jenkins job, as check-deb-build.yml replaces the
+# DEB one: a container per distribution on a hosted runner, rather than a
+# dedicated EC2 VM per distribution.
+#
+# Unlike the DEB build, the PGDG repository is not optional here.
+# pkg/redhat/build.sh opens with `export PATH=$(ls -d /usr/pgsql-1* | ...)` and
+# runs under `set -e`, so the build dies immediately without a PGDG PostgreSQL
+# installed.
+#
+# The QA job does not sign anything; `rpmsign --resign` is a separate step in
+# the release and snapshot jobs.
+
+name: Check RPM builds
+
+on:
+  # Callable from snapshot.yml, so that what gets published is the
+  # same build that runs on every push rather than a second
+  # definition of it that can drift.
+  workflow_call:
+
+  push:
+    branches: [ "master" ]
+    paths:
+      - 'pkg/redhat/**'
+      - 'pkg/linux/**'
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'docs/**'
+      - 'requirements.txt'
+      - 'Makefile'
+      - 'tools/setup-python-env.sh'
+      - '.github/workflows/check-rpm-build.yml'
+
+  workflow_dispatch:
+
+concurrency:
+  # The workflow's own name, spelled out rather than taken from
+  # github.workflow, because in a reusable workflow that expression is
+  # the CALLER's name. Every workflow Snapshot calls would otherwise
+  # share one group and, with cancel-in-progress, cancel each other.
+  # github.event_name is in the key because a called workflow inherits the
+  # caller's ref: once this is on master, the nightly Snapshot's deb build
+  # and an ordinary push's deb build would otherwise share a group and,
+  # with cancel-in-progress, kill each other. A push landing mid-nightly
+  # would cancel the snapshot's build and skip the publish entirely.
+  group: 'check-rpm-build @ ${{ github.ref }} @ ${{ github.event_name }}'
+  cancel-in-progress: true
+
+permissions:
+  contents: read
+
+jobs:
+  build-rpm:
+    runs-on: ubuntu-24.04
+
+    strategy:
+      fail-fast: false
+      matrix:
+        include:
+          # "name" exists only because artifact names may not contain a colon.
+          # "repo" selects the PGDG repository RPM, which is built per
+          # distribution family and major version.
+          - name: 'el-9'
+            image: 'almalinux:9'
+            repo: 'https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm'
+          - name: 'el-10'
+            image: 'almalinux:10'
+            repo: 'https://download.postgresql.org/pub/repos/yum/reporpms/EL-10-x86_64/pgdg-redhat-repo-latest.noarch.rpm'
+          - name: 'fedora-43'
+            image: 'fedora:43'
+            repo: 'https://download.postgresql.org/pub/repos/yum/reporpms/F-43-x86_64/pgdg-fedora-repo-latest.noarch.rpm'
+          - name: 'fedora-44'
+            image: 'fedora:44'
+            repo: 'https://download.postgresql.org/pub/repos/yum/reporpms/F-44-x86_64/pgdg-fedora-repo-latest.noarch.rpm'
+
+    container: ${{ matrix.image }}
+
+    steps:
+      # Before checkout, so the action has git available.
+      - name: Install the build environment
+        env:
+          PGDG_REPO: ${{ matrix.repo }}
+        run: |
+          dnf install -y dnf-plugins-core
+
+          # EL needs EPEL and CRB for the build dependencies; Fedora has
+          # everything in the main repositories.
+          if [ ! -f /etc/fedora-release ]; then
+              dnf install -y epel-release
+              dnf config-manager --set-enabled crb
+          fi
+
+          # The distro's own PostgreSQL module would shadow PGDG's packages.
+          dnf -qy module disable postgresql || true
+
+          dnf install -y --nogpgcheck "${PGDG_REPO}"
+
+          # The compiler toolchain is not optional: psycopg-c and gssapi are
+          # both built from source (pkg/linux/build-functions.sh passes
+          # --no-binary psycopg), and rpmbuild needs redhat-rpm-config. The
+          # buildfarm gets these from the @development-tools group; they are
+          # listed individually here so the container stays small.
+          dnf install -y \
+              diffutils \
+              expect \
+              fakeroot \
+              file \
+              findutils \
+              gcc \
+              gcc-c++ \
+              git \
+              krb5-devel \
+              libpq5-devel \
+              make \
+              openssl-devel \
+              patch \
+              postgresql18-devel \
+              python3-devel \
+              python3-pip \
+              python3-sphinx \
+              redhat-rpm-config \
+              rpm-build \
+              rpm-sign \
+              unzip \
+              wget \
+              yum-utils \
+              zlib-devel
+
+          # pkg/redhat/build.sh:229 shells out to yumdownloader, and a missing
+          # one surfaces as a bare exit 127 twelve minutes into the build,
+          # after the docs and the webpack bundle. Fail here instead, where the
+          # message is obvious. dnf5 distributions (EL10, Fedora 41+) get
+          # yumdownloader through yum-utils' compatibility shims rather than
+          # from yum itself, so it is worth checking rather than assuming.
+          command -v yumdownloader >/dev/null || {
+              echo "ERROR: yumdownloader is not on PATH; pkg/redhat/build.sh needs it." >&2
+              exit 1
+          }
+
+      - name: Install the Sphinx extensions
+        run: python3 -m pip install --break-system-packages sphinxcontrib-youtube || python3 -m pip install sphinxcontrib-youtube
+
+      - name: Install syft
+        run: curl -sSfL https://raw.githubusercontent.com/anchore/syft/v1.52.0/install.sh | sh -s -- -b /usr/local/bin v1.52.0
+
+      - uses: actions/setup-node@v7
+        with:
+          node-version: '20.x'
+
+      - uses: actions/checkout@v7
+
+      # The container runs as root while the workspace is owned by the runner
+      # user, so git refuses to operate on it ("detected dubious ownership").
+      # The build shells out to git for the commit hash during `yarn run
+      # bundle`, which fails with exit 128 without this.
+      - name: Mark the workspace as a safe git directory
+        run: git config --global --add safe.directory "${GITHUB_WORKSPACE}"
+
+      - name: Enable Corepack
+        run: corepack enable
+
+      - name: Check the RPM build
+        run: make redhat
+
+      - name: Archive the packages
+        uses: actions/upload-artifact@v7
+        with:
+          name: pgadmin4-rpm-build-output-${{ matrix.name }}
+          if-no-files-found: error
+          path: dist/*.rpm

.github/workflows/check-tarball-build.yml

@@ -1,15 +1,57 @@
 name: Check tarball build
 
 on:
+  # Callable from snapshot.yml, so that what gets published is the
+  # same build that runs on every push rather than a second
+  # definition of it that can drift.
+  workflow_call:
+
   push:
     branches: [ "master" ]
+    paths:
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'docs/**'
+      - 'pkg/src/**'
+      - 'requirements.txt'
+      - 'Makefile'
+      - 'LICENSE'
+      - 'README.md'
+      - 'tools/setup-python-env.sh'
+      - '.github/workflows/check-tarball-build.yml'
   pull_request:
     branches: [ "master" ]
+    paths:
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'docs/**'
+      - 'pkg/src/**'
+      - 'requirements.txt'
+      - 'Makefile'
+      - 'LICENSE'
+      - 'README.md'
+      - 'tools/setup-python-env.sh'
+      - '.github/workflows/check-tarball-build.yml'
 
   workflow_dispatch:
 
 concurrency:
-  group: '${{ github.workflow }} @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }}'
+  # The workflow's own name, spelled out rather than taken from
+  # github.workflow, because in a reusable workflow that expression is
+  # the CALLER's name. Every workflow Snapshot calls would otherwise
+  # share one group and, with cancel-in-progress, cancel each other.
+  # github.event_name is in the key because a called workflow inherits the
+  # caller's ref: once this is on master, the nightly Snapshot's deb build
+  # and an ordinary push's deb build would otherwise share a group and,
+  # with cancel-in-progress, kill each other. A push landing mid-nightly
+  # would cancel the snapshot's build and skip the publish entirely.
+  group: 'check-tarball-build @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }} @ ${{ github.event_name }}'
   cancel-in-progress: true
 
 jobs:
@@ -17,7 +59,7 @@ jobs:
     runs-on: ubuntu-22.04
 
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v7
 
       - name: Install platform dependencies
         run: |
@@ -33,7 +75,8 @@ jobs:
           make src
 
       - name: Archive source tarball
-        uses: actions/upload-artifact@v4
+        uses: actions/upload-artifact@v7
         with:
           name: pgadmin4-tarball-build-output
+          if-no-files-found: error
           path: dist/*

.github/workflows/check-translations.yml

@@ -3,8 +3,16 @@ name: Check translations
 on:
   push:
     branches: [ "master" ]
+    paths:
+      - 'web/**'
+      - 'Makefile'
+      - '.github/workflows/check-translations.yml'
   pull_request:
     branches: [ "master" ]
+    paths:
+      - 'web/**'
+      - 'Makefile'
+      - '.github/workflows/check-translations.yml'
 
   workflow_dispatch:
 
@@ -17,7 +25,7 @@ jobs:
     runs-on: ubuntu-22.04
 
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v7
 
       - name: Install platform dependencies
         run: |

.github/workflows/check-windows-build.yml

@@ -0,0 +1,149 @@
+# Replaces the pgadmin4-windows-x64-qa Jenkins job.
+#
+# This runs on a hosted runner, not a self-hosted one. Code signing in Make.bat
+# is conditional on PGADMIN_WINDOWS_CSC being set (see :SIGN_FILES,
+# :CREATE_INSTALLER and :VERIFY_SIGNATURE in Make.bat), so an unsigned build
+# check needs neither the Certum hardware token nor the machine it is plugged
+# into. Only the release and snapshot builds, which do sign, need the
+# self-hosted runner.
+#
+# Dependencies come from dpage/winpgbuild, which is exactly where the
+# buildfarm's winpgbuild-update job gets them, so the toolchain matches what
+# the release build uses rather than being an approximation of it.
+#
+# UNTESTED as written: unlike the macOS equivalent this has not yet had a
+# successful run, so expect the first few attempts to need adjustment.
+
+name: Check Windows build
+
+on:
+  push:
+    branches: [ "master" ]
+    paths:
+      - 'Make.bat'
+      - 'pkg/win32/**'
+      - 'pkg/python-version.txt'
+      - '.github/actions/install-pgbuild-deps/action.yml'
+      # Which build of each dependency this compiles against, so a
+      # change to it changes what the installer contains.
+      - 'pkg/pgbuild-deps.lock'
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'docs/**'
+      - 'requirements.txt'
+      - '.github/workflows/check-windows-build.yml'
+
+  workflow_dispatch:
+
+concurrency:
+  # The workflow's own name, spelled out rather than taken from
+  # github.workflow, because in a reusable workflow that expression is
+  # the CALLER's name. Every workflow Snapshot calls would otherwise
+  # share one group and, with cancel-in-progress, cancel each other.
+  group: 'check-windows-build @ ${{ github.ref }}'
+  cancel-in-progress: true
+
+permissions:
+  contents: read
+
+jobs:
+  build-installer:
+    runs-on: windows-2025
+    timeout-minutes: 120
+
+    env:
+      # The major version of the PostgreSQL release to pull from pgbuild,
+      # matching DEFAULT_POSTGRESQL_VERSION on the buildfarm.
+      POSTGRES_MAJOR: '18'
+
+    steps:
+      - uses: actions/checkout@v7
+
+      - uses: actions/setup-node@v7
+        with:
+          node-version: '20.x'
+
+      - name: Enable Corepack
+        run: corepack enable
+
+      # None of these are on the hosted image. wget matters most: Make.bat's
+      # Electron download is an unbounded retry loop (Make.bat:370), so without
+      # it the build spins on error 9009 until the job times out rather than
+      # failing. syft generates the SBOM, and its absence is silent, since
+      # :GENERATE_SBOM redirects into sbom.json and returns 0 regardless. The
+      # buildfarm's Windows worker installs all three via Chocolatey too.
+      - name: Install Inno Setup, syft and wget
+        run: choco install innosetup syft wget -y --no-progress
+
+      # From pgadmin-org/pgbuild, which supersedes dpage/winpgbuild and is
+      # where the macOS dependencies come from too, so both platforms build
+      # against one manifest of pinned versions. The archives unpack to
+      # <DEPS_DIR>\postgresql and <DEPS_DIR>\krb5.
+      # Unpacked under the runner's own temp directory rather than a fixed
+      # path. C:\build64 was the obvious choice and the wrong one: it is what
+      # the buildfarm's winpgbuild-update job manages on the Windows worker,
+      # deleting and re-extracting postgresql and krb5 inside it. Since the
+      # signing builds will run on that same machine as a self-hosted runner,
+      # a shared path would have the two systems overwriting each other's
+      # dependencies, and the resulting Jenkins failures would look nothing
+      # like their cause.
+      - name: Install the PostgreSQL and Kerberos dependencies
+        id: deps
+        uses: ./.github/actions/install-pgbuild-deps
+        with:
+          arch: x86_64
+          postgres-major: ${{ env.POSTGRES_MAJOR }}
+
+      - name: Record the dependency location
+        shell: pwsh
+        run: '"DEPS_DIR=${{ steps.deps.outputs.prefix }}" | Out-File -FilePath $env:GITHUB_ENV -Append'
+
+      # The hosted image ships Visual Studio Enterprise at a path that differs
+      # from the Community install Make.bat defaults to, and the redistributable
+      # version directory changes with every VS update, so both are discovered
+      # rather than hardcoded.
+      - name: Locate the Visual Studio toolchain
+        shell: pwsh
+        run: |
+          $vswhere = "${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer\vswhere.exe"
+          $vs = & $vswhere -latest -products * -property installationPath
+          if (-not $vs) { throw "Could not locate a Visual Studio installation" }
+          Write-Output "Visual Studio: $vs"
+
+          $redist = Get-ChildItem "$vs\VC\Redist\MSVC" -Directory |
+              Where-Object { Test-Path "$($_.FullName)\vc_redist.x64.exe" } |
+              Sort-Object Name -Descending |
+              Select-Object -First 1
+          if (-not $redist) { throw "Could not locate vc_redist.x64.exe under $vs" }
+          Write-Output "VC++ redistributable: $($redist.FullName)"
+
+          "VS_INSTALL_DIR=$vs"                  | Out-File -FilePath $env:GITHUB_ENV -Append
+          "PGADMIN_VCREDIST_DIR=$($redist.FullName)" | Out-File -FilePath $env:GITHUB_ENV -Append
+
+      # psycopg[c] compiles against libpq, so the build needs the MSVC
+      # environment. vcvars64.bat only sets it for its own process, hence
+      # invoking it and Make.bat in a single cmd session, as the Jenkins job
+      # does.
+      #
+      # No Python is set up for this job: Make.bat downloads the version named
+      # in pkg/python-version.txt, so the build gets the same interpreter here
+      # as it does on the signing host and on a developer's machine.
+      - name: Check the installer build
+        shell: cmd
+        run: |
+          SET "PGADMIN_POSTGRES_DIR=%DEPS_DIR%\postgresql"
+          SET "PGADMIN_KRB5_DIR=%DEPS_DIR%\krb5"
+          SET "PGADMIN_INNOTOOL_DIR=C:\Program Files (x86)\Inno Setup 6"
+
+          CALL "%VS_INSTALL_DIR%\VC\Auxiliary\Build\vcvars64.bat" || EXIT /b 1
+          CALL Make.bat || EXIT /b 1
+
+      - name: Archive the installer
+        uses: actions/upload-artifact@v7
+        with:
+          name: pgadmin4-windows-build-output
+          if-no-files-found: error
+          path: dist/*.exe

.github/workflows/promote-release.yml

@@ -0,0 +1,447 @@
+# Promote a tested release candidate to the download server.
+#
+# This is the irreversible one. Everything before it produces something that
+# can be rebuilt or deleted without anybody noticing; this puts packages in
+# front of every pgAdmin user, and within the hour they are on the PostgreSQL
+# mirror network and in the S3 archive, which has no --delete and therefore no
+# undo.
+#
+# So it builds nothing. It takes a candidate that already exists on the
+# development server, having been built, signed, indexed and installed from by
+# the acceptance test, and moves it across. If a candidate needs changing, the
+# answer is a new candidate rather than a repair applied here.
+#
+# The version is separate from the location deliberately: 2026-09-21-1 is a
+# build, 9.18 is what users will call it, and conflating them is how somebody
+# publishes the wrong tree under the right name.
+
+name: Promote release
+
+on:
+  workflow_dispatch:
+    inputs:
+      version:
+        description: 'Version to publish, for example 9.18'
+        required: true
+        type: string
+      location:
+        description: 'Candidate to promote, for example 2026-09-21-1'
+        required: true
+        type: string
+      confirm:
+        description: 'Type the version again to confirm'
+        required: true
+        type: string
+      container-tags:
+        description: >-
+          Space separated tags for the container, for example
+          "9 9.18 9.18.0 latest". Required when scope is everything.
+        required: false
+        type: string
+        default: ''
+      scope:
+        description: >-
+          How much to do. "everything" is a real promotion. "files" stops
+          before the website and the S3 archive, neither of which can be
+          undone. "release-directory" stops before the package
+          repositories as well, touching only v<VERSION>, which is the
+          only setting that leaves the live repositories alone and so the
+          only one safe to rehearse the download server with.
+          "registries" is the other half: it skips the download server
+          entirely and runs only the container re-tag and the chart push,
+          so those can be exercised against a candidate tag without a
+          release. It does not upload to PyPI, there being no published
+          wheel to upload.
+        type: choice
+        required: true
+        default: release-directory
+        options:
+          - release-directory
+          - files
+          - everything
+          - registries
+
+concurrency:
+  group: 'promote-release'
+  cancel-in-progress: false
+
+permissions:
+  contents: read
+
+jobs:
+  # Every input is checked here, before either of the jobs that act on one
+  # runs, because the checks used to live in promote and the registries scope
+  # skips that job: under that scope the confirmation gate did not apply to
+  # the step that moves the latest tag.
+  check:
+    runs-on: ubuntu-24.04
+
+    steps:
+      - name: Check the request
+        env:
+          VERSION: ${{ inputs.version }}
+          LOCATION: ${{ inputs.location }}
+          CONFIRM: ${{ inputs.confirm }}
+          TAGS: ${{ inputs.container-tags }}
+          SCOPE: ${{ inputs.scope }}
+        run: |
+          set -euo pipefail
+
+          # Typed twice, because the cost of getting this wrong is a version
+          # published from the wrong tree and no way to unpublish it.
+          if [ "${VERSION}" != "${CONFIRM}" ]; then
+              echo "The confirmation does not match the version." >&2
+              exit 1
+          fi
+
+          # The same shapes the wrapper enforces, checked here so a mistake
+          # costs a second rather than a round trip.
+          printf '%s' "${VERSION}" | grep -Eq '^[0-9]{1,2}\.[0-9]{1,2}(\.[0-9]{1,2})?$' || {
+              echo "Not a version: ${VERSION}" >&2; exit 1; }
+          printf '%s' "${LOCATION}" | grep -Eq '^[0-9]{4}-[0-9]{2}-[0-9]{2}(-[1-9][0-9]?)?$' || {
+              echo "Not a build location: ${LOCATION}" >&2; exit 1; }
+
+          # Only the scopes that publish containers need tags, but when they
+          # are given they are checked whatever the scope, so a bad value is
+          # not discovered halfway through a promotion.
+          if [ "${SCOPE}" = "everything" ] || [ "${SCOPE}" = "registries" ]; then
+              [ -n "${TAGS}" ] || {
+                  echo "container-tags is required for scope ${SCOPE}." >&2
+                  exit 1; }
+          fi
+          # -f, because an unquoted expansion is also a glob: a tag of * would
+          # otherwise be replaced by whatever is in the working directory.
+          set -f
+          for tag in ${TAGS}; do
+              printf '%s' "${tag}" | grep -Eq '^[A-Za-z0-9][A-Za-z0-9._-]{0,127}$' || {
+                  echo "Not a container tag: ${tag}" >&2; exit 1; }
+          done
+          set +f
+
+          echo "Request accepted: ${VERSION} from ${LOCATION}, scope ${SCOPE}."
+
+  promote:
+    needs: check
+    # Skipped entirely when only the registries are being exercised, so a
+    # rehearsal of those never touches the download server.
+    if: ${{ inputs.scope != 'registries' }}
+    runs-on: [self-hosted, publish]
+    environment: publishing
+
+    steps:
+      # The inputs are checked in the job above; this is about the runner.
+      - name: Check the runner
+        env:
+          DOWNLOAD: ${{ vars.DOWNLOAD_SSH_TARGET }}
+          PUBLISH_KEY: ${{ vars.PUBLISH_SSH_KEY || '~/.ssh/pga-publish' }}
+        run: |
+          set -euo pipefail
+
+          [ -n "${DOWNLOAD}" ] || { echo "DOWNLOAD_SSH_TARGET is not set." >&2; exit 1; }
+
+          # Both variables reach option positions: the target is the first
+          # positional argument to every ssh below, and the key path follows
+          # -i, so a value beginning with a hyphen would be read as an option
+          # rather than as the host or the path it is meant to be. Only an
+          # administrator can set a repository variable, which makes this
+          # defence in depth rather than a live hole, but it is checked here,
+          # once, before anything is published; the -- at each call site
+          # closes the same gap from the other end.
+          TARGET_RE='^[A-Za-z0-9][A-Za-z0-9._-]*(@[A-Za-z0-9][A-Za-z0-9.-]*)?$'
+          printf '%s' "${DOWNLOAD}" | grep -Eq "${TARGET_RE}" || {
+              echo "DOWNLOAD_SSH_TARGET is not a [user@]host." >&2; exit 1; }
+
+          KEY="${PUBLISH_KEY/#\~/$HOME}"
+          printf '%s' "${KEY}" | grep -Eq '^/[A-Za-z0-9._/-]+$' || {
+              echo "PUBLISH_SSH_KEY is not a plain absolute path." >&2
+              exit 1; }
+          [ -r "${KEY}" ] || { echo "Missing SSH key: ${KEY}" >&2; exit 1; }
+          if head -c 4 "${KEY}" | grep -q '^ssh-'; then
+              echo "${KEY} is a public key; -i needs the private one." >&2
+              exit 1
+          fi
+
+      # Checked before anything is created, so that a version published by
+      # mistake is caught here rather than by release-create failing halfway
+      # through and leaving a directory behind.
+      - name: Refuse to republish
+        env:
+          VERSION: ${{ inputs.version }}
+          DOWNLOAD: ${{ vars.DOWNLOAD_SSH_TARGET }}
+          PUBLISH_KEY: ${{ vars.PUBLISH_SSH_KEY || '~/.ssh/pga-publish' }}
+        run: |
+          set -euo pipefail
+          publish() {
+              ssh -i "${PUBLISH_KEY/#\~/$HOME}" -o BatchMode=yes \
+                  -o StrictHostKeyChecking=yes -- "${DOWNLOAD}" "$@"
+          }
+          if publish release-exists "${VERSION}" 2>/dev/null; then
+              echo "Version ${VERSION} is already published." >&2
+              echo "Publishing is single-shot; a correction needs a new version." >&2
+              exit 1
+          fi
+          echo "Version ${VERSION} is not yet published."
+
+      - name: Publish the release directory
+        env:
+          VERSION: ${{ inputs.version }}
+          LOCATION: ${{ inputs.location }}
+          DOWNLOAD: ${{ vars.DOWNLOAD_SSH_TARGET }}
+          PUBLISH_KEY: ${{ vars.PUBLISH_SSH_KEY || '~/.ssh/pga-publish' }}
+        run: |
+          set -euo pipefail
+          publish() {
+              echo "+ $*"
+              ssh -i "${PUBLISH_KEY/#\~/$HOME}" -o BatchMode=yes \
+                  -o StrictHostKeyChecking=yes -- "${DOWNLOAD}" "$@"
+          }
+
+          # The downloads first: the directory, then the files sorted into it,
+          # then the packages into the live repository trees. Nothing is
+          # visible to a package manager until the indices are rebuilt below,
+          # so an interruption here leaves packages that nothing points at
+          # rather than a repository describing packages that are not there.
+          publish release-create "${VERSION}"
+          publish release-fetch "${VERSION}" "${LOCATION}"
+
+      # Separate from the step above because this is where a promotion stops
+      # being reversible in practice. The step above creates one directory that
+      # can simply be deleted; this copies packages into the live repositories
+      # and re-signs the indices every client reads.
+      - name: Publish the packages
+        if: ${{ inputs.scope != 'release-directory' }}
+        env:
+          VERSION: ${{ inputs.version }}
+          LOCATION: ${{ inputs.location }}
+          DOWNLOAD: ${{ vars.DOWNLOAD_SSH_TARGET }}
+          PUBLISH_KEY: ${{ vars.PUBLISH_SSH_KEY || '~/.ssh/pga-publish' }}
+        run: |
+          set -euo pipefail
+          publish() {
+              echo "+ $*"
+              ssh -i "${PUBLISH_KEY/#\~/$HOME}" -o BatchMode=yes \
+                  -o StrictHostKeyChecking=yes -- "${DOWNLOAD}" "$@"
+          }
+
+          # The auto-updater archives, which release-fetch deliberately left
+          # behind because they belong outside the release directory.
+          publish autoupdate-publish "${VERSION}"
+
+          publish packages-fetch "${LOCATION}"
+
+          # The indices, which is the point at which the new packages become
+          # installable.
+          for codename in bookworm trixie jammy noble resolute; do
+              publish rebuild-apt "${codename}"
+          done
+          publish rebuild-yum redhat rhel 9 x86_64
+          publish rebuild-yum redhat rhel 10 x86_64
+          publish rebuild-yum fedora fedora 43 x86_64
+          publish rebuild-yum fedora fedora 44 x86_64
+
+          # The platform tables carry the release history, so they change with
+          # every release rather than only when a platform is added.
+          publish rebuild-readme apt
+          publish rebuild-readme yum
+
+      - name: Update the website
+        if: ${{ inputs.scope == 'everything' }}
+        env:
+          VERSION: ${{ inputs.version }}
+          DOWNLOAD: ${{ vars.DOWNLOAD_SSH_TARGET }}
+          PUBLISH_KEY: ${{ vars.PUBLISH_SSH_KEY || '~/.ssh/pga-publish' }}
+        run: |
+          set -euo pipefail
+          publish() {
+              echo "+ $*"
+              ssh -i "${PUBLISH_KEY/#\~/$HOME}" -o BatchMode=yes \
+                  -o StrictHostKeyChecking=yes -- "${DOWNLOAD}" "$@"
+          }
+
+          # Separate from the packages, and after them, because the website
+          # announcing a release whose files are not there yet is worse than
+          # files sitting there unannounced for a minute.
+          publish create-release "${VERSION}"
+          publish load-docs "${VERSION}"
+          publish purge-cache
+
+      - name: Archive to S3
+        if: ${{ inputs.scope == 'everything' }}
+        env:
+          DOWNLOAD: ${{ vars.DOWNLOAD_SSH_TARGET }}
+          PUBLISH_KEY: ${{ vars.PUBLISH_SSH_KEY || '~/.ssh/pga-publish' }}
+        run: |
+          set -euo pipefail
+          # Last, and on its own, because it is the slowest step and the one
+          # with no undo: the sync has no --delete, so anything it copies is
+          # in the archive permanently.
+          echo "+ sync-s3"
+          ssh -i "${PUBLISH_KEY/#\~/$HOME}" -o BatchMode=yes \
+              -o StrictHostKeyChecking=yes -- "${DOWNLOAD}" sync-s3
+
+      - name: Note what was skipped
+        if: ${{ inputs.scope != 'everything' }}
+        env:
+          SCOPE: ${{ inputs.scope }}
+          VERSION: ${{ inputs.version }}
+        run: |
+          echo "scope was ${SCOPE}, so this was not a full promotion."
+          if [ "${SCOPE}" = "release-directory" ]; then
+              echo "Only /var/ftp/pgadmin4/v${VERSION} was written. The package"
+              echo "repositories, the website and the S3 archive are untouched,"
+              echo "so removing that directory undoes this entirely."
+          else
+              echo "The website was not updated and nothing was archived to S3."
+              echo "The packages are live and will reach the mirrors at the next"
+              echo "hourly sync."
+          fi
+
+  # The registries, which need none of the publishing keys and no self-hosted
+  # runner:
+  # nothing here touches our servers. Separate so that a Docker Hub outage
+  # cannot leave a half-finished promotion on the download server, and so the
+  # runner holding the SSH keys never handles registry credentials.
+  registries:
+    needs: [check, promote]
+    # always(), because under the registries scope promote is skipped rather
+    # than run, and a plain needs would skip this with it. check is never
+    # skipped, so requiring its success is what keeps the inputs validated on
+    # both paths.
+    if: >-
+      ${{ always()
+          && needs.check.result == 'success'
+          && (inputs.scope == 'everything' || inputs.scope == 'registries')
+          && (needs.promote.result == 'success'
+              || needs.promote.result == 'skipped') }}
+    runs-on: ubuntu-24.04
+    environment: publishing
+
+    permissions:
+      contents: read
+      # For PyPI trusted publishing, which exchanges this for a short-lived
+      # upload credential rather than using a stored API token.
+      id-token: write
+      # For GHCR, which needs no stored credential at all.
+      packages: write
+
+    steps:
+      - uses: actions/checkout@v7
+
+      # By commit rather than by tag, since this script is piped into a shell
+      # in the same job that then logs in to two registries, and a tag can be
+      # moved. bec5b06 is v4.3.0.
+      - name: Install Helm
+        run: |
+          set -euo pipefail
+          curl -fsSL https://raw.githubusercontent.com/helm/helm/bec5b06ed841fe5269972d864d5177944fd5970f/scripts/get-helm-3 -o get-helm-3
+          chmod +x get-helm-3
+          ./get-helm-3
+
+      # Re-tagged rather than rebuilt, so what ships is the manifest the
+      # acceptance test ran against. imagetools works registry-side, so
+      # nothing is pulled or pushed through this runner.
+      - name: Publish the container
+        env:
+          LOCATION: ${{ inputs.location }}
+          TAGS: ${{ inputs.container-tags }}
+          DOCKERHUB_USERNAME: ${{ secrets.DOCKERHUB_USERNAME }}
+          DOCKERHUB_TOKEN: ${{ secrets.DOCKERHUB_TOKEN }}
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          GITHUB_ACTOR: ${{ github.actor }}
+        run: |
+          set -euo pipefail
+          # Validated by the check job. -f so that the word splitting below
+          # does not also glob against the workspace.
+          set -f
+
+          printf '%s' "${DOCKERHUB_TOKEN}" \
+              | docker login -u "${DOCKERHUB_USERNAME}" --password-stdin
+          printf '%s' "${GITHUB_TOKEN}" \
+              | docker login ghcr.io -u "${GITHUB_ACTOR}" --password-stdin
+
+          # Docker Hub stays canonical, because every tutorial, compose file
+          # and manifest in the world names dpage/pgadmin4. GHCR is published
+          # alongside it: organisation owned, no stored credential, and not
+          # subject to Docker Hub's anonymous pull limits.
+          for tag in ${TAGS}; do
+              echo "+ ${LOCATION} -> :${tag}"
+              docker buildx imagetools create \
+                  --tag "dpage/pgadmin4:${tag}" \
+                  --tag "ghcr.io/pgadmin-org/pgadmin4:${tag}" \
+                  "dpage/pgadmin4:${LOCATION}"
+          done
+          docker logout ghcr.io
+          docker logout
+
+      # The chart carries the release version from pkg/helm/Chart.yaml, so
+      # unlike the container there is no candidate copy to re-tag: it is
+      # packaged and pushed once, here.
+      #
+      # To GHCR rather than Docker Hub. The chart's install base is a small
+      # fraction of the container's, so moving it breaks far less than moving
+      # the image would, oci://docker.io/dpage was an odd home for a chart in
+      # the first place, and it needs no stored credential here.
+      - name: Publish the Helm chart
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          GITHUB_ACTOR: ${{ github.actor }}
+        run: |
+          set -euo pipefail
+          printf '%s' "${GITHUB_TOKEN}" \
+              | helm registry login ghcr.io -u "${GITHUB_ACTOR}" --password-stdin
+          helm package pkg/helm
+          helm push pgadmin4-helm-*.tgz oci://ghcr.io/pgadmin-org
+          helm registry logout ghcr.io
+
+      # Fetched from the published release rather than rebuilt, so what
+      # reaches PyPI is the file the acceptance test installed.
+      - name: Collect the wheel
+        if: ${{ inputs.scope == 'everything' }}
+        env:
+          VERSION: ${{ inputs.version }}
+        run: |
+          set -euo pipefail
+          mkdir -p pypi-dist
+          BASE="https://ftp.postgresql.org/pub/pgadmin/pgadmin4/v${VERSION}"
+          WHEEL="pgadmin4-${VERSION}-py3-none-any.whl"
+          curl -fsS -o "pypi-dist/${WHEEL}" "${BASE}/pip/${WHEEL}"
+          # Beside the wheel rather than in pypi-dist, because everything in
+          # that directory is uploaded and PyPI has not accepted detached
+          # signatures since 2023.
+          curl -fsS -o "${WHEEL}.asc" "${BASE}/pip/${WHEEL}.asc"
+          ls -l pypi-dist
+
+      # The wheel arrives over TLS, which says it came from the mirror and
+      # nothing about what the mirror was given: the tree is replicated from
+      # our download server to machines we do not run, and the signature that
+      # has been sitting beside the file all along is the only thing that ties
+      # these bytes back to the key on the publishing server. Checking it
+      # costs a second and turns the last hop of a release into something an
+      # attacker cannot quietly alter.
+      - name: Verify the wheel before uploading it
+        if: ${{ inputs.scope == 'everything' }}
+        env:
+          VERSION: ${{ inputs.version }}
+        run: |
+          set -euo pipefail
+          curl -fsS -o packages_pgadmin_org.pub \
+              https://www.pgadmin.org/static/packages_pgadmin_org.pub
+
+          # A keyring of its own, holding that one key and nothing the runner
+          # image happened to trust already, so a signature made by any other
+          # key fails for want of a public key rather than passing on the
+          # strength of somebody else's.
+          GNUPGHOME=$(mktemp -d)
+          export GNUPGHOME
+          gpg --batch --import packages_pgadmin_org.pub
+          gpg --batch --verify "pgadmin4-${VERSION}-py3-none-any.whl.asc" \
+              "pypi-dist/pgadmin4-${VERSION}-py3-none-any.whl"
+          echo "Signature verified; the upload may proceed."
+
+      # Trusted publishing: PyPI verifies this workflow's OIDC identity, so
+      # there is no API token to hold, rotate or leak.
+      - name: Upload to PyPI
+        if: ${{ inputs.scope == 'everything' }}
+        uses: pypa/gh-action-pypi-publish@dc37677b2e1c63e2034f94d8a5b11f265b73ba33  # v1.14.2
+        with:
+          packages-dir: pypi-dist

.github/workflows/purge-website-cache.yml

@@ -0,0 +1,54 @@
+# Purge the cache in front of the website.
+#
+# Promotion purges it once, but the website edits that follow a release, the
+# downloads being activated, the current version record and the news article,
+# all happen afterwards and are all cached. This is the button for that, and
+# for the times somebody edits the site outside a release.
+#
+# It takes no arguments: the verb behind it clears everything, and there is
+# nothing for a caller to choose.
+
+name: Purge website cache
+
+on:
+  workflow_dispatch:
+
+concurrency:
+  group: 'purge-website-cache'
+  cancel-in-progress: true
+
+permissions:
+  contents: read
+
+jobs:
+  purge:
+    runs-on: [self-hosted, publish]
+    environment: publishing
+
+    steps:
+      - name: Purge
+        env:
+          DOWNLOAD: ${{ vars.DOWNLOAD_SSH_TARGET }}
+          PUBLISH_KEY: ${{ vars.PUBLISH_SSH_KEY || '~/.ssh/pga-publish' }}
+        run: |
+          set -euo pipefail
+          [ -n "${DOWNLOAD}" ] || { echo "DOWNLOAD_SSH_TARGET is not set." >&2; exit 1; }
+
+          # The target is the first positional argument to ssh and the key
+          # path follows -i, so a value beginning with a hyphen would be read
+          # as an option rather than as what it is meant to be. Only an
+          # administrator can set a repository variable, so this is defence in
+          # depth rather than a live hole, but it costs a line and rules out a
+          # whole shape of mistake; the -- below does the same job from the
+          # other direction.
+          TARGET_RE='^[A-Za-z0-9][A-Za-z0-9._-]*(@[A-Za-z0-9][A-Za-z0-9.-]*)?$'
+          printf '%s' "${DOWNLOAD}" | grep -Eq "${TARGET_RE}" || {
+              echo "DOWNLOAD_SSH_TARGET is not a [user@]host." >&2; exit 1; }
+
+          KEY="${PUBLISH_KEY/#\~/$HOME}"
+          printf '%s' "${KEY}" | grep -Eq '^/[A-Za-z0-9._/-]+$' || {
+              echo "PUBLISH_SSH_KEY is not a plain absolute path." >&2
+              exit 1; }
+
+          ssh -i "${KEY}" -o BatchMode=yes \
+              -o StrictHostKeyChecking=yes -- "${DOWNLOAD}" purge-cache

.github/workflows/release-candidate.yml

@@ -0,0 +1,439 @@
+# Release candidate builds, replacing the buildfarm's pgadmin4-*-build jobs.
+#
+# The same builds as the nightly snapshot, published to the development server
+# instead of the download server. That difference is the point: a snapshot is
+# finished when it is published, whereas a candidate is published in order to
+# be tested, and promoted to the download server only afterwards.
+#
+# developer.pgadmin.org serves this tree over HTTP as soon as it is written, so
+# a candidate's repositories can be added and installed from immediately,
+# rather than waiting on the hourly sync between the download server and the
+# mirrors.
+#
+# Never scheduled. A candidate exists because somebody decided to make one.
+
+name: Release candidate
+
+on:
+  workflow_dispatch:
+    inputs:
+      location:
+        description: >-
+          Build directory name, normally today's date. A second
+          candidate on the same day needs a -N suffix, for example
+          2026-09-17-2.
+        required: false
+        default: ''
+      publish:
+        description: Upload to the development server when the build succeeds
+        type: boolean
+        required: false
+        default: false
+
+
+concurrency:
+  # One candidate at a time, and never cancelled: a cancelled run can abandon a
+  # notarisation already submitted to Apple, and leaves the signing token in an
+  # unknown state.
+  group: 'release-candidate'
+  cancel-in-progress: false
+
+permissions:
+  contents: read
+
+jobs:
+  # The directory name, decided once. Two jobs need it and they must agree:
+  # the repo RPMs carry the candidate's own URL inside them, so if that job and
+  # the assemble job each called date(1) a run straddling midnight would ship a
+  # repository configuration pointing at a build that does not exist.
+  location:
+    runs-on: ubuntu-24.04
+    outputs:
+      name: ${{ steps.pick.outputs.name }}
+    steps:
+      - id: pick
+        env:
+          REQUESTED: ${{ inputs.location }}
+        run: |
+          set -euo pipefail
+          NAME="${REQUESTED:-}"
+          [ -n "${NAME}" ] || NAME=$(date +%Y-%m-%d)
+
+          # Validated here so that everything downstream, including a shell on
+          # the machine holding the publishing keys, is working with a name
+          # that cannot be anything but a date and an optional suffix. The
+          # wrapper on the server applies its own rule to the same value; this
+          # one exists so a bad input fails in five seconds rather than after
+          # an hour of building.
+          if ! printf '%s' "${NAME}" | grep -Eq '^[0-9]{4}-[0-9]{2}-[0-9]{2}(-[1-9][0-9]?)?$'; then
+              echo "Not a valid build location: ${NAME}" >&2
+              echo "Expected YYYY-MM-DD, optionally with a -N suffix." >&2
+              exit 1
+          fi
+
+          echo "Build location: ${NAME}"
+          echo "name=${NAME}" >> "${GITHUB_OUTPUT}"
+
+  deb:
+    uses: ./.github/workflows/check-deb-build.yml
+  rpm:
+    uses: ./.github/workflows/check-rpm-build.yml
+  tarball:
+    uses: ./.github/workflows/check-tarball-build.yml
+  wheel:
+    uses: ./.github/workflows/check-python-build.yml
+  docs:
+    uses: ./.github/workflows/check-doc-builds.yml
+  # The container, pushed to the registry under this candidate's location so
+  # that it can be tested and then re-tagged at promotion. Not part of the
+  # download tree, which is why it is not in assemble's needs.
+  container:
+    needs: location
+    if: inputs.publish
+    # The caller caps a called workflow's token: the top-level
+    # 'contents: read' leaves 'packages: none', so the publish-container job's
+    # 'packages: write' request must be granted here or the workflow is
+    # rejected before it starts.
+    permissions:
+      contents: read
+      packages: write
+    uses: ./.github/workflows/check-container-build.yml
+    with:
+      publish: true
+      location: ${{ needs.location.outputs.name }}
+    secrets: inherit
+
+  # The Helm chart is built as a check but not published here. Its version
+  # comes from pkg/helm/Chart.yaml, so pushing it would publish the release
+  # version before the release, and the registry has no notion of a candidate
+  # the way the download server does. It goes out at promotion.
+  helm:
+    uses: ./.github/workflows/check-helm-build.yml
+
+  # The repository configuration RPMs. These are not built by the QA
+  # workflows, because they are not a build of pgAdmin: they are a one-file
+  # package carrying a .repo pointing at the tree they ship in, which is why
+  # the URL has to be known before they are built.
+  repo-rpm:
+    needs: location
+    runs-on: ubuntu-24.04
+    container: almalinux:9
+    steps:
+      - name: Install the build environment
+        run: dnf install -y --setopt=install_weak_deps=False rpm-build python3 git
+
+      - uses: actions/checkout@v7
+
+      - name: Mark the workspace as a safe git directory
+        run: git config --global --add safe.directory "${GITHUB_WORKSPACE}"
+
+      - name: Build the repository RPMs
+        env:
+          LOCATION: ${{ needs.location.outputs.name }}
+        run: |
+          # Through the environment rather than interpolated into the script.
+          # The location is a dispatch input, so it is text somebody chose, and
+          # workflow expression substitution happens before the shell ever sees the
+          # line, so a crafted location would otherwise become shell text.
+          export PGADMIN_REPO_DIR="https://developer.pgadmin.org/builds/${LOCATION}/yum"
+          echo "Repositories will point at ${PGADMIN_REPO_DIR}"
+          pkg/redhat/repo-rpm.sh
+
+      - name: Archive the repository RPMs
+        uses: actions/upload-artifact@v7
+        with:
+          name: pgadmin4-repo-rpm-build-output
+          if-no-files-found: error
+          path: dist/*.noarch.rpm
+
+  # snapshot-macos.yml and snapshot-windows.yml are the signed-build
+  # workflows rather than snapshot-only ones; the name predates there being
+  # a second caller.
+  macos:
+    uses: ./.github/workflows/snapshot-macos.yml
+    secrets: inherit
+
+  windows:
+    uses: ./.github/workflows/snapshot-windows.yml
+    secrets: inherit
+
+  assemble:
+    needs: [location, deb, rpm, tarball, wheel, docs, repo-rpm, macos, windows]
+
+    # the runner, not a hosted runner. This job assembles a tree of several
+    # hundred megabytes and then, when publishing, sends it to the development
+    # server; splitting the two meant uploading that tree as an artifact and
+    # immediately downloading it again on the runner, having first queued for a
+    # hosted runner behind whatever else the organisation was building.
+    runs-on: [self-hosted, publish]
+
+    # For the variables naming the keys and the target, which live here. The
+    # environment carries no protection rules, so a run that is not publishing
+    # is not gated by it.
+    environment: publishing
+
+    # Everything must have built except Windows. That is the one runner which
+    # can legitimately be offline, and a candidate without the installer is
+    # still worth having; a candidate missing its documentation, source tarball,
+    # wheel or repository RPMs is not, and the repository RPMs are worse than
+    # missing, since install-repo-readme.py then fails after the packages have
+    # been uploaded and signed, leaving half a candidate on the server.
+    if: >-
+      always()
+      && needs.location.result == 'success'
+      && needs.deb.result == 'success'
+      && needs.rpm.result == 'success'
+      && needs.tarball.result == 'success'
+      && needs.wheel.result == 'success'
+      && needs.docs.result == 'success'
+      && needs.repo-rpm.result == 'success'
+      && needs.macos.result == 'success'
+
+    steps:
+      - uses: actions/checkout@v7
+
+      # Only the build outputs, which are all named pgadmin4-*. The container
+      # build also leaves a 'pgadmin-org~pgadmin4~*.dockerbuild' build-record
+      # artifact that docker/build-push-action uploads; it is not a release
+      # file, and it is not stored as a plain zip, so download-artifact fails
+      # to extract it and, downloading everything, fails the whole step.
+      - name: Collect the build artefacts
+        uses: actions/download-artifact@v7
+        with:
+          path: artefacts
+          pattern: pgadmin4-*
+
+      # The layout is the one the publishing scripts and the download site
+      # expect, and is what the wrapper's stage-create verb creates on the
+      # staging server.
+      # The Debian architecture comes from the package filename rather than a
+      # table, since dpkg already encodes it there; the codename does not, so
+      # that mapping is explicit.
+      - name: Assemble the staging tree
+        env:
+          LOCATION: ${{ needs.location.outputs.name }}
+        run: |
+          set -euo pipefail
+          # Flat, beside apt/ and yum/, which is how both the staging server
+          # and the snapshots tree are laid out. The docs/macos/pip/source/
+          # windows subdivision belongs to a published release, and it is the
+          # promotion step that sorts files into it on the way there.
+          # Explicitly, rather than trusting the checkout to have cleaned it.
+          # This runs on a self-hosted runner whose workspace persists between
+          # jobs, and a previous run's tree left behind here is indistinguishable
+          # from this one's until something downstream has to choose between
+          # them.
+          rm -rf stage
+
+          STAGE="stage/${LOCATION}"
+          mkdir -p "${STAGE}/yum"
+
+          # An artefact can be legitimately absent: the Windows signing host is
+          # allowed to be offline, and a failed matrix leg is reported by its
+          # own job rather than by a confusing cp error here.
+          copy_into() {
+              DEST=$1; shift
+              for SRC in "$@"; do
+                  [ -e "${SRC}" ] || continue
+                  mkdir -p "${DEST}"
+                  cp "${SRC}" "${DEST}/"
+              done
+          }
+
+          codename_for() {
+              case "$1" in
+                  debian-12)   echo bookworm ;;
+                  debian-13)   echo trixie ;;
+                  ubuntu-2204) echo jammy ;;
+                  ubuntu-2404) echo noble ;;
+                  ubuntu-2604) echo resolute ;;
+                  *) echo "Unknown Debian build name: $1" >&2; exit 1 ;;
+              esac
+          }
+
+          for DIR in artefacts/pgadmin4-deb-build-output-*; do
+              [ -d "${DIR}" ] || continue
+              CODENAME=$(codename_for "${DIR##*-output-}")
+              for DEB in "${DIR}"/*.deb; do
+                  ARCH=$(basename "${DEB}" .deb); ARCH=${ARCH##*_}
+                  TARGET="${STAGE}/apt/${CODENAME}/dists/pgadmin4/main/binary-${ARCH}"
+                  mkdir -p "${TARGET}"
+                  cp "${DEB}" "${TARGET}/"
+              done
+          done
+
+          # RPM trees are named for the distribution, which the build name
+          # already carries: el-9 becomes redhat/rhel-9-x86_64.
+          for DIR in artefacts/pgadmin4-rpm-build-output-*; do
+              [ -d "${DIR}" ] || continue
+              NAME=${DIR##*-output-}
+              case "${NAME}" in
+                  el-*)     FAMILY=redhat; TREE="rhel-${NAME#el-}" ;;
+                  fedora-*) FAMILY=fedora; TREE="${NAME}" ;;
+                  *) echo "Unknown RPM build name: ${NAME}" >&2; exit 1 ;;
+              esac
+              # Every RPM for a distribution goes in that distribution's
+              # tree, including the noarch ones. Taking the directory from the
+              # package's own architecture would file pgadmin4 and
+              # pgadmin4-web, both noarch, under rhel-9-noarch, where no
+              # client looks: dnf asks for <name>-<version>-$basearch. The
+              # RPM matrix is x86_64 only for now, so this is a constant; when
+              # aarch64 arrives it becomes a property of the build.
+              TARGET="${STAGE}/yum/${FAMILY}/${TREE}-x86_64"
+              mkdir -p "${TARGET}"
+              cp "${DIR}"/*.rpm "${TARGET}/"
+          done
+
+          copy_into "${STAGE}" artefacts/pgadmin4-tarball-build-output/*
+          copy_into "${STAGE}" artefacts/pgadmin4-python-build-output/*
+          # The version is read once here and used for the documentation
+          # filenames, which the build leaves unversioned as pgadmin4.pdf and
+          # pgAdmin4.epub whilst the download site has always carried
+          # pgadmin4-<version>.pdf and .epub.
+          VERSION=$(python3 -c "import sys; sys.path.insert(0, 'web'); import version; print(version.APP_VERSION)")
+
+          for SRC in artefacts/pgadmin4-pdf-build-output/*.pdf; do
+              [ -e "${SRC}" ] && cp "${SRC}" "${STAGE}/pgadmin4-${VERSION}.pdf"
+          done
+          for SRC in artefacts/pgadmin4-epub-build-output/*.epub; do
+              [ -e "${SRC}" ] && cp "${SRC}" "${STAGE}/pgadmin4-${VERSION}.epub"
+          done
+
+          # The docs tarball is what load-docs.sh unpacks on the web server, so
+          # it ships as a tarball rather than as the directory of files the
+          # build produces.
+          if [ -d artefacts/pgadmin4-html-build-output ]; then
+              # Under a pgadmin4-<version>-docs/ directory, not flat. The
+              # web server's load-docs.sh unpacks this into the docs root
+              # and then hands docloader that directory name, so a flat
+              # archive would scatter several hundred files across the root
+              # and then fail on a directory that does not exist. Every
+              # released tarball has carried that top level; the tar here
+              # had not.
+              DOCS_DIR="pgadmin4-${VERSION}-docs"
+              rm -rf "artefacts/${DOCS_DIR}"
+              mv artefacts/pgadmin4-html-build-output "artefacts/${DOCS_DIR}"
+              tar -czf "${STAGE}/pgadmin4-${VERSION}-docs.tar.gz" \
+                  -C artefacts "${DOCS_DIR}"
+          fi
+
+          # At the root of yum/, beside the family directories, which is
+          # where the README instructions tell people to fetch them from.
+          copy_into "${STAGE}/yum" artefacts/pgadmin4-repo-rpm-build-output/*
+
+          copy_into "${STAGE}" artefacts/pgadmin4-macos-snapshot-*/*
+          copy_into "${STAGE}" artefacts/pgadmin4-windows-snapshot/*
+
+          find "${STAGE}" -type f | sort
+
+      - name: Check the keys are present
+        if: inputs.publish
+        env:
+          STAGING: ${{ vars.STAGING_SSH_TARGET }}
+          PUBLISH_KEY: ${{ vars.PUBLISH_SSH_KEY || '~/.ssh/pga-publish' }}
+          UPLOAD_KEY: ${{ vars.UPLOAD_SSH_KEY || '~/.ssh/pga-upload' }}
+        run: |
+          set -euo pipefail
+          for TOOL in ssh rsync; do
+              command -v "${TOOL}" >/dev/null || {
+                  echo "This runner has no ${TOOL}." >&2; exit 1; }
+          done
+
+          # These three variables reach option positions. The target is the
+          # first positional argument to ssh, and the key paths are spliced
+          # into the -e string that rsync splits on whitespace before exec'ing
+          # it, so a value beginning with a hyphen, or one carrying a space,
+          # would be read as an option or as a second word rather than as the
+          # host or the path it is meant to be. Only an administrator can set
+          # a repository variable, which makes this defence in depth rather
+          # than a live hole, but it is checked here, once, rather than at
+          # each point of use; the -- in the publish step below closes the
+          # same gap from the other end.
+          TARGET_RE='^[A-Za-z0-9][A-Za-z0-9._-]*(@[A-Za-z0-9][A-Za-z0-9.-]*)?$'
+          printf '%s' "${STAGING}" | grep -Eq "${TARGET_RE}" || {
+              echo "STAGING_SSH_TARGET is not a [user@]host." >&2; exit 1; }
+
+          for KEY in "${PUBLISH_KEY/#\~/$HOME}" "${UPLOAD_KEY/#\~/$HOME}"; do
+              printf '%s' "${KEY}" | grep -Eq '^/[A-Za-z0-9._/-]+$' || {
+                  echo "Not a plain absolute path: ${KEY}" >&2; exit 1; }
+              if [ ! -r "${KEY}" ]; then
+                  echo "Missing or unreadable SSH key: ${KEY}" >&2
+                  exit 1
+              fi
+              # A public key is readable too, and pointing -i at one fails
+              # later inside ssh with a message that does not mention which
+              # file was wrong. Both halves of a pair sit in the same
+              # directory with names one suffix apart, so this is an easy
+              # thing to configure wrongly and a cheap thing to catch.
+              if head -c 4 "${KEY}" | grep -q '^ssh-'; then
+                  echo "${KEY} is a public key; -i needs the private one." >&2
+                  echo "Drop the .pub suffix from the variable that names it." >&2
+                  exit 1
+              fi
+          done
+          if [ ! -r ~/.ssh/known_hosts ]; then
+              echo "This runner has no ~/.ssh/known_hosts, so host key" >&2
+              echo "checking would fail. Add the servers' host keys." >&2
+              exit 1
+          fi
+
+      - name: Publish the candidate
+        if: inputs.publish
+        env:
+          STAGING: ${{ vars.STAGING_SSH_TARGET }}
+          LOCATION: ${{ inputs.location }}
+          PUBLISH_KEY: ${{ vars.PUBLISH_SSH_KEY || '~/.ssh/pga-publish' }}
+          UPLOAD_KEY: ${{ vars.UPLOAD_SSH_KEY || '~/.ssh/pga-upload' }}
+        run: |
+          set -euo pipefail
+          if [ -z "${STAGING}" ]; then
+              echo "The STAGING_SSH_TARGET variable is not set." >&2
+              exit 1
+          fi
+
+          # One directory came out of assemble, named for the date. An explicit
+          # location overrides it so that a test run does not land on the
+          # build the buildfarm is still writing on the same server.
+          # assemble produces exactly one directory, named for the date.
+          # Anything else means the artefact is not what this step thinks it
+          # is, and guessing which one to publish is not a decision to make at
+          # three in the morning.
+          if [ "$(find stage -mindepth 1 -maxdepth 1 -type d | wc -l)" != "1" ]; then
+              echo "Expected one directory in the build artefact:" >&2
+              ls -l stage >&2
+              exit 1
+          fi
+          BUILT=$(basename "$(find stage -mindepth 1 -maxdepth 1 -type d)")
+          DEST=${LOCATION:-${BUILT}}
+          echo "Publishing ${BUILT} as ${DEST}"
+
+          publish() {
+              ssh -i "${PUBLISH_KEY/#\~/$HOME}" -o BatchMode=yes \
+                  -o StrictHostKeyChecking=yes -- "${STAGING}" "$@"
+          }
+
+          publish stage-create "${DEST}"
+
+          # No --delete, deliberately: rrsync refuses it anyway, and a
+          # publishing step that can remove things is a publishing step that
+          # can remove the wrong things.
+          rsync -rlt --safe-links --no-specials --no-devices \
+              -e "ssh -i ${UPLOAD_KEY/#\~/$HOME} -o BatchMode=yes -o StrictHostKeyChecking=yes" \
+              "stage/${BUILT}/" "${STAGING}:${DEST}/"
+
+          # Signing before indexing: the metadata has to describe the signed
+          # packages rather than the unsigned ones just uploaded.
+          publish stage-sign "${DEST}"
+          publish stage-index-apt "${DEST}"
+          publish stage-index-yum "${DEST}"
+
+  # Installing from the candidate, which is the only check that proves a user
+  # could have. It gates nothing automatically yet, promotion still being a
+  # human decision, but a red result here is a candidate that must not be
+  # promoted.
+  acceptance:
+    needs: [location, assemble]
+    if: inputs.publish
+    uses: ./.github/workflows/acceptance-test.yml
+    with:
+      base-url: https://developer.pgadmin.org/builds/${{ needs.location.outputs.name }}

.github/workflows/run-feature-tests-epas.yml

@@ -3,8 +3,28 @@ name: Run feature tests on EPAS
 on:
   push:
     branches: [ "master" ]
+    paths:
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'requirements.txt'
+      - 'Makefile'
+      - 'tools/setup-python-env.sh'
+      - '.github/workflows/run-feature-tests-epas.yml'
   pull_request:
     branches: [ "master" ]
+    paths:
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'requirements.txt'
+      - 'Makefile'
+      - 'tools/setup-python-env.sh'
+      - '.github/workflows/run-feature-tests-epas.yml'
 
   workflow_dispatch:
 
@@ -26,7 +46,7 @@ jobs:
     runs-on: ubuntu-22.04
 
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v7
 
       - name: Setup the EDB APT repo on Linux
         run: |
@@ -141,15 +161,16 @@ jobs:
           }
           EOF
 
-      - name: Upgrade yarn
-        run: |
-          yarn set version berry
-          yarn set version 4
+      # Corepack reads packageManager from web/package.json and provisions
+      # exactly that Yarn: a single pinned download, with nothing written
+      # into the checkout.
+      - name: Enable Corepack
+        run: corepack enable
 
       - name: Build the JS bundle
         run: |
           cd web
-          yarn install
+          yarn install --immutable
           yarn run bundle
 
       - name: Run the tests
@@ -162,21 +183,21 @@ jobs:
 
       - name: Archive server log
         if: success() || failure()
-        uses: actions/upload-artifact@v4
+        uses: actions/upload-artifact@v7
         with:
           name: server-log-pg${{ matrix.pgver }}
           path: var/pgadmin4.log
 
       - name: Archive regression log
         if: success() || failure()
-        uses: actions/upload-artifact@v4
+        uses: actions/upload-artifact@v7
         with:
           name: regression-log-pg${{ matrix.pgver }}
           path: web/regression/regression.log
 
       - name: Archive screenshots
         if: success() || failure()
-        uses: actions/upload-artifact@v4
+        uses: actions/upload-artifact@v7
         with:
           name: screenshots-pg${{ matrix.pgver }}
           path: web/regression/screenshots

.github/workflows/run-feature-tests-pg.yml

@@ -6,8 +6,28 @@ name: Run feature tests on PostgreSQL
 on:
   push:
     branches: [ "master" ]
+    paths:
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'requirements.txt'
+      - 'Makefile'
+      - 'tools/setup-python-env.sh'
+      - '.github/workflows/run-feature-tests-pg.yml'
   pull_request:
     branches: [ "master" ]
+    paths:
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'requirements.txt'
+      - 'Makefile'
+      - 'tools/setup-python-env.sh'
+      - '.github/workflows/run-feature-tests-pg.yml'
 
   workflow_dispatch:
 
@@ -25,7 +45,7 @@ jobs:
     runs-on: ubuntu-22.04
 
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v7
 
       - name: Setup the PGDG APT repo
         run: |
@@ -151,15 +171,16 @@ jobs:
           }
           EOF
 
-      - name: Upgrade yarn
-        run: |
-          yarn set version berry
-          yarn set version 4
+      # Corepack reads packageManager from web/package.json and provisions
+      # exactly that Yarn: a single pinned download, with nothing written
+      # into the checkout.
+      - name: Enable Corepack
+        run: corepack enable
 
       - name: Build the JS bundle
         run: |
           cd web
-          yarn install
+          yarn install --immutable
           yarn run bundle
 
       - name: Run the tests
@@ -172,21 +193,21 @@ jobs:
 
       - name: Archive server log
         if: success() || failure()
-        uses: actions/upload-artifact@v4
+        uses: actions/upload-artifact@v7
         with:
           name: server-log-pg${{ matrix.pgver }}
           path: var/pgadmin4.log
 
       - name: Archive regression log
         if: success() || failure()
-        uses: actions/upload-artifact@v4
+        uses: actions/upload-artifact@v7
         with:
           name: regression-log-pg${{ matrix.pgver }}
           path: web/regression/regression.log
 
       - name: Archive screenshots
         if: success() || failure()
-        uses: actions/upload-artifact@v4
+        uses: actions/upload-artifact@v7
         with:
           name: screenshots-pg${{ matrix.pgver }}
           path: web/regression/screenshots

.github/workflows/run-javascript-tests.yml

@@ -3,8 +3,30 @@ name: Run Javascript tests
 on:
   push:
     branches: [ "master" ]
+    paths:
+      - 'web/**/*.js'
+      - 'web/**/*.jsx'
+      - 'web/package.json'
+      - 'web/yarn.lock'
+      - 'web/jest.config.js'
+      - 'web/webpack.shim.js'
+      - 'web/regression/javascript/**'
+      - 'web/.yarnrc.yml'
+      - 'web/babel.config.json'
+      - '.github/workflows/run-javascript-tests.yml'
   pull_request:
     branches: [ "master" ]
+    paths:
+      - 'web/**/*.js'
+      - 'web/**/*.jsx'
+      - 'web/package.json'
+      - 'web/yarn.lock'
+      - 'web/jest.config.js'
+      - 'web/webpack.shim.js'
+      - 'web/regression/javascript/**'
+      - 'web/.yarnrc.yml'
+      - 'web/babel.config.json'
+      - '.github/workflows/run-javascript-tests.yml'
 
   workflow_dispatch:
 
@@ -22,21 +44,22 @@ jobs:
     runs-on: ${{ matrix.os }}
 
     steps:
-      - uses: actions/setup-node@v4
+      - uses: actions/setup-node@v7
         with:
           node-version: '20.x'
 
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v7
 
-      - name: Upgrade yarn
-        run: |
-          yarn set version berry
-          yarn set version 4
+      # Corepack reads packageManager from web/package.json and provisions
+      # exactly that Yarn: a single pinned download, with nothing written
+      # into the checkout.
+      - name: Enable Corepack
+        run: corepack enable
 
       - name: Install Node modules
         run: |
           cd web
-          yarn install
+          yarn install --immutable
 
       - name: Run the tests
         run: |

.github/workflows/run-python-tests-epas.yml

@@ -13,8 +13,30 @@ name: Run Python tests on EPAS
 on:
   push:
     branches: [ "master" ]
+    paths:
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'requirements.txt'
+      - 'Makefile'
+      - 'tools/setup-python-env.sh'
+      - 'tools/get_sb_package.py'
+      - '.github/workflows/run-python-tests-epas.yml'
   pull_request:
     branches: [ "master" ]
+    paths:
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'requirements.txt'
+      - 'Makefile'
+      - 'tools/setup-python-env.sh'
+      - 'tools/get_sb_package.py'
+      - '.github/workflows/run-python-tests-epas.yml'
 
   workflow_dispatch:
 
@@ -48,10 +70,10 @@ jobs:
     runs-on: ${{ matrix.os }}
 
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v7
 
       - name: Update python version
-        uses: actions/setup-python@v5
+        uses: actions/setup-python@v7
         with:
           python-version: '3.10'
 
@@ -311,14 +333,14 @@ jobs:
 
       - name: Archive server log
         if: success() || failure()
-        uses: actions/upload-artifact@v4
+        uses: actions/upload-artifact@v7
         with:
           name: server-log-epas-${{ matrix.os }}-pg${{ matrix.pgver }}
           path: var/pgadmin4.log
 
       - name: Archive regression log
         if: success() || failure()
-        uses: actions/upload-artifact@v4
+        uses: actions/upload-artifact@v7
         with:
           name: regression-log-epas-${{ matrix.os }}-pg${{ matrix.pgver }}
           path: web/regression/regression.log

.github/workflows/run-python-tests-pg.yml

@@ -6,10 +6,37 @@ name: Run Python tests on PostgreSQL
 on:
   push:
     branches: [ "master" ]
+    paths:
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'requirements.txt'
+      - 'Makefile'
+      - 'tools/setup-python-env.sh'
+      - 'tools/get_sb_package.py'
+      - '.github/workflows/run-python-tests-pg.yml'
   pull_request:
     branches: [ "master" ]
+    paths:
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'requirements.txt'
+      - 'Makefile'
+      - 'tools/setup-python-env.sh'
+      - 'tools/get_sb_package.py'
+      - '.github/workflows/run-python-tests-pg.yml'
 
   workflow_dispatch:
+    inputs:
+      pg_timetable_version:
+        description: 'pg_timetable version to install for the tests'
+        required: false
+        type: string
 
 concurrency:
   group: '${{ github.workflow }} @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }}'
@@ -17,6 +44,8 @@ concurrency:
 
 jobs:
   run-python-tests-pg:
+    env:
+      PG_TIMETABLE_VERSION: ${{ inputs.pg_timetable_version || '6.3.0' }}
     strategy:
       fail-fast: false
       matrix:
@@ -26,10 +55,10 @@ jobs:
     runs-on: ${{ matrix.os }}
 
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v7
 
       - name: Update python version
-        uses: actions/setup-python@v5
+        uses: actions/setup-python@v7
         with:
           python-version: '3.10'
 
@@ -143,6 +172,38 @@ jobs:
 
           psql postgres -p 59${{ matrix.pgver }} -c 'CREATE ROLE postgres SUPERUSER LOGIN;'
 
+      # pg_timetable tables are created by the agent and need the agent to test run_now.
+      - name: Install and start pg_timetable on Linux
+        if: ${{ matrix.os == 'ubuntu-22.04' }}
+        run: |
+          wget --quiet -O /tmp/pg_timetable.tar.gz https://github.com/cybertec-postgresql/pg_timetable/releases/download/v${{ env.PG_TIMETABLE_VERSION }}/pg_timetable_Linux_x86_64.tar.gz
+          tar -xzf /tmp/pg_timetable.tar.gz -C /tmp --strip-components=1
+          /tmp/pg_timetable --init --clientname=runner "host=/var/run/postgresql port=59${{ matrix.pgver }} dbname=postgres user=postgres"
+          nohup /tmp/pg_timetable --clientname=runner "host=/var/run/postgresql port=59${{ matrix.pgver }} dbname=postgres user=postgres" > /tmp/pg_timetable.log 2>&1 &
+          echo $! > /tmp/pg_timetable.pid
+          sleep 2
+
+      - name: Install and start pg_timetable on macOS
+        if: ${{ matrix.os == 'macos-latest' }}
+        run: |
+          curl -sSL -o /tmp/pg_timetable.tar.gz https://github.com/cybertec-postgresql/pg_timetable/releases/download/v${{ env.PG_TIMETABLE_VERSION }}/pg_timetable_Darwin_arm64.tar.gz
+          tar -xzf /tmp/pg_timetable.tar.gz -C /tmp --strip-components=1
+          /tmp/pg_timetable --init --clientname=runner "host=/tmp port=59${{ matrix.pgver }} dbname=postgres user=postgres"
+          nohup /tmp/pg_timetable --clientname=runner "host=/tmp port=59${{ matrix.pgver }} dbname=postgres user=postgres" > /tmp/pg_timetable.log 2>&1 &
+          echo $! > /tmp/pg_timetable.pid
+          sleep 2
+
+      - name: Install and start pg_timetable on Windows
+        if: ${{ matrix.os == 'windows-latest' }}
+        shell: pwsh
+        run: |
+          $env:PGPASSWORD = 'postgres'
+          curl.exe -sSL -o pg_timetable.zip https://github.com/cybertec-postgresql/pg_timetable/releases/download/v${{ env.PG_TIMETABLE_VERSION }}/pg_timetable_Windows_x86_64.zip
+          Expand-Archive -Path pg_timetable.zip -DestinationPath .
+          & .\pg_timetable_Windows_x86_64\pg_timetable.exe --init --clientname=runner "postgresql://postgres:postgres@127.0.0.1:59${{ matrix.pgver }}/postgres"
+          Start-Process -FilePath .\pg_timetable_Windows_x86_64\pg_timetable.exe -ArgumentList @('--clientname=runner', "postgresql://postgres:postgres@127.0.0.1:59${{ matrix.pgver }}/postgres") -RedirectStandardError .\pg_timetable_Windows_x86_64\pg_timetable.err -NoNewWindow
+          Start-Sleep -Seconds 3
+
       - name: Install Python dependencies on Linux and macOS
         if: ${{ matrix.os == 'macos-latest' || matrix.os == 'ubuntu-22.04' }}
         run: make install-python-testing
@@ -318,16 +379,29 @@ jobs:
           python web\regression\runtests.py --exclude feature_tests
         shell: cmd
 
+      - name: Stop pg_timetable on Linux and macOS
+        if: always() && (matrix.os == 'macos-latest' || matrix.os == 'ubuntu-22.04')
+        run: |
+          if [ -f /tmp/pg_timetable.pid ]; then
+            kill $(cat /tmp/pg_timetable.pid) 2>/dev/null || true
+          fi
+
+      - name: Stop pg_timetable on Windows
+        if: always() && matrix.os == 'windows-latest'
+        shell: pwsh
+        run: |
+          Get-Process -Name pg_timetable -ErrorAction SilentlyContinue | Stop-Process -Force
+
       - name: Archive server log
         if: success() || failure()
-        uses: actions/upload-artifact@v4
+        uses: actions/upload-artifact@v7
         with:
           name: server-log-${{ matrix.os }}-pg${{ matrix.pgver }}
           path: var/pgadmin4.log
 
       - name: Archive regression log
         if: success() || failure()
-        uses: actions/upload-artifact@v4
+        uses: actions/upload-artifact@v7
         with:
           name: regression-log-${{ matrix.os }}-pg${{ matrix.pgver }}
           path: web/regression/regression.log

.github/workflows/run-python-tests-server-mode.yml

@@ -0,0 +1,224 @@
+name: Run Python tests in server mode (data isolation)
+
+# This workflow runs the data-isolation tests with SERVER_MODE=True.
+# The main run-python-tests-pg.yml workflow runs everything with
+# SERVER_MODE=False, so any test that gates itself on `config.SERVER_MODE`
+# (notably web/pgadmin/browser/server_groups/tests/test_sg_data_isolation.py
+# and web/pgadmin/browser/server_groups/servers/tests/test_server_data_isolation.py)
+# skips itself in CI. That gap allowed the admin-bypass regression in
+# 9a76ed8 to ship; this workflow exists so regressions to the centralized
+# access-control helpers in web/pgadmin/utils/server_access.py are caught.
+#
+# Scope is intentionally narrow: one OS, one PG version, only the
+# data-isolation modules. Keep it cheap to run on every PR.
+
+on:
+  push:
+    branches: [ "master" ]
+    paths:
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'requirements.txt'
+      - 'Makefile'
+      - 'tools/setup-python-env.sh'
+      - '.github/workflows/run-python-tests-server-mode.yml'
+  pull_request:
+    branches: [ "master" ]
+    paths:
+      - 'web/**'
+      # Not the message catalogues: a .po change cannot break a build or a
+      # test, and check-translations already compiles them, which is the
+      # check that would catch a malformed one.
+      - '!web/pgadmin/translations/**'
+      - 'requirements.txt'
+      - 'Makefile'
+      - 'tools/setup-python-env.sh'
+      - '.github/workflows/run-python-tests-server-mode.yml'
+
+  workflow_dispatch:
+
+concurrency:
+  group: '${{ github.workflow }} @ ${{ github.event.pull_request.head.label || github.head_ref || github.ref }}'
+  cancel-in-progress: true
+
+jobs:
+  run-python-tests-server-mode:
+    runs-on: ubuntu-24.04
+
+    env:
+      PG_VER: 18
+
+    steps:
+      - uses: actions/checkout@v7
+        with:
+          # We don't run any authenticated git operations after checkout
+          # (no push, no submodule fetch, no comment back to the PR), so
+          # persisting the token in the local git config only widens the
+          # blast radius of an unrelated step compromise.
+          persist-credentials: false
+
+      - name: Update python version
+        uses: actions/setup-python@v7
+        with:
+          python-version: '3.10'
+
+      - name: Setup the PGDG APT repo
+        # apt-key is deprecated on Ubuntu 24.04+; install the key into
+        # /etc/apt/keyrings/ and reference it via signed-by= in the
+        # sources.list entry instead.
+        run: |
+          sudo install -d -m 0755 /etc/apt/keyrings
+          wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc \
+            | sudo gpg --dearmor -o /etc/apt/keyrings/pgdg.gpg
+          sudo sh -c 'echo "deb [signed-by=/etc/apt/keyrings/pgdg.gpg] https://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
+
+      - name: Uninstall PostgreSQL if already present
+        run: |
+          if [ -n "$(ls /etc/postgresql/*/*/postgresql.conf 2>/dev/null)" ]; then
+            installed_pg_version=$( pg_config --version | cut -d ' ' -f 2 | cut -d '.' -f 1 )
+            echo "Installed PostgreSQL version: $installed_pg_version"
+            if [ $installed_pg_version != ${PG_VER} ]; then
+              sudo pg_dropcluster $installed_pg_version main --stop
+              sudo apt-get -y remove "postgresql-${installed_pg_version}"
+            fi
+          fi
+
+      - name: Install platform dependencies
+        run: |
+          sudo apt update
+          sudo apt install -y libpq-dev libffi-dev libssl-dev libkrb5-dev zlib1g-dev postgresql-${PG_VER}
+
+      - name: Start PostgreSQL
+        run: |
+          sudo su -c "echo local all all trust > /etc/postgresql/${PG_VER}/main/pg_hba.conf"
+          sudo sed -i "s/port = 543[0-9]/port = 59${PG_VER}/g" /etc/postgresql/${PG_VER}/main/postgresql.conf
+          sudo su - postgres -c "/usr/lib/postgresql/${PG_VER}/bin/postgres -D /var/lib/postgresql/${PG_VER}/main -c config_file=/etc/postgresql/${PG_VER}/main/postgresql.conf &"
+
+          # Bounded readiness wait: 60 attempts × 2s = 120s cap. If PG
+          # never becomes ready, fail fast with logs rather than hanging
+          # until the job timeout.
+          for attempt in $(seq 1 60); do
+            if sudo runuser -l postgres -c "pg_isready -p 59${PG_VER}" 2>/dev/null; then
+              break
+            fi
+            >&2 echo "Postgres is unavailable (attempt ${attempt}/60) - sleeping for 2 seconds"
+            sleep 2
+            if [ "$attempt" -eq 60 ]; then
+              >&2 echo "Postgres failed to become ready within 120 seconds"
+              sudo tail -n 200 /var/log/postgresql/postgresql-${PG_VER}-main.log || true
+              exit 1
+            fi
+          done
+
+      - name: Install Python dependencies
+        run: make install-python-testing
+
+      - name: Create the test configuration (SERVER_MODE=True)
+        run: |
+          mkdir -p var
+          cat <<EOF > web/config_local.py
+          from config import *
+
+          # Debug mode
+          DEBUG = True
+
+          # App mode — this is the whole point of this workflow.
+          SERVER_MODE = True
+
+          # Log
+          CONSOLE_LOG_LEVEL = DEBUG
+          FILE_LOG_LEVEL = DEBUG
+
+          DEFAULT_SERVER = '127.0.0.1'
+
+          UPGRADE_CHECK_ENABLED = False
+
+          LOG_FILE = "$(pwd)/var/pgadmin4.log"
+          SESSION_DB_PATH = "$(pwd)/var/sessions"
+          STORAGE_DIR = "$(pwd)/var/storage"
+          SQLITE_PATH = "$(pwd)/var/pgadmin4.db"
+          TEST_SQLITE_PATH = "$(pwd)/var/pgadmin4.db"
+          AZURE_CREDENTIAL_CACHE_DIR = "$(pwd)/var/azurecredentialcache"
+          EOF
+
+          cat <<EOF > web/regression/test_config.json
+          {
+            "pgAdmin4_login_credentials": {
+              "new_password": "NEWPASSWORD",
+              "login_password": "PASSWORD",
+              "login_username": "USER@EXAMPLE.COM"
+            },
+            "pgAdmin4_test_user_credentials": {
+              "new_password": "NEWPASSWORD",
+              "login_password": "PASSWORD",
+              "login_username": "USER2@EXAMPLE.COM"
+            },
+            "pgAdmin4_test_non_admin_credentials": {
+              "new_password": "NEWPASSWORD",
+              "login_password": "PASSWORD",
+              "login_username": "USER3@EXAMPLE.COM"
+            },
+            "server_group": 1,
+            "server_credentials": [
+              {
+                "name": "PostgreSQL ${{ env.PG_VER }}",
+                "comment": "PostgreSQL ${{ env.PG_VER }} Server",
+                "db_username": "postgres",
+                "host": "/var/run/postgresql",
+                "db_password": "postgres",
+                "db_port": 59${{ env.PG_VER }},
+                "maintenance_db": "postgres",
+                "sslmode": "prefer",
+                "tablespace_path": "/var/lib/postgresql/tablespaces/${{ env.PG_VER }}",
+                "enabled": true,
+                "default_binary_paths": {
+                  "pg": "/usr/lib/postgresql/${{ env.PG_VER }}/bin",
+                  "ppas": ""
+                }
+              }
+            ],
+            "server_update_data": [
+              {
+                "comment": "This is test update comment"
+              }
+            ]
+          }
+          EOF
+
+      - name: Run server-group data isolation tests
+        run: |
+          . venv/bin/activate
+          python web/regression/runtests.py --pkg browser.server_groups.tests --modules test_sg_data_isolation
+
+      - name: Run server data isolation tests
+        run: |
+          . venv/bin/activate
+          python web/regression/runtests.py --pkg browser.server_groups.servers.tests --modules test_server_data_isolation
+
+      - name: Run SQL Editor unauth-pickle regression test
+        # Regression guard for the CSRF-only-no-auth chain on
+        # /sqleditor/close and /sqleditor/.../update_connection: both
+        # endpoints reach pickle.loads via close_sqleditor_session() /
+        # check_transaction_status(), so they must require an
+        # authenticated session. This test is a no-op in DESKTOP mode
+        # (auto-re-authentication) so it can only run here.
+        run: |
+          . venv/bin/activate
+          python web/regression/runtests.py --pkg tools.sqleditor --modules test_close_requires_auth
+
+      - name: Archive server log
+        if: success() || failure()
+        uses: actions/upload-artifact@v7
+        with:
+          name: server-log-server-mode
+          path: var/pgadmin4.log
+
+      - name: Archive regression log
+        if: success() || failure()
+        uses: actions/upload-artifact@v7
+        with:
+          name: regression-log-server-mode
+          path: web/regression/regression.log

.github/workflows/snapshot-macos.yml

@@ -0,0 +1,179 @@
+# Signed, notarised macOS snapshot builds, replacing the buildfarm's
+# pgadmin4-appbundle-snapshot job.
+#
+# Unlike check-macos-build.yml this produces something distributable: the
+# bundle is signed with the Developer ID, notarised by Apple and stapled, and a
+# ZIP is built alongside the DMG because the Electron auto-updater consumes the
+# ZIP whilst the DMG is the primary download.
+#
+# Uploading is deliberately not wired up yet. This proves the signed build
+# works; publishing comes after.
+#
+# Triggered by hand for now rather than nightly, so it cannot start signing
+# things before we mean it to.
+
+name: Snapshot - macOS
+
+on:
+  # Callable from snapshot.yml so that the orchestrator produces one
+  # complete tree. Signing stays here rather than moving to the
+  # servers like the GPG signing did, because the Apple and Certum
+  # credentials cannot follow it.
+  workflow_call:
+
+  workflow_dispatch:
+
+concurrency:
+  # Not cancel-in-progress, unlike the QA builds. Cancelling a signing build
+  # partway through wastes forty minutes of work and, worse, can abandon a
+  # notarisation already submitted to Apple, leaving a request sitting in their
+  # queue for a build nobody will collect. Queue instead.
+  # Spelled out rather than taken from github.workflow, which in a
+  # reusable workflow is the CALLER's name, so every workflow Snapshot
+  # calls would otherwise share one group.
+  group: 'snapshot-macos @ ${{ github.ref }}'
+  cancel-in-progress: false
+
+permissions:
+  contents: read
+
+jobs:
+  appbundle:
+    runs-on: ${{ matrix.runner }}
+
+    # The signing credentials live on an environment rather than loose on the
+    # repository, so only the workflows that should be signing can reach them.
+    environment: signing
+
+    strategy:
+      fail-fast: false
+      matrix:
+        include:
+          - { name: 'arm64', arch: 'arm64',  runner: 'macos-15' }
+          - { name: 'x64',   arch: 'x86_64', runner: 'macos-26-intel' }
+
+    timeout-minutes: 180
+
+    steps:
+      - uses: actions/checkout@v7
+
+      - uses: actions/setup-node@v7
+        with:
+          node-version: '20.x'
+
+      - name: Enable Corepack
+        run: corepack enable
+
+      - name: Install the build dependencies
+        run: brew install syft wget
+
+      - name: Install the PostgreSQL build dependencies
+        uses: ./.github/actions/install-pgbuild-deps
+        with:
+          arch: ${{ matrix.arch }}
+
+      # The buildfarm keeps the Developer ID in the worker's login keychain and
+      # unlocks it with devkeys/unlock-csc.sh. A hosted runner has no such
+      # keychain, so one is created for this job alone and destroyed after it,
+      # which is also why the password is generated rather than configured: it
+      # never outlives the job.
+      - name: Import the signing certificate
+        env:
+          MACOS_CERTIFICATE: ${{ secrets.MACOS_CERTIFICATE }}
+          MACOS_CERTIFICATE_PASSWORD: ${{ secrets.MACOS_CERTIFICATE_PASSWORD }}
+        run: |
+          KEYCHAIN="${RUNNER_TEMP}/build.keychain"
+          KEYCHAIN_PASSWORD=$(uuidgen)
+          echo "KEYCHAIN=${KEYCHAIN}" >> "${GITHUB_ENV}"
+
+          echo "${MACOS_CERTIFICATE}" | base64 --decode > "${RUNNER_TEMP}/cert.p12"
+
+          security create-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN}"
+          security set-keychain-settings -lut 21600 "${KEYCHAIN}"
+          security unlock-keychain -p "${KEYCHAIN_PASSWORD}" "${KEYCHAIN}"
+          security import "${RUNNER_TEMP}/cert.p12" \
+              -k "${KEYCHAIN}" \
+              -P "${MACOS_CERTIFICATE_PASSWORD}" \
+              -T /usr/bin/codesign
+          # Without this, codesign prompts for permission to use the key, which
+          # on a headless runner means hanging until the job times out.
+          security set-key-partition-list -S apple-tool:,apple:,codesign: \
+              -s -k "${KEYCHAIN_PASSWORD}" "${KEYCHAIN}" > /dev/null
+          security list-keychain -d user -s "${KEYCHAIN}" login.keychain
+
+          rm -f "${RUNNER_TEMP}/cert.p12"
+          echo "Identities available to codesign:"
+          security find-identity -v -p codesigning "${KEYCHAIN}"
+
+      # build.sh decides whether to sign and notarise purely by whether these
+      # files exist, which is what keeps the QA build credential-free.
+      - name: Write the signing configuration
+        env:
+          MACOS_DEVELOPER_ID: ${{ secrets.MACOS_DEVELOPER_ID }}
+          APPLE_ID: ${{ secrets.APPLE_ID }}
+          APPLE_APP_SPECIFIC_PASSWORD: ${{ secrets.APPLE_APP_SPECIFIC_PASSWORD }}
+          APPLE_TEAM_ID: ${{ secrets.APPLE_TEAM_ID }}
+        run: |
+          printf 'DEVELOPER_ID="%s"\n' "${MACOS_DEVELOPER_ID}" > pkg/mac/codesign.conf
+          {
+              printf 'DEVELOPER_USER=%s\n' "${APPLE_ID}"
+              printf 'DEVELOPER_ASP=%s\n' "${APPLE_APP_SPECIFIC_PASSWORD}"
+              printf 'DEVELOPER_TEAM_ID=%s\n' "${APPLE_TEAM_ID}"
+          } > pkg/mac/notarization.conf
+
+      # --zip as well as the DMG: the DMG is the download, the ZIP is what the
+      # Electron auto-updater fetches. The buildfarm's snapshot job does the
+      # same.
+      - name: Build the signed appbundle
+        run: |
+          export PGADMIN_POSTGRES_DIR=/opt/pgbuild/postgresql
+          export OPENSSL_DIR=/opt/pgbuild/openssl
+          export OPENSSL_STATIC=1
+
+          make appbundle BUILD_OPTS="--zip"
+
+      - name: Verify the signature and notarisation
+        run: |
+          APP="mac-build/pgAdmin 4.app"
+          echo "=== codesign ==="
+          codesign --verify --deep --strict --verbose=2 "${APP}"
+          codesign -dvvv "${APP}" 2>&1 | grep -E 'Authority|TeamIdentifier|Identifier='
+          echo "=== gatekeeper assessment ==="
+          spctl --assess --type execute --verbose=4 "${APP}"
+          echo "=== stapled notarisation ==="
+          # stapler looks the ticket up in Apple's CloudKit, and a dropped
+          # connection there fails the step with error 68, so it is retried.
+          # A genuinely broken ticket still fails all three attempts.
+          validate() {
+              for attempt in 1 2 3; do
+                  xcrun stapler validate "$1" && return 0
+                  [ "${attempt}" -lt 3 ] || return 1
+                  echo "stapler validate failed; retrying in $((attempt * 30))s"
+                  sleep $((attempt * 30))
+              done
+          }
+          validate "${APP}"
+          for F in dist/*.dmg; do
+              echo "--- ${F} ---"
+              validate "${F}"
+          done
+
+      - name: Archive the disk image and zip
+        uses: actions/upload-artifact@v7
+        with:
+          name: pgadmin4-macos-snapshot-${{ matrix.name }}
+          if-no-files-found: error
+          path: |
+            dist/*.dmg
+            dist/*.zip
+
+      # Runs even on failure: a keychain holding a Developer ID key must not
+      # outlive the job that created it, and the conf files carry the Apple
+      # credentials.
+      - name: Clean up the credentials
+        if: always()
+        run: |
+          rm -f pkg/mac/codesign.conf pkg/mac/notarization.conf
+          if [ -n "${KEYCHAIN:-}" ] && [ -f "${KEYCHAIN}" ]; then
+              security delete-keychain "${KEYCHAIN}"
+          fi

.github/workflows/snapshot-windows.yml

@@ -0,0 +1,180 @@
+# Signed Windows snapshot builds, replacing the buildfarm's
+# pgadmin4-windows-x64-snapshot job.
+#
+# This is the one workflow that cannot use a hosted runner. The certificate is
+# on a Certum hardware token plugged into a machine we host ourselves, reached
+# through the Windows machine certificate store, and a PIN handler answers the
+# prompt from the interactive desktop session. None of that can be moved to a
+# runner GitHub provides.
+#
+# Uploading is not wired up yet; this proves the signed build works.
+#
+# The runner must be running in the logged-in interactive session, not as a
+# Windows service. A service runs in session 0 with no desktop, so the PIN
+# prompt appears where the handler cannot see it and signing hangs rather than
+# failing.
+
+name: Snapshot - Windows
+
+on:
+  # Callable from snapshot.yml so that the orchestrator produces one
+  # complete tree. Signing stays here rather than moving to the
+  # servers like the GPG signing did, because the Apple and Certum
+  # credentials cannot follow it.
+  workflow_call:
+
+  workflow_dispatch:
+
+concurrency:
+  # Serialised deliberately, and not cancel-in-progress. There is one hardware
+  # token, and two builds signing through it at once is a good way to find out
+  # what proCertum does under contention. Jenkins may also be using it.
+  group: 'windows-signing'
+  cancel-in-progress: false
+
+permissions:
+  contents: read
+
+jobs:
+  installer:
+    runs-on: [self-hosted, windows-x64]
+    timeout-minutes: 120
+
+    environment: signing
+
+    env:
+      POSTGRES_MAJOR: '18'
+
+    steps:
+      - uses: actions/checkout@v7
+
+      - uses: actions/setup-node@v7
+        with:
+          node-version: '20.x'
+
+      - name: Enable Corepack
+        run: corepack enable
+
+      # No Python step, and none needed. actions/setup-python hangs on this
+      # runner: it installs Python rather than unpacking it, and anything
+      # raising a UAC prompt in the auto-logged-in session waits forever with
+      # nobody to answer it, exactly as the card's PIN dialog would. The first
+      # attempt sat on that step for thirty minutes against eleven seconds for
+      # setup-node. Using whatever Python is on PATH avoids the hang and is
+      # worse: this machine has 3.14 installed whilst the released installers
+      # carry 3.13, so it would have quietly shipped a different interpreter
+      # from the one the macOS build ships.
+      #
+      # Make.bat now downloads the version named in pkg/python-version.txt
+      # itself, as a plain tarball with no installer and so no prompt, which
+      # settles both problems and means this host needs no Python at all.
+
+      # Unlike the hosted build, nothing is installed here. This machine is
+      # configured by hand rather than by Ansible, it is the only one in the
+      # pipeline that cannot simply be rebuilt, and a CI job has no business
+      # mutating it. So check, and stop with something useful to act on rather
+      # than failing halfway through a build.
+      - name: Verify the build prerequisites
+        shell: powershell
+        run: |
+          $missing = @()
+          if (-not (Test-Path "C:\Program Files (x86)\Inno Setup 6\ISCC.exe")) { $missing += "innosetup" }
+          foreach ($tool in @('syft', 'wget')) {
+              if (-not (Get-Command $tool -ErrorAction SilentlyContinue)) { $missing += $tool }
+          }
+          if ($missing.Count) {
+              throw ("Missing build prerequisites on this runner: $($missing -join ', '). " +
+                     "Install with: choco install $($missing -join ' ') -y")
+          }
+          Write-Output "All prerequisites present."
+
+      - name: Install the PostgreSQL and Kerberos dependencies
+        id: deps
+        uses: ./.github/actions/install-pgbuild-deps
+        with:
+          arch: x86_64
+          postgres-major: ${{ env.POSTGRES_MAJOR }}
+
+      - name: Record the dependency location
+        shell: powershell
+        run: '"DEPS_DIR=${{ steps.deps.outputs.prefix }}" | Out-File -FilePath $env:GITHUB_ENV -Encoding utf8 -Append'
+
+      # Discovered rather than hardcoded. The buildfarm pins these to specific
+      # paths in its Jenkins node configuration, which needs editing every time
+      # Visual Studio or the Windows SDK updates, and that configuration is
+      # going away with the buildfarm.
+      - name: Locate the toolchain
+        shell: powershell
+        run: |
+          $vswhere = "${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer\vswhere.exe"
+          $vs = & $vswhere -latest -products * -property installationPath
+          if (-not $vs) { throw "Could not locate a Visual Studio installation" }
+
+          $redist = Get-ChildItem "$vs\VC\Redist\MSVC" -Directory |
+              Where-Object { Test-Path "$($_.FullName)\vc_redist.x64.exe" } |
+              Sort-Object Name -Descending | Select-Object -First 1
+          if (-not $redist) { throw "Could not locate vc_redist.x64.exe under $vs" }
+
+          # signtool lives under the SDK's versioned bin directory, and also in
+          # the App Certification Kit, which is where the buildfarm points at.
+          # Take the newest SDK copy, falling back to the ACK one.
+          $signtool = Get-ChildItem "${env:ProgramFiles(x86)}\Windows Kits\10\bin" `
+                  -Filter signtool.exe -Recurse -ErrorAction SilentlyContinue |
+              Where-Object { $_.FullName -match '\\x64\\' } |
+              Sort-Object FullName -Descending | Select-Object -First 1
+          if (-not $signtool) {
+              $ack = "${env:ProgramFiles(x86)}\Windows Kits\10\App Certification Kit\signtool.exe"
+              if (Test-Path $ack) { $signtool = Get-Item $ack }
+          }
+          if (-not $signtool) { throw "Could not locate signtool.exe" }
+
+          Write-Output "Visual Studio:   $vs"
+          Write-Output "VC++ redist:     $($redist.FullName)"
+          Write-Output "signtool:        $($signtool.DirectoryName)"
+
+          "VS_INSTALL_DIR=$vs"                        | Out-File -FilePath $env:GITHUB_ENV -Encoding utf8 -Append
+          "PGADMIN_VCREDIST_DIR=$($redist.FullName)"  | Out-File -FilePath $env:GITHUB_ENV -Encoding utf8 -Append
+          "PGADMIN_SIGNTOOL_DIR=$($signtool.DirectoryName)" | Out-File -FilePath $env:GITHUB_ENV -Encoding utf8 -Append
+
+      # Setting PGADMIN_WINDOWS_CSC is what makes Make.bat sign: it selects the
+      # certificate by subject name from the machine store, where proCertum
+      # installed it. Kept in a repository variable rather than the tree, so a
+      # certificate renewal is a settings change rather than a commit.
+      - name: Build the signed installer
+        shell: cmd
+        env:
+          PGADMIN_WINDOWS_CSC: ${{ vars.PGADMIN_WINDOWS_CSC }}
+        run: |
+          IF "%PGADMIN_WINDOWS_CSC%" == "" (
+              ECHO ERROR: the PGADMIN_WINDOWS_CSC repository variable is not set,
+              ECHO        so Make.bat would silently produce an unsigned build.
+              EXIT /b 1
+          )
+
+          SET "PGADMIN_POSTGRES_DIR=%DEPS_DIR%\postgresql"
+          SET "PGADMIN_KRB5_DIR=%DEPS_DIR%\krb5"
+          SET "PGADMIN_INNOTOOL_DIR=C:\Program Files (x86)\Inno Setup 6"
+
+          CALL "%VS_INSTALL_DIR%\VC\Auxiliary\Build\vcvars64.bat" || EXIT /b 1
+          CALL Make.bat || EXIT /b 1
+
+      # Make.bat now fails the build if either signature fails, the executable
+      # inside the installer included, so this is a second opinion rather than
+      # the only check. It verifies what is in dist/, which is the installer;
+      # the executable within it is covered by Make.bat refusing to continue.
+      - name: Verify the signatures
+        shell: powershell
+        run: |
+          $signtool = Join-Path $env:PGADMIN_SIGNTOOL_DIR 'signtool.exe'
+          Get-ChildItem dist\*.exe | ForEach-Object {
+              Write-Output "--- $($_.Name) ---"
+              & $signtool verify /pa /v $_.FullName
+              if ($LASTEXITCODE -ne 0) { throw "Signature verification failed for $($_.Name)" }
+          }
+
+      - name: Archive the installer
+        uses: actions/upload-artifact@v7
+        with:
+          name: pgadmin4-windows-snapshot
+          if-no-files-found: error
+          path: dist/*.exe

.github/workflows/snapshot.yml

@@ -0,0 +1,465 @@
+# Nightly snapshot builds, replacing the buildfarm's pgadmin4-all-snapshot job
+# and the dozen per-artefact snapshot jobs it drives.
+#
+# Nothing here is a second definition of a build. Every artefact comes from the
+# same workflow that runs on each push, called rather than copied, so a
+# snapshot cannot quietly diverge from what QA tested. That was not true of the
+# buildfarm, where pgadmin4-deb-build and pgadmin4-deb-snapshot were separate
+# job definitions carrying the same commands.
+#
+# Nothing here signs anything either, beyond the macOS notarisation and the
+# Windows Authenticode signature, which have to happen where their credentials
+# are. The GPG key that signs the RPMs and the repository metadata stays on the
+# servers: this workflow assembles the tree and uploads it, and asks the
+# staging server to
+# index and sign, so a compromised workflow run can ask for a signature but
+# never holds the means to make one.
+
+name: Snapshot
+
+on:
+  workflow_dispatch:
+    inputs:
+      location:
+        description: >-
+          Snapshot directory name, normally today's date. The buildfarm
+          writes <date> on the same server, so a test run wants a -N
+          suffix, for example 2026-09-17-2.
+        required: false
+        default: ''
+      publish:
+        description: Upload to the download server when the build succeeds
+        type: boolean
+        required: false
+        default: false
+
+  # Nightly, matching the buildfarm's pgadmin4-all-snapshot, which ran at
+  # 01:01. GitHub's scheduler is best-effort and runs late under load, which
+  # does not matter for a snapshot: the directory is named for the date the
+  # run assembles it, not for the minute it started.
+  schedule:
+    - cron: '1 1 * * *'
+
+concurrency:
+  # One snapshot at a time, and never cancelled: a cancelled run can abandon a
+  # notarisation already submitted to Apple, and leaves the signing token in an
+  # unknown state.
+  group: 'snapshot'
+  cancel-in-progress: false
+
+permissions:
+  contents: read
+
+jobs:
+  # The directory name, decided once. Two jobs need it and they must agree:
+  # the repo RPMs carry the snapshot's own URL inside them, so if that job and
+  # the assemble job each called date(1) a run straddling midnight would ship a
+  # repository configuration pointing at a snapshot that does not exist.
+  #
+  # It is also where a scheduled run on a fork stops. A fork with Actions
+  # enabled inherits the schedule but none of the signing secrets or
+  # self-hosted runners, so the macOS jobs would fail at the certificate and
+  # the Windows job would queue for a day. Every other job waits on this one,
+  # so skipping it skips the run. A dispatch still runs anywhere.
+  location:
+    if: >-
+      github.event_name != 'schedule'
+      || github.repository == 'pgadmin-org/pgadmin4'
+    runs-on: ubuntu-24.04
+    outputs:
+      name: ${{ steps.pick.outputs.name }}
+      # Whether a location was asked for by name, which decides both what the
+      # published directory is called and whether retention runs. It travels
+      # as a flag so that the steps downstream never need the raw input to
+      # work out what was requested: this job is where that input is checked,
+      # and a value that has not been through the check below has no business
+      # reaching the machine holding the publishing keys.
+      named: ${{ steps.pick.outputs.named }}
+    steps:
+      - id: pick
+        env:
+          REQUESTED: ${{ inputs.location }}
+        run: |
+          set -euo pipefail
+          NAME="${REQUESTED:-}"
+          if [ -n "${NAME}" ]; then NAMED=yes; else NAMED=no; fi
+          [ -n "${NAME}" ] || NAME=$(date +%Y-%m-%d)
+
+          # Validated here so that everything downstream, including a shell on
+          # the machine holding the publishing keys, is working with a name
+          # that cannot be anything but a date and an optional suffix. The
+          # wrapper on the server applies its own rule to the same value; this
+          # one exists so a bad input fails in five seconds rather than after
+          # an hour of building.
+          if ! printf '%s' "${NAME}" | grep -Eq '^[0-9]{4}-[0-9]{2}-[0-9]{2}(-[1-9][0-9]?)?$'; then
+              echo "Not a valid snapshot location: ${NAME}" >&2
+              echo "Expected YYYY-MM-DD, optionally with a -N suffix." >&2
+              exit 1
+          fi
+
+          echo "Snapshot location: ${NAME}"
+          echo "name=${NAME}" >> "${GITHUB_OUTPUT}"
+          echo "named=${NAMED}" >> "${GITHUB_OUTPUT}"
+
+  deb:
+    needs: location
+    uses: ./.github/workflows/check-deb-build.yml
+  rpm:
+    needs: location
+    uses: ./.github/workflows/check-rpm-build.yml
+  tarball:
+    needs: location
+    uses: ./.github/workflows/check-tarball-build.yml
+  wheel:
+    needs: location
+    uses: ./.github/workflows/check-python-build.yml
+  docs:
+    needs: location
+    uses: ./.github/workflows/check-doc-builds.yml
+  # No helm job here. The chart is not part of the download tree: the
+  # buildfarm pushed it to an OCI registry, which nothing in this workflow
+  # does yet. Calling the build and then discarding its artefact, which is what
+  # happened before, cost a runner and proved nothing that check-helm-build
+  # does not already prove on every push.
+
+  # The repository configuration RPMs. These are not built by the QA
+  # workflows, because they are not a build of pgAdmin: they are a one-file
+  # package carrying a .repo pointing at the tree they ship in, which is why
+  # the URL has to be known before they are built.
+  repo-rpm:
+    needs: location
+    runs-on: ubuntu-24.04
+    container: almalinux:9
+    steps:
+      - name: Install the build environment
+        run: dnf install -y --setopt=install_weak_deps=False rpm-build python3 git
+
+      - uses: actions/checkout@v7
+
+      - name: Mark the workspace as a safe git directory
+        run: git config --global --add safe.directory "${GITHUB_WORKSPACE}"
+
+      - name: Build the repository RPMs
+        env:
+          LOCATION: ${{ needs.location.outputs.name }}
+        run: |
+          # Through the environment rather than interpolated into the script.
+          # The location is a dispatch input, so it is text somebody chose, and
+          # workflow expression substitution happens before the shell ever sees the
+          # line, so a crafted location would otherwise become shell text.
+          export PGADMIN_REPO_DIR="https://ftp.postgresql.org/pub/pgadmin/pgadmin4/snapshots/${LOCATION}/yum"
+          echo "Repositories will point at ${PGADMIN_REPO_DIR}"
+          pkg/redhat/repo-rpm.sh
+
+      - name: Archive the repository RPMs
+        uses: actions/upload-artifact@v7
+        with:
+          name: pgadmin4-repo-rpm-build-output
+          if-no-files-found: error
+          path: dist/*.noarch.rpm
+
+  macos:
+    needs: location
+    uses: ./.github/workflows/snapshot-macos.yml
+    secrets: inherit
+
+  windows:
+    needs: location
+    uses: ./.github/workflows/snapshot-windows.yml
+    secrets: inherit
+
+  assemble:
+    needs: [location, deb, rpm, tarball, wheel, docs, repo-rpm, macos, windows]
+
+    # the runner, not a hosted runner. This job assembles a tree of several
+    # hundred megabytes and then, when publishing, sends it to the download
+    # server; splitting the two meant uploading that tree as an artifact and
+    # immediately downloading it again on the runner, having first queued for a
+    # hosted runner behind whatever else the organisation was building.
+    runs-on: [self-hosted, publish]
+
+    # For the variables naming the keys and the target, which live here. The
+    # environment carries no protection rules, so a run that is not publishing
+    # is not gated by it.
+    environment: publishing
+
+    # Everything must have built except Windows. That is the one runner which
+    # can legitimately be offline, and a snapshot without the installer is
+    # still worth having; a snapshot missing its documentation, source tarball,
+    # wheel or repository RPMs is not, and the repository RPMs are worse than
+    # missing, since install-repo-readme.py then fails after the packages have
+    # been uploaded and signed, leaving half a snapshot on the download server.
+    if: >-
+      always()
+      && needs.location.result == 'success'
+      && needs.deb.result == 'success'
+      && needs.rpm.result == 'success'
+      && needs.tarball.result == 'success'
+      && needs.wheel.result == 'success'
+      && needs.docs.result == 'success'
+      && needs.repo-rpm.result == 'success'
+      && needs.macos.result == 'success'
+
+    steps:
+      - uses: actions/checkout@v7
+
+      - name: Collect the build artefacts
+        uses: actions/download-artifact@v7
+        with:
+          path: artefacts
+
+      # The layout is the one the publishing scripts and the download site
+      # expect, and is what the wrapper's stage-create verb creates on the
+      # staging server.
+      # The Debian architecture comes from the package filename rather than a
+      # table, since dpkg already encodes it there; the codename does not, so
+      # that mapping is explicit.
+      - name: Assemble the staging tree
+        env:
+          LOCATION: ${{ needs.location.outputs.name }}
+        run: |
+          set -euo pipefail
+          # Flat, beside apt/ and yum/, which is how both the staging server
+          # and the snapshots tree are laid out. The docs/macos/pip/source/
+          # windows subdivision belongs to a published release, and it is the
+          # promotion step that sorts files into it on the way there.
+          # Explicitly, rather than trusting the checkout to have cleaned it.
+          # This runs on a self-hosted runner whose workspace persists between
+          # jobs, and a previous run's tree left behind here is indistinguishable
+          # from this one's until something downstream has to choose between
+          # them.
+          rm -rf stage
+
+          STAGE="stage/${LOCATION}"
+          mkdir -p "${STAGE}/yum"
+
+          # An artefact can be legitimately absent: the Windows signing host is
+          # allowed to be offline, and a failed matrix leg is reported by its
+          # own job rather than by a confusing cp error here.
+          copy_into() {
+              DEST=$1; shift
+              for SRC in "$@"; do
+                  [ -e "${SRC}" ] || continue
+                  mkdir -p "${DEST}"
+                  cp "${SRC}" "${DEST}/"
+              done
+          }
+
+          codename_for() {
+              case "$1" in
+                  debian-12)   echo bookworm ;;
+                  debian-13)   echo trixie ;;
+                  ubuntu-2204) echo jammy ;;
+                  ubuntu-2404) echo noble ;;
+                  ubuntu-2604) echo resolute ;;
+                  *) echo "Unknown Debian build name: $1" >&2; exit 1 ;;
+              esac
+          }
+
+          for DIR in artefacts/pgadmin4-deb-build-output-*; do
+              [ -d "${DIR}" ] || continue
+              CODENAME=$(codename_for "${DIR##*-output-}")
+              for DEB in "${DIR}"/*.deb; do
+                  ARCH=$(basename "${DEB}" .deb); ARCH=${ARCH##*_}
+                  TARGET="${STAGE}/apt/${CODENAME}/dists/pgadmin4/main/binary-${ARCH}"
+                  mkdir -p "${TARGET}"
+                  cp "${DEB}" "${TARGET}/"
+              done
+          done
+
+          # RPM trees are named for the distribution, which the build name
+          # already carries: el-9 becomes redhat/rhel-9-x86_64.
+          for DIR in artefacts/pgadmin4-rpm-build-output-*; do
+              [ -d "${DIR}" ] || continue
+              NAME=${DIR##*-output-}
+              case "${NAME}" in
+                  el-*)     FAMILY=redhat; TREE="rhel-${NAME#el-}" ;;
+                  fedora-*) FAMILY=fedora; TREE="${NAME}" ;;
+                  *) echo "Unknown RPM build name: ${NAME}" >&2; exit 1 ;;
+              esac
+              # Every RPM for a distribution goes in that distribution's
+              # tree, including the noarch ones. Taking the directory from the
+              # package's own architecture would file pgadmin4 and
+              # pgadmin4-web, both noarch, under rhel-9-noarch, where no
+              # client looks: dnf asks for <name>-<version>-$basearch. The
+              # RPM matrix is x86_64 only for now, so this is a constant; when
+              # aarch64 arrives it becomes a property of the build.
+              TARGET="${STAGE}/yum/${FAMILY}/${TREE}-x86_64"
+              mkdir -p "${TARGET}"
+              cp "${DIR}"/*.rpm "${TARGET}/"
+          done
+
+          copy_into "${STAGE}" artefacts/pgadmin4-tarball-build-output/*
+          copy_into "${STAGE}" artefacts/pgadmin4-python-build-output/*
+          # The version is read once here and used for the documentation
+          # filenames, which the build leaves unversioned as pgadmin4.pdf and
+          # pgAdmin4.epub whilst the download site has always carried
+          # pgadmin4-<version>.pdf and .epub.
+          VERSION=$(python3 -c "import sys; sys.path.insert(0, 'web'); import version; print(version.APP_VERSION)")
+
+          for SRC in artefacts/pgadmin4-pdf-build-output/*.pdf; do
+              [ -e "${SRC}" ] && cp "${SRC}" "${STAGE}/pgadmin4-${VERSION}.pdf"
+          done
+          for SRC in artefacts/pgadmin4-epub-build-output/*.epub; do
+              [ -e "${SRC}" ] && cp "${SRC}" "${STAGE}/pgadmin4-${VERSION}.epub"
+          done
+
+          # The docs tarball is what load-docs.sh unpacks on the web server, so
+          # it ships as a tarball rather than as the directory of files the
+          # build produces.
+          if [ -d artefacts/pgadmin4-html-build-output ]; then
+              # Under a pgadmin4-<version>-docs/ directory, not flat. The
+              # web server's load-docs.sh unpacks this into the docs root
+              # and then hands docloader that directory name, so a flat
+              # archive would scatter several hundred files across the root
+              # and then fail on a directory that does not exist. Every
+              # released tarball has carried that top level; the tar here
+              # had not.
+              DOCS_DIR="pgadmin4-${VERSION}-docs"
+              rm -rf "artefacts/${DOCS_DIR}"
+              mv artefacts/pgadmin4-html-build-output "artefacts/${DOCS_DIR}"
+              tar -czf "${STAGE}/pgadmin4-${VERSION}-docs.tar.gz" \
+                  -C artefacts "${DOCS_DIR}"
+          fi
+
+          # At the root of yum/, beside the family directories, which is
+          # where the README instructions tell people to fetch them from.
+          copy_into "${STAGE}/yum" artefacts/pgadmin4-repo-rpm-build-output/*
+
+          copy_into "${STAGE}" artefacts/pgadmin4-macos-snapshot-*/*
+          copy_into "${STAGE}" artefacts/pgadmin4-windows-snapshot/*
+
+          find "${STAGE}" -type f | sort
+
+      - name: Check the keys are present
+        # A scheduled run always publishes, that being the entire point of the
+        # nightly; the input exists so that a dispatched test run does not.
+        # It has to be spelled out because a schedule event carries no inputs
+        # at all, so `inputs.publish` is null rather than false, and the two
+        # publishing steps were quietly skipped on every nightly.
+        if: ${{ github.event_name == 'schedule' || inputs.publish }}
+        env:
+          DOWNLOAD: ${{ vars.DOWNLOAD_SSH_TARGET }}
+          PUBLISH_KEY: ${{ vars.PUBLISH_SSH_KEY || '~/.ssh/pga-publish' }}
+          UPLOAD_KEY: ${{ vars.UPLOAD_SSH_KEY || '~/.ssh/pga-upload' }}
+        run: |
+          set -euo pipefail
+          for TOOL in ssh rsync; do
+              command -v "${TOOL}" >/dev/null || {
+                  echo "This runner has no ${TOOL}." >&2; exit 1; }
+          done
+
+          # These three variables reach option positions. The target is the
+          # first positional argument to ssh, and the key paths are spliced
+          # into the -e string that rsync splits on whitespace before exec'ing
+          # it, so a value beginning with a hyphen, or one carrying a space,
+          # would be read as an option or as a second word rather than as the
+          # host or the path it is meant to be. Only an administrator can set
+          # a repository variable, which makes this defence in depth rather
+          # than a live hole, but it is checked here, once, rather than at
+          # each point of use; the -- in the publish step below closes the
+          # same gap from the other end.
+          TARGET_RE='^[A-Za-z0-9][A-Za-z0-9._-]*(@[A-Za-z0-9][A-Za-z0-9.-]*)?$'
+          printf '%s' "${DOWNLOAD}" | grep -Eq "${TARGET_RE}" || {
+              echo "DOWNLOAD_SSH_TARGET is not a [user@]host." >&2; exit 1; }
+
+          for KEY in "${PUBLISH_KEY/#\~/$HOME}" "${UPLOAD_KEY/#\~/$HOME}"; do
+              printf '%s' "${KEY}" | grep -Eq '^/[A-Za-z0-9._/-]+$' || {
+                  echo "Not a plain absolute path: ${KEY}" >&2; exit 1; }
+              if [ ! -r "${KEY}" ]; then
+                  echo "Missing or unreadable SSH key: ${KEY}" >&2
+                  exit 1
+              fi
+              # A public key is readable too, and pointing -i at one fails
+              # later inside ssh with a message that does not mention which
+              # file was wrong. Both halves of a pair sit in the same
+              # directory with names one suffix apart, so this is an easy
+              # thing to configure wrongly and a cheap thing to catch.
+              if head -c 4 "${KEY}" | grep -q '^ssh-'; then
+                  echo "${KEY} is a public key; -i needs the private one." >&2
+                  echo "Drop the .pub suffix from the variable that names it." >&2
+                  exit 1
+              fi
+          done
+          if [ ! -r ~/.ssh/known_hosts ]; then
+              echo "This runner has no ~/.ssh/known_hosts, so host key" >&2
+              echo "checking would fail. Add the servers' host keys." >&2
+              exit 1
+          fi
+
+      - name: Publish the snapshot
+        if: ${{ github.event_name == 'schedule' || inputs.publish }}
+        env:
+          DOWNLOAD: ${{ vars.DOWNLOAD_SSH_TARGET }}
+          # From the location job rather than from inputs.location, so the
+          # name reaching the publishing key is the one that job checked the
+          # shape of. The two agree today, which is exactly why it is worth
+          # fixing: the validation sat upstream of this step by coincidence
+          # rather than by construction.
+          LOCATION: ${{ needs.location.outputs.name }}
+          NAMED: ${{ needs.location.outputs.named }}
+          PUBLISH_KEY: ${{ vars.PUBLISH_SSH_KEY || '~/.ssh/pga-publish' }}
+          UPLOAD_KEY: ${{ vars.UPLOAD_SSH_KEY || '~/.ssh/pga-upload' }}
+        run: |
+          set -euo pipefail
+          if [ -z "${DOWNLOAD}" ]; then
+              echo "The DOWNLOAD_SSH_TARGET variable is not set." >&2
+              exit 1
+          fi
+
+          # One directory came out of assemble, named for the date. An explicit
+          # location overrides it so that a test run does not land on the
+          # snapshot the buildfarm is still writing on the same server.
+          # assemble produces exactly one directory, named for the date.
+          # Anything else means the artefact is not what this step thinks it
+          # is, and guessing which one to publish is not a decision to make at
+          # three in the morning.
+          if [ "$(find stage -mindepth 1 -maxdepth 1 -type d | wc -l)" != "1" ]; then
+              echo "Expected one directory in the snapshot artefact:" >&2
+              ls -l stage >&2
+              exit 1
+          fi
+          BUILT=$(basename "$(find stage -mindepth 1 -maxdepth 1 -type d)")
+          # An empty input still means "whatever assemble called it", which is
+          # why this turns on the flag rather than on the name being empty:
+          # the location job fills a blank input in with today's date, so the
+          # name itself no longer says whether anybody asked for one.
+          if [ "${NAMED}" = "yes" ]; then
+              DEST=${LOCATION}
+          else
+              DEST=${BUILT}
+          fi
+          echo "Publishing ${BUILT} as ${DEST}"
+
+          publish() {
+              ssh -i "${PUBLISH_KEY/#\~/$HOME}" -o BatchMode=yes \
+                  -o StrictHostKeyChecking=yes -- "${DOWNLOAD}" "$@"
+          }
+
+          publish snapshot-create "${DEST}"
+
+          # No --delete, deliberately: rrsync refuses it anyway, and a
+          # publishing step that can remove things is a publishing step that
+          # can remove the wrong things.
+          rsync -rlt --safe-links --no-specials --no-devices \
+              -e "ssh -i ${UPLOAD_KEY/#\~/$HOME} -o BatchMode=yes -o StrictHostKeyChecking=yes" \
+              "stage/${BUILT}/" "${DOWNLOAD}:${DEST}/"
+
+          # Signing before indexing: the metadata has to describe the signed
+          # packages rather than the unsigned ones just uploaded.
+          publish snapshot-sign "${DEST}"
+          publish snapshot-index-apt "${DEST}"
+          publish snapshot-index-yum "${DEST}"
+
+          # Retention, which the buildfarm did with ls | tail | xargs rm. The
+          # verb takes no argument: it cannot be asked to remove a particular
+          # snapshot, only to enforce the retention the server already has.
+          #
+          # Skipped when the directory was named by hand, because that is a
+          # test run, and a test run has no business deciding which of the
+          # real snapshots are old enough to delete.
+          if [ "${NAMED}" = "yes" ]; then
+              echo "Named location, so leaving retention alone."
+          else
+              publish snapshot-purge
+          fi

.github/workflows/sonarqube-scan.yml

@@ -1,58 +0,0 @@
-# This workflow requires the following configuration in Github
-#
-# Variables:
-#   SONARQUBE_PROJECT_KEY - The project key in SonarQube
-#
-# Secrets:
-#   SONARQUBE_TOKEN - SonarQube API token
-#   SONARQUBE_HOST - The URL of the SonarQube host
-
-name: SonarQube scan
-
-on:
-  push:
-    branches: [ "master" ]
-
-concurrency:
-  group: sonarqube
-  cancel-in-progress: false
-
-jobs:
-  run-sonarqube-scan:
-    # Only run if the project key is set
-    if: vars.SONARQUBE_PROJECT_KEY != null
-
-    runs-on: ubuntu-22.04
-
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-
-      - name: Create the scan properties file
-        run: |
-          cat <<EOF > sonar-project.properties
-          sonar.projectKey=${{ vars.SONARQUBE_PROJECT_KEY }}
-          sonar.projectName=pgAdmin 4
-          sonar.projectVersion=%VERSION%
-
-          # Ignore templates and SQL scripts as they confuse the scanner
-          sonar.exclusions=**/templates/**/*, **/*.sql
-          
-          # Let SonarQube know where tests can be found
-          sonar.test.inclusions=**/tests/**, web/regression
-          
-          # Python compatibility
-          sonar.python.version=3.7, 3.8, 3.9, 3.10, 3.11
-          EOF
-          
-          APP_RELEASE=`grep "^APP_RELEASE" web/config.py | cut -d"=" -f2 | sed 's/ //g'`
-          APP_REVISION=`grep "^APP_REVISION" web/config.py | cut -d"=" -f2 | sed 's/ //g'`
-          APP_LONG_VERSION=${APP_RELEASE}.${APP_REVISION}
-          sed -i "s/%VERSION%/${APP_LONG_VERSION}/g" sonar-project.properties
-
-      - name: SonarQube Scan
-        uses: sonarsource/sonarqube-scan-action@master
-        env:
-          SONAR_TOKEN: ${{ secrets.SONARQUBE_TOKEN }}
-          SONAR_HOST_URL: ${{ secrets.SONARQUBE_HOST }}

CONTRIBUTING.md

@@ -0,0 +1,341 @@
+# Contributing to pgAdmin 4
+
+Thank you for your interest in contributing to pgAdmin 4.
+
+## Contents
+
+- Getting Started
+- Reporting Issues
+- Making Changes
+- Pull Requests
+- AI-assisted Contributions
+- Development Setup
+- Database Migrations
+- Security Issues
+- Community and Support
+- License
+
+## Getting Started
+
+Before starting work, please review the project documentation and familiarize yourself with the architecture and development workflow.
+
+### Architecture
+
+pgAdmin 4 is written as a web application with Python (Flask) on the server side and ReactJS, HTML5 with CSS for the client side processing and UI.
+
+Although developed using web technologies, pgAdmin 4 can be deployed either on a web server using a browser, or standalone on a workstation. The [runtime/](runtime/) subdirectory contains an Electron-based runtime application intended to allow this, which will fork a Python server process and display the UI.
+
+For a fuller introduction to the codebase, see the [code overview](docs/en_US/code_overview.rst).
+
+If you are new to the codebase, consider starting with smaller bug fixes or documentation improvements before working on larger changes.
+
+The Sphinx documentation also includes contributor guidance for [coding standards](docs/en_US/coding_standards.rst), [submitting pull requests](docs/en_US/submitting_pull_requests.rst), [code review](docs/en_US/code_review.rst), and [translations](docs/en_US/translations.rst).
+
+## Reporting Issues
+
+When reporting a bug:
+
+- Search existing issues first.
+- If a similar issue exists, add any additional information or context you have. Do not create a duplicate issue.
+- Provide clear steps to reproduce the issue.
+- Include relevant environment and version information.
+- Attach screenshots, logs, or error messages when appropriate.
+
+For feature requests, describe the problem being solved and the expected behavior. 
+
+
+## Making Changes
+
+When working on a contribution:
+
+- Keep changes focused and easy to review.
+- Follow existing coding patterns and conventions, including the [coding standards](docs/en_US/coding_standards.rst).
+- Avoid unrelated refactoring and changes in the same commit.
+- Keep commit messages clear and descriptive.
+- Update tests or documentation when necessary.
+
+## Pull Requests
+
+Before opening a pull request:
+
+- Ensure your changes build successfully.
+- Test your changes locally.
+- Review your code before submission.
+- Update your branch with the latest changes from `master` upstream when appropriate.
+
+When opening a pull request:
+
+- Clearly describe the change.
+- Explain the reason for the change.
+- Include screenshots or recordings for UI-related changes when applicable.
+- Submit any changes as Pull Requests against the `master` branch of the [pgadmin-org/pgadmin4](https://github.com/pgadmin-org/pgadmin4) repository.
+
+Use a clear pull request title that describes the change. Short prefixes such as `feat:`, `fix:`, `docs:`, `test:`, `refactor:`, and `chore:` are useful when they match the change being made. Branch names are contributor-local and do not need to follow a project-specific naming convention.
+
+For more detail, see the [pull request submission guide](docs/en_US/submitting_pull_requests.rst) and [code review guide](docs/en_US/code_review.rst).
+
+## AI-assisted Contributions
+
+Contributors are responsible for understanding, testing, and standing behind everything they submit, whether or not AI tools were used. Please do not open large numbers of auto-generated issues or pull requests without first discussing that work with the maintainers.
+
+## Development Setup
+
+In the following documentation and examples, `$PGADMIN4_SRC` is used to denote the top-level directory of your copy of the pgAdmin source tree (either from a tarball or a git checkout).
+
+### Prerequisites
+
+1. Install Node.js 20 and above (https://nodejs.org/en/download)
+2. yarn (https://yarnpkg.com/getting-started/install)
+3. Python 3.9 and above (https://www.python.org/downloads/)
+4. PostgreSQL server (https://www.postgresql.org/download)
+
+Start by enabling Corepack, if it isn't already; this will add the yarn binary to your PATH:
+
+```bash
+corepack enable
+```
+
+### Building Web Assets
+
+pgAdmin is dependent on a number of third-party JavaScript libraries. These, along with its own JavaScript code, CSS code and images must be compiled into a "bundle" which is transferred to the browser for execution and rendering. This is far more efficient than simply requesting each asset as it is needed by the client.
+
+To create the bundle, you will need the 'yarn' package management tool to be installed. Then, you can run the following commands on a *nix system to download the required packages and build the bundle:
+
+```bash
+$ cd $PGADMIN4_SRC
+$ make install-node
+$ make bundle
+```
+
+On Windows systems (where "make" is not available), the following commands can be used:
+
+```bat
+C:\> cd $PGADMIN4_SRC\web
+C:\$PGADMIN4_SRC\web> yarn install
+C:\$PGADMIN4_SRC\web> yarn run bundle
+```
+
+### Python Environment
+
+In order to run the Python code, a suitable runtime environment is required. Python version 3.9 and later are currently supported. It is recommended that a Python virtual environment is set up for this purpose, rather than using the system Python environment. On Linux and Mac systems, the process is fairly simple - adapt as required for your distribution:
+
+1. Create a virtual environment in an appropriate directory. The last argument is the name of the environment; that can be changed as desired:
+
+   ```bash
+   $ python3 -m venv venv
+   ```
+
+2. Now activate the virtual environment:
+
+   ```bash
+   $ source venv/bin/activate
+   ```
+
+   On Windows:
+
+   ```bash
+   venv\Scripts\activate
+   ```
+
+3. Some of the components used by pgAdmin require a very recent version of *pip*, so update that to the latest:
+
+   ```bash
+   (venv) $ pip install --upgrade pip
+   ```
+
+4. Ensure that a PostgreSQL installation's bin/ directory is in the path (so pg_config can be found for building psycopg3), and install the required packages:
+
+   ```bash
+   (venv) $ PATH=$PATH:/usr/local/pgsql/bin pip install -r $PGADMIN4_SRC/requirements.txt
+   ```
+
+   If you are planning to run the regression tests, you also need to install additional requirements from `web/regression/requirements.txt`:
+
+   ```bash
+   (venv) $ pip install -r $PGADMIN4_SRC/web/regression/requirements.txt
+   ```
+
+### Configuration
+
+Create a local configuration file for pgAdmin. Edit `$PGADMIN4_SRC/web/config_local.py` and add any desired configuration options (use the `config.py` file as a reference - any settings duplicated in `config_local.py` will override those in `config.py`). A typical development configuration may look like:
+
+```python
+import os
+import logging
+
+# Change pgAdmin data directory
+DATA_DIR = '/Users/myuser/.pgadmin_dev'
+
+# Change pgAdmin server and port
+DEFAULT_SERVER = '127.0.0.1'
+DEFAULT_SERVER_PORT = 5051
+
+# Switch between server and desktop mode
+SERVER_MODE = True
+
+# Change pgAdmin config DB path in case an external DB is used.
+CONFIG_DATABASE_URI="postgresql://postgres:postgres@localhost:5436/pgadmin"
+
+# Set up SMTP
+MAIL_SERVER = 'smtp.gmail.com'
+MAIL_PORT = 465
+MAIL_USE_SSL = True
+MAIL_USERNAME = 'user@gmail.com'
+MAIL_PASSWORD = 'xxxxxxxxxx'
+
+# Change log level
+CONSOLE_LOG_LEVEL = logging.INFO
+FILE_LOG_LEVEL = logging.INFO
+
+# Use a different config DB for each server mode.
+if SERVER_MODE == False:
+  SQLITE_PATH = os.path.join(
+      DATA_DIR,
+      'pgadmin4-desktop.db'
+  )
+else:
+  SQLITE_PATH = os.path.join(
+      DATA_DIR,
+      'pgadmin4-server.db'
+  )
+```
+
+This configuration allows easy switching between server and desktop modes for testing.
+
+### Running pgAdmin
+
+The initial setup of the configuration database is interactive in server mode, and non-interactive in desktop mode. You can run it either by running:
+
+```bash
+(venv) $ python3 $PGADMIN4_SRC/web/setup.py
+```
+
+or by starting pgAdmin 4:
+
+```bash
+(venv) $ python3 $PGADMIN4_SRC/web/pgAdmin4.py
+```
+
+Whilst it is possible to automatically run setup in desktop mode by running the runtime, that will not work in server mode as the runtime doesn't allow command line interaction with the setup program.
+
+At this point you will be able to run pgAdmin 4 from the command line in either server or desktop mode, and access it from a web browser using the URL shown in the terminal once pgAdmin has started up.
+
+Setup of an environment on Windows is somewhat more complicated unfortunately, please see `pkg/win32/README.md` for complete details.
+
+### Building the documentation
+
+In order to build the docs, an additional Python package is required in the virtual environment. This can be installed with the pip package manager:
+
+```bash
+$ source venv/bin/activate
+(venv) $ pip install Sphinx
+(venv) $ pip install sphinxcontrib-youtube
+```
+
+The docs can then be built using the Makefile in `$PGADMIN4_SRC`, e.g.
+
+```bash
+(venv) $ make docs
+```
+
+The output can be found in `$PGADMIN4_SRC/docs/en_US/_build/html/index.html`
+
+### Runtime Development
+
+For Electron runtime development:
+
+1. Navigate to the `runtime` directory.
+2. Install dependencies:
+
+```bash
+yarn install
+```
+
+3. Copy:
+
+```text
+dev_config.json.in
+```
+
+to:
+
+```text
+dev_config.json
+```
+
+4. Update the paths to your Python executable and `pgAdmin4.py`.
+
+Start the runtime:
+
+```bash
+yarn run start
+```
+
+### Building packages
+
+Most packages can be built using the Makefile in `$PGADMIN4_SRC`, provided all the setup and configuration above has been completed.
+
+To build a source tarball:
+
+```bash
+(venv) $ make src
+```
+
+To build a PIP Wheel, activate either a Python 3 virtual environment, configured with all the required packages, and then run:
+
+```bash
+(venv) $ make pip
+```
+
+To build the macOS AppBundle, please see `pkg/mac/README.md`.
+
+To build the Windows installer, please see `pkg/win32/README.md`.
+
+## Database Migrations
+
+In order to make changes to the SQLite DB, navigate to the 'web' directory:
+
+```bash
+(venv) $ cd $PGADMIN4_SRC/web
+```
+
+Create a migration file with the following command:
+
+```bash
+(venv) $ FLASK_APP=pgAdmin4.py flask db revision
+```
+
+This will create a file in `$PGADMIN4_SRC/web/migrations/versions/`. Add any changes to the `upgrade` function.
+
+When making schema changes, update the `SCHEMA_VERSION` value in:
+
+```text
+web/pgadmin/model/__init__.py
+```
+
+There is no need to increment the `SETTINGS_SCHEMA_VERSION`.
+
+## Security Issues
+
+**Do not report security vulnerabilities through GitHub issues.**
+
+Potential security issues should be reported to: 
+`security@pgadmin.org`.
+
+Note that this **address should only be used for reporting security issues** that you believe you've found in the design or code of pgAdmin, pgAgent, and the pgAdmin website. It **should not be used to ask security questions**.
+
+If you are unsure whether an issue is a security vulnerability, please lean on the side of caution and report it to the above address. The pgAdmin team will review the report and respond as appropriate.
+
+## Community and Support
+
+For development discussions, use:
+
+`pgadmin-hackers@postgresql.org`
+
+For support options, visit the [pgAdmin support page](https://www.pgadmin.org/support/).
+
+Use the [GitHub issue tracker](https://github.com/pgadmin-org/pgadmin4/issues) for reporting bugs and requesting features, but please follow the guidelines outlined in the "Reporting Issues" section above.
+
+## License
+
+By contributing to pgAdmin 4, you agree that your contributions will be licensed under the project's existing and future license terms.

Dockerfile

@@ -42,9 +42,7 @@ RUN --mount=type=bind,source=.git,target=/pgadmin4/.git \
     export CPPFLAGS="-DPNG_ARM_NEON_OPT=0" && \
     npm install -g corepack && \
     corepack enable && \
-    yarn set version berry && \
-    yarn set version 4 && \
-    yarn install && \
+    yarn install --immutable && \
     yarn run bundle && \
     rm -rf yarn.lock \
            package.json \
@@ -61,8 +59,15 @@ RUN --mount=type=bind,source=.git,target=/pgadmin4/.git \
 FROM python:3-alpine AS env-builder
 
 # Install dependencies
+#
+# libpq is a runtime dependency of psycopg's C extension: psycopg[c] is built
+# from source against postgresql-dev, but that is removed with build-deps
+# below, so libpq.so.5 must be installed separately to survive. Without it,
+# importing psycopg (which the Sphinx docs build does, via config.py) fails
+# with "no pq wrapper available".
 RUN apk add --no-cache \
-        make && \
+        make \
+        libpq && \
     apk add --no-cache --virtual build-deps \
         build-base \
         openssl-dev \
@@ -79,6 +84,13 @@ RUN python3 -m venv --system-site-packages --without-pip /venv && \
     /venv/bin/python3 -m pip install --no-cache-dir -r requirements.txt && \
     apk del --no-cache build-deps
 
+# Remove the files pgAdmin never uses. The script reads the language list from
+# web/config.py, so it is copied in separately to avoid a change to it
+# reinstalling the requirements above.
+COPY pkg/prune_site_packages.py /prune/pkg/
+COPY web/config.py /prune/web/
+RUN /venv/bin/python3 /prune/pkg/prune_site_packages.py /venv
+
 #########################################################################
 # Now, create a documentation build container for the Sphinx docs
 #########################################################################
@@ -204,7 +216,10 @@ RUN /venv/bin/python3 -m pip install --no-cache-dir gunicorn==23.0.0 && \
     chown pgadmin:root /pgadmin4/config_distro.py && \
     chmod g=u /pgadmin4/config_distro.py && \
     chmod g=u /etc/passwd && \
-    setcap CAP_NET_BIND_SERVICE=+eip /usr/local/bin/python3.[0-9][0-9] && \
+    PYBIN="$(ls /usr/local/bin/python3.[0-9][0-9] 2>/dev/null | head -n1)" && \
+    cp "$PYBIN" /usr/local/bin/python3-cap && \
+    setcap CAP_NET_BIND_SERVICE=+eip /usr/local/bin/python3-cap && \
+    ln -s /usr/local/bin/python3-cap /venv/bin/python3-cap && \
     echo "pgadmin ALL = NOPASSWD: /usr/sbin/postfix start" > /etc/sudoers.d/postfix && \
     echo "pgadminr ALL = NOPASSWD: /usr/sbin/postfix start" >> /etc/sudoers.d/postfix
 

Make.bat

@@ -20,12 +20,18 @@ IF "%1" == "clean" (
 )
 
 REM Main build sequence
+REM
+REM The clean runs first because :FETCH_PYTHON unpacks into the temp directory
+REM that it removes, and the fetch runs before :SET_ENVIRONMENT because the
+REM latter has no interpreter of its own to ask about the build.
+CALL :CLEAN || EXIT /B 1
+CALL :FETCH_PYTHON || EXIT /B 1
 CALL :SET_ENVIRONMENT
 CALL :VALIDATE_ENVIRONMENT || EXIT /B 1
-CALL :CLEAN || EXIT /B 1
 CALL :CREATE_VIRTUAL_ENV || EXIT /B 1
 CALL :CREATE_PYTHON_ENV || EXIT /B 1
 CALL :CREATE_RUNTIME_ENV || EXIT /B 1
+CALL :SIGN_COMPONENTS || EXIT /B 1
 CALL :GENERATE_SBOM || EXIT /B 1
 CALL :CREATE_INSTALLER || EXIT /B 1
 CALL :VERIFY_SIGNATURE || EXIT /B 1
@@ -50,15 +56,78 @@ REM Main build sequence Ends
     EXIT /B 0
 
 
+:FETCH_PYTHON
+    REM Fetch the Python this build uses, rather than using whatever happens to
+    REM be installed on the machine running it. Which interpreter pgAdmin ships
+    REM is a decision recorded in pkg\python-version.txt, not a property of the
+    REM build agent, and this is the only place on Windows that reads it.
+    REM
+    REM The distribution comes from astral-sh/python-build-standalone: it is
+    REM relocatable, published per exact CPython version, and is a plain tarball
+    REM rather than an installer, so unpacking it raises no UAC prompt. That
+    REM matters on the signing host, where the desktop session is logged in
+    REM automatically and an elevation dialog waits forever for somebody who is
+    REM not there.
+    REM
+    REM curl.exe and tar.exe have shipped in Windows since 1803, so this needs
+    REM nothing installed to bootstrap itself, not even a Python.
+    ECHO Reading the Python version...
+    SET "PYTHON_VERSION="
+    SET "PYTHON_BUILD_STANDALONE_TAG="
+    FOR /F "eol=# usebackq tokens=1,2 delims==" %%a IN ("%WD%\pkg\python-version.txt") DO (
+        IF "%%a" == "PYTHON_VERSION" SET "PYTHON_VERSION=%%b"
+        IF "%%a" == "PYTHON_BUILD_STANDALONE_TAG" SET "PYTHON_BUILD_STANDALONE_TAG=%%b"
+    )
+
+    IF "%PYTHON_VERSION%" == "" (
+        ECHO PYTHON_VERSION is not set in pkg\python-version.txt.
+        EXIT /B 1
+    )
+    IF "%PYTHON_BUILD_STANDALONE_TAG%" == "" (
+        ECHO PYTHON_BUILD_STANDALONE_TAG is not set in pkg\python-version.txt.
+        EXIT /B 1
+    )
+
+    REM Split for the runtime build, where e.g. 3.13.15 becomes 313
+    FOR /F "tokens=1,2,3 delims=." %%a IN ("%PYTHON_VERSION%") DO (
+        SET "PYTHON_MAJOR=%%a"
+        SET "PYTHON_MINOR=%%b"
+        SET "PYTHON_REVISION=%%c"
+    )
+
+    SET "PGADMIN_PYTHON_DIR=%TMPDIR%\python"
+    SET "PYTHON_ARCHIVE=cpython-%PYTHON_VERSION%+%PYTHON_BUILD_STANDALONE_TAG%-x86_64-pc-windows-msvc-install_only.tar.gz"
+
+    IF NOT EXIST "%TMPDIR%"  MKDIR "%TMPDIR%"
+
+    ECHO Downloading Python %PYTHON_VERSION%...
+    curl.exe --fail --location --silent --show-error --output "%TMPDIR%\python.tar.gz" "https://github.com/astral-sh/python-build-standalone/releases/download/%PYTHON_BUILD_STANDALONE_TAG%/%PYTHON_ARCHIVE%" || EXIT /B 1
+
+    ECHO Unpacking Python...
+    REM The archive unpacks to a single python\ directory.
+    tar -x -f "%TMPDIR%\python.tar.gz" -C "%TMPDIR%" || EXIT /B 1
+    DEL /q "%TMPDIR%\python.tar.gz" > nul 2>&1
+
+    "%PGADMIN_PYTHON_DIR%\python.exe" --version || EXIT /B 1
+
+    REM :CREATE_VIRTUAL_ENV needs virtualenv rather than the venv module, as it
+    REM relocates the result. pip is bundled with the distribution, but ask
+    REM ensurepip for it anyway so this does not quietly depend on that.
+    ECHO Installing virtualenv...
+    "%PGADMIN_PYTHON_DIR%\python.exe" -m ensurepip --upgrade || EXIT /B 1
+    "%PGADMIN_PYTHON_DIR%\python.exe" -m pip install --upgrade pip virtualenv || EXIT /B 1
+
+    EXIT /B 0
+
+
 :SET_ENVIRONMENT
     ECHO Configuring the environment...
-    IF "%PGADMIN_PYTHON_DIR%" == ""   SET "PGADMIN_PYTHON_DIR=C:\Python313"
-    IF "%PGADMIN_KRB5_DIR%" == ""     SET "PGADMIN_KRB5_DIR=C:\Program Files\MIT\Kerberos"
-    IF "%PGADMIN_POSTGRES_DIR%" == "" SET "PGADMIN_POSTGRES_DIR=C:\Program Files\PostgreSQL\17"
+    IF "%PGADMIN_KRB5_DIR%" == ""     SET "PGADMIN_KRB5_DIR=C:\build64\krb5"
+    IF "%PGADMIN_POSTGRES_DIR%" == "" SET "PGADMIN_POSTGRES_DIR=C:\build64\postgresql"
     IF "%PGADMIN_INNOTOOL_DIR%" == "" SET "PGADMIN_INNOTOOL_DIR=C:\Program Files (x86)\Inno Setup 6"
     IF "%PGADMIN_VCREDIST_DIR%" == "" SET "PGADMIN_VCREDIST_DIR=C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Redist\MSVC\14.40.33807"
     IF "%PGADMIN_VCREDIST_FILE%" == "" SET "PGADMIN_VCREDIST_FILE=vc_redist.x64.exe"
-    IF "%PGADMIN_SIGNTOOL_DIR%" == "" SET "PGADMIN_SIGNTOOL_DIR=C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64"
+    IF "%PGADMIN_SIGNTOOL_DIR%" == "" SET "PGADMIN_SIGNTOOL_DIR=C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\x64"
     IF "%PGADMIN_WINDOWS_CSC%" == "" SET "PGADMIN_WINDOWS_CSC="
 
     REM Set additional variables we need
@@ -74,11 +143,6 @@ REM Main build sequence Ends
     SET INSTALLERNAME=%APP_SHORTNAME%-%APP_MAJOR%.%APP_MINOR%-%APP_VERSION_SUFFIX%-x64.exe
     IF "%APP_VERSION_SUFFIX%" == "" SET INSTALLERNAME=%APP_SHORTNAME%-%APP_MAJOR%.%APP_MINOR%-x64.exe
 
-    REM get Python version for the runtime build ex. 3.9.2 will be 39
-    FOR /f "tokens=1 DELims=." %%G IN ('%PGADMIN_PYTHON_DIR%/python.exe -c "import sys; print(sys.version.split(' ')[0])"') DO SET PYTHON_MAJOR=%%G
-    FOR /f "tokens=2 DELims=." %%G IN ('%PGADMIN_PYTHON_DIR%/python.exe -c "import sys; print(sys.version.split(' ')[0])"') DO SET PYTHON_MINOR=%%G
-    FOR /f "tokens=3 DELims=." %%G IN ('%PGADMIN_PYTHON_DIR%/python.exe -c "import sys; print(sys.version.split(' ')[0])"') DO SET PYTHON_REVISION=%%G
-
     EXIT /B 0
 
 
@@ -90,8 +154,8 @@ REM Main build sequence Ends
     ECHO Output directory:          %DISTROOT%
     ECHO Installer name:            %INSTALLERNAME%
     ECHO.
-    ECHO Python directory:          %PGADMIN_PYTHON_DIR%
     ECHO Python version:            %PYTHON_MAJOR%.%PYTHON_MINOR%.%PYTHON_REVISION%
+    ECHO Python directory:          %PGADMIN_PYTHON_DIR%
     ECHO.
     ECHO KRB5 directory:            %PGADMIN_KRB5_DIR%
     ECHO PostgreSQL directory:      %PGADMIN_POSTGRES_DIR%
@@ -113,41 +177,16 @@ REM Main build sequence Ends
     ECHO ****************************************************************
 
     ECHO Checking the environment...
-    IF NOT EXIST "%PGADMIN_INNOTOOL_DIR%" (
-        ECHO !PGADMIN_INNOTOOL_DIR! does not exist
-        ECHO Please install InnoTool and set the PGADMIN_INNOTOOL_DIR environment variable.
-        EXIT /B 1
-    )
-
-    IF NOT EXIST "%PGADMIN_VCREDIST_DIR%" (
-        ECHO !PGADMIN_VCREDIST_DIR! does not exist
-        ECHO Please install Microsoft Visual studio and set the PGADMIN_VCREDIST_DIR environment variable.
-        EXIT /B 1
-    )
-
-    IF NOT EXIST "%PGADMIN_KRB5_DIR%" (
-        ECHO !PGADMIN_KRB5_DIR! does not exist.
-        ECHO Please install MIT Kerberos for Windows and set the PGADMIN_KRB5_DIR environment variable.
-        EXIT /B 1
-    )
-
-    IF NOT EXIST "%PGADMIN_PYTHON_DIR%" (
-        ECHO !PGADMIN_PYTHON_DIR! does not exist.
-        ECHO Please install Python and set the PGADMIN_PYTHON_DIR environment variable.
-        EXIT /B 1
-    )
-
-    IF NOT EXIST "%PGADMIN_POSTGRES_DIR%" (
-        ECHO !PGADMIN_POSTGRES_DIR! does not exist.
-        ECHO Please install PostgreSQL and set the PGADMIN_POSTGRES_DIR environment variable.
-        EXIT /B 1
-    )
-
-    IF NOT EXIST "%PGADMIN_PYTHON_DIR%\Scripts\virtualenv.exe" (
-        ECHO !PGADMIN_PYTHON_DIR!\Scripts\virtualenv.exe does not exist.
-        ECHO Please install the virtualenv package in Python.
-        EXIT /B 1
-    )
+    REM The checks are made by :REQUIRE_DIR rather than inline, because the
+    REM message names the directory that was looked for, and a default such as
+    REM "C:\Program Files (x86)\Inno Setup 6" carries a closing parenthesis.
+    REM Inside a parenthesised block that parenthesis ends the block, as cmd
+    REM expands the variable when it parses the block rather than when it runs it,
+    REM so the block failed to parse whether or not the directory was there.
+    CALL :REQUIRE_DIR "%PGADMIN_INNOTOOL_DIR%" "Please install InnoTool and set the PGADMIN_INNOTOOL_DIR environment variable." || EXIT /B 1
+    CALL :REQUIRE_DIR "%PGADMIN_VCREDIST_DIR%" "Please install Microsoft Visual Studio and set the PGADMIN_VCREDIST_DIR environment variable." || EXIT /B 1
+    CALL :REQUIRE_DIR "%PGADMIN_KRB5_DIR%" "Please install MIT Kerberos for Windows, from the winpgbuild project or elsewhere, and set the PGADMIN_KRB5_DIR environment variable." || EXIT /B 1
+    CALL :REQUIRE_DIR "%PGADMIN_POSTGRES_DIR%" "Please install PostgreSQL, from the winpgbuild project or elsewhere, and set the PGADMIN_POSTGRES_DIR environment variable." || EXIT /B 1
 
     SET "PATH=%PGADMIN_POSTGRES_DIR%\bin;%PATH%"
 
@@ -161,10 +200,14 @@ REM Main build sequence Ends
     CD "%TMPDIR%"
 
     REM Note that we must use virtualenv.exe here, as the venv module doesn't allow python.exe to relocate.
-    "%PGADMIN_PYTHON_DIR%\Scripts\virtualenv.exe" venv
+    "%PGADMIN_PYTHON_DIR%\Scripts\virtualenv.exe" venv || EXIT /B 1
 
     XCOPY /S /I /E /H /Y "%PGADMIN_PYTHON_DIR%\DLLs" "%TMPDIR%\venv\DLLs" > nul || EXIT /B 1
-    XCOPY /S /I /E /H /Y "%PGADMIN_PYTHON_DIR%\Lib" "%TMPDIR%\venv\Lib" > nul || EXIT /B 1
+    REM Copy the standard library, but NOT site-packages: the venv already has its
+    REM own seeded pip there, and overwriting only the files the system Python also
+    REM has leaves a mix of two pip versions behind.
+    ROBOCOPY /E /R:3 /W:5 /NFL /NDL /NP "%PGADMIN_PYTHON_DIR%\Lib" "%TMPDIR%\venv\Lib" /XD site-packages
+    CALL :CHECK_ROBOCOPY_ERROR || EXIT /B 1
 
     ECHO Activating virtual environment -  %TMPDIR%\venv...
     CALL "%TMPDIR%\venv\Scripts\activate" || EXIT /B 1
@@ -181,24 +224,29 @@ REM Main build sequence Ends
     ECHO Staging Python...
     MKDIR "%BUILDROOT%\python\Lib" || EXIT /B 1
 
-    ECHO Downloading embedded Python...
-    REM Get the python embeddable and extract it to %BUILDROOT%\python
-    CD "%TMPDIR%
-    %PGADMIN_PYTHON_DIR%\python -c "import sys; from urllib.request import urlretrieve; urlretrieve('https://www.python.org/ftp/python/' + sys.version.split(' ')[0] + '/python-' + sys.version.split(' ')[0] + '-embed-amd64.zip', 'python-embedded.zip')" || EXIT /B 1
-    %PGADMIN_PYTHON_DIR%\python -c "import zipfile; z = zipfile.ZipFile('python-embedded.zip', 'r'); z.extractall('../win-build/python/')" || EXIT /B 1
+    ECHO Downloading embedded Python %PYTHON_VERSION%...
+    REM What ships is the embeddable distribution from python.org, a different
+    REM build from the one :FETCH_PYTHON downloaded, and it has to be the same
+    REM CPython version: the extension modules in site-packages were compiled
+    REM against the build Python and are about to be run under this one. Both
+    REM therefore read pkg\python-version.txt, rather than either asking the
+    REM other what it is.
+    curl.exe --fail --location --silent --show-error --output "%TMPDIR%\python-embedded.zip" "https://www.python.org/ftp/python/%PYTHON_VERSION%/python-%PYTHON_VERSION%-embed-amd64.zip" || EXIT /B 1
+    tar -x -f "%TMPDIR%\python-embedded.zip" -C "%BUILDROOT%\python" || EXIT /B 1
 
     ECHO Copying site-packages...
     XCOPY /S /I /E /H /Y "%TMPDIR%\venv\Lib\site-packages" "%BUILDROOT%\python\Lib\site-packages" > nul || EXIT /B 1
 
+    REM This is done to the copy rather than the venv, which still needs pip to
+    REM install Sphinx for the docs in :CREATE_RUNTIME_ENV.
+    ECHO Removing unused files from the installed packages...
+    "%TMPDIR%\venv\Scripts\python.exe" "%WD%\pkg\prune_site_packages.py" "%BUILDROOT%\python\Lib\site-packages" || EXIT /B 1
+
     REM NOTE: There is intentionally no space after "site" in the line below, to prevent Python barfing if there's one in the file
     ECHO import site>> "%BUILDROOT%\python\python%PYTHON_MAJOR%%PYTHON_MINOR%._pth"
 
-    ECHO Staging Kerberos components...
-    COPY "%PGADMIN_KRB5_DIR%\bin\kinit.exe" "%BUILDROOT%\python" > nul || EXIT /B 1
-    COPY "%PGADMIN_KRB5_DIR%\bin\krb5_64.dll" "%BUILDROOT%\python" > nul || EXIT /B 1
-    COPY "%PGADMIN_KRB5_DIR%\bin\comerr64.dll" "%BUILDROOT%\python" > nul || EXIT /B 1
-    COPY "%PGADMIN_KRB5_DIR%\bin\k5sprt64.dll" "%BUILDROOT%\python" > nul || EXIT /B 1
-    COPY "%PGADMIN_KRB5_DIR%\bin\gssapi64.dll" "%BUILDROOT%\python" > nul || EXIT /B 1
+    REM NOTE: The Kerberos components are staged into the runtime directory
+    REM alongside libpq.dll, not here. See :CREATE_RUNTIME_ENV.
 
     ECHO Cleaning up unnecessary .pyc and .pyo files...
     FOR /R "%BUILDROOT%\python" %%f in (*.pyc *.pyo) do DEL /q "%%f" 1> nul 2>&1
@@ -216,14 +264,19 @@ REM Main build sequence Ends
     RD /Q /S "%WD%\web\pgadmin\static\js\generated\.cache" 1> nul 2>&1
 
     ECHO Copying web directory...
-    ROBOCOPY /S "%WD%\web" "%BUILDROOT%\web" > nul
-    CALL :CHECK_ROBOCOPY_ERROR
+    ROBOCOPY /S /NFL /NDL /NP "%WD%\web" "%BUILDROOT%\web"
+    CALL :CHECK_ROBOCOPY_ERROR || EXIT /B 1
 
     ECHO Installing javascript dependencies...
     CD "%BUILDROOT%\web"
-    CALL yarn set version berry || EXIT /B 1
-    CALL yarn set version 4 || EXIT /B 1
-    CALL yarn install || EXIT /B 1
+    SET "YARN_VERSION="
+    FOR /f "delims=" %%v IN ('node -p "require('./package.json').packageManager.split('@')[1]"') DO SET "YARN_VERSION=%%v"
+    IF "%YARN_VERSION%"=="" (
+        ECHO ERROR: Could not determine Yarn version from package.json packageManager field.
+        EXIT /B 1
+    )
+    CALL yarn set version %YARN_VERSION% || EXIT /B 1
+    CALL yarn install --immutable || EXIT /B 1
     CALL npm rebuild || EXIT /B 1
 
     ECHO Bundling javascript...
@@ -237,8 +290,18 @@ REM Main build sequence Ends
     RD /Q /S "%BUILDROOT%\web\regression" 1> nul 2>&1
     ECHO Removing tools...
     RD /Q /S "%BUILDROOT%\web\tools" 1> nul 2>&1
-    ECHO Removing yarn cache...
+    ECHO Removing the JavaScript build configuration...
     RD /Q /S "%BUILDROOT%\web\.yarn" 1> nul 2>&1
+    DEL /q "%BUILDROOT%\web\yarn.lock" 1> nul 2>&1
+    DEL /q "%BUILDROOT%\web\.yarnrc.yml" 1> nul 2>&1
+    DEL /q "%BUILDROOT%\web\package.json" 1> nul 2>&1
+    DEL /q "%BUILDROOT%\web\jest.config.js" 1> nul 2>&1
+    DEL /q "%BUILDROOT%\web\babel.cfg" 1> nul 2>&1
+    DEL /q "%BUILDROOT%\web\babel.config.json" 1> nul 2>&1
+    DEL /q "%BUILDROOT%\web\webpack.config.js" 1> nul 2>&1
+    DEL /q "%BUILDROOT%\web\webpack.shim.js" 1> nul 2>&1
+    DEL /q "%BUILDROOT%\web\.eslintrc.js" 1> nul 2>&1
+    DEL /q "%BUILDROOT%\web\.editorconfig" 1> nul 2>&1
     ECHO Removing any existing configurations...
     DEL /q "%BUILDROOT%\web\pgadmin4.db" 1> nul 2>&1
     DEL /q "%BUILDROOT%\web\config_local.py" 1> nul 2>&1
@@ -276,8 +339,13 @@ REM Main build sequence Ends
 
     CD "%BUILDROOT%\runtime\resources\app\"
 
-    CALL yarn set version berry || EXIT /B 1
-    CALL yarn set version 4 || EXIT /B 1
+    SET "YARN_VERSION="
+    FOR /f "delims=" %%v IN ('node -p "require('./package.json').packageManager.split('@')[1]"') DO SET "YARN_VERSION=%%v"
+    IF "%YARN_VERSION%"=="" (
+        ECHO ERROR: Could not determine Yarn version from package.json packageManager field.
+        EXIT /B 1
+    )
+    CALL yarn set version %YARN_VERSION% || EXIT /B 1
     CALL yarn workspaces focus --production || EXIT /B 1
 
     ECHO Removing yarn cache...
@@ -286,9 +354,33 @@ REM Main build sequence Ends
     ECHO Downloading Electron to %TMPDIR%...
     REM Get a fresh copy of electron.
 
-    REM WGET
-    FOR /f "tokens=*" %%i IN ('npm info electron version') DO SET "ELECTRON_VERSION=%%i"
+    REM Resolve the electron version from runtime\yarn.lock, NOT from the npm
+    REM registry and NOT from the range in runtime\package.json. The registry's
+    REM `latest` dist-tag lands any newly published electron release in shipped
+    REM binaries without review, whilst the package.json range is only a lower
+    REM bound, so yarn is free to resolve it to a build other than the one we
+    REM ship. The lockfile is the single source of truth, and `yarn info`
+    REM reports its resolution without touching the network or needing
+    REM node_modules.
+    REM
+    REM It must run inside runtime\ though: outside a yarn project, `yarn info`
+    REM silently falls back to querying the registry and still exits 0, so check
+    REM the lockfile is present first and validate what comes back.
+    IF NOT EXIST "%WD%\runtime\yarn.lock" (
+        ECHO ERROR: "%WD%\runtime\yarn.lock" not found; cannot resolve the pinned Electron version.
+        EXIT /B 1
+    )
 
+    SET "ELECTRON_VERSION="
+    PUSHD "%WD%\runtime" || EXIT /B 1
+    FOR /f "delims=" %%i IN ('yarn info electron --json ^| node -e "const lines=require('fs').readFileSync(0,'utf8').split('\n').filter(Boolean);const pkg=lines.map(l=>{try{return JSON.parse(l);}catch(e){return null;}}).find(o=>o&&typeof o.value==='string'&&o.value.startsWith('electron@npm:'));const version=(pkg&&pkg.children&&pkg.children.Version)||'';process.stdout.write(/^[0-9]+[.][0-9]+[.][0-9]+(-[0-9A-Za-z.-]+)?$/.test(version)?version:'');"') DO SET "ELECTRON_VERSION=%%i"
+    POPD
+    IF "%ELECTRON_VERSION%"=="" (
+        ECHO ERROR: Could not resolve the pinned Electron version from "%WD%\runtime\yarn.lock".
+        EXIT /B 1
+    )
+
+    REM WGET
     :GET_NW
         wget https://github.com/electron/electron/releases/download/v%ELECTRON_VERSION%/electron-v%ELECTRON_VERSION%-win32-x64.zip -O "%TMPDIR%\electron-v%ELECTRON_VERSION%-win32-x64.zip"
         IF %ERRORLEVEL% NEQ 0 GOTO GET_NW
@@ -310,36 +402,51 @@ REM Main build sequence Ends
     %TMPDIR%\rcedit-x64.exe "%BUILDROOT%\runtime\pgAdmin4.exe" --set-icon "%WD%\pkg\win32\Resources\pgAdmin4.ico"
     %TMPDIR%\rcedit-x64.exe "%BUILDROOT%\runtime\pgAdmin4.exe" --set-version-string "FileDescription" "%APP_NAME%"
     %TMPDIR%\rcedit-x64.exe "%BUILDROOT%\runtime\pgAdmin4.exe" --set-version-string "ProductName" "%APP_NAME%"
-    %TMPDIR%\rcedit-x64.exe "%BUILDROOT%\runtime\pgAdmin4.exe" --set-product-version "%APP_VERSION%""
-
-    IF NOT "%PGADMIN_WINDOWS_CSC%" == "" (
-        ECHO Attempting to sign the pgAdmin4.exe...
-        CALL "%PGADMIN_SIGNTOOL_DIR%\signtool.exe" sign /sm /n "%PGADMIN_WINDOWS_CSC%" /tr http://timestamp.digicert.com /td sha256 /fd sha1 /v "%BUILDROOT%\runtime\pgAdmin4.exe"
-        IF %ERRORLEVEL% NEQ 0 (
-            ECHO.
-            ECHO ************************************************************
-            ECHO * Failed to sign the pgAdmin4.exe
-            ECHO ************************************************************
-            PAUSE
-        )
-    ) ELSE (
-        ECHO Skipping code signing ^(PGADMIN_WINDOWS_CSC is not set^)...
-    )
+    %TMPDIR%\rcedit-x64.exe "%BUILDROOT%\runtime\pgAdmin4.exe" --set-product-version "%APP_VERSION%"
 
     ECHO Staging PostgreSQL components...
     COPY "%PGADMIN_POSTGRES_DIR%\bin\libpq.dll" "%BUILDROOT%\runtime" > nul || EXIT /B 1
     COPY "%PGADMIN_POSTGRES_DIR%\bin\libcrypto-*-x64.dll" "%BUILDROOT%\runtime" > nul || EXIT /B 1
     COPY "%PGADMIN_POSTGRES_DIR%\bin\libssl-*-x64.dll" "%BUILDROOT%\runtime" > nul || EXIT /B 1
-    IF EXIST "%PGADMIN_POSTGRES_DIR%\bin\libintl-*.dll" COPY "%PGADMIN_POSTGRES_DIR%\bin\libintl-*.dll" "%BUILDROOT%\runtime" > nul
-    IF EXIST "%PGADMIN_POSTGRES_DIR%\bin\libiconv-*.dll" COPY "%PGADMIN_POSTGRES_DIR%\bin\libiconv-*.dll" "%BUILDROOT%\runtime" > nul
-    IF EXIST "%PGADMIN_POSTGRES_DIR%\bin\liblz4.dll" COPY "%PGADMIN_POSTGRES_DIR%\bin\liblz4.dll" "%BUILDROOT%\runtime" > nul
-    IF EXIST "%PGADMIN_POSTGRES_DIR%\bin\libzstd.dll" COPY "%PGADMIN_POSTGRES_DIR%\bin\libzstd.dll" "%BUILDROOT%\runtime" > nul
+    IF EXIST "%PGADMIN_POSTGRES_DIR%\bin\libintl-*.dll" (
+        COPY "%PGADMIN_POSTGRES_DIR%\bin\libintl-*.dll" "%BUILDROOT%\runtime" > nul || EXIT /B 1
+    )
+    IF EXIST "%PGADMIN_POSTGRES_DIR%\bin\libiconv-*.dll" (
+        COPY "%PGADMIN_POSTGRES_DIR%\bin\libiconv-*.dll" "%BUILDROOT%\runtime" > nul || EXIT /B 1
+    )
+    IF EXIST "%PGADMIN_POSTGRES_DIR%\bin\liblz4.dll" (
+        COPY "%PGADMIN_POSTGRES_DIR%\bin\liblz4.dll" "%BUILDROOT%\runtime" > nul || EXIT /B 1
+    )
+    IF EXIST "%PGADMIN_POSTGRES_DIR%\bin\libzstd.dll" (
+        COPY "%PGADMIN_POSTGRES_DIR%\bin\libzstd.dll" "%BUILDROOT%\runtime" > nul || EXIT /B 1
+    )
     COPY "%PGADMIN_POSTGRES_DIR%\bin\zlib1.dll" "%BUILDROOT%\runtime" > nul || EXIT /B 1
     COPY "%PGADMIN_POSTGRES_DIR%\bin\pg_dump.exe" "%BUILDROOT%\runtime" > nul || EXIT /B 1
-    COPY "%PGADMIN_POSTGRES_DIR%\bin\pg_dumpall.exe" "%BUILDROOT%\runtime" > nul || EXIT /B 1L%
+    COPY "%PGADMIN_POSTGRES_DIR%\bin\pg_dumpall.exe" "%BUILDROOT%\runtime" > nul || EXIT /B 1
     COPY "%PGADMIN_POSTGRES_DIR%\bin\pg_restore.exe" "%BUILDROOT%\runtime" > nul || EXIT /B 1
     COPY "%PGADMIN_POSTGRES_DIR%\bin\psql.exe" "%BUILDROOT%\runtime" > nul || EXIT /B 1
 
+    REM The Kerberos runtime belongs here, next to libpq.dll and the client
+    REM binaries: PostgreSQL 18 and later are built with GSSAPI support, so
+    REM libpq.dll has a load-time dependency on gssapi64.dll, and pg_dump.exe
+    REM and friends resolve it from their own directory. The pgAdmin server
+    REM process finds it here too, because the runtime prepends this directory
+    REM to PATH before spawning Python.
+    REM
+    REM krb5_64.dll loads krbcc64.dll dynamically rather than importing it, but
+    REM it is not optional: on Windows krb5 defaults the credential cache type
+    REM to CCAPI, and the entry points for that are left null when the DLL
+    REM cannot be loaded, so the first use of the default credential cache
+    REM calls address zero. ccapiserver.exe is the process krbcc64.dll drives.
+    ECHO Staging Kerberos components...
+    COPY "%PGADMIN_KRB5_DIR%\bin\kinit.exe" "%BUILDROOT%\runtime" > nul || EXIT /B 1
+    COPY "%PGADMIN_KRB5_DIR%\bin\krb5_64.dll" "%BUILDROOT%\runtime" > nul || EXIT /B 1
+    COPY "%PGADMIN_KRB5_DIR%\bin\comerr64.dll" "%BUILDROOT%\runtime" > nul || EXIT /B 1
+    COPY "%PGADMIN_KRB5_DIR%\bin\k5sprt64.dll" "%BUILDROOT%\runtime" > nul || EXIT /B 1
+    COPY "%PGADMIN_KRB5_DIR%\bin\gssapi64.dll" "%BUILDROOT%\runtime" > nul || EXIT /B 1
+    COPY "%PGADMIN_KRB5_DIR%\bin\krbcc64.dll" "%BUILDROOT%\runtime" > nul || EXIT /B 1
+    COPY "%PGADMIN_KRB5_DIR%\bin\ccapiserver.exe" "%BUILDROOT%\runtime" > nul || EXIT /B 1
+
     ECHO Staging VC++ runtime...
     MKDIR "%BUILDROOT%\installer" || EXIT /B 1
     COPY "%PGADMIN_VCREDIST_DIR%\%PGADMIN_VCREDIST_FILE%" "%BUILDROOT%\installer" > nul || EXIT /B 1
@@ -366,8 +473,12 @@ REM Main build sequence Ends
     DEL /s "%WD%\pkg\win32\installer.iss.in_stage*" > nul
 
     ECHO Creating windows installer using INNO tool...
+    REM Inno signs the installer and its uninstaller itself, one file per call,
+    REM through the same script as :SIGN_FILES. Inno replaces $q with a quote
+    REM and $f with the already-quoted file name. The outer pair of quotes is
+    REM for cmd /c, which strips the first and last quote of its command line.
     IF NOT "%PGADMIN_WINDOWS_CSC%" == "" (
-        CALL "%PGADMIN_INNOTOOL_DIR%\ISCC.exe" "%WD%\pkg\win32\installer.iss" "/SpgAdminSigntool=%PGADMIN_SIGNTOOL_DIR%\signtool.exe sign /sm /n $q%PGADMIN_WINDOWS_CSC%$q /tr http://timestamp.digicert.com /td sha256 /fd sha1 /v $f" || EXIT /B 1
+        CALL "%PGADMIN_INNOTOOL_DIR%\ISCC.exe" "%WD%\pkg\win32\installer.iss" "/DSIGNED" "/SpgAdminSigntool=%ComSpec% /c $q$q%WD%\pkg\win32\sign-files.bat$q $q%PGADMIN_WINDOWS_CSC%$q $f$q" || EXIT /B 1
     ) ELSE (
         CALL "%PGADMIN_INNOTOOL_DIR%\ISCC.exe" "%WD%\pkg\win32\installer.iss" || EXIT /B 1
     )
@@ -396,17 +507,86 @@ REM Main build sequence Ends
     ECHO Verifying the installer signature...
 
     CALL "%PGADMIN_SIGNTOOL_DIR%\signtool.exe" verify /pa /v "%DISTROOT%\%INSTALLERNAME%"
-    IF %ERRORLEVEL% NEQ 0 (
+    REM PAUSE was the old handler here, which on the signing host either returns
+    REM immediately, leaving the build to carry on with an unverified installer,
+    REM or blocks until the job times out. There is nobody at that machine to
+    REM press a key.
+    IF ERRORLEVEL 1 (
         ECHO.
         ECHO ************************************************************
         ECHO * Failed to verify signature of the installer
         ECHO ************************************************************
-        PAUSE
+        EXIT /B 1
     )
 
     EXIT /B 0
 
 
+REM Sign one or more files, passed as quoted arguments, with a SHA-256 file
+REM digest. pkg\win32\sign-files.bat does the work, in signtool's split
+REM digest, sign and ingest steps, because the one-step form cannot use a
+REM SHA-2 digest with the card's key; the script explains why. All the files
+REM go in one call because each call costs one PIN prompt, and their names
+REM must be unique, which the script checks.
+:SIGN_FILES
+    IF "%PGADMIN_WINDOWS_CSC%" == "" EXIT /B 0
+
+    CALL "%WD%\pkg\win32\sign-files.bat" "%PGADMIN_WINDOWS_CSC%" %*
+    REM IF ERRORLEVEL, not IF %ERRORLEVEL%: the latter would be expanded before
+    REM the script had run were this ever moved inside a parenthesised block.
+    IF ERRORLEVEL 1 (
+        ECHO.
+        ECHO ************************************************************
+        ECHO * Failed to sign one or more files
+        ECHO ************************************************************
+        EXIT /B 1
+    )
+
+    EXIT /B 0
+
+
+REM Sign the components that we build ourselves: the runtime executable, and
+REM the PostgreSQL and Kerberos utilities and libraries obtained from the
+REM winpgbuild project, all of which are staged into the runtime directory by
+REM :CREATE_RUNTIME_ENV. The Electron, Python and VC++ runtime components are
+REM deliberately left alone, as they are third party binaries that we do not
+REM build, and signing them would replace any signature of their own. Names
+REM are matched as patterns as some of the libraries include version numbers,
+REM and some of them are optional.
+:SIGN_COMPONENTS
+    IF "%PGADMIN_WINDOWS_CSC%" == "" (
+        ECHO Skipping code signing ^(PGADMIN_WINDOWS_CSC is not set^)...
+        EXIT /B 0
+    )
+
+    ECHO Attempting to sign the pgAdmin, PostgreSQL and Kerberos components...
+
+    SETLOCAL EnableDelayedExpansion
+    SET "COMPONENTS="
+    REM FOR expands an item containing a wildcard against the current directory
+    REM and silently drops it when nothing matches there, so the loop must run
+    REM in the runtime directory for the versioned libraries to be found at
+    REM all. Plain names are passed through whether or not the file exists,
+    REM hence the IF EXIST for the optional ones.
+    PUSHD "%BUILDROOT%\runtime" || EXIT /B 1
+    FOR %%f IN (pgAdmin4.exe libpq.dll libcrypto-*-x64.dll libssl-*-x64.dll libintl-*.dll libiconv-*.dll liblz4.dll libzstd.dll zlib1.dll pg_dump.exe pg_dumpall.exe pg_restore.exe psql.exe kinit.exe krb5_64.dll comerr64.dll k5sprt64.dll gssapi64.dll krbcc64.dll ccapiserver.exe) DO (
+        IF EXIST "%%f" SET "COMPONENTS=!COMPONENTS! "%BUILDROOT%\runtime\%%f""
+    )
+    POPD
+    IF "!COMPONENTS!" == "" (
+        ECHO.
+        ECHO ************************************************************
+        ECHO * No components were found to sign
+        ECHO ************************************************************
+        ENDLOCAL
+        EXIT /B 1
+    )
+    CALL :SIGN_FILES !COMPONENTS! || EXIT /B 1
+    ENDLOCAL
+
+    EXIT /B 0
+
+
 :USAGE
     ECHO Invalid command line options.
     ECHO Usage: "Make.bat [clean]"
@@ -417,3 +597,16 @@ REM Main build sequence Ends
 :CHECK_ROBOCOPY_ERROR
     IF %ERRORLEVEL% GEQ 8 EXIT /B %ERRORLEVEL%
     EXIT /B 0
+
+
+REM Check that a prerequisite directory exists, reporting the path that was
+REM looked for and how to correct it if it does not. The first argument is the
+REM directory and the second the hint; both are echoed here, outside any
+REM parenthesised block, so a parenthesis in either is just a character.
+:REQUIRE_DIR
+    IF EXIST "%~1" EXIT /B 0
+
+    ECHO %~1 does not exist.
+    ECHO %~2
+
+    EXIT /B 1

Makefile

@@ -25,7 +25,7 @@ appbundle:
 	./pkg/mac/build.sh $(BUILD_OPTS)
 
 install-node:
-	cd web && yarn install
+	cd web && yarn install --immutable
 
 install-python:
 	./tools/setup-python-env.sh

README.md

@@ -9,12 +9,12 @@ tarball or a git checkout.
 
 ## Architecture
 
-pgAdmin 4 is written as a web application with Python(Flask) on the server side
+pgAdmin 4 is written as a web application with Python (Flask) on the server side
 and ReactJS, HTML5 with CSS for the client side processing and UI.
 
 Although developed using web technologies, pgAdmin 4 can be deployed either on
 a web server using a browser, or standalone on a workstation. The runtime/
-subdirectory contains an Electron based runtime application intended to allow this,
+subdirectory contains an Electron-based runtime application intended to allow this,
 which will fork a Python server process and display the UI.
 
 ## Prerequisites
@@ -31,11 +31,11 @@ corepack enable
 
 # Building the Web Assets
 
-pgAdmin is dependent on a number of third party Javascript libraries. These,
-along with it's own Javascript code, CSS code and images must be
+pgAdmin is dependent on a number of third-party JavaScript libraries. These,
+along with its own JavaScript code, CSS code and images must be
 compiled into a "bundle" which is transferred to the browser for execution
 and rendering. This is far more efficient than simply requesting each
-asset as it's needed by the client.
+asset as it is needed by the client.
 
 To create the bundle, you will need the 'yarn' package management tool to be
 installed. Then, you can run the following commands on a *nix system to
@@ -60,7 +60,7 @@ C:\$PGADMIN4_SRC\web> yarn run bundle
 
 In order to run the Python code, a suitable runtime environment is required.
 Python version 3.9 and later are currently supported. It is recommended that a
-Python Virtual Environment is setup for this purpose, rather than using the
+Python virtual environment is set up for this purpose, rather than using the
 system Python environment. On Linux and Mac systems, the process is fairly
 simple - adapt as required for your distribution:
 
@@ -112,17 +112,17 @@ simple - adapt as required for your distribution:
    # Change pgAdmin data directory
    DATA_DIR = '/Users/myuser/.pgadmin_dev'
 
-   #Change pgAdmin server and port
+   # Change pgAdmin server and port
    DEFAULT_SERVER = '127.0.0.1'
    DEFAULT_SERVER_PORT = 5051
 
    # Switch between server and desktop mode
    SERVER_MODE = True
 
-   #Change pgAdmin config DB path in case external DB is used.
+   # Change pgAdmin config DB path in case an external DB is used.
    CONFIG_DATABASE_URI="postgresql://postgres:postgres@localhost:5436/pgadmin"
 
-   #Setup SMTP
+   # Set up SMTP
    MAIL_SERVER = 'smtp.gmail.com'
    MAIL_PORT = 465
    MAIL_USE_SSL = True
@@ -172,7 +172,7 @@ server or desktop mode, and access it from a web browser using the URL shown in
 the terminal once pgAdmin has started up.
 
 Setup of an environment on Windows is somewhat more complicated unfortunately,
-please see *pkg/win32/README.txt* for complete details.
+please see *pkg/win32/README.md* for complete details.
 
 # Building the documentation
 
@@ -226,9 +226,9 @@ with all the required packages, and then run:
 (venv) $ make pip
 ```
 
-To build the macOS AppBundle, please see *pkg/mac/README*.
+To build the macOS AppBundle, please see *pkg/mac/README.md*.
 
-To build the Windows installer, please see *pkg/win32/README.txt*.
+To build the Windows installer, please see *pkg/win32/README.md*.
 # Create Database Migrations
 
 In order to make changes to the SQLite DB, navigate to the 'web' directory:

docs/en_US/ai_tools.rst

@@ -82,6 +82,38 @@ Select your preferred LLM provider from the dropdown:
 After configuring your provider, click *Save* to apply the changes.
 
 
+.. _ai_data_handling:
+
+Data Handling and Provider Selection
+************************************
+
+When a cloud LLM provider is configured, pgAdmin transmits information about
+your database to that provider's API. Depending on the feature in use, this may
+include schema definitions such as table, column, index and constraint names
+and data types; server and database configuration settings read from
+``pg_settings``; query text; and EXPLAIN plan output. The *AI Assistant* in the
+Query Tool is also able to run queries against your database, within a read-only
+transaction and limited to 1000 rows, so row data may be included where the
+assistant determines it is needed to answer a question.
+
+None of this is transmitted unless you invoke an AI feature, and none of it is
+transmitted at all when no provider has been configured, which is the default;
+when AI features have been disabled by the administrator through the
+``LLM_ENABLED`` setting; or when a locally hosted provider such as Ollama or
+Docker Model Runner is configured.
+
+Each provider processes this data under its own terms of service, privacy policy
+and legal jurisdiction, and operates its infrastructure in locations of its own
+choosing. If you work in an environment subject to data residency requirements,
+procurement policies, or sector-specific rules governing the handling of
+database metadata, review both the provider's terms and your own organisation's
+policies before enabling a cloud provider.
+
+The providers listed in pgAdmin reflect the APIs that pgAdmin is able to
+communicate with. Their inclusion is not a recommendation, and no provider is
+enabled by default.
+
+
 Security Reports
 ****************
 

docs/en_US/backup_dialog.rst

@@ -100,6 +100,10 @@ tab to provide options related to data or pgAdmin objects that correspond to *pg
    * Move the switch next to *Only schemas* to limit the back up to schema-level
      database objects.
 
+   * Move the switch next to *Only statistics* to the *Yes* position to limit
+     the back up to optimizer statistics. **Note:** This option is visible only
+     for database server greater than or equal to 18.
+
    * Move the switch next to *Blobs* to the *No* position to exclude large
      objects in the backup.
 
@@ -143,6 +147,22 @@ tab to provide options related to data or pgAdmin objects that correspond to *pg
      Table access methods. **Note:** This option is visible only for
      database server greater than or equal to 15.
 
+   * Move the switch next to *Row security policies* to the *Yes* position to
+     exclude row security policies. **Note:** This option is visible only for
+     database server greater than or equal to 18.
+
+   * Move the switch next to *Data* to the *Yes* position to exclude data from
+     the backup. **Note:** This option is visible only for database server
+     greater than or equal to 18.
+
+   * Move the switch next to *Schema* to the *Yes* position to exclude schema
+     (the data definitions) from the backup. **Note:** This option is visible
+     only for database server greater than or equal to 18.
+
+   * Move the switch next to *Statistics* to the *Yes* position to exclude
+     optimizer statistics. **Note:** This option is visible only for database
+     server greater than or equal to 18.
+
 .. image:: images/backup_queries.png
     :alt: Queries option on backup dialog
     :align: center
@@ -259,6 +279,15 @@ tab to provide other backup options.
      position to include a statement that will use a SET SESSION AUTHORIZATION
      command to determine object ownership (instead of an ALTER OWNER command).
 
+   * Move the switch next to *Dump statistics* to the *Yes* position to include
+     optimizer statistics in the backup. It cannot be combined with *Only
+     data*, *Only schemas* or *Do not save* *Statistics*. **Note:** This option
+     is visible only for database server greater than or equal to 18.
+
+   * Move the switch next to *Sequence data* to the *Yes* position to include
+     sequence data that would normally be excluded. **Note:** This option is
+     visible only for database server greater than or equal to 18.
+
    * Use the *Exclude schema* field to not dump schemas whose name matches
      pattern.
 

docs/en_US/backup_server_dialog.rst

@@ -45,6 +45,10 @@ tab to provide options related to data or pgAdmin objects that correspond to *pg
 
    * Move the switch next to *Only roles* to limit the back up to roles only.
 
+   * Move the switch next to *Only statistics* to the *Yes* position to limit
+     the back up to optimizer statistics. **Note:** This option is visible only
+     for database server greater than or equal to 18.
+
 .. image:: images/backup_server_do_not_save.png
     :alt: Do not save option on backup server dialog
     :align: center
@@ -88,6 +92,22 @@ tab to provide options related to data or pgAdmin objects that correspond to *pg
      Table access methods. **Note:** This option is visible only for
      database server greater than or equal to 15.
 
+   * Move the switch next to *Row security policies* to the *Yes* position to
+     exclude row security policies. **Note:** This option is visible only for
+     database server greater than or equal to 18.
+
+   * Move the switch next to *Data* to the *Yes* position to exclude data from
+     the backup. **Note:** This option is visible only for database server
+     greater than or equal to 18.
+
+   * Move the switch next to *Schema* to the *Yes* position to exclude schema
+     (the data definitions) from the backup. **Note:** This option is visible
+     only for database server greater than or equal to 18.
+
+   * Move the switch next to *Statistics* to the *Yes* position to exclude
+     optimizer statistics. **Note:** This option is visible only for database
+     server greater than or equal to 18.
+
 .. image:: images/backup_server_queries.png
     :alt: Queries option on backup server dialog
     :align: center
@@ -171,6 +191,15 @@ tab to provide other backup options.
      position to include a statement that will use a SET SESSION AUTHORIZATION
      command to determine object ownership (instead of an ALTER OWNER command).
 
+   * Move the switch next to *Dump statistics* to the *Yes* position to include
+     optimizer statistics in the backup. It cannot be combined with *Only
+     data*, *Only schemas* or *Do not save* *Statistics*. **Note:** This option
+     is visible only for database server greater than or equal to 18.
+
+   * Move the switch next to *Sequence data* to the *Yes* position to include
+     sequence data that would normally be excluded. **Note:** This option is
+     visible only for database server greater than or equal to 18.
+
    * Use the *Exclude database* field to not dump databases whose name matches
      pattern.
 

docs/en_US/change_password_dialog.rst

@@ -1,8 +1,8 @@
 .. _change_password_dialog:
 
-*******************************
-`Change Password Dialog`:index:
-*******************************
+**************************************
+`Change Server Password Dialog`:index:
+**************************************
 
 It is a good policy to routinely change your password to protect data, even in
 what you may consider a 'safe' environment. In the workplace, failure to apply
@@ -30,7 +30,9 @@ comprehensive list and they **will not guarantee security**.
     :alt: Change database password dialog
     :align: center
 
-Use the *Change Password* dialog to change your password:
+Use the *Change Server Password* dialog to change the password of the role that
+pgAdmin uses to connect to the database server, rather than the password you use
+to log in to pgAdmin itself:
 
 * The name displayed in the *User* field is the role for which you are modifying
   the password; it is the role that is associated with the server connection
@@ -39,7 +41,7 @@ Use the *Change Password* dialog to change your password:
 * Enter the desired password for in the *New Password* field.
 * Re-enter the new password in the *Confirm Password* field.
 
-Click the *Save* button to change your password.
+Click the *Change* button to change your password.
 
 Click the *Close* button to exit without changing your password.
 

docs/en_US/change_user_password.rst

@@ -1,8 +1,8 @@
 .. _change_user_password:
 
-************************************
-`Change User Password Dialog`:index:
-************************************
+***************************************
+`Change pgAdmin Password Dialog`:index:
+***************************************
 
 It is a good policy to routinely change your password to protect data, even in
 what you may consider a 'safe' environment. In the workplace, failure to apply
@@ -30,11 +30,18 @@ comprehensive list and they **will not guarantee security**.
     :alt: Change current user password dialog
     :align: center
 
-Use the *Change Password* dialog to change your password:
+Use the *Change pgAdmin Password* dialog to change the password you use to log
+in to pgAdmin itself, rather than the password of a database server connection:
 
 * Enter your existing password in the *Current Password* field.
 * Enter the desired password for in the *New Password* field.
 * Re-enter the new password in the *Confirm Password* field.
 
-Click the *Change Password* button to change your password; click *Close* to
-exit the dialog.
+Click the *Change* button to change your password; click *Close* to exit the
+dialog.
+
+Changing your password signs out all of your other active sessions, so anyone
+using your account elsewhere must sign in again with the new password. The
+session you change it in stays signed in. When an administrator resets your
+password from the :ref:`User Management <user_management>` page, all of your
+sessions are signed out.

docs/en_US/cloud_deployment.rst

@@ -4,9 +4,9 @@
 `PostgreSQL Cloud Deployment`:index:
 *************************************
 
-A PostgreSQL server can be deployed on the Amazon, EDB BigAnimal, Azure,
-Google cloud using this module. In future more cloud provider options will
-be available.
+A PostgreSQL server can be deployed on the Amazon, Azure, Google cloud
+or pgEdge Starfleet using this module. In future more cloud provider
+options will be available.
 
 To launch the *Cloud Deployment...* tool, right click on the *Server Group* or
 *Server* of the tree control, and select *Deploy a Cloud Instance* from the
@@ -16,6 +16,6 @@ To launch the *Cloud Deployment...* tool, right click on the *Server Group* or
    :maxdepth: 2
 
    cloud_aws_rds
-   cloud_edb_biganimal
    cloud_azure_database
    cloud_google_cloud_sql
+   cloud_pgedge_starfleet

docs/en_US/cloud_edb_biganimal.rst

@@ -1,110 +0,0 @@
-.. _cloud_edb_biganimal:
-
-******************************************
-`EDB BigAnimal Cloud Deployment`:index:
-******************************************
-
-To deploy a PostgreSQL server on the EDB BigAnimal cloud, follow the below steps.
-
-.. image:: images/cloud_provider_for_postgresql.png
-    :alt: Cloud Deployment Provider
-    :align: center
-
-Once you launch the tool, select the EDB BigAnimal option.
-Click on the *Next* button to proceed further.
-
-.. image:: images/cloud_biganimal_credentials.png
-    :alt: Cloud Deployment Provider
-    :align: center
-
-The next steps is to authenticate the user to EDB BigAninal.
-Click the given button to authenticate, by clicking the button, the user
-will be redirected to the new tab for the verification.
-Once you confirm the one time code, the pgAdmin will automatically detect it
-and the next button will be enabled. To proceed further, click on the next button.
-
-.. image:: images/cloud_biganimal_cluster.png
-    :alt: Cloud Deployment Provider
-    :align: center
-
-* Use the *Project* field to choose a project in your Biganimal account.
-
-* Use the *Cluster type* field to choose a cluster type.
-
-* Use the *No. of Standby Replicas* field to specify the replicas if you have selected the High Availability cluster.
-
-* Use the *Cluster provider* field to choose the provider.
-
-
-.. image:: images/cloud_biganimal_instance.png
-    :alt: Cloud Deployment Provider
-    :align: center
-
-Use the fields from the Instance Specification tab to specify the Instance
-details.
-
-* Use the *Cluster name* field to add a cluster name for the PostgreSQL
-  server; the name specified will be displayed in the *Object Explorer* too.
-
-* Use the *Region* field to select the region.
-
-* Use the *Public IP range* field to specify the IP Address range for permitting the
-  inbound traffic. Leave it blank for 0.0.0.0/0
-
-* Use the *Instance type* field to select the instance type.
-
-* Use the *Instance series* field to select the instance series.
-
-* Use the *Instance size* field to allocate the computational, network, and
-  memory capacity required by planned workload of this DB instance.
-
-* Use the *Volume type* field to select the instance storage type.
-
-* Use the *Volume properties* field to specify the storage capacity. This field is specific to Azure.
-
-* Use the *Volume size* field to specify the storage size. This field is specific to AWS.
-
-* Use the *Volume IOPS* field to specify the storage IOPS. This field is specific to AWS.
-
-* Use the *Disk throughput* field to specify the disk throughput. This field is specific to AWS.
-
-
-.. image:: images/cloud_biganimal_database.png
-    :alt: Cloud Deployment Provider
-    :align: center
-
-Use the fields from the Database Details tab to specify the Instance details.
-
-* Use the drop-down list box in the *Server group* field to select the parent
-  node for the server; the server will be displayed in the *Object Explorer*
-  within the specified group.
-
-* Use the *Database type* field to specify the PostgreSQL
-  type, EnterpriseDB PostgreSQL Advanced Server or PostgreSQL.
-
-* Use the *PostgreSQL version* field to select the database version.
-
-* Use the *Database Password* field to provide a password that will be supplied when
-  authenticating with the server.
-
-* Use the *Confirm password* field to repeat the password.
-
-
-.. image:: images/cloud_biganimal_review.png
-    :alt: Cloud Deployment Provider
-    :align: center
-
-At the end, review the Cluster details that you provided. Click on Finish
-button to deploy the instance on EDB BigAnimal.
-
-.. image:: images/cloud_deployment_tree.png
-    :alt: Cloud Deployment Provider
-    :align: center
-
-Once you click on the finish, one background process will start which will
-deploy the instance in the cloud and monitor the progress of the deployment.
-You can view all the background processes with their running status and logs
-on the :ref:`Processes <processes>` tab.
-
-The Server will be added to the tree with the cloud deployment icon. Once the
-deployment is done, the server details will be updated.

docs/en_US/cloud_pgedge_starfleet.rst

@@ -0,0 +1,102 @@
+.. _cloud_pgedge_starfleet:
+
+************************************************
+`pgEdge Starfleet Deployment`:index:
+************************************************
+
+To deploy a PostgreSQL database on pgEdge Starfleet, follow the steps below.
+pgAdmin creates a *Managed* database, which Starfleet hosts for you.
+
+.. image:: images/cloud_provider_for_postgresql.png
+    :alt: Cloud Deployment Provider
+    :align: center
+
+Once you launch the tool, select the pgEdge Starfleet option and click on the
+*Next* button to proceed.
+
+.. image:: images/cloud_starfleet_credentials.png
+    :alt: pgEdge Starfleet credentials
+    :align: center
+
+In the Credentials step, enter the *Auth ID* and *Auth secret* of a Starfleet
+API client. pgAdmin checks them with Starfleet when you click *Next*.
+
+.. note:: Create the API client in the pgEdge Starfleet console, under
+ *Settings > API Clients*. The Auth secret is shown only when the client is
+ created, so keep a copy of it. See the
+ `pgEdge Starfleet documentation <https://docs.pgedge.com/pgedge-starfleet/>`_
+ for details.
+
+.. image:: images/cloud_starfleet_instance.png
+    :alt: pgEdge Starfleet instance specification
+    :align: center
+
+Use the fields from the Instance Specification step to specify the database
+details.
+
+* Use the *Database name* field to name the database. The name may contain
+  lowercase letters and digits only, must start with a letter, and can be up
+  to 50 characters long.
+
+* Use the *Display name* field to optionally set a friendlier name, up to 25
+  characters long.
+
+* Select the location to deploy the database to from the *Region* field.
+
+* Use the *Size* field to select the size of the database.
+
+* Use the *PostgreSQL version* field to select the PostgreSQL version.
+
+* Use the *Allowed IP addresses* field to list the IPv4 addresses or CIDR
+  ranges that may connect to the database, separated by commas. The field is
+  prefilled with your public IP address. At least one and at most 50 entries
+  are required; IPv6 addresses are not accepted. Without a matching entry the
+  database will not accept connections from pgAdmin.
+
+* Use the *Connect as* field to choose whether pgAdmin connects as *admin*
+  (the database administrator, which is not a superuser) or *app* (an
+  application user).
+
+.. image:: images/cloud_starfleet_database.png
+    :alt: pgEdge Starfleet database details
+    :align: center
+
+In the Database Details step, use the *pgAdmin server group* field to select
+the server group the new server will be registered in.
+
+.. image:: images/cloud_starfleet_review.png
+    :alt: pgEdge Starfleet review
+    :align: center
+
+Finally, review the summary in the Review step and click *Finish* to start the
+deployment. The progress of the deployment is shown in the same way as for the
+other cloud providers, and the new server is added to the *Object Explorer*
+when the database is available. pgAdmin connects with *sslmode* set to
+*require* and *gssencmode* set to *disable*.
+
+If the deployment fails after the database has been created, for example
+because pgEdge Starfleet reports it as failed or it does not become available
+within 30 minutes, pgAdmin removes the server from the *Object Explorer* but
+does not delete the database. Check the pgEdge Starfleet console, and delete
+the database there if it is not needed.
+
+.. image:: images/cloud_starfleet_password.png
+    :alt: pgEdge Starfleet database password
+    :align: center
+
+pgEdge Starfleet generates the database password. When the deployment
+finishes, pgAdmin shows it once in the *pgEdge Starfleet database password*
+dialog, together with the host and user name.
+
+* Use the *Copy* button to copy the password to the clipboard.
+
+* Use the *Save password* button to save the password with the server. This
+  button is only shown if saving passwords is permitted by the
+  :ref:`ALLOW_SAVE_PASSWORD <config_py>` setting.
+
+The password is not shown again in pgAdmin after the dialog is closed. If you
+lose it, reset it from the pgEdge Starfleet console.
+
+.. note:: pgAdmin contacts the Starfleet API at the address given by the
+ *STARFLEET_API_URL* configuration setting, which defaults to
+ *https://api.pgedge.com*. The address must use HTTPS.

docs/en_US/conf.py

@@ -239,6 +239,14 @@ latex_documents = [
 # https://groups.google.com/forum/#!topic/sphinx-users/ZlQ95_QikXo
 latex_elements = {
     'fncychap': r'\usepackage[Sonny]{fncychap}',
+    # pdflatex's default utf8 inputenc covers Latin-1/Latin-Extended-A but
+    # not the Vietnamese precomposed code points that appear in CVE
+    # reporter names. Declare the specific characters we use rather than
+    # switching engines.
+    'preamble': r'''
+\DeclareUnicodeCharacter{1EA1}{\d{a}}
+\DeclareUnicodeCharacter{1EC1}{\`{\^e}}
+''',
 }
 
 

docs/en_US/config_py.rst

@@ -1,8 +1,8 @@
 .. _config_py:
 
-***************************
-`The config.py File`:index:
-***************************
+*****************************
+`Configuration Files`:index:
+*****************************
 
 There are multiple configuration files that are read at startup by pgAdmin. These
 files are used for configuration options that:
@@ -32,6 +32,12 @@ The configuration files are as follows:
   and may be created by users in the same directory as ``config.py`` if
   needed.
 
+  .. note:: On macOS, ``config.py`` is located inside the application bundle
+     (``pgAdmin 4.app/Contents/Resources/web/``), which is replaced in its
+     entirety when pgAdmin is upgraded, so a ``config_local.py`` file created
+     there will be lost. Use ``config_system.py`` instead, which is stored
+     outside the application bundle.
+
 * ``config_system.py``: This file is read after ``config_local.py`` and is
   intended for system administrators to include settings that are configured
   system-wide from a secure location that users cannot normally modify and that

docs/en_US/container_deployment.rst

@@ -157,14 +157,35 @@ of the `Preferences JSON file <https://www.pgadmin.org/docs/pgadmin4/latest/pref
 
 Override the default file path for the pgadmin configurations file.This can be used while provisioning
 container with read only root file system to achieve a more secure pgadmin4 deployment for kubernetes.
-Note that if you are externally mapping this file, then environment variables passed using *PGADMIN_CONFIG_*
-suffix will be ignored.
+Note that if you are externally mapping this file, then environment variables
+passed using *PGADMIN_CONFIG_* suffix will be ignored only when that file
+exists and is non-empty. A missing or empty file is generated with those
+values.
 
 **PGPASS_FILE**
 
 *Default: <null>*
-This varible should be set to if you want to pass password using pgpass
-file for the servers added in pgadmin.
+Set this variable to the path of a pgpass file if you want to supply passwords
+for the servers added in pgAdmin. On startup, the file is copied into the
+container and used as the ``.pgpass`` file.
+
+**PUID**
+
+*Default: 5050*
+
+The user ID that pgAdmin runs as. This is only used when the container is
+started as root (for example with ``--user root``), in which case the
+*pgadmin* user is given this UID, the ownership of */var/lib/pgadmin* is
+changed to match, and pgAdmin is then run as that user rather than as root.
+It is ignored when the container is started as any other user, which is the
+default. The value must be numeric, and may not be 0.
+
+**PGID**
+
+*Default: 0*
+
+The group ID that pgAdmin runs as. As with *PUID*, this is only used when the
+container is started as root.
 
 **GUNICORN_ACCESS_LOGFILE**
 
@@ -194,20 +215,62 @@ where it may be increased.
 
 This is a variable prefix that can be used to override any of the configuration
 options in pgAdmin's *config.py* file. Add the *PGADMIN_CONFIG_* prefix to any
-variable name from *config.py* and give the value in the format 'string value'
-for strings, True/False for booleans or 123 for numbers. See below for an
-example.
+variable name from *config.py* and give the value as a Python expression:
+``'string value'`` (including the quotes) for strings, ``True`` or ``False``
+for booleans, or ``123`` for numbers. See below for an example.
 
-Settings are written to */pgadmin4/config_distro.py* within the container, which
-is read after */pgadmin4/config.py* and before */pgadmin4/config_local.py*.
-Any settings given will therefore override anything in config.py, but can be
-overridden by settings in config_local.py.
+*PGADMIN_DEFAULT_* variables, including *PGADMIN_DEFAULT_EMAIL* and
+*PGADMIN_DEFAULT_PASSWORD*, are ordinary text and take no Python literal
+quotes. *PGADMIN_CONFIG_* values are written as Python code into
+*/pgadmin4/config_distro.py*, or into the file named by
+*PGADMIN_CUSTOM_CONFIG_DISTRO_FILE* if that is set. The values ``true`` and
+``false``, in any letter case, are written as ``True`` and ``False``. A bare
+hostname is a Python name, so ``MAIL_SERVER = mail.example.com`` raises
+``NameError`` at startup.
 
-Settings are only written to */pgadmin4/config_distro.py* once, typically on
-first launch of the container. If */pgadmin4/config_distro.py* contains one or
-more lines, then no changes are made; for example, if the container instance is
-restarted, or */pgadmin4/config_distro.py* is mapped to a file on persistent
-storage (not recommended - use */pgadmin4/config_local.py* instead)!
+Quoting added by the shell or by YAML sits outside that Python expression and
+is removed before the value is written. The *docker run* example below keeps
+the Python quotes inside shell quotes, for example
+``-e 'PGADMIN_CONFIG_LOGIN_BANNER="Authorised users only!"'``.
+
+In Docker Compose map syntax, YAML consumes the quotes around a scalar. A
+YAML-only quoted hostname, ``PGADMIN_CONFIG_MAIL_SERVER: "mail.example.com"``
+or ``PGADMIN_CONFIG_MAIL_SERVER: 'mail.example.com'``, reaches the container
+as ``mail.example.com`` and cannot serve as a Python string. Nest the Python
+quotes inside the scalar:
+``PGADMIN_CONFIG_MAIL_SERVER: "'mail.example.com'"``. The container then
+writes ``MAIL_SERVER = 'mail.example.com'``. ``"587"`` and ``"True"`` are
+already valid Python, so they need no nested quotes. The list form keeps
+single quotes, as ``docker run -e`` does
+(``- PGADMIN_CONFIG_MAIL_SERVER='mail.example.com'``); nesting them there
+produces ``"'mail.example.com'"``, which is valid Python but puts stray
+quote characters into the value and fails silently rather than at startup.
+An ``env_file`` value strips one layer of quotes, so the same nesting as the
+map form applies there. The Compose example in the Examples section uses the
+map form for an SMTP server, username, password, and *SECURITY_EMAIL_SENDER*.
+
+Compose substitutes ``$VAR`` and ``${VAR}`` in Compose file values, and in
+double-quoted ``env_file`` values, so write a literal dollar as ``$$``.
+``"'pa$word'"`` reaches the container as ``'pa'``, with only a warning about
+an unset variable. The entrypoint does not expand the value again, so ``$$``
+is the only escaping required.
+
+Settings are written to */pgadmin4/config_distro.py* within the container (or
+to the file named by *PGADMIN_CUSTOM_CONFIG_DISTRO_FILE*), which is read after
+*/pgadmin4/config.py* and before */pgadmin4/config_local.py*. Any settings
+given will therefore override anything in config.py, but can be overridden by
+settings in config_local.py.
+
+The file is generated only when it is missing or empty, typically on first
+launch, and a non-empty file is left unchanged, including when the container
+is restarted. To apply corrected *PGADMIN_CONFIG_* values, recreate the
+container (``docker compose up -d`` does this when the environment changes,
+whereas ``docker compose restart`` does not), keeping the */var/lib/pgadmin*
+mapping to retain your data. If the file is on persistent storage, either
+because it is mapped (not recommended; use */pgadmin4/config_local.py*
+instead) or because *PGADMIN_CUSTOM_CONFIG_DISTRO_FILE* points there,
+recreating the container is not enough: edit the file, or empty it so that it
+is regenerated.
 
 See :ref:`config_py` for more information on the available configuration settings.
 
@@ -219,13 +282,37 @@ host machine to allow configuration to be customised and shared between
 instances.
 
 .. warning:: Warning: pgAdmin runs as the *pgadmin* user (UID: 5050) in the
-    *pgadmin* group (GID: 5050) in the container. You must ensure that all files
+    *root* group (GID: 0) in the container. You must ensure that all files
     are readable, and where necessary (e.g. the working/session directory)
     writeable for this user on the host machine. For example:
 
     .. code-block:: bash
 
-        sudo chown -R 5050:5050 <host_directory>
+        sudo chown -R 5050:0 <host_directory>
+
+    When using rootless Podman, user IDs in the container are mapped to a
+    range of subordinate IDs on the host, so changing the ownership of a host
+    directory to 5050 as shown above does not make it writeable by the
+    container. Instead, either add the *U* option to the volume, which has
+    Podman recursively change the ownership of the directory and everything
+    in it to match the container's user, for example:
+
+    .. code-block:: bash
+
+        -v /path/to/pgadmin-data:/var/lib/pgadmin:U
+
+    or start the container as root, which in a rootless container is your own
+    user on the host. The container will change the ownership of
+    */var/lib/pgadmin* and then run pgAdmin as the *pgadmin* user; see *PUID*
+    and *PGID* above. For example:
+
+    .. code-block:: bash
+
+        --user root
+
+    Neither option changes SELinux labels, so on a host with SELinux enforcing,
+    the volume also needs the *z* (shared) or *Z* (private) option to relabel
+    it, for example ``-v /path/to/pgadmin-data:/var/lib/pgadmin:Z,U``.
 
     On some filesystems that do not support extended attributes, it may not be
     possible to run pgAdmin without specifying a value for *PGADMIN_LISTEN_PORT*
@@ -303,6 +390,37 @@ Run a simple container over port 80, setting some configuration options:
         -e 'PGADMIN_CONFIG_CONSOLE_LOG_LEVEL=10' \
         -d dpage/pgadmin4
 
+Run pgAdmin with Docker Compose, publishing port 80 and sending mail through
+an external SMTP server. *PGADMIN_DEFAULT_EMAIL* and
+*PGADMIN_DEFAULT_PASSWORD* are ordinary strings. Each *PGADMIN_CONFIG_*
+string below includes the Python quotes that YAML would otherwise remove.
+*PGADMIN_DISABLE_POSTFIX* may be any non-empty value; it is ordinary text,
+not a Python expression. The named volume keeps */var/lib/pgadmin* when the
+container is recreated:
+
+.. code-block:: yaml
+
+    services:
+      pgadmin:
+        image: dpage/pgadmin4
+        ports:
+          - "80:80"
+        environment:
+          PGADMIN_DEFAULT_EMAIL: user@domain.com
+          PGADMIN_DEFAULT_PASSWORD: SuperSecret
+          PGADMIN_DISABLE_POSTFIX: "1"
+          PGADMIN_CONFIG_MAIL_SERVER: "'mail.example.com'"
+          PGADMIN_CONFIG_MAIL_PORT: "587"
+          PGADMIN_CONFIG_MAIL_USE_TLS: "True"
+          PGADMIN_CONFIG_MAIL_USERNAME: "'smtp-user'"
+          PGADMIN_CONFIG_MAIL_PASSWORD: "'s3cret=value'"
+          PGADMIN_CONFIG_SECURITY_EMAIL_SENDER: "'pgadmin@example.com'"
+        volumes:
+          - pgadmin-data:/var/lib/pgadmin
+
+    volumes:
+      pgadmin-data:
+
 Run a TLS secured container using a shared config/storage directory in
 /private/var/lib/pgadmin on the host, and servers pre-loaded from
 /tmp/servers.json on the host:
@@ -320,6 +438,44 @@ Run a TLS secured container using a shared config/storage directory in
         -e 'PGADMIN_ENABLE_TLS=True' \
         -d dpage/pgadmin4
 
+Restricted Security Contexts (OpenShift, ``--cap-drop=ALL``)
+************************************************************
+
+Some platforms refuse to honor Linux file capabilities. The two situations
+the pgAdmin container handles automatically are:
+
+- ``--cap-drop=ALL`` (or an equivalent restricted Kubernetes SecurityContext
+  such as OpenShift's ``restricted-v2`` SCC), which zeros the bounding set
+  and removes ``CAP_NET_BIND_SERVICE``. Exec of a capability-tagged binary
+  then fails with ``Operation not permitted``.
+
+- ``--security-opt=no-new-privileges`` (or
+  ``allowPrivilegeEscalation: false``), which causes the kernel to silently
+  strip file capabilities on exec. The binary runs, but a subsequent
+  ``bind()`` to a port below 1024 fails with ``EPERM``.
+
+The container's entrypoint reads ``/proc/self/status`` at startup, detects
+either condition, switches gunicorn to the non-capability python
+interpreter, and (when *PGADMIN_LISTEN_PORT* is not set) defaults the
+listen port to **8080** for plain HTTP and **8443** for TLS instead of
+80/443. A message is logged so the choice is visible.
+
+In practice this means a typical OpenShift deployment requires no special
+build, no setcap, and no custom configuration — only a Service / Route
+that targets the chosen non-privileged port:
+
+.. code-block:: bash
+
+    docker run --rm -p 8080:8080 \
+        --security-opt=no-new-privileges \
+        --cap-drop=ALL \
+        -e 'PGADMIN_DEFAULT_EMAIL=user@domain.com' \
+        -e 'PGADMIN_DEFAULT_PASSWORD=SuperSecret' \
+        dpage/pgadmin4
+
+If you explicitly set *PGADMIN_LISTEN_PORT*, that value is honored in both
+the restricted and unrestricted paths.
+
 Reverse Proxying
 ****************
 
@@ -526,3 +682,84 @@ the container is typically launched per the example below:
         -e "SCRIPT_NAME=/pgadmin4" \
         -l "traefik.frontend.pgadmin4.rule=Host(`host.example.com`) && PathPrefix(`/pgadmin4`)" \
         -d dpage/pgadmin4
+
+Sharing the data volume across containers (Kubernetes init containers)
+----------------------------------------------------------------------
+
+A common Kubernetes pattern is to bootstrap a pgAdmin deployment with one or
+more init containers that share the ``/var/lib/pgadmin`` volume with the main
+pgAdmin container — for example, an init container that runs
+``setup.py load-servers`` to import a ``servers.json`` definition file at
+each rollout.
+
+**The image tag of any such sidecar/init container must NOT be newer than
+the main pgAdmin container's tag.** pgAdmin's configuration database
+(``pgadmin4.db``) is migrated forward only — destructive operations such as
+dropping a column are part of normal upgrades. If an init container running
+``pgadmin4:latest`` (or any newer tag) executes ``setup.py`` against a
+``pgadmin4.db`` that the main, older pgAdmin will then read, the init
+container's migrations will advance the schema past what the main container's
+ORM understands, and the main container will fail at runtime with errors
+like ``no such column: <table>.<column>``.
+
+The safe configuration is to pin **both** the main container and every
+sidecar/init container that touches the data volume to the **same**
+explicit version tag, and upgrade them together:
+
+.. code-block:: yaml
+
+    # Deployment manifest (spec.template.spec): pin every container that
+    # touches the data volume to the same explicit tag. Do NOT use :latest.
+    spec:
+      template:
+        spec:
+          initContainers:
+            - name: import-servers-json
+              image: docker.io/dpage/pgadmin4:9.14   # match the main container
+              # ... rest of the init container spec ...
+          containers:
+            - name: pgadmin
+              image: docker.io/dpage/pgadmin4:9.14   # main pgAdmin container
+
+If you deploy pgAdmin with a Helm chart, set the equivalent image-tag values
+for both the main container and every init/sidecar container rather than the
+raw fields shown above. When upgrading pgAdmin, change every reference to the
+image tag at the same time so that the main container and any sidecar/init
+containers move forward together.
+
+Use ``strategy: Recreate``, not ``RollingUpdate``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Even when every container's image tag is pinned correctly, **a rolling
+upgrade across pgAdmin versions is unsafe** when the old and new pods share
+a data volume. Kubernetes' default ``RollingUpdate`` strategy starts the
+new pod, waits for it to become healthy, and only *then* terminates the
+old pod. During that overlap window:
+
+1. The new pod's startup runs ``db_upgrade()`` and applies any pending
+   migrations to the shared ``pgadmin4.db`` — including destructive ones
+   (column drops, table renames, type changes).
+2. The new pod becomes healthy. The old pod is still alive and still has
+   ``pgadmin4.db`` open with its older ORM schema metadata.
+3. Until Kubernetes terminates the old pod, requests routed to it
+   generate queries that reference the pre-migration schema. Those
+   queries now fail at runtime against the migrated database — for
+   example, ``no such column: <table>.<column>`` when a column was
+   dropped in this release.
+
+Because pgAdmin's migrations are forward-only with single-step destructive
+operations (a column dropped in release N+1 is gone immediately, not after
+a deprecation cycle), there is no safe way for an N-version pod to keep
+serving against a migrated N+1 schema. Set the deployment strategy to
+``Recreate``, which terminates the old pod *before* starting the new one:
+
+.. code-block:: yaml
+
+    spec:
+      strategy:
+        type: Recreate   # not RollingUpdate
+
+The trade-off is a few seconds of downtime during each upgrade, in
+exchange for not serving traffic from a pod whose ORM is misaligned with
+the database schema underneath it. This is the supported upgrade
+strategy for pgAdmin K8s deployments today.

docs/en_US/editgrid.rst

@@ -15,8 +15,15 @@ to specify the number of rows you would like to display in the editor panel.
 
 To modify the content of a table, each row in the table must be uniquely
 identifiable. If the table definition does not include an OID or a primary key,
-the displayed data is read only. Note that views cannot be edited; updatable
-views (using rules) are not supported.
+the displayed data is read only. Simple, automatically-updatable views (a
+single base table, with no ``INSTEAD OF`` triggers or rewrite rules, whose
+base table's primary key columns are all exposed in the view under their
+original names) can also be edited; updating and deleting rows is supported,
+but inserting new rows through a view is not, so the *Add row* and *Paste*
+buttons are disabled when editing a view. Materialized views, views based
+on more than one table, views exposing only part of a composite primary key,
+and views relying on ``INSTEAD OF`` triggers or rules created with
+``CREATE RULE`` remain read only.
 
 The editor features a toolbar that allows quick access to frequently used
 options, and a work environment divided into two panels:
@@ -101,6 +108,11 @@ properties of the geometries directly in map, just click the specific geometry:
       viewer will render geometries with the same SRID in the map. If SRID=4326 the
       OSM tile layer will be added into the map.
 
+    - *Custom tile provider:* A custom map tile provider ({z}/{x}/{y} URL template,
+      in EPSG:3857, EPSG:4326 or EPSG:3395) can be configured as a base layer via
+      *Preferences > Query Tool > Geometry Viewer*. When configured, it is
+      selected as the default base layer.
+
     - *Data size:* For performance reasons, the viewer will render no more than
       100000 geometries, totaling up to 20MB.
 

docs/en_US/function_dialog.rst

@@ -39,6 +39,8 @@ Use the fields in the *Definition* tab to define the function:
 * Use the drop-down listbox next to *Return type* to select the data type
   returned by the function, if any. If *Custom return type?* is enabled this field
   will change to an input text field.
+* Move the *Returns a set?* switch to indicate if the function returns a set
+  that includes multiple rows. The default is *No*.
 * Use the drop-down listbox next to *Language* to select the implementation
   language. The default is *sql*.
 * Use the drop-down listbox next to *Depends on extensions* to select the extension that this function
@@ -88,8 +90,6 @@ function:
     * *IMMUTABLE* indicates that the function cannot modify the database and
       always returns the same result when given the same argument values.
 
-* Move the *Returns a Set?* switch to indicate if the function returns a set
-  that includes multiple rows. The default is *No*.
 * Move the *Strict?* switch to indicate if the function always returns NULL
   whenever any of its arguments are NULL. If *Yes*, the function is not executed
   when there are NULL arguments; instead a NULL result is assumed

docs/en_US/import_export_servers.rst

@@ -132,10 +132,21 @@ The JSON file format used when importing or exporting servers is quite
 straightforward and simply contains a list of servers, with a number of
 attributes. The following attributes are required to be present in every server
 definition: Name, Group, Port, Username, SSLMode, MaintenanceDB and one of Host,
-HostAddr or Service.
+HostAddr or Service. A shared server may supply SharedUsername in place of
+Username, in which case the shared username is also used as the username of the
+imported server.
 
 Password fields cannot be imported or exported.
 
+In desktop mode, ``PasswordExecCommand`` is the shell command to run, as shown
+in the example below. In server mode it must instead be the name of a command
+defined in the ``SERVER_PASSEXEC_COMMANDS`` setting (see :ref:`config_py`), and
+the same name is written when servers are exported. A server whose
+``PasswordExecCommand`` is not the name of a configured command is still
+imported, but without a password exec command, and a warning naming the server
+is printed. ``PasswordExecExpiration`` is imported only together with a valid
+command name.
+
 The following example shows both a minimally defined and a fully defined server:
 
 .. code-block:: python

docs/en_US/index.rst

@@ -26,6 +26,7 @@ of database objects.
    developer_tools
    processes
    pgagent
+   pgtimetable_chains
    contributions
    release_notes
    licence

docs/en_US/kerberos.rst

@@ -34,7 +34,7 @@ from *config.py* file and modify the values for the following parameters.
      through kerberos. If that authentication fails, then it will return back
      to the login page where you need to provide internal pgAdmin user
      credentials for authentication."
-   "KERBEROS_AUTO_CREATE_USER", "Set the value to *True* if you want to
+   "KRB_AUTO_CREATE_USER", "Set the value to *True* if you want to
    automatically create a pgAdmin user corresponding to a successfully
    authenticated Kerberos user. Please note that password is not stored in the
    pgAdmin database."
@@ -126,6 +126,82 @@ PostgreSQL Server settings to configure Kerberos Authentication
 * Note that, you have to login into pgAdmin with Kerberos authentication to
   then connect to PostgreSQL using Kerberos.
 
+* In server mode, the only Kerberos credentials used to connect to a
+  PostgreSQL server are those delegated by a user who logged in to pgAdmin
+  with Kerberos, and only for a server with "Kerberos authentication"
+  enabled. The default credential cache and client keytab of the operating
+  system account that pgAdmin runs as are never used, so a user cannot
+  connect to a server with that account's Kerberos identity.
+
+* To enforce this for Windows SSPI, which uses the logon of the account
+  pgAdmin runs as, and for gssproxy, which environment variables do not
+  stop, in server mode pgAdmin also tells libpq what to use and what to
+  refuse.
+
+  * For a Kerberos-login user's connection to a server with Kerberos
+    authentication enabled, pgAdmin forces ``gsslib=gssapi``, replacing any
+    ``gsslib`` the user set. Without it, a libpq built with both GSSAPI and
+    SSPI answers the server's request with SSPI, which uses the Windows
+    logon of the account pgAdmin runs as and ignores the delegated
+    credentials, whereas ``gsslib=gssapi`` makes libpq use the delegated
+    credential cache. This helps only with a Windows libpq build that
+    includes both GSSAPI and SSPI, as pgAdmin's Windows packages do. With
+    libpq 16 or later, SSPI is also refused with ``require_auth=!sspi``;
+    with an older libpq it is not refused.
+
+  * Every other connection uses ``require_auth=!gss,!sspi`` and
+    ``gssencmode=disable``, merged with the server's own "Require
+    authentication" (``require_auth``) parameter. A server whose
+    ``require_auth`` allows only ``gss`` can be used only by a
+    Kerberos-login user connecting to a server with Kerberos authentication
+    enabled, and one that allows only ``sspi`` cannot be used in server
+    mode.
+
+  * The ``require_auth`` protection needs libpq 16 or later in pgAdmin.
+    Without it only the ``KRB5CCNAME`` and ``KRB5_CLIENT_KTNAME`` isolation
+    applies to connections that may not use Kerberos, which does not cover
+    Windows SSPI or gssproxy. ``gssencmode`` needs libpq 12 or later;
+    ``gsslib`` is known to every libpq that pgAdmin supports.
+
+  * psql and the utilities (such as pg_dump) get no ``require_auth`` in their
+    connection string unless the user set one for the server, which is then
+    merged as above. Their protection is the ``PGREQUIREAUTH``,
+    ``PGGSSENCMODE`` and ``PGGSSLIB`` environment variables. Only a libpq
+    16 or later in the utility honours ``PGREQUIREAUTH``; an older one
+    ignores it silently.
+
+  * A service file entry's settings take precedence over these environment
+    variables for psql and the utilities, whereas pgAdmin's own connections
+    are not affected, because their connection string takes precedence over
+    the service file. Only a service listed in
+    ``SERVER_MODE_ALLOWED_SERVICES`` can be used in server mode, so only an
+    entry the administrator has written can do this. Do not set
+    ``require_auth``, ``gssencmode`` or ``gsslib`` in such an entry unless
+    every pgAdmin user may use what it allows: the ``KRB5CCNAME`` and
+    ``KRB5_CLIENT_KTNAME`` isolation cannot be overridden by a service file,
+    but ``require_auth`` and ``gsslib`` in a listed service can re-enable
+    Windows SSPI or gssproxy for the utilities.
+
+
+Accounts
+========
+
+A Kerberos user is only ever logged in to the Kerberos account whose username
+is their principal (for example *user@EXAMPLE.COM*), never to an ``INTERNAL``
+or other account with the same username. If there is no such Kerberos account
+and *KRB_AUTO_CREATE_USER* is *False*, the login fails.
+
+The administrator account created when pgAdmin is first set up is an
+``INTERNAL`` account. If you use Kerberos authentication only, create a
+Kerberos administrator account and deactivate the initial one:
+
+.. code-block:: bash
+
+    /path/to/python /path/to/setup.py add-external-user user@EXAMPLE.COM --auth-source kerberos --admin
+    /path/to/python /path/to/setup.py update-user admin@example.com --inactive
+
+See :ref:`Accounts from different authentication sources
+<auth_source_accounts>` for more information.
 
 Master Password
 ===============

docs/en_US/keyboard_shortcuts.rst

@@ -15,45 +15,47 @@ When using main browser window, the following keyboard shortcuts are available:
    :class: longtable
    :widths: 2 2 3
 
-   +----------------------------+--------------------+------------------------------------+
-   | Shortcut (Windows/Linux)   | Shortcut (Mac)     | Function                           |
-   +============================+====================+====================================+
-   | Shift + Ctrl + a           | Shift + Ctrl + a   | Add grid row                       |
-   +----------------------------+--------------------+------------------------------------+
-   | Shift + Alt + b            | Shift + Option + b | Object explorer                    |
-   +----------------------------+--------------------+------------------------------------+
-   | Shift + Alt + n            | Shift + Option + n | Create object                      |
-   +----------------------------+--------------------+------------------------------------+
-   | Shift + Alt + d            | Shift + Option + d | Delete object                      |
-   +----------------------------+--------------------+------------------------------------+
-   | Shift + Alt + g            | Shift + Option + g | Direct debugging                   |
-   +----------------------------+--------------------+------------------------------------+
-   | Shift + Alt + e            | Shift + Option + e | Edit object properties             |
-   +----------------------------+--------------------+------------------------------------+
-   | Shift + Alt + f            | Shift + Option + f | File main menu                     |
-   +----------------------------+--------------------+------------------------------------+
-   | Shift + Alt + h            | Shift + Option + h | Help main menu                     |
-   +----------------------------+--------------------+------------------------------------+
-   | Shift + Alt + o            | Shift + Option + o | Object main menu                   |
-   +----------------------------+--------------------+------------------------------------+
-   | Shift + Alt + q            | Shift + Option + q | Open query tool                    |
-   +----------------------------+--------------------+------------------------------------+
-   | Shift + Ctrl + f           | Shift + Ctrl + f   | Quick Search                       |
-   +----------------------------+--------------------+------------------------------------+
-   | F5                         | F5                 | Refresh object explorer            |
-   +----------------------------+--------------------+------------------------------------+
-   | Shift + Alt + s            | Shift + Option + s | Search objects                     |
-   +----------------------------+--------------------+------------------------------------+
-   | Shift + Alt + [            | Shift + Option + [ | Tabbed panel backward              |
-   +----------------------------+--------------------+------------------------------------+
-   | Shift + Alt + ]            | Shift + Option + ] | Tabbed panel forward               |
-   +----------------------------+--------------------+------------------------------------+
-   | Shift + Alt + w            | Shift + Ctrl + w   | Close tab panel                    |
-   +----------------------------+--------------------+------------------------------------+
-   | Shift + Alt + l            | Shift + Option + l | Tools main menu                    |
-   +----------------------------+--------------------+------------------------------------+
-   | Shift + Alt + v            | Shift + Option + v | View data                          |
-   +----------------------------+--------------------+------------------------------------+
+   +----------------------------+---------------------------+------------------------------------+
+   | Shortcut (Windows/Linux)   | Shortcut (Mac)            | Function                           |
+   +============================+===========================+====================================+
+   | Shift + Ctrl + a           | Shift + Ctrl + a          | Add grid row                       |
+   +----------------------------+---------------------------+------------------------------------+
+   | Shift + Alt + b            | Shift + Option + b        | Object explorer                    |
+   +----------------------------+---------------------------+------------------------------------+
+   | Ctrl + Alt + b             | Ctrl + Option + b         | Toggle Object Explorer             |
+   +----------------------------+---------------------------+------------------------------------+
+   | Shift + Alt + n            | Shift + Option + n        | Create object                      |
+   +----------------------------+---------------------------+------------------------------------+
+   | Shift + Alt + d            | Shift + Option + d        | Delete object                      |
+   +----------------------------+---------------------------+------------------------------------+
+   | Shift + Alt + g            | Shift + Option + g        | Direct debugging                   |
+   +----------------------------+---------------------------+------------------------------------+
+   | Shift + Alt + e            | Shift + Option + e        | Edit object properties             |
+   +----------------------------+---------------------------+------------------------------------+
+   | Shift + Alt + f            | Shift + Option + f        | File main menu                     |
+   +----------------------------+---------------------------+------------------------------------+
+   | Shift + Alt + h            | Shift + Option + h        | Help main menu                     |
+   +----------------------------+---------------------------+------------------------------------+
+   | Shift + Alt + o            | Shift + Option + o        | Object main menu                   |
+   +----------------------------+---------------------------+------------------------------------+
+   | Shift + Alt + q            | Shift + Option + q        | Open query tool                    |
+   +----------------------------+---------------------------+------------------------------------+
+   | Shift + Ctrl + f           | Shift + Ctrl + f          | Quick Search                       |
+   +----------------------------+---------------------------+------------------------------------+
+   | F5                         | F5                        | Refresh object explorer            |
+   +----------------------------+---------------------------+------------------------------------+
+   | Shift + Alt + s            | Shift + Option + s        | Search objects                     |
+   +----------------------------+---------------------------+------------------------------------+
+   | Ctrl + Alt + Page Up       | Ctrl + Option + Page Up   | Tabbed panel backward              |
+   +----------------------------+---------------------------+------------------------------------+
+   | Ctrl + Alt + Page Down     | Ctrl + Option + Page Down | Tabbed panel forward               |
+   +----------------------------+---------------------------+------------------------------------+
+   | Shift + Alt + w            | Shift + Ctrl + w          | Close tab panel                    |
+   +----------------------------+---------------------------+------------------------------------+
+   | Shift + Alt + l            | Shift + Option + l        | Tools main menu                    |
+   +----------------------------+---------------------------+------------------------------------+
+   | Shift + Alt + v            | Shift + Option + v        | View data                          |
+   +----------------------------+---------------------------+------------------------------------+
 
 Property Grid Controls
 **********************
@@ -98,6 +100,8 @@ When using the syntax-highlighting SQL editors, the following shortcuts are avai
    +--------------------------+----------------------+-------------------------------------+
    | Ctrl + /                 | Cmd + /              | Comment/Uncomment code (Block)      |
    +--------------------------+----------------------+-------------------------------------+
+   | Ctrl + Shift + d         | Cmd + Shift + d      | Duplicate current line/selection    |
+   +--------------------------+----------------------+-------------------------------------+
    | Ctrl + a                 | Cmd + a              | Select all                          |
    +--------------------------+----------------------+-------------------------------------+
    | Ctrl + c                 | Cmd + c              | Copy selected text to the clipboard |

docs/en_US/ldap.rst

@@ -133,5 +133,51 @@ credentials is the responsibility of:
   of pgAdmin and protects against attackers who would otherwise reach the
   LDAP server through pgAdmin.
 
-See :ref:`Avoiding a bruteforce attack <login>` for the equivalent note
-on the login page.
+See :ref:`Avoiding a bruteforce attack <avoiding_bruteforce>` for the equivalent note
+on the login page.
+
+Internal accounts
+*****************
+
+pgAdmin treats accounts from different authentication sources as separate
+accounts, even when they share a username. An LDAP user is only ever logged
+in to the LDAP account with that username, and never to an ``INTERNAL``
+account with the same name, so each account keeps its own role and
+settings.
+
+The administrator account created when pgAdmin is first set up always uses
+the ``INTERNAL`` authentication source. It remains in the pgAdmin database
+when *AUTHENTICATION_SOURCES* is set to *['ldap']*, although it can then no
+longer be used to log in. If you use LDAP authentication only, create an
+LDAP administrator account, for example:
+
+.. code-block:: bash
+
+    /path/to/python /path/to/setup.py add-external-user ldapuser --auth-source ldap --admin
+
+and then deactivate the initial ``INTERNAL`` administrator account so that
+it cannot be used if internal authentication is enabled again later:
+
+.. code-block:: bash
+
+    /path/to/python /path/to/setup.py update-user admin@example.com --inactive
+
+When both *internal* and *ldap* are listed in *AUTHENTICATION_SOURCES*, a
+username and password entered on the login page are tried against each source
+in turn, in the order they are listed, and the first source that accepts the
+password signs the user in; the sources listed after it are not tried. Every
+source listed before it is still tried, so the password is a failed attempt at
+each of those. If the same username exists as both an internal and an LDAP
+account, a wrong password sent to the directory is a failed LDAP bind that
+counts towards the directory's lockout, even when a source listed later (such
+as the internal account) then accepts the sign-in. pgAdmin's own lockout
+counter for the internal account increases only when the sign-in fails at every
+source. Avoid giving an internal and an LDAP account the same username.
+
+When *LDAP_DN_CASE_SENSITIVE* is off, names that differ only in case are the
+same login. Do not create two accounts whose usernames differ only in case;
+pgAdmin cannot tell which one a sign-in is for.
+
+See :ref:`Accounts from different authentication sources
+<auth_source_accounts>` and :ref:`User Management <user_management>` for more
+information on the ``setup.py`` user management commands.

docs/en_US/login.rst

@@ -52,10 +52,17 @@ to launch a password recovery utility.
 If you have forgotten the email associated with your account, please contact
 your administrator.
 
-Please note that your LDAP password cannot be recovered using this page. If
-you enter your LDAP username in the *Email Address/Username* field, and then
-enter your email to recover your password, an error message will be displayed
-asking you to contact the LDAP administrator to recover your LDAP password.
+Password recovery works only for accounts using the ``INTERNAL``
+authentication source, which are the only accounts whose password pgAdmin
+holds. Recovery looks up the email address you enter and acts on the ``INTERNAL``
+account that has it: if one exists, reset instructions are sent for that
+account. The password of an account authenticated against an external source
+(``LDAP``, ``OAUTH2``, ``KERBEROS`` or ``WEBSERVER``) cannot be recovered here,
+because it is held by that source; if the email belongs only to such an
+account, an error asks you to contact that source's administrator. See
+:ref:`Accounts from different authentication sources <auth_source_accounts>`.
+
+.. _avoiding_bruteforce:
 
 Avoiding a bruteforce attack
 ****************************

docs/en_US/managing_database_objects.rst

@@ -39,6 +39,7 @@ node, and select *Create Cast...*
    publication_dialog
    schema_dialog
    sequence_dialog
+   statistics_dialog
    subscription_dialog
    synonym_dialog
    trigger_function_dialog

docs/en_US/menu_bar.rst

@@ -72,7 +72,7 @@ following options (in alphabetical order):
 |                             |                                                                                                                          |
 |   2) *Deploy Cloud Instance*| Click to open the :ref:`Cloud Deployment <cloud_deployment>` dialog to deploy an cloud instance.                         |
 +-----------------------------+--------------------------------------------------------------------------------------------------------------------------+
-| *Change Password...*        | Click to open the :ref:`Change Password... <change_password_dialog>` dialog to change your password.                     |
+| *Change Server Password...* | Click to open the :ref:`Change Server Password... <change_password_dialog>` dialog to change the server password.        |
 +-----------------------------+--------------------------------------------------------------------------------------------------------------------------+
 | *Clear Saved Password*      | If you have saved the database server password, click to clear the saved password.                                       |
 |                             | Enable only when password is already saved.                                                                              |

docs/en_US/mfa.rst

@@ -30,6 +30,9 @@ modify the values for the following parameters.
    "MFA_SUPPORTED_METHODS", "Set the authentication methods to be supported e.g. email, authenticator"
    "MFA_EMAIL_SUBJECT", "<APP_NAME> - Verification Code e.g. pgAdmin 4 -
    Verification Code"
+   "MFA_EMAIL_CODE_MAX_ATTEMPTS", "The number of wrong entries allowed for one
+   emailed verification code, after which the code is discarded and a new one
+   must be sent. The default value is 5. Values below 1 are treated as 1."
    "MFA_FORCE_REGISTRATION", "Force the user to configure the authentication
    method on login (if no authentication is already configured)."
 

docs/en_US/oauth2.rst

@@ -11,6 +11,25 @@ file (see the :ref:`config.py <config_py>` documentation) on the system where
 pgAdmin is installed in Server mode. You can copy these settings from *config.py*
 file and modify the values for the following parameters.
 
+.. warning::
+   pgAdmin reads OAuth2 provider settings **only** from the ``OAUTH2_CONFIG``
+   list; each provider is a single dictionary entry within that list. Settings
+   such as ``OAUTH2_CLIENT_ID`` or ``OAUTH2_SSL_CERT_VERIFICATION`` defined at
+   the top level of the configuration are ignored.
+
+   This matters in container deployments. Although most options can be set with
+   an individual ``PGADMIN_CONFIG_<KEY>`` environment variable, OAuth2 is the
+   exception: individual variables such as ``PGADMIN_CONFIG_OAUTH2_CLIENT_ID``
+   or ``PGADMIN_CONFIG_OAUTH2_SSL_CERT_VERIFICATION`` will **not** configure a
+   provider. Instead, configure the whole provider list through a single
+   ``PGADMIN_CONFIG_OAUTH2_CONFIG`` variable, for example::
+
+       PGADMIN_CONFIG_OAUTH2_CONFIG="[{'OAUTH2_NAME': 'my-provider', 'OAUTH2_DISPLAY_NAME': 'My Provider', 'OAUTH2_CLIENT_ID': '...', 'OAUTH2_CLIENT_SECRET': '...', 'OAUTH2_SERVER_METADATA_URL': 'https://provider.example.com/.well-known/openid-configuration', 'OAUTH2_SCOPE': 'openid email profile', 'OAUTH2_SSL_CERT_VERIFICATION': False}]"
+
+   If pgAdmin detects per-provider OAuth2 settings at the top level while no
+   provider is configured in ``OAUTH2_CONFIG``, it logs a warning at startup
+   to highlight the misconfiguration.
+
 OAuth2 vs OpenID Connect (OIDC)
 ================================
 
@@ -63,17 +82,52 @@ and secure.
     "OAUTH2_API_BASE_URL", "Oauth2 base URL endpoint to make requests simple, ex: *https://api.github.com/*"
     "OAUTH2_USERINFO_ENDPOINT", "User Endpoint, ex: *user* (for github, or *user/emails* if the user's email address is private) and *userinfo* (for google). **For OIDC providers**, this is optional if the ID token contains sufficient claims (email, preferred_username, or sub)."
     "OAUTH2_SCOPE", "Oauth scope, ex: 'openid email profile'. **For OIDC providers**, include 'openid' scope to receive an ID token."
-    "OAUTH2_ICON", "The Font-awesome icon to be placed on the oauth2 button,  ex: fa-github"
+    "OAUTH2_ICON", "The Font Awesome icon to be placed on the oauth2 button. A brand icon name (e.g. fa-github) uses the brands style by default; to use another style, include the style class explicitly (e.g. 'fas fa-key')."
     "OAUTH2_BUTTON_COLOR", "Oauth2 button color"
     "OAUTH2_USERNAME_CLAIM", "The claim which is used for the username. If the value is empty, **for OIDC providers** pgAdmin will use: 1) email, 2) preferred_username, or 3) sub (in that order). **For OAuth2 providers** without OIDC, email is required. Ex: *oid* (for AzureAD), *email* (for Github), *preferred_username* (for Keycloak)"
     "OAUTH2_AUTO_CREATE_USER", "Set the value to *True* if you want to automatically
     create a pgAdmin user corresponding to a successfully authenticated Oauth2 user.
     Please note that password is not stored in the pgAdmin database."
+    "OAUTH2_AUTO_LOGIN", "Set the value to *True* to send users straight to the OAuth2 provider
+    instead of showing the pgAdmin login page. This only takes effect when *oauth2* is the only
+    value in AUTHENTICATION_SOURCES and exactly one provider is configured. The default is *False*.
+    See :ref:`oauth2_auto_login` below."
     "OAUTH2_ADDITIONAL_CLAIMS", "If a dictionary is provided, pgAdmin will check for a matching key and value on the **ID token first** (for OIDC providers), then fall back to the userinfo endpoint response. In case there is no match with the provided config, the user will receive an authorization error. Useful for checking AzureAD_ *wids* or *groups*, GitLab_ *owner*, *maintainer* and *reporter* claims."
+    "OAUTH2_SERVER_GROUP_CLAIM", "The name of a claim listing the server groups whose shared servers the user may access. If set, shared servers owned by other users are only visible and accessible if the name of their server group is in the claim. See :ref:`oauth2_server_group_claims` below."
+    "OAUTH2_SERVER_GROUP_CLAIM_MAPPING", "An optional dictionary mapping values of the OAUTH2_SERVER_GROUP_CLAIM claim to a server group name or a list of server group names. Values without a mapping are used as server group names unchanged."
     "OAUTH2_SSL_CERT_VERIFICATION", "Set this variable to False to disable SSL certificate verification for OAuth2 provider.
     This may need to set False, in case of self-signed certificates."
     "OAUTH2_CHALLENGE_METHOD", "Enable PKCE workflow. PKCE method name, only *S256* is supported"
     "OAUTH2_RESPONSE_TYPE", "Enable PKCE workflow. Mandatory with OAUTH2_CHALLENGE_METHOD, must be set to *code*"
+    "OAUTH2_LOGOUT_URL", "The provider's logout endpoint, used to end the user's session with the provider
+    when they log out of pgAdmin. *{redirect_uri}* and *{id_token}* in the value are replaced with the pgAdmin
+    URL and the user's ID token. Ex: *https://example.com/realms/master/protocol/openid-connect/logout?post_logout_redirect_uri={redirect_uri}&id_token_hint={id_token}* (for Keycloak)"
+
+Accounts
+========
+
+An OAuth2 user is only ever logged in to the OAuth2 account whose username is
+the one resolved from their identity. When *OAUTH2_USERNAME_CLAIM* is set, that
+claim is used, taken from the ID token if present and otherwise from the
+userinfo profile. When it is not set, an OIDC provider uses the first of
+``email``, ``preferred_username`` or ``sub`` that is present, and a non-OIDC
+provider uses the email address. The user is never logged in to an ``INTERNAL``
+or other account with the same username. If there is no such OAuth2 account and
+*OAUTH2_AUTO_CREATE_USER* is *False*, the login fails. When you provision an
+administrator account for an OAuth2-only deployment, give it the username your
+provider resolves to, which may not be the email address.
+
+The administrator account created when pgAdmin is first set up is an
+``INTERNAL`` account. If you use OAuth2 authentication only, create an OAuth2
+administrator account and deactivate the initial one:
+
+.. code-block:: bash
+
+    /path/to/python /path/to/setup.py add-external-user user@example.com --auth-source oauth2 --admin
+    /path/to/python /path/to/setup.py update-user admin@example.com --inactive
+
+See :ref:`Accounts from different authentication sources
+<auth_source_accounts>` for more information.
 
 Redirect URL
 ============
@@ -100,6 +154,21 @@ After configuration, on restart, you can see the login page with the Oauth2 logi
     :alt: Oauth2 login
     :align: center
 
+.. _oauth2_auto_login:
+
+Skipping the Login Page
+-----------------------
+
+If OAuth2 is the only authentication source and a single provider is configured, set
+OAUTH2_AUTO_LOGIN to *True* to send users straight to the provider rather than showing them the
+login page with a single button. Note that any LOGIN_BANNER will not be seen in this case.
+
+The login page is still shown after a login fails, so that the error can be read, and after the
+user logs out, so that they are not logged straight back in by the provider. Setting
+OAUTH2_LOGOUT_URL for the provider is recommended, so that logging out of pgAdmin also ends the
+user's session with the provider. To show the login page at any other time, add *?no_auto_login*
+to its URL, for example *https://pgadmin.example.com/login?no_auto_login*.
+
 PKCE Workflow
 =============
 
@@ -323,6 +392,49 @@ Example:
         # then userinfo endpoint if not found
     }]
 
+.. _oauth2_server_group_claims:
+
+Restricting Shared Servers with a Claim
+---------------------------------------
+
+**OAUTH2_SERVER_GROUP_CLAIM** limits which shared servers an OAuth2 user can
+see, based on a claim from the identity provider such as a list of roles or
+groups. When it is set:
+
+* A shared server owned by another user is only visible, and can only be
+  connected to, if the name of the server group it is in appears in the claim.
+* If the claim is missing for a user, they see no shared servers owned by
+  other users.
+* Servers and server groups that the user owns themselves are not affected.
+* Users who log in by other methods are not affected.
+
+The claim is read from the ID token first, then from the userinfo endpoint
+response. Its value may be a string or a list of strings; values of any other
+type (for example, group objects returned by some providers) are ignored.
+Server group names are matched exactly, with no trimming or case folding.
+
+**OAUTH2_SERVER_GROUP_CLAIM_MAPPING** can be used to translate claim values
+into server group names. A value may map to a single name or a list of names,
+and values with no mapping are used as server group names unchanged.
+
+The claim is only read when the user logs in, so changes made at the identity
+provider take effect at the user's next login.
+
+Example:
+
+.. code-block:: python
+
+    OAUTH2_CONFIG = [{
+        # ... other config ...
+        'OAUTH2_SERVER_GROUP_CLAIM': 'roles',
+        'OAUTH2_SERVER_GROUP_CLAIM_MAPPING': {
+            'dba': ['Production', 'Staging'],
+            'developer': 'Staging'
+        },
+        # A user with the roles ['developer', 'Reporting'] can see shared
+        # servers in the 'Staging' and 'Reporting' server groups.
+    }]
+
 Legacy OAuth2 Configuration (Without OIDC)
 -------------------------------------------
 

docs/en_US/pgtimetable_chains.rst

@@ -0,0 +1,239 @@
+.. _pgtimetable_chains:
+
+
+***************************************
+`pgTimeTable Chains`:index:
+***************************************
+
+**pg_timetable** is a PostgreSQL-based scheduling agent that runs and manages what are called `Chains`.
+Each chain is composed of a set of Tasks to be executed in the order they should run.
+A chain is assigned a single schedule using an extended cron-style format.
+This UI has been tested with pg_timetable 6.3.0 and above.
+
+A task may be a series of *SQL* statements, a *BUILTIN* pg_timetable command (such as sending email)
+or an operating system *PROGRAM* program/batch/shell script.
+
+Switches on the *pgTimeTable Chain* dialog (accessed
+through the *Properties* context menu) allow you to modify a chain or disable the whole chain,
+as well as modify tasks within the chain.
+
+When you highlight the name of a defined chain in the pgAdmin tree control, the
+*Properties* tab of the main pgAdmin window will display details about the chain,
+and the *Statistics* tab will display details about the chain's execution.
+There are also statistics about each task.
+
+pg_timetable supports the ability to have more than one job agent running at a time.
+Job agents can be deployed on various platforms and binaries are readily available to 
+deploy on Linux, Windows, and Mac.
+
+For complete installation instructions, configuration options, and command-line
+usage, please refer to the
+`pg_timetable documentation <https://cybertec-postgresql.github.io/pg_timetable/>`_.
+
+If you are migrating from pgAgent or another PostgreSQL based scheduler, pg_timetable provides
+migration SQL queries to help in that migration.  See the
+`migration tools <https://github.com/cybertec-postgresql/pg_timetable/tree/master/extras>`_
+on GitHub for details.
+
+Viewing pgTimeTable
+********************
+To enable viewing of the *pgTimeTable Chains* node, enable it on the File -> Preferences -> Nodes.
+It will only show if the schema *timetable* and associated tables exist in your maintenance database.
+
+Creating a Chain
+****************
+
+Note that pg_timetable is not installed via `CREATE EXTENSION`.
+Instead you use a pgTimeTable agent to install the necessary tables.
+To create or manage a chain, use the pgAdmin tree control to browse to the
+server on which the timetable schema exists.  The tree control will
+display a *pgTimeTable Chains* node, under which currently defined chains are
+displayed.
+
+To add a new chain, right click on the *pgTimeTable Chains* node,
+and select *Create pgTimeTable Chain...* from the context menu.
+
+When the chain dialog opens, use the tabs on the dialog to define the chain
+and its tasks.
+
+.. image:: images/pgtimetable_chain_general.png
+    :alt: pgTimeTable chain dialog general tab
+    :align: center
+
+Use the fields on the *General* tab to provide general information about the
+chain:
+
+* Provide a name for the chain in the *Name* field.
+* Move the *Enabled* switch to the *Yes* position to enable the chain, or
+  *No* to disable it.
+* Use the *Max instances* field to specify the number of parallel instances
+  (clients) that may execute this chain simultaneously.  Leave the field blank
+  to allow unlimited parallel execution.
+* Use the *Timeout (ms)* field to specify the maximum number of milliseconds
+  the chain may run before it is aborted.  A value of *0* means no timeout.
+* Move the *Self-destruct* switch to *Yes* to have the chain delete itself
+  after a successful run.
+* Move the *Exclusive execution* switch to *Yes* to pause all other parallel
+  chains while this chain is executing.
+* Use the *Host agent* field to specify the client name of the agent running
+  pgTimeTable that should execute this chain.  Leave the field blank to allow
+  any available host to run the chain.
+
+  .. note:: You can query the ``timetable.active_session`` view to see the
+      client names reported by running pgTimeTable agents:
+
+      .. code-block:: sql
+
+          SELECT DISTINCT client_name FROM timetable.active_session
+
+      Use the client name exactly as reported by the query in the *Host agent*
+      field.
+
+* Use the *On error* field to specify the behavior when an error occurs.
+  Accepted values are:
+
+  * *NULL* - Use the default error handling.
+  * *LOG* - Log the error and continue execution.
+  * *ABORT* - Abort the chain on error.
+
+* Use the *Schedule* field to specify a cron-style schedule for the chain.
+  The format consists of a single field with 5 slots. As with regular cron,
+  you can use a comma (`,`) for multiple values and an asterisk (`*`) as a wildcard for all.
+  E.g. `20 1,5 * * *` would run at 1:20 and 5:20 AM.
+  The timezone is always the timezone of the server the pgTimeTable database resides on.
+
+  .. code-block:: text
+
+      * * * * *
+      | | | | |
+      | | | | +---- day of the week (0 - 7) (0 and 7 = Sunday)
+      | | | +------ month (1 - 12)
+      | | +-------- day of the month (1 - 31)
+      | +---------- hour (0 - 23)
+      +------------ minute (0 - 59)
+
+  If you leave the field blank it runs every minute
+  (the effective schedule is `* * * * *`).
+
+In addition to cron syntax, pgTimeTable supports additional special case formats.
+Namely `@after`, `@every`, `@reboot`.
+
+The `@every` and `@after` should be followed with additional arguments.
+For example `@every 2 hours`.
+
+
+.. image:: images/pgtimetable_chain_tasks.png
+    :alt: pgTimeTable chain dialog tasks tab
+    :align: center
+
+Use the *Tasks* tab to define and manage the tasks that the chain will
+execute.  Click the Add icon (+) to add a new task.  Tasks are executed in
+order of their *Order* value.
+
+Click the compose icon (located at the left side of the header) to open the
+task definition dialog.  See `Chain Task Dialog`_ below for details on
+defining a task.
+
+When you have finished defining the chain, you can use the *SQL* tab to review
+the SQL that will create or modify your chain.
+
+Click the *Save* button to save the chain, or *Close* to exit without saving.
+Use the *Reset* button to remove your unsaved entries from the dialog.
+
+After saving a chain, the chain will be listed under the *pgTimeTable Chains*
+node of the pgAdmin tree control.  The *Properties* tab in the main pgAdmin
+window will display a high-level overview of the selected chain, and the
+*Statistics* tab will show the details of each execution run.
+
+.. image:: images/pgtimetable_chain_properties.png
+    :alt: pgTimeTable chain properties
+    :align: center
+
+To modify an existing chain or to review detailed information about a chain,
+right-click on a chain name, and select *Properties* from the context menu.
+
+
+Chain Task Dialog
+*****************
+
+A chain task defines a single unit of work to be performed as part of a chain.
+Each chain can contain one or more tasks, which are executed sequentially in
+order.
+
+.. image:: images/pgtimetable_task_general.png
+    :alt: pgTimeTable task dialog general tab
+    :align: center
+
+Use the fields on the *General* tab to define the task:
+
+* Provide a name for the task in the *Name* field.
+* Use the *Order* field to specify the execution order of the task within the
+  chain.  Tasks are executed in ascending order by this value.
+* Use the *Kind* drop-down to select the type of task:
+
+  * *SQL* - The task executes SQL statements.
+  * *PROGRAM* - The task executes an operating system command.
+  * *BUILTIN* - The task executes one of the built-in pgTimeTable commands.
+
+* When *Kind* is set to *SQL*, use the *Connection string* field to optionally
+  specify a libpq-style connection string for a remote database.  Leave the
+  field blank to execute against the pgTimeTable database.
+
+  .. note:: The *Connection string* field is only available when the
+      pgTimeTable extension version supports it (version 5.x or later).
+      It is ignored for *PROGRAM* and *BUILTIN* task kinds.
+
+* Move the *Ignore error* switch to *Yes* to continue chain execution even if
+  this task fails.  Set to *No* to stop the chain when an error occurs.
+
+.. image:: images/pgtimetable_task_code.png
+    :alt: pgTimeTable task dialog code tab
+    :align: center
+
+Use the *Code* tab to provide the code or command for the task.  The content
+of the *Code* tab depends on the selected *Kind*:
+
+* If *Kind* is *SQL*, provide one or more SQL statements in the *SQL* field.
+  Use ``$1``, ``$2``, etc. as parameter placeholders that will be substituted
+  from the *Parameters* collection.
+* If *Kind* is *PROGRAM*, provide the full path and arguments of the program
+  to execute in the *Program* field.
+* If *Kind* is *BUILTIN*, select one of the following internal commands from
+  the *Internal Command* drop-down:
+
+  * *NoOp* - No operation; the task completes immediately.
+  * *Sleep* - Pause execution for a duration specified by a parameter.
+  * *Log* - Write a message to the pgTimeTable log.
+  * *SendMail* - Send an email (requires parameters for recipient, subject,
+    and body).
+  * *Download* - Download a file from a URL.
+  * *CopyFromFile* - Copy data from a file into a database table.
+  * *CopyToFile* - Copy data from a database table to a file.
+  * *Shutdown* - Shut down the pgTimeTable service.
+
+.. image:: images/pgtimetable_task_parameters.png
+    :alt: pgTimeTable task dialog parameters
+    :align: center
+
+Use the *Parameters* sub-collection to define parameter values that will be
+substituted into the task command.  Click the Add icon (+) to add a new
+parameter row:
+
+* Use the *Order* column to specify the parameter position (``$1``, ``$2``,
+  etc.).
+* Use the *Value* column to provide the parameter value.  The value may be a
+  plain string or a JSON value.
+
+Click the compose icon to close the task definition dialog, then click *Save*
+on the chain dialog to save all changes.
+
+Refer to `pg_timetable samples <https://cybertec-postgresql.github.io/pg_timetable/latest/samples/>`_
+for the kind of parameters expected for each type.
+
+
+Both the Chain and Tasks have a statistics tab, which show the results of past runs of tasks.
+
+
+.. image:: images/pgtimetable_task_statistics.png
+    :alt: pgTimeTable task statistics
+    :align: center

docs/en_US/preferences.rst

@@ -589,6 +589,15 @@ Use the fields on the *CSV/TXT Output* panel to control the CSV/TXT output.
   quoted in the CSV/TXT output; select *Strings*, *All*, or *None*.
 * Use the *Replace null values with* option to replace null values with
   specified string in the output file. Default is set to 'NULL'.
+* Use the *Output file encoding* drop-down listbox to specify the character
+  encoding used when saving query results to a file. The default is utf-8; an
+  encoding that is not listed can also be typed in. Any character that the
+  chosen encoding cannot represent is written as a question mark (?).
+* Use the *Add byte order mark (BOM)?* switch to add a byte order mark at the
+  start of the saved file when a UTF encoding is used. This helps applications
+  such as Microsoft Excel detect the encoding correctly. This applies to the
+  CSV/TXT output only. The utf-16, utf-32 and utf-8-sig encodings always
+  include a BOM, whatever this is set to.
 
 .. image:: images/preferences_sql_display.png
     :alt: Preferences sqleditor display options
@@ -635,6 +644,39 @@ a graphical EXPLAIN.
 * When the *Verbose output?* switch is set to *True*, graphical explain details
   will include extended information about the query execution plan.
 
+Use the fields on the *Geometry Viewer* panel to configure a custom map tile
+provider used as a base layer when viewing geometry data.
+
+* Use the *Custom tile provider URL* field to specify the URL template of a
+  custom XYZ tile provider, e.g.
+  ``https://myserver.example.com/tiles/{z}/{x}/{y}.png``. The template must
+  contain the ``{x}``, ``{y}`` and ``{z}`` placeholders, and may contain
+  ``{s}`` for subdomains (a, b, c). Leave the field empty to disable the
+  custom tile provider.
+
+* Use the *Custom tile provider name* field to specify the display name of
+  the custom tile provider in the layer selector of the Geometry Viewer.
+
+* Use the *Custom tile provider CRS* field to specify the coordinate
+  reference system of the custom tile provider. If it is not EPSG:3857
+  (Web Mercator), the built-in tile layers will be hidden as they cannot be
+  mixed with other coordinate systems.
+
+* Use the *Custom tile provider attribution* field to specify the
+  attribution text shown on the map. It may contain HTML links.
+
+* Use the *Custom tile provider max zoom* field to specify the maximum zoom
+  level of the custom tile provider.
+
+When a custom tile provider is configured, it is selected as the default
+base layer of the Geometry Viewer.
+
+An administrator may set a system-wide default for these fields via the
+``DEFAULT_GEOMETRY_VIEWER_PROVIDER`` setting in :ref:`config_py`. It applies
+to any user who has not saved their own values for the fields above; a
+user's own preferences, once saved, always take precedence over the
+system-wide default.
+
 .. image:: images/preferences_graph_visualiser.png
     :alt: Preferences sqleditor graph visualiser section
     :align: center
@@ -721,6 +763,9 @@ preferences for copied data.
   character for copied data.
 * Use the *Result copy quoting* drop-down listbox to select which type of fields
   require quoting; select *All*, *None*, or *Strings*.
+* When the *Copy with headers?* switch is set to true, the column headers are
+  included by default when copying data from the results grid. This can still
+  be toggled per-copy from the results grid copy options menu.
 * When the *Striped rows?* switch is set to true, the result grid will display
   rows with alternating background colors.
 

docs/en_US/query_tool.rst

@@ -243,7 +243,9 @@ iteratively. For example, you can ask for a query and then follow up with
 
 **Note:** The AI Assistant uses database schema inspection tools to understand
 your database structure. It supports SELECT, INSERT, UPDATE, DELETE, and DDL
-statements. All generated queries should be reviewed before execution.
+statements. All generated queries should be reviewed before execution. See
+:ref:`ai_data_handling` for details of the information that is transmitted to
+your configured LLM provider.
 
 The Data Output Panel
 *********************

docs/en_US/query_tool_toolbar.rst

@@ -85,9 +85,7 @@ Query Editing Options
    |                      +---------------------------------------------------------------------------------------------------+-----------------------+
    |                      | Select *Find* to provide a search target, and search the SQL Editor contents.                     | Cmd/Ctrl + F          |
    |                      +---------------------------------------------------------------------------------------------------+-----------------------+
-   |                      | Select *Replace* to locate and replace (with prompting) individual occurrences of the target.     | Option + Cmd + F (MAC)|
-   |                      |                                                                                                   | Ctrl + Shift + F      |
-   |                      |                                                                                                   | (Others)              |
+   |                      | Select *Replace* to locate and replace (with prompting) individual occurrences of the target.     | Cmd/Ctrl + R          |
    |                      +---------------------------------------------------------------------------------------------------+-----------------------+
    |                      | Select *Go to Line/Column* to go to specified line number and column position                     | Cmd/Ctrl + L          |
    |                      +---------------------------------------------------------------------------------------------------+-----------------------+
@@ -212,10 +210,12 @@ Data Editing Options
    | *Save Data Changes*  | Click the *Save Data Changes* icon to save data changes (insert, update, or delete) in the Data   | F6             |
    |                      | Output Panel to the server.                                                                       |                |
    +----------------------+---------------------------------------------------------------------------------------------------+----------------+
-   | *Save results to*    | Click the Save results to file icon to save the result set of the current query as a delimited    | F8             |
-   | *file*               | text file (CSV, if the field separator is set to a comma). This button will only be enabled when  |                |
-   |                      | a query has been executed and there are results in the data grid. You can specify the CSV/TXT     |                |
-   |                      | settings in the Preference Dialogue under SQL Editor -> CSV/TXT output.                           |                |
+   | *Save results to*    | Click the Save results to file icon to save the result set of the current query. By               | F8             |
+   | *file*               | default it is saved as a delimited text file (CSV, if the field separator is set to a             |                |
+   |                      | comma). Use the adjacent drop-down list to instead save the results as JSON or XML.               |                |
+   |                      | This button is only enabled when a query has been executed and there are results in               |                |
+   |                      | the data grid. You can specify the CSV/TXT settings (including the output file encoding           |                |
+   |                      | and byte order mark) in the Preferences dialog under Query Tool -> CSV/TXT Output.                |                |
    +----------------------+---------------------------------------------------------------------------------------------------+----------------+
    | Graph Visualiser     | Use the Graph Visualiser button to generate graphs of the query results.                          |                |
    +----------------------+---------------------------------------------------------------------------------------------------+----------------+

docs/en_US/release_notes.rst

@@ -12,6 +12,10 @@ notes for it.
    :maxdepth: 1
 
 
+   release_notes_9_19
+   release_notes_9_18
+   release_notes_9_17
+   release_notes_9_16
    release_notes_9_15
    release_notes_9_14
    release_notes_9_13

docs/en_US/release_notes_9_16.rst

@@ -0,0 +1,133 @@
+************
+Version 9.16
+************
+
+Release date: 2026-06-18
+
+This release contains a number of bug fixes and new features since the release of pgAdmin 4 v9.15.
+
+.. warning:: Starting with this release, when a server connection is configured
+    with both an external password-exec command and a passfile, pgAdmin now
+    uses the passfile and ignores the password-exec command. Previously the
+    password-exec command took precedence. A warning is written to the log when
+    the password-exec command is ignored in favour of the passfile.
+
+Supported Database Servers
+**************************
+**PostgreSQL**: 14, 15, 16, 17 and 18
+
+**EDB Advanced Server**: 14, 15, 16, 17 and 18
+
+Bundled PostgreSQL Utilities
+****************************
+**psql**, **pg_dump**, **pg_dumpall**, **pg_restore**: 18.4
+
+
+New features
+************
+
+  | `Issue #2431 <https://github.com/pgadmin-org/pgadmin4/issues/2431>`_ -  Added an option to colourize panel and tab headers based on the connected server's colour, making it easier to tell which server a tab is connected to at a glance.
+  | `Issue #7641 <https://github.com/pgadmin-org/pgadmin4/issues/7641>`_ -  Allow the OAuth2 login button icon to use any Font Awesome style (e.g. ``fas fa-key``), not only brand icons.
+  | `Issue #9301 <https://github.com/pgadmin-org/pgadmin4/issues/9301>`_ -  Added a "Back to login" link to the Forgot Password and Reset Password pages.
+  | `Issue #9626 <https://github.com/pgadmin-org/pgadmin4/issues/9626>`_ -  Add support for the TOAST tuple target storage parameter in the Materialized View dialog.
+  | `Issue #9646 <https://github.com/pgadmin-org/pgadmin4/issues/9646>`_ -  Make the init container security context in the Helm chart configurable via containerSecurityContext, consistent with the main container.
+  | `Issue #9699 <https://github.com/pgadmin-org/pgadmin4/issues/9699>`_ -  Add support for closing a tab with a middle-click on its title.
+
+Housekeeping
+************
+
+  | `Issue #9817 <https://github.com/pgadmin-org/pgadmin4/issues/9817>`_ -  Correct the macOS Replace keyboard shortcut documented in the Query Tool toolbar reference.
+  | `Issue #9866 <https://github.com/pgadmin-org/pgadmin4/issues/9866>`_ -  Fix a typo in the PGPASS_FILE environment-variable documentation and clarify its behaviour.
+  | `Issue #9917 <https://github.com/pgadmin-org/pgadmin4/issues/9917>`_ -  Update the Italian translation.
+  | `Issue #9959 <https://github.com/pgadmin-org/pgadmin4/issues/9959>`_ -  Bump Electron in the desktop runtime from 41.5.0 to 42.1.0 and pin the packaged Electron version.
+  | `Issue #9981 <https://github.com/pgadmin-org/pgadmin4/issues/9981>`_ -  Clarify the SSH tunnel "Prompt for identity file password?" switch label and help text to indicate it applies only to identity-file authentication.
+  | `Issue #10014 <https://github.com/pgadmin-org/pgadmin4/issues/10014>`_ -  Document the Kubernetes init-container tag-mismatch and RollingUpdate hazards on shared data volumes.
+  | `Issue #10018 <https://github.com/pgadmin-org/pgadmin4/issues/10018>`_ -  Remove the EDB BigAnimal cloud deployment support.
+  | `Issue #10023 <https://github.com/pgadmin-org/pgadmin4/issues/10023>`_ -  Bump JavaScript and Python third-party dependencies, including cryptography, axios, shell-quote, and assorted dependabot lockfile updates.
+  | `Issue #10049 <https://github.com/pgadmin-org/pgadmin4/issues/10049>`_ -  Bump vulnerable transitive dependencies (tar, flatted) to clear security advisories.
+  | `Issue #10050 <https://github.com/pgadmin-org/pgadmin4/issues/10050>`_ -  Rebase the version-specific SQL templates so the default targets PostgreSQL 14, the oldest supported server version, dropping the obsolete sub-14 template buckets.
+  | `Issue #10063 <https://github.com/pgadmin-org/pgadmin4/issues/10063>`_ -  Strip the foreign-architecture slice from the macOS bundle so single-arch builds no longer ship the universal2 Python framework's unused arm64/x86_64 code.
+  | `Issue #10094 <https://github.com/pgadmin-org/pgadmin4/issues/10094>`_ -  Update the Italian translation for v9.16.
+
+Bug fixes
+*********
+
+  | `Issue #6308 <https://github.com/pgadmin-org/pgadmin4/issues/6308>`_ -  Fix the infinite loading spinner after an idle database connection is silently dropped, by detecting stale connections and offering a reconnect dialog.
+  | `Issue #7346 <https://github.com/pgadmin-org/pgadmin4/issues/7346>`_ -  Fixed an issue where preferences set via the CLI (setup.py set-prefs) were not validated, so invalid values were stored silently; CLI preference values are now validated against the preference type and rejected (and reported) if invalid.
+  | `Issue #7596 <https://github.com/pgadmin-org/pgadmin4/issues/7596>`_ -  Fix the Query Tool turning into a blank white screen when the runtime has a malformed default locale, by guarding the Query History date/time formatting against the resulting RangeError.
+  | `Issue #8318 <https://github.com/pgadmin-org/pgadmin4/issues/8318>`_ -  Fixed an error ("i.default.find(...) is undefined") that prevented deleting a table or relationship link in the ERD tool when a foreign key referenced a column that had been renamed.
+  | `Issue #9060 <https://github.com/pgadmin-org/pgadmin4/issues/9060>`_ -  Fixed an issue in the Create Table dialog where renaming a column did not update the column references in foreign key and unique constraint definitions for the new table.
+  | `Issue #9091 <https://github.com/pgadmin-org/pgadmin4/issues/9091>`_ -  Fix the Query Tool re-prompting for an unsaved password in a loop and rejecting the re-entered password, by caching the entered password on the server manager when the primary connection is already established.
+  | `Issue #9128 <https://github.com/pgadmin-org/pgadmin4/issues/9128>`_ -  Fixed an issue where the object breadcrumbs popup blocked clicks on the object explorer items beneath it.
+  | `Issue #9595 <https://github.com/pgadmin-org/pgadmin4/issues/9595>`_ -  Fix missing ALTER ... SET DEFAULT statements for inherited columns in the generated table SQL/EDIT script.
+  | `Issue #9677 <https://github.com/pgadmin-org/pgadmin4/issues/9677>`_ -  Fix the Unlogged table toggle in table properties not generating any ALTER TABLE ... SET LOGGED/UNLOGGED statement.
+  | `Issue #9701 <https://github.com/pgadmin-org/pgadmin4/issues/9701>`_ -  Ensure pgAdmin uses psycopg3 rather than psycopg2 when connecting to the configuration database via PGADMIN_CONFIG_CONFIG_DATABASE_URI.
+  | `Issue #9744 <https://github.com/pgadmin-org/pgadmin4/issues/9744>`_ -  Fix a View/Edit Data crash when the session contains a transaction object that is not filter-capable (e.g. left by the Query Tool or persisted by an older version), which could prevent the desktop application from loading after an upgrade.
+  | `Issue #9762 <https://github.com/pgadmin-org/pgadmin4/issues/9762>`_ -  Fix the "Cannot read properties of undefined (reading 'map')" crash in the desktop runtime when a menu refresh is triggered before the application menus have been received.
+  | `Issue #9766 <https://github.com/pgadmin-org/pgadmin4/issues/9766>`_ -  Fixed an issue where a server's custom foreground colour was not applied to the object counts (children count) and column type labels shown in the object explorer.
+  | `Issue #9782 <https://github.com/pgadmin-org/pgadmin4/issues/9782>`_ -  Optimise pgAdmin startup time by replacing the fixed server-ping interval with adaptive pinging that backs off when no servers are configured.
+  | `Issue #9806 <https://github.com/pgadmin-org/pgadmin4/issues/9806>`_ -  Fixed an issue where generated font and image filenames contained a double dot (e.g. ``Roboto-Bold..ttf``) due to the webpack asset filename template.
+  | `Issue #9828 <https://github.com/pgadmin-org/pgadmin4/issues/9828>`_ -  Fix tool calls failing against OpenAI-compatible providers that emit empty/null name, arguments, or id fields in streaming continuation deltas.
+  | `Issue #9829 <https://github.com/pgadmin-org/pgadmin4/issues/9829>`_ -  Fixed installation on Python 3.9 (e.g. RHEL/Rocky/AlmaLinux 8 and 9) failing with "No module named 'pkg_resources'" by pinning setuptools below the version that dropped pkg_resources for Python 3.9.
+  | `Issue #9854 <https://github.com/pgadmin-org/pgadmin4/issues/9854>`_ -  Fix the JSON editor stripping trailing fractional zeros (e.g. 10.00) and rewriting large integers in jsonb values, which corrupted unmodified numbers when saving.
+  | `Issue #9864 <https://github.com/pgadmin-org/pgadmin4/issues/9864>`_ -  Fixed a regression where the rectangular (block/column) text selection in the code editor stopped working; restored the default Alt+drag selection without re-introducing the crosshair cursor on Alt+F5 (#9570).
+  | `Issue #9868 <https://github.com/pgadmin-org/pgadmin4/issues/9868>`_ -  Warn before opening a very large JSON/JSONB value in the data grid cell editor, which could freeze pgAdmin, and let the user choose whether to proceed.
+  | `Issue #9875 <https://github.com/pgadmin-org/pgadmin4/issues/9875>`_ -  Fixed an issue where EXPLAIN and EXPLAIN ANALYZE failed to execute when blank lines separated clauses in the SQL query.
+  | `Issue #9810 <https://github.com/pgadmin-org/pgadmin4/issues/9810>`_ -  Use the ServerManager's passfile for the credential gate in connect() so the check matches the passfile actually used for the connection, and warn on conflicting passfile/passexec settings.
+  | `Issue #9892 <https://github.com/pgadmin-org/pgadmin4/issues/9892>`_ -  Fix blank difference counts on the top-level group rows in Schema Diff.
+  | `Issue #9896 <https://github.com/pgadmin-org/pgadmin4/issues/9896>`_ -  Fix invalid DDL reconstruction for SERIAL columns in Schema Diff and the generated SQL/CREATE Script so the output round-trips on a clean target.
+  | `Issue #9933 <https://github.com/pgadmin-org/pgadmin4/issues/9933>`_ -  Remove the administrator-role bypass from the server-access helpers so the access-control checks added in 9.15 (CVE-2026-7813) are enforced uniformly. The Administrator role manages pgAdmin itself, not other users' database connections.
+  | `Issue #9935 <https://github.com/pgadmin-org/pgadmin4/issues/9935>`_ -  Fix "Illegal instruction" crash on startup of the Linux DEB and RPM packages on older x86_64 CPUs by pinning the psycopg C extension build to the x86-64 baseline.
+  | `Issue #9936 <https://github.com/pgadmin-org/pgadmin4/issues/9936>`_ -  Fix the AI panel silently falling back to the default provider when a custom LLM API URL or key file was set, and allow self-hosted LLM endpoints on any loopback port.
+  | `Issue #9939 <https://github.com/pgadmin-org/pgadmin4/issues/9939>`_ -  Fix saving a newly-added row in the Query Tool failing when the result set includes expression or alias columns that are not real columns of the underlying table.
+  | `Issue #9952 <https://github.com/pgadmin-org/pgadmin4/issues/9952>`_ -  Ship libpq-oauth-18.so and libcurl in the Docker image so PostgreSQL 18 OAuth connections work out of the box.
+  | `Issue #9976 <https://github.com/pgadmin-org/pgadmin4/issues/9976>`_ -  Fix a startup migration crash (NoSuchTableError) when an old configuration database contains a stale foreign-key reference.
+  | `Issue #9984 <https://github.com/pgadmin-org/pgadmin4/issues/9984>`_ -  Fix the Docker entrypoint mishandling a quoted PGADMIN_CONFIG_CONFIG_DATABASE_URI, which caused a SQLAlchemy parse error and silently skipped PGADMIN_DEFAULT_EMAIL/PASSWORD setup.
+  | `Issue #9985 <https://github.com/pgadmin-org/pgadmin4/issues/9985>`_ -  Make CAP_NET_BIND_SERVICE optional in the Docker image so the container works on restricted runtimes that disable that capability.
+  | `Issue #9987 <https://github.com/pgadmin-org/pgadmin4/issues/9987>`_ -  Fix "AttributeError: 'PgAdmin' object has no attribute 'login_manager'" crash when running setup.py user-management commands (add-user, update-user) from the CLI.
+  | `Issue #9988 <https://github.com/pgadmin-org/pgadmin4/issues/9988>`_ -  Provide an actionable error when 'openid' is in OAUTH2_SCOPE but OAUTH2_SERVER_METADATA_URL is not set, instead of a cryptic Authlib failure.
+  | `Issue #10013 <https://github.com/pgadmin-org/pgadmin4/issues/10013>`_ -  Fix pg_attribute filtering by attname returning the wrong attnum when the same column name exists in multiple tables.
+  | `Issue #10022 <https://github.com/pgadmin-org/pgadmin4/issues/10022>`_ -  Fix AI Assistant read-only transaction bypass that allowed prompt-injected multi-statement payloads to commit out of the READ ONLY wrapper and execute arbitrary SQL, chaining to RCE via COPY ... TO PROGRAM on a superuser connection (CVE-2026-12045). Reported by Isaac Chen.
+  | `Issue #10026 <https://github.com/pgadmin-org/pgadmin4/issues/10026>`_ -  Fix SQL injection in the named restore point endpoint where the user-supplied restore point name was interpolated into SQL via str.format() instead of being passed as a bound parameter (CVE-2026-12050). Reported by Geo.
+  | `Issue #10027 <https://github.com/pgadmin-org/pgadmin4/issues/10027>`_ -  Fix the spurious "Crypt key is missing" error and logged traceback in the Query Tool new-connection endpoints after a backend restart, by surfacing it as the standard CRYPTKEY_MISSING response so the client recovers transparently.
+  | `Issue #10028 <https://github.com/pgadmin-org/pgadmin4/issues/10028>`_ -  Fix open redirect in the multi-factor authentication flow via an unvalidated 'next' parameter that allowed a crafted link to redirect an authenticated victim to an attacker-controlled host (CVE-2026-12049). Reported by Mai Phạm Hiền.
+  | `Issue #10029 <https://github.com/pgadmin-org/pgadmin4/issues/10029>`_ -  Fixed a regression where the rectangular (block/column) text selection in the code editor stopped working; restored the default Alt+drag selection without re-introducing the crosshair cursor on Alt+F5 (#9570).
+  | `Issue #10030 <https://github.com/pgadmin-org/pgadmin4/issues/10030>`_ -  Accept prepare and binary keyword arguments in DictCursor.execute() so callers using the modern psycopg API no longer raise TypeError.
+  | `Issue #10059 <https://github.com/pgadmin-org/pgadmin4/issues/10059>`_ -  Fix the generated SQL for editing a SQL-language function/procedure whose body contains the word "return" (e.g. a RETURNING clause), which was wrongly treated as a SQL-standard body and produced a statement without the AS $BODY$ wrapper.
+  | `Issue #10068 <https://github.com/pgadmin-org/pgadmin4/issues/10068>`_ -  Fix critical stored cross-site scripting where PostgreSQL server error text and Explain plan-node content passed through html-react-parser across notifier toasts, form errors, modal alerts, and the Explain visualiser. Because pgAdmin's default Content-Security-Policy allows inline script and an iframe ``srcdoc`` inherits the embedding origin, the injected JavaScript ran same-origin to the victim's authenticated pgAdmin session and could read every saved server connection credential and issue arbitrary SQL against every server the victim was connected to (CVE-2026-12048). Reported by Fernando Bortotti.
+  | `Issue #10069 <https://github.com/pgadmin-org/pgadmin4/issues/10069>`_ -  Fix HTML injection in the cloud deployment module (RDS, Azure, Google) where SDK exception text was forwarded to the browser unsanitised and rendered through html-react-parser in the Cloud Wizard (CVE-2026-12047). Reported by Fernando Bortotti.
+  | `Issue #10072 <https://github.com/pgadmin-org/pgadmin4/issues/10072>`_ -  Fix two SQL Editor endpoints (close and update_connection) missing the ``@pga_login_required`` decorator, making them reachable without authentication in server mode and exposing a pickle deserialization sink (CVE-2026-12046). Reported by Fernando Bortotti.
+  | `Issue #10078 <https://github.com/pgadmin-org/pgadmin4/issues/10078>`_ -  Fix SQL injection across sixteen dialog templates that rendered ``COMMENT ON ... IS '<description>'`` and the related ``pgstattuple``/``pgstatindex`` stats sinks, where a low-privilege user could plant a table or index name containing an apostrophe and a superuser viewing statistics on the object would trigger SQL execution under the superuser role. The fix switches the affected templates to the ``qtLiteral`` escape filter and rewrites the ``pgstattuple``/``pgstatindex`` calls to address the relation via OID with a ``::oid::regclass`` cast, eliminating the embedded string-literal call form entirely. Also hardens ``qtLiteral`` to raise instead of silently returning raw values when ``conn`` is falsy (CVE-2026-12044). Reported by Jasser Chebbi.
+
+Additional changes (no associated issue)
+****************************************
+
+Dependencies
+------------
+
+Non-breaking ``dependabot`` updates aggregated for v9.16.
+
+Python:
+
+  | ``certifi`` 2026.4.22 -> 2026.5.20
+  | ``cryptography`` 47.0 -> 49.0
+  | ``Flask-Security-Too`` 5.4 -> 5.6 (``python_version <= '3.9'``)
+  | ``google-auth-oauthlib`` 1.3.1 -> 1.4.0 (``python_version > '3.9'``; Python 3.9 stays on 1.3.1)
+  | ``requests`` >=2.33.1 -> >=2.34.2 (``python_version > '3.9'``)
+  | ``safety`` >=3.7.0 -> >=3.8.1
+  | ``selenium`` 4.43.0 -> 4.44.0
+  | ``testscenarios`` 0.6.1 -> 0.6.2 (``python_version > '3.9'``)
+  | ``typer`` 0.25 -> 0.26 (``python_version > '3.9'``)
+  | ``urllib3`` 2.6 -> 2.7 (``python_version > '3.9'``)
+
+JavaScript (``web/``):
+
+  | ``@tanstack/react-query`` 5.100.5 -> 5.100.9
+  | ``ip-address`` 10.1.0 -> 10.1.1
+  | ``postcss`` 8.5.12 -> 8.5.14
+
+JavaScript (``runtime/``):
+
+  | ``axios`` 1.16.0 -> 1.18.0
+  | ``electron`` 41.5.0 -> 42.3.3
+  | ``eslint`` 10.3.0 -> 10.4.1

docs/en_US/release_notes_9_17.rst

@@ -0,0 +1,119 @@
+************
+Version 9.17
+************
+
+Release date: 2026-07-30
+
+This release contains a number of bug fixes and new features since the release of pgAdmin 4 v9.16.
+
+Supported Database Servers
+**************************
+**PostgreSQL**: 14, 15, 16, 17 and 18
+
+**EDB Advanced Server**: 14, 15, 16, 17 and 18
+
+Bundled PostgreSQL Utilities
+****************************
+**psql**, **pg_dump**, **pg_dumpall**, **pg_restore**: 18.4
+
+
+New features
+************
+
+  | `Issue #9990 <https://github.com/pgadmin-org/pgadmin4/issues/9990>`_ -  Include the authenticated user's identity in the HTTP access log.
+  | `Issue #9942 <https://github.com/pgadmin-org/pgadmin4/issues/9942>`_ -  Add an opt-in Gateway API HTTPRoute template to the Helm chart as an alternative to the existing Ingress.
+  | `Issue #10104 <https://github.com/pgadmin-org/pgadmin4/issues/10104>`_ -  Add a preference to cap the row count fetched by the plain "View Data" action, so it is usable on large tables without always doing a full ``SELECT *``.
+  | `Issue #10142 <https://github.com/pgadmin-org/pgadmin4/issues/10142>`_ -  Add support for a custom XYZ tile provider (URL, name, CRS, attribution, max zoom) in the Geometry Viewer, alongside the existing built-in base layers.
+
+Housekeeping
+************
+
+  | `Issue #10077 <https://github.com/pgadmin-org/pgadmin4/issues/10077>`_ -  Centralize shared-server-group visibility and access-control logic, and adjust the ServerGroup-to-Server/SharedServer model relationships.
+  | `Issue #10093 <https://github.com/pgadmin-org/pgadmin4/issues/10093>`_ -  Add a basic starter contributing guide.
+  | `Issue #10135 <https://github.com/pgadmin-org/pgadmin4/issues/10135>`_ -  Fail the macOS appbundle build if any bundled library links outside the bundle, and scan all Mach-O binaries for bundle linkage rather than only files named ``.so``/``.dylib``.
+  | `Issue #10154 <https://github.com/pgadmin-org/pgadmin4/issues/10154>`_ -  Pin the sonarqube-scan-action GitHub workflow to a full commit SHA instead of a mutable branch ref, to harden against supply-chain tampering.
+  | `Issue #10138 <https://github.com/pgadmin-org/pgadmin4/issues/10138>`_ -  Update the Simplified Chinese (zh_Hans_CN) translation to match the wording used in the interface.
+  | `Issue #10156 <https://github.com/pgadmin-org/pgadmin4/issues/10156>`_ -  Pin the Yarn version used by the build scripts to the ``packageManager`` field, rather than whatever Yarn happens to be on the builder's PATH.
+  | `Issue #10176 <https://github.com/pgadmin-org/pgadmin4/issues/10176>`_ -  Bump JavaScript and Python third-party dependencies, including axios, webpack, react, electron, and certifi.
+
+Bug fixes
+*********
+
+  | `Issue #10053 <https://github.com/pgadmin-org/pgadmin4/issues/10053>`_ -  Warn when OAuth2 provider settings are misplaced at the top level of the config instead of under ``OAUTH2_CONFIG``.
+  | `Issue #10100 <https://github.com/pgadmin-org/pgadmin4/issues/10100>`_ -  Fix Schema Diff's "Generate Script" and the browser tree's CREATE Script view emitting wrong SQL for SERIAL/identity columns, by detecting column-owned sequences via pg_depend instead of guessing the sequence name.
+  | `Issue #10102 <https://github.com/pgadmin-org/pgadmin4/issues/10102>`_ -  Fix a Schema Diff result-status filter chip showing "No difference found" after being toggled off and back on, even when real differences exist.
+  | `Issue #10106 <https://github.com/pgadmin-org/pgadmin4/issues/10106>`_ -  Fix the Object Explorer briefly showing the literal HTML markup instead of a greyed-out "[Disconnecting...]" label when disconnecting a server or database.
+  | `Issue #10107 <https://github.com/pgadmin-org/pgadmin4/issues/10107>`_ -  Detect a selected-but-unusable OS keyring and fall back gracefully instead of failing.
+  | `Issue #10109 <https://github.com/pgadmin-org/pgadmin4/issues/10109>`_ -  Fix ALT+F5 ("Execute query at cursor") doing nothing when the cursor is on or near a statement that is not highlighted, in a Query Tool tab with multiple statements separated by blank lines.
+  | `Issue #10110 <https://github.com/pgadmin-org/pgadmin4/issues/10110>`_ -  Stop the googleapiclient cloud-deployment dependency from pulling in the system oauth2client package.
+  | `Issue #10117 <https://github.com/pgadmin-org/pgadmin4/issues/10117>`_ -  Fix a "'Response' object is not iterable" crash when expanding a Trigger node under a Table to view its trigger function, and report the correct error message on a node.sql failure in that flow.
+  | `Issue #10158 <https://github.com/pgadmin-org/pgadmin4/issues/10158>`_ -  Honor the selected EOL sequence when copying query text to the clipboard.
+  | `Issue #10187 <https://github.com/pgadmin-org/pgadmin4/issues/10187>`_ -  Fix the object browser's extension UI breaking under PostgreSQL 19's extension catalog changes.
+  | `Issue #10190 <https://github.com/pgadmin-org/pgadmin4/issues/10190>`_ -  Fix a tool-permission bypass where a user denied the Query Tool, Grant Wizard, or Schema Diff permission could still drive that tool's backend routes and Socket.IO handlers directly, since the permission check was applied only to a single "front door" route per tool. Also fixes a non-owner triggering an adhoc connection against another user's shared server persisting a new server record still owned by that other user (CVE-2026-17350). Reported by LXY.
+  | `Issue #10191 <https://github.com/pgadmin-org/pgadmin4/issues/10191>`_ -  Fix OS command injection in the MASTER_PASSWORD_HOOK feature, where an externally-sourced username (e.g. via OAuth2/OIDC, Kerberos, or webserver authentication) containing shell metacharacters could execute arbitrary commands as the pgAdmin service account when the configured hook string uses ``%u`` (CVE-2026-17347). Reported by Thiago Pereira.
+  | `Issue #10192 <https://github.com/pgadmin-org/pgadmin4/issues/10192>`_ -  Fix a lexer-differential bypass of the AI Assistant's read-only transaction guard, where sqlparse's string-literal lexing disagreed with PostgreSQL's own parser under ``standard_conforming_strings = on``, letting a crafted multi-statement payload smuggle a COMMIT past the intended read-only wrapper, an incomplete fix for CVE-2026-12045 (CVE-2026-17351). Reported by Kai Aizen.
+  | `Issue #10193 <https://github.com/pgadmin-org/pgadmin4/issues/10193>`_ -  Fix SQL injection in the Index Statistics all-indexes listing and the Publications/Subscriptions Dependencies views, where an apostrophe in a table, index, publication, or subscription name broke out of an unescaped template interpolation, an incomplete fix for CVE-2026-12044 (CVE-2026-17346). Reported by Hung Tran Quoc (@rampage0010).
+  | `Issue #10194 <https://github.com/pgadmin-org/pgadmin4/issues/10194>`_ -  Fix several Constraints, Preferences, Debugger, and Schema Diff routes missing the ``@pga_login_required`` decorator, making them reachable without authentication in server mode, an incomplete fix for CVE-2026-12046 (CVE-2026-17348). Reported by Hung Tran Quoc (@rampage0010).
+  | `Issue #10200 <https://github.com/pgadmin-org/pgadmin4/issues/10200>`_ -  Fix an adhoc server connection cloning another user's stored database credentials (password, save password flag, tunnel password) alongside ownership, letting a non-owner who cloned another user's shared server connect using that user's saved database password (CVE-2026-17349).
+  | `Issue #10213 <https://github.com/pgadmin-org/pgadmin4/issues/10213>`_ -  Fix OS command injection in the Import/Export Data tool, where a query-based export could pass a crafted query string past the ``\copy (...)`` parenthesis-balance guard by exploiting a backslash-escape mismatch with psql's default ``standard_conforming_strings = on`` behaviour, exposing a live ``TO PROGRAM`` clause for arbitrary command execution (CVE-2026-17566). Reported by Arpit Jain.
+
+Additional changes (no associated issue)
+****************************************
+
+Dependencies
+------------
+
+Non-breaking ``dependabot`` and audit-driven bumps aggregated for v9.17.
+
+Python:
+
+  | ``certifi`` 2026.5.20 -> 2026.6.17
+
+JavaScript (``web/``):
+
+  | ``@babel/core`` 7.29.0 -> 7.29.6
+  | ``@date-io/date-fns`` 3.x -> 3.2.1
+  | ``@szhsin/react-menu`` 4.5.1 -> 4.5.2
+  | ``@tanstack/react-query`` 5.100.9 -> 5.101.4
+  | ``@types/react`` 19.2.14 -> 19.2.17
+  | ``ajv`` 8.18.0 -> 8.20.0
+  | ``anti-trojan-source`` 1.8.1 -> 1.12.0
+  | ``autoprefixer`` 10.5.0 -> 10.5.4
+  | ``axios`` 1.16.0 -> 1.18.1
+  | ``core-js`` added as an explicit direct dependency (3.49.0), previously relied on transitively via pickr
+  | ``date-fns`` 4.1.0 -> 4.4.0
+  | ``dompurify`` 3.4.1 -> 3.4.12
+  | ``eslint-plugin-jest`` 29.15.2 -> 29.15.5
+  | ``globals`` 17.5.0 -> 17.7.0
+  | ``hotkeys-js`` 4.0.3 -> 4.0.4
+  | ``html-to-image`` 1.11.11 -> 1.11.13
+  | ``ip-address`` 10.1.1 -> 10.2.0
+  | ``jest`` / ``jest-environment-jsdom`` 30.3.0 -> 30.4.2 / 30.4.1
+  | ``marked`` 18.0.2 -> 18.0.7
+  | ``moment-timezone`` 0.6.2 -> 0.6.3
+  | ``papaparse`` 5.5.3 -> 5.5.4
+  | ``postcss`` 8.5.10/8.5.14 -> 8.5.20
+  | ``react`` / ``react-dom`` 19.2.5 -> 19.2.7
+  | ``react-checkbox-tree`` 2.0.1 -> 2.0.2
+  | ``react-draggable`` 4.5.0 -> 4.7.0
+  | ``react-timer-hook`` 4.0.5 -> 4.0.6
+  | ``sharp`` 0.34.4 -> 0.35.3
+  | ``sql-formatter`` 15.7.3 -> 15.8.2
+  | ``svgo`` 4.0.1 -> 4.0.2
+  | ``terser-webpack-plugin`` 5.5.0 -> 5.6.1
+  | ``typescript-eslint`` 8.59.0 -> 8.65.0
+  | ``webpack`` 5.106.2 -> 5.108.4
+  | ``webpack-bundle-analyzer`` 5.3.0 -> 5.3.1
+  | ``zustand`` 5.0.12 -> 5.0.14
+  | Transitive advisory bumps: ``brace-expansion``, ``form-data``, ``undici``, ``js-yaml``
+  | Reverted ``azure-mgmt-resource`` to avoid a breaking import-path change in ``pgadmin/misc/cloud/azure``
+
+JavaScript (``runtime/``):
+
+  | ``electron`` 42.3.3 -> 43.1.1
+  | ``eslint`` 10.4.1 -> 10.7.0
+  | ``globals`` 17.6.0 -> 17.7.0
+  | ``axios`` 1.18.0 -> 1.18.1
+  | ``ip-address`` 10.1.1 -> 10.2.0
+  | ``postcss`` 8.5.10 -> 8.5.20
+  | Pinned ``packageManager`` to ``yarn@4.15.0``

docs/en_US/release_notes_9_18.rst

@@ -0,0 +1,136 @@
+************
+Version 9.18
+************
+
+Release date: 2026-09-17
+
+This release contains a number of bug fixes and new features since the release of pgAdmin 4 v9.17.
+
+Supported Database Servers
+**************************
+**PostgreSQL**: 14, 15, 16, 17 and 18
+
+**EDB Advanced Server**: 14, 15, 16, 17 and 18
+
+Bundled PostgreSQL Utilities
+****************************
+**psql**, **pg_dump**, **pg_dumpall**, **pg_restore**: 18.4
+
+
+New features
+************
+
+  | `Issue #9631 <https://github.com/pgadmin-org/pgadmin4/issues/9631>`_ -  Collapse and restore the Object Explorer by re-clicking the current workspace icon, in the manner of the VS Code side bar, remembering the choice across refreshes. A keyboard shortcut, Ctrl+Alt+B by default, does the same thing and can be changed through the new ``toggle_object_explorer`` preference.
+
+Housekeeping
+************
+
+  | `Issue #10221 <https://github.com/pgadmin-org/pgadmin4/issues/10221>`_ -  Skip importing and initialising the kerberos, ldap, mfa, oauth2 and webserver authentication providers unless ``SERVER_MODE`` is set, leaving desktop mode with internal authentication alone.
+  | `Issue #10247 <https://github.com/pgadmin-org/pgadmin4/issues/10247>`_ -  Relax the ``azure-mgmt-resource`` pin to allow 24.0.0, and aggregate the third-party JavaScript and Python dependency bumps for this release.
+  | `Issue #10293 <https://github.com/pgadmin-org/pgadmin4/issues/10293>`_ -  Make the Schema Diff regression test assert its own generated script, which it previously swallowed, so invalid generated SQL can no longer pass silently.
+
+Bug fixes
+*********
+
+  | `Issue #9226 <https://github.com/pgadmin-org/pgadmin4/issues/9226>`_ -  Accept ``SharedUsername`` when importing a shared server from a servers.json definition, instead of insisting on ``Username`` for every server.
+  | `Issue #10155 <https://github.com/pgadmin-org/pgadmin4/issues/10155>`_ -  Share concurrent identical GET requests behind ``getNodeAjaxOptions()`` so a wide table's Columns tab no longer fires one duplicate ``get_types`` request per column row.
+  | `Issue #10179 <https://github.com/pgadmin-org/pgadmin4/issues/10179>`_ -  Fix inherited columns in the Table dialog being editable and deletable: a column already inherited from a parent carries ``inheritedfromtable`` while one fetched interactively through 'Inherited from table(s)' carries ``inheritedfrom`` and has no ``attnum`` yet, and only the latter was checked, after an ``isNew()`` short-circuit that treated the attnum-less rows as new.
+  | `Issue #10180 <https://github.com/pgadmin-org/pgadmin4/issues/10180>`_ -  Fix the Data type dropdown on the expanded Definition tab of the Table dialog offering every type, ignoring the allowed-type restriction already applied to the inline editor.
+  | `Issue #10214 <https://github.com/pgadmin-org/pgadmin4/issues/10214>`_ -  Fix the ``existingSecret`` path in the Helm deployment template.
+  | `Issue #10235 <https://github.com/pgadmin-org/pgadmin4/issues/10235>`_ -  Remove a trailing quote from the Windows installer's ``ProductVersion``, which was stamped as e.g. ``9.17"``.
+  | `Issue #10236 <https://github.com/pgadmin-org/pgadmin4/issues/10236>`_ -  Fix Schema Diff reporting false differences for SERIAL/BIGSERIAL columns by ignoring the owned sequence's oid, and fix the invalid ``ALTER COLUMN ... TYPE bigserial`` SQL generated when such a column genuinely differs.
+  | `Issue #10237 <https://github.com/pgadmin-org/pgadmin4/issues/10237>`_ -  Fix a ``replace() argument 2 must be str, not None`` crash when a per-server Password Exec Command is used with a service-only (pg_service.conf) connection, which leaves host, port and username unset.
+  | `Issue #10239 <https://github.com/pgadmin-org/pgadmin4/issues/10239>`_ -  Remove a redundant ``passlib`` pin that conflicts with the indirectly required ``libpass``.
+  | `Issue #10252 <https://github.com/pgadmin-org/pgadmin4/issues/10252>`_ -  Fix the argument grid on the Definition tab of a user-defined function or procedure refusing to delete, or add, a row in edit mode.
+  | `Issue #10295 <https://github.com/pgadmin-org/pgadmin4/issues/10295>`_ -  Reinstate dependency ordering of the script Schema Diff generates, which had been lost since the React port left ``dependLevel`` unset.
+  | `Issue #10297 <https://github.com/pgadmin-org/pgadmin4/issues/10297>`_ -  Fix Schema Diff duplicating any column that also differs when it recreates a foreign table.
+  | `Issue #10298 <https://github.com/pgadmin-org/pgadmin4/issues/10298>`_ -  Fix Schema Diff generating SQL that PostgreSQL rejects when a sequence's MINVALUE is raised above its current value.
+  | `Issue #10300 <https://github.com/pgadmin-org/pgadmin4/issues/10300>`_ -  Fix a foreign table column added by Schema Diff losing its collation.
+  | `Issue #10302 <https://github.com/pgadmin-org/pgadmin4/issues/10302>`_ -  Fix Schema Diff injecting whitespace into an applied function or procedure body, which left a whitespace-only difference behind.
+  | `Issue #10303 <https://github.com/pgadmin-org/pgadmin4/issues/10303>`_ -  Report a Schema Diff comparison that fails part way through as a failure, rather than as a success.
+  | `Issue #10309 <https://github.com/pgadmin-org/pgadmin4/issues/10309>`_ -  Reject an empty or null ``Username`` when importing a non-shared server, which previously imported cleanly and left a server libpq would silently authenticate as the OS account running pgAdmin.
+  | `Issue #10311 <https://github.com/pgadmin-org/pgadmin4/issues/10311>`_ -  Fix login being impossible against Flask-Security-Too 5.8.2, which corrected a long-standing inversion in ``UserMixin.is_locked()`` that ``User.is_locked()`` had been written against.
+  | `Issue #10341 <https://github.com/pgadmin-org/pgadmin4/issues/10341>`_ -  Omit the redundant ``TABLESPACE pg_default`` clause from generated index SQL, which was invalid on a partitioned table.
+  | `Issue #10383 <https://github.com/pgadmin-org/pgadmin4/issues/10383>`_ -  Fix an authentication bypass in Webserver authentication mode, where ``get_user()`` fell back to reading the configured ``WEBSERVER_REMOTE_USER`` name from the request headers when it was absent from the WSGI environment, letting any client that could reach pgAdmin assert any identity, including an administrator's (CVE-2026-86863). Header-asserted identity is now opt-in, restricted to a configured list of trusted proxies with an optional shared secret, and refused for accounts whose authentication source is not ``webserver``. Reported by Sanghyeon Lee (@h9e0n).
+  | `Issue #10384 <https://github.com/pgadmin-org/pgadmin4/issues/10384>`_ -  Fix argument and connection-string injection in the Backup tool, where the client-supplied database name was appended to the pg_dump argument vector as a bare positional argument: because getopt_long permutes arguments, a value beginning with a dash supplied further options such as ``--file``, overriding the storage-confined output path, and because libpq expands a database name containing an equals sign into a full connection string, one could also redirect the connection to an attacker-controlled host and exfiltrate the stored password (CVE-2026-86864). The database name is now passed through the ``PGDATABASE`` environment variable instead. Reported by Sanghyeon Lee (@h9e0n) and Hitesh Jambhale.
+  | `Issue #10385 <https://github.com/pgadmin-org/pgadmin4/issues/10385>`_ -  Fix a time-of-check to time-of-use flaw in the File Manager's ``save_file`` endpoint, which backs saving from the Query Tool and ERD: the requested path was validated with ``check_access_permission()`` and then opened with a plain ``open()``, so a symbolic link planted in between was followed, writing outside the storage directory. This is the sink CVE-2026-7819's hardening of the separate upload path did not cover (CVE-2026-86861). Reported by sec-rex.
+  | `Issue #10388 <https://github.com/pgadmin-org/pgadmin4/issues/10388>`_ -  Fix connection-string injection in the Restore and Maintenance tools, where the client-supplied database name was passed straight to ``--dbname``: libpq expands a database name containing an equals sign into a full connection string, whose embedded keywords override the ``--host`` and ``--port`` pgAdmin supplies, so the connection - and the stored password exported in ``PGPASSWORD`` - could be redirected to a server of the caller's choosing (CVE-2026-86862). The database name is now passed through the ``PGDATABASE`` environment variable, which libpq never expands. Found by Hitesh Jambhale.
+  | `Issue #10393 <https://github.com/pgadmin-org/pgadmin4/issues/10393>`_ -  Render the Validate binary path dialog as HTML, instead of showing the raw markup.
+  | `Issue #10420 <https://github.com/pgadmin-org/pgadmin4/issues/10420>`_ -  Refuse HTTP redirects on LLM API requests, rather than following a ``Location`` header on to a destination ``ALLOWED_LLM_API_URLS`` was never applied to. This is hardening rather than a fix for an exploitable flaw, since returning the redirect at all requires control of a host already on the allowlist. Reported by Ziya Abdullayev.
+
+Dependencies
+************
+
+Non-breaking ``dependabot`` and audit-driven bumps aggregated for v9.18.
+
+Python:
+
+  | ``Authlib`` 1.7.* -> 1.8.*
+  | ``azure-mgmt-resource`` ==25.0.0 -> >=24.0.0,<26.0.0
+  | ``certifi`` 2026.6.17 -> 2026.7.22
+  | ``cryptography`` 49.0.* -> 50.0.*
+  | ``Flask-Security-Too`` 5.8.* -> >=5.8.2,<5.9
+  | ``google-auth-oauthlib`` 1.4.0 -> 1.4.1
+  | ``gssapi`` 1.11.* -> 1.12.*
+  | ``passlib`` 1.* pin removed (redundant, and conflicting with ``libpass``)
+  | ``psycopg[c]`` 3.3.4 -> 3.3.5
+  | ``selenium`` (``web/regression``) 4.45.0 -> 4.48.0
+  | ``setuptools`` 83.* -> 84.*
+  | ``testscenarios`` (``web/regression``) 0.6.2 -> 0.7.0
+  | ``typer`` 0.26.* -> 0.27.*
+  | Skipped: ``paramiko`` 3 -> 5 (blocked on ``sshtunnel``'s ``paramiko.DSSKey`` usage) and ``azure-mgmt-resource`` 26.0.0 (drops Python 3.9 support)
+
+JavaScript (``web/``):
+
+  | ``@babel/*`` toolchain (core, eslint-parser, eslint-plugin, plugin-syntax-jsx, plugin-transform-class-properties, plugin-transform-object-rest-spread, plugin-transform-runtime, preset-env, preset-react, preset-typescript) -> 7.29.7
+  | ``@mui/icons-material`` / ``@mui/material`` 7.3.10 -> 7.3.11
+  | ``@mui/x-date-pickers`` 8.28.3 -> 8.29.3
+  | ``@tanstack/react-query`` 5.101.4 -> 5.102.8
+  | ``@tanstack/react-virtual`` 3.13.24 -> 3.14.10
+  | ``@testing-library/jest-dom`` 6.9.1 -> 6.10.0
+  | ``@testing-library/react`` 16.3.2 -> 16.3.3
+  | ``@testing-library/user-event`` 14.6.1 -> 14.6.3
+  | ``@types/react`` 19.2.17 -> 19.2.18
+  | ``@types/react-dom`` 19.2.3 -> 19.2.5
+  | ``anti-trojan-source`` 1.12.0 -> 1.12.2
+  | ``axios`` 1.18.1 -> 1.20.0
+  | ``codemirror`` 6.0.2 -> 6.65.7
+  | ``core-js`` 3.49.0 -> 3.50.0
+  | ``css-loader`` 7.1.4 -> 7.1.5
+  | ``diff-arrays-of-objects`` 1.1.10 -> 1.1.11
+  | ``dompurify`` 3.4.12 -> 3.4.14
+  | ``eslint`` 9.39.4 -> 9.39.5
+  | ``eslint-plugin-jest`` 29.15.5 -> 29.16.6
+  | ``globals`` 17.7.0 -> 17.12.0
+  | ``hotkeys-js`` 4.0.4 -> 4.0.7
+  | ``image-minimizer-webpack-plugin`` 4.1.4 -> 5.0.0
+  | ``ip-address`` 10.2.0 -> 10.7.0
+  | ``jest`` / ``jest-environment-jsdom`` 30.4.2 / 30.4.1 -> 30.5.1
+  | ``lossless-json`` 4.3.0 -> 4.3.1
+  | ``marked`` 18.0.7 -> 18.0.11
+  | ``papaparse`` 5.5.4 -> 5.7.0
+  | ``postcss`` 8.5.20 -> 8.5.26
+  | ``rc-dock`` 4.0.0-alpha.2 -> 4.0.0-alpha.3
+  | ``react`` / ``react-dom`` 19.2.7 -> 19.2.8
+  | ``react-arborist`` 3.5.0 -> 3.16.0
+  | ``react-draggable`` 4.7.0 -> 4.7.1
+  | ``sharp`` 0.35.3 -> 0.35.4
+  | ``svgo`` 4.0.2 -> 4.1.0
+  | ``svgo-loader`` 4.0.0 -> 5.0.0
+  | ``typescript-eslint`` 8.65.0 -> 8.69.0
+  | ``use-resize-observer`` 9.1.0 -> 10.0.0
+  | ``vanilla-jsoneditor`` 3.12.0 -> 3.13.0
+  | ``webpack-bundle-analyzer`` 5.3.1 -> 5.3.2
+  | ``zustand`` 5.0.14 -> 5.0.15
+  | Transitive advisory bumps: ``brace-expansion``, ``fast-uri``, ``js-yaml``, ``shell-quote``, ``socket.io-parser``, ``tar``
+  | Held back: ``@simonwep/pickr`` 1.10.x (webpack production-bundle interop break), Babel 8, and ``webpack`` 5.110.3 (npm-quarantined at bump time)
+
+JavaScript (``runtime/``):
+
+  | ``axios`` 1.18.1 -> 1.19.0
+  | ``electron`` 43.1.1 -> 43.4.0
+  | ``eslint`` 10.7.0 -> 10.8.1
+  | ``globals`` 17.7.0 -> 17.11.0
+  | ``ip-address`` 10.2.0 -> 10.3.1
+  | ``postcss`` 8.5.20 -> 8.5.23
+  | Transitive advisory bumps: ``brace-expansion``, ``fast-uri``, ``undici``

docs/en_US/release_notes_9_19.rst

@@ -0,0 +1,196 @@
+************
+Version 9.19
+************
+
+Release date: 2026-10-29
+
+This release contains a number of bug fixes and new features since the release of pgAdmin 4 v9.18.
+
+.. warning:: In server mode, free-text Password Exec Commands are no longer
+    run, and ``ENABLE_SERVER_PASS_EXEC_CMD`` is deprecated and ignored.
+    Administrators now define the permitted commands by name in
+    ``SERVER_PASSEXEC_COMMANDS``, and users choose one of those names in the
+    server properties. Configure ``SERVER_PASSEXEC_COMMANDS`` **before** the
+    first start after upgrading: on that start, each existing command that
+    exactly matches a configured entry is converted to its name, and every
+    other command is cleared, which cannot be undone. If the setting is empty,
+    the conversion is postponed and a warning is logged at each start. See
+    ``config.py`` and the server dialog documentation for details.
+
+.. note:: Users who do not own a shared server never inherit the owner's
+    password file; it is treated like the owner's password, SSH key and SSL
+    client files. Each user can set their own password file on their copy of
+    the server, and a file that everyone should use can be placed in a
+    ``SHARED_STORAGE`` directory and referenced as ``Name:/.pgpass``.
+
+.. note:: In desktop mode, when an SSH tunnel is configured with an identity
+    file or a password, pgAdmin no longer also offers keys from the SSH agent;
+    the agent is still used when neither is configured. In server mode, SSH
+    tunnels never use the SSH agent, or the keys and configuration in the
+    ``~/.ssh`` directory of the account pgAdmin runs as, so a tunnel that
+    relied on them must be given an identity file or password on the server.
+
+.. note:: On Python 3.10 and later, pgAdmin now requires Flask-Security-Too
+    5.8.3 or later, which fixes an open redirect (GHSA-ccgp-pv8r-95wm). This
+    matters to anyone installing pgAdmin from the Python wheel into an
+    existing environment. Python 3.9 installations remain on the
+    Flask-Security-Too 5.6 series.
+
+Supported Database Servers
+**************************
+**PostgreSQL**: 14, 15, 16, 17 and 18
+
+**EDB Advanced Server**: 14, 15, 16, 17 and 18
+
+Bundled PostgreSQL Utilities
+****************************
+**psql**, **pg_dump**, **pg_dumpall**, **pg_restore**: 18.6
+
+
+New features
+************
+
+  | `Issue #2018 <https://github.com/pgadmin-org/pgadmin4/issues/2018>`_ -  Add a Statistics node for creating and managing extended statistics.
+  | `Issue #2363 <https://github.com/pgadmin-org/pgadmin4/issues/2363>`_ -  Allow data to be edited through simple auto-updatable views in View/Edit Data.
+  | `Issue #3205 <https://github.com/pgadmin-org/pgadmin4/issues/3205>`_ -  Allow Query Tool results to be saved as JSON or XML, as well as CSV.
+  | `Issue #3834 <https://github.com/pgadmin-org/pgadmin4/issues/3834>`_ -  Add a keyboard shortcut to duplicate the current line or selection in the SQL editor.
+  | `Issue #4128 <https://github.com/pgadmin-org/pgadmin4/issues/4128>`_ -  Allow the encoding of Query Tool result files to be chosen.
+  | `Issue #4129 <https://github.com/pgadmin-org/pgadmin4/issues/4129>`_ -  Add a 'copy with headers' option for Query Tool results.
+  | `Issue #5691 <https://github.com/pgadmin-org/pgadmin4/issues/5691>`_ -  Close dialogs with the Escape key.
+  | `Issue #6695 <https://github.com/pgadmin-org/pgadmin4/issues/6695>`_ -  Allow a byte order mark to be added to Query Tool result files.
+  | `Issue #7167 <https://github.com/pgadmin-org/pgadmin4/issues/7167>`_ -  Allow dialogs such as Sort/Filter to be saved and closed with the Enter key.
+  | `Issue #8647 <https://github.com/pgadmin-org/pgadmin4/issues/8647>`_ -  Allow shift + click to extend the cell range selection in the Query Tool results grid.
+  | `Issue #9057 <https://github.com/pgadmin-org/pgadmin4/issues/9057>`_ -  Support UNLOGGED partitioned tables correctly, which PostgreSQL 18 no longer allows to be created or altered.
+  | `Issue #9064 <https://github.com/pgadmin-org/pgadmin4/issues/9064>`_ -  Add the PostgreSQL 18 pg_dump options to the Backup and Backup Server dialogs.
+  | `Issue #9066 <https://github.com/pgadmin-org/pgadmin4/issues/9066>`_ -  Add the PostgreSQL 18 pg_restore options to the Restore dialog.
+  | `Issue #9212 <https://github.com/pgadmin-org/pgadmin4/issues/9212>`_ -  Show fill factor, TOAST tuple target and parallel workers in the table Properties panel.
+  | `Issue #9264 <https://github.com/pgadmin-org/pgadmin4/issues/9264>`_ -  Move the 'Returns a set?' option to the Definition tab in the Function dialog.
+  | `Issue #9704 <https://github.com/pgadmin-org/pgadmin4/issues/9704>`_ -  Allow an OAuth2 claim to restrict which shared servers a user can see, configured through ``OAUTH2_SERVER_GROUP_CLAIM`` and ``OAUTH2_SERVER_GROUP_CLAIM_MAPPING``.
+  | `Issue #9975 <https://github.com/pgadmin-org/pgadmin4/issues/9975>`_ -  Allow the login page to be skipped when OAuth2 is the only authentication source, using ``OAUTH2_AUTO_LOGIN`` and ``OAUTH2_LOGOUT_URL``.
+  | `Issue #10148 <https://github.com/pgadmin-org/pgadmin4/issues/10148>`_ -  Add support for managing pg_timetable chains and tasks.
+  | `Issue #10249 <https://github.com/pgadmin-org/pgadmin4/issues/10249>`_ -  Replace free-text Password Exec Commands in server mode with an administrator-defined allowlist, ``SERVER_PASSEXEC_COMMANDS``. Commands run without a shell, with a reduced environment, and receive the pgAdmin user's identity in ``PGADMIN_PASSEXEC_*`` variables; users of a shared server inherit the owner's command by default.
+  | `Issue #10473 <https://github.com/pgadmin-org/pgadmin4/issues/10473>`_ -  Add a macOS 26 layered app icon with dark, clear and tinted variants.
+  | `Issue #10499 <https://github.com/pgadmin-org/pgadmin4/issues/10499>`_ -  Add pgEdge Starfleet to the Deploy Cloud Instance wizard, for creating Starfleet Managed databases.
+  | `Issue #10503 <https://github.com/pgadmin-org/pgadmin4/issues/10503>`_ -  Add numpad zoom shortcuts to the Desktop View menu.
+
+Housekeeping
+************
+
+  | `Issue #5369 <https://github.com/pgadmin-org/pgadmin4/issues/5369>`_ -  Clarify the configuration files documentation.
+  | `Issue #9230 <https://github.com/pgadmin-org/pgadmin4/issues/9230>`_ -  Rename the server 'Change Password' option to 'Change Server Password', and the user menu option to 'Change pgAdmin Password', so the two can no longer be confused.
+  | `Issue #9331 <https://github.com/pgadmin-org/pgadmin4/issues/9331>`_ -  Remove unused Google API documents, Babel locale data and packaging tools from the packages.
+  | `Issue #9524 <https://github.com/pgadmin-org/pgadmin4/issues/9524>`_ -  Document running the container with rootless Podman, and the ``PUID`` and ``PGID`` environment variables.
+  | `Issue #10363 <https://github.com/pgadmin-org/pgadmin4/issues/10363>`_ -  Enforce ``--immutable`` on every yarn install, in CI and the release builds, to harden the supply chain.
+  | `Issue #10546 <https://github.com/pgadmin-org/pgadmin4/issues/10546>`_ -  Fix the flaky ``test_windows_pty_failures`` test counting psql output from other tests.
+  | `Issue #10552 <https://github.com/pgadmin-org/pgadmin4/issues/10552>`_ -  Add a test for Reset discarding pending SQL editor values in dialogs.
+  | `Issue #10553 <https://github.com/pgadmin-org/pgadmin4/issues/10553>`_ -  Make the server tests restore the shared test fixture after themselves.
+  | `Issue #10601 <https://github.com/pgadmin-org/pgadmin4/issues/10601>`_ -  Remove the dead tree ``loadfail`` handler from ``browser.js``.
+  | `Issue #10602 <https://github.com/pgadmin-org/pgadmin4/issues/10602>`_ -  Fix the Jest ``addNewDatagridRow`` helper so schema UI specs actually add a row.
+
+Bug fixes
+*********
+
+  | `Issue #5940 <https://github.com/pgadmin-org/pgadmin4/issues/5940>`_ -  Fix View/Edit Data failing on SQL_ASCII databases when a name contains a backslash followed by 'u' or 'U'.
+  | `Issue #6090 <https://github.com/pgadmin-org/pgadmin4/issues/6090>`_ -  Refresh a stale server connection manager when a server id is reused, so one user's session can no longer pick up settings from another server.
+  | `Issue #6231 <https://github.com/pgadmin-org/pgadmin4/issues/6231>`_ -  Generate a single GRANT statement for roles with identical privileges.
+  | `Issue #6481 <https://github.com/pgadmin-org/pgadmin4/issues/6481>`_ -  Fix index and constraint columns not being shown when their names require quoting.
+  | `Issue #6652 <https://github.com/pgadmin-org/pgadmin4/issues/6652>`_ -  Fix Schema Diff treating functions that differ only in OUT arguments or return type as unrelated objects.
+  | `Issue #6671 <https://github.com/pgadmin-org/pgadmin4/issues/6671>`_ -  Allow the emailed MFA code to be re-entered after an invalid code is entered.
+  | `Issue #7232 <https://github.com/pgadmin-org/pgadmin4/issues/7232>`_ -  Fix the tab switching shortcuts not working whilst focus is inside the PSQL, Query, ERD or Schema Diff tools.
+  | `Issue #7612 <https://github.com/pgadmin-org/pgadmin4/issues/7612>`_ -  Fix the server context menu showing database options after the tree state is restored.
+  | `Issue #7619 <https://github.com/pgadmin-org/pgadmin4/issues/7619>`_ -  Fix Query Tool autocomplete running as the wrong user, or failing, after changing the connection to a different user.
+  | `Issue #8015 <https://github.com/pgadmin-org/pgadmin4/issues/8015>`_ -  Re-sort renamed server groups and other nodes in the Object Explorer instead of waiting for a reload.
+  | `Issue #8144 <https://github.com/pgadmin-org/pgadmin4/issues/8144>`_ -  Connect the server when changing the Query Tool connection after it was disconnected.
+  | `Issue #8529 <https://github.com/pgadmin-org/pgadmin4/issues/8529>`_ -  Rewrite the container entrypoint using bash features, and pass values to the embedded Python safely, so an email address containing an apostrophe works and a validation error stops the container rather than passing silently.
+  | `Issue #8664 <https://github.com/pgadmin-org/pgadmin4/issues/8664>`_ -  Fix debugger messages from successive steps running together on one line.
+  | `Issue #8991 <https://github.com/pgadmin-org/pgadmin4/issues/8991>`_ -  Fix BEGIN, COMMIT and ROLLBACK silently failing in the Query Tool under server cursor mode.
+  | `Issue #9130 <https://github.com/pgadmin-org/pgadmin4/issues/9130>`_ -  Select the adjacent tab when the active tab is closed, rather than the left-most.
+  | `Issue #9450 <https://github.com/pgadmin-org/pgadmin4/issues/9450>`_ -  Allow roles holding ADMIN OPTION to manage Group Role membership.
+  | `Issue #9603 <https://github.com/pgadmin-org/pgadmin4/issues/9603>`_ -  Restore the per-tab toolbar options when Query Tool tabs are restored on relaunch.
+  | `Issue #9624 <https://github.com/pgadmin-org/pgadmin4/issues/9624>`_ -  Fix a database's label staying at '[Disconnecting...]' when disconnecting it fails.
+  | `Issue #9630 <https://github.com/pgadmin-org/pgadmin4/issues/9630>`_ -  Fix the parameter value dropdown keeping stale options when the parameter name is changed.
+  | `Issue #9672 <https://github.com/pgadmin-org/pgadmin4/issues/9672>`_ -  Fix View/Edit Data not handling generated columns properly.
+  | `Issue #9784 <https://github.com/pgadmin-org/pgadmin4/issues/9784>`_ -  Fix modal dialogs losing keyboard focus to a tool iframe loading in the background.
+  | `Issue #9798 <https://github.com/pgadmin-org/pgadmin4/issues/9798>`_ -  Fix the collation and ctype query error for databases with a non-default LC_COLLATE.
+  | `Issue #9814 <https://github.com/pgadmin-org/pgadmin4/issues/9814>`_ -  Disable the SSH agent when an SSH tunnel identity file or password is provided.
+  | `Issue #9818 <https://github.com/pgadmin-org/pgadmin4/issues/9818>`_ -  Keep the AI Assistant's intermediate responses instead of replacing them with placeholder messages.
+  | `Issue #9836 <https://github.com/pgadmin-org/pgadmin4/issues/9836>`_ -  Fix the CREATE TABLE script ignoring the UNLOGGED attribute of a partition.
+  | `Issue #9838 <https://github.com/pgadmin-org/pgadmin4/issues/9838>`_ -  Fix formatting a view's SQL being treated as a column change that drops and re-creates the view.
+  | `Issue #9865 <https://github.com/pgadmin-org/pgadmin4/issues/9865>`_ -  Fix modal dialogs being hidden from assistive technology by ``aria-hidden`` on the application root.
+  | `Issue #9890 <https://github.com/pgadmin-org/pgadmin4/issues/9890>`_ -  Fix ERD tables becoming immovable after a Shift-drag selection.
+  | `Issue #9921 <https://github.com/pgadmin-org/pgadmin4/issues/9921>`_ -  Fix Azure and Google authentication in the cloud deployment wizard.
+  | `Issue #9984 <https://github.com/pgadmin-org/pgadmin4/issues/9984>`_ -  Report an unreachable external configuration database, or a malformed ``CONFIG_DATABASE_URI``, as a failed check rather than an unhandled exception.
+  | `Issue #10031 <https://github.com/pgadmin-org/pgadmin4/issues/10031>`_ -  Fix Query Tool tabs running their query automatically after a session restore.
+  | `Issue #10103 <https://github.com/pgadmin-org/pgadmin4/issues/10103>`_ -  Exclude non-editable alias and expression columns when saving edited rows in the Query Tool.
+  | `Issue #10136 <https://github.com/pgadmin-org/pgadmin4/issues/10136>`_ -  Restore tags for standard users on shared servers, and never inherit the owner's password file.
+  | `Issue #10143 <https://github.com/pgadmin-org/pgadmin4/issues/10143>`_ -  Fix switching back to a dialog tab containing a data grid being slow, by skipping virtualisation for small grids.
+  | `Issue #10226 <https://github.com/pgadmin-org/pgadmin4/issues/10226>`_ -  Restore remembering the last visited directory in the desktop file dialogs.
+  | `Issue #10251 <https://github.com/pgadmin-org/pgadmin4/issues/10251>`_ -  Fix invalid SQL from the Maintenance dialog for REINDEX ... CONCURRENTLY.
+  | `Issue #10254 <https://github.com/pgadmin-org/pgadmin4/issues/10254>`_ -  Fix the Object Explorer shortcut not moving keyboard focus into the tree.
+  | `Issue #10273 <https://github.com/pgadmin-org/pgadmin4/issues/10273>`_ -  Fix the dashboard transactions per second graph being wrong for refresh rates other than one second.
+  | `Issue #10292 <https://github.com/pgadmin-org/pgadmin4/issues/10292>`_ -  Fix Schema Diff scripts that convert a column to or from SERIAL.
+  | `Issue #10301 <https://github.com/pgadmin-org/pgadmin4/issues/10301>`_ -  Drop the scaffolding default partition after Schema Diff rebuilds a partitioned table.
+  | `Issue #10310 <https://github.com/pgadmin-org/pgadmin4/issues/10310>`_ -  Fix the Statistics node failing to list its children in Object Explorer.
+  | `Issue #10334 <https://github.com/pgadmin-org/pgadmin4/issues/10334>`_ -  Add Caddy reverse proxy configuration examples to the documentation.
+  | `Issue #10347 <https://github.com/pgadmin-org/pgadmin4/issues/10347>`_ -  Fix the selected UI language not persisting beyond the request that set it in server mode.
+  | `Issue #10348 <https://github.com/pgadmin-org/pgadmin4/issues/10348>`_ -  Fix OpenAI streaming tool calls being split into two entries in the AI Assistant.
+  | `Issue #10349 <https://github.com/pgadmin-org/pgadmin4/issues/10349>`_ -  Fix the OAuth2 userinfo request crashing when ``OAUTH2_USERINFO_ENDPOINT`` is set to None.
+  | `Issue #10350 <https://github.com/pgadmin-org/pgadmin4/issues/10350>`_ -  Fix the MAINTAIN privilege being silently dropped for views and materialised views on PostgreSQL 17 and later.
+  | `Issue #10357 <https://github.com/pgadmin-org/pgadmin4/issues/10357>`_ -  Fix the cursor jumping to the start of SQL fields in dialogs when keys are pressed together.
+  | `Issue #10364 <https://github.com/pgadmin-org/pgadmin4/issues/10364>`_ -  Explain Docker Compose quoting for ``PGADMIN_CONFIG_*`` values in the container documentation.
+  | `Issue #10386 <https://github.com/pgadmin-org/pgadmin4/issues/10386>`_ -  Stop the Query Tool spinner, and its idle CPU use, whilst a password prompt is open.
+  | `Issue #10401 <https://github.com/pgadmin-org/pgadmin4/issues/10401>`_ -  Show default privileges in the Database properties panel.
+  | `Issue #10409 <https://github.com/pgadmin-org/pgadmin4/issues/10409>`_ -  Include the authenticated user in the access log on logout.
+  | `Issue #10414 <https://github.com/pgadmin-org/pgadmin4/issues/10414>`_ -  Fix the Linux packages shipping a stray copy of Python as ``venv/bin/python``, which stopped the DEB package installing on Ubuntu 26.04.
+  | `Issue #10415 <https://github.com/pgadmin-org/pgadmin4/issues/10415>`_ -  Prefer the user's email address as the Gravatar identifier.
+  | `Issue #10418 <https://github.com/pgadmin-org/pgadmin4/issues/10418>`_ -  Remove the dead ``usr`` parameter from Query Tool connection URLs.
+  | `Issue #10419 <https://github.com/pgadmin-org/pgadmin4/issues/10419>`_ -  Fix Kerberos login failures returning a JSON 500 response, and first-time automatically created Kerberos logins being rejected.
+  | `Issue #10422 <https://github.com/pgadmin-org/pgadmin4/issues/10422>`_ -  Fix Schema Diff repeating unchanged column comments and identity options.
+  | `Issue #10424 <https://github.com/pgadmin-org/pgadmin4/issues/10424>`_ -  Fix Reset Layout dropping Query Tool tabs from the saved application state.
+  | `Issue #10428 <https://github.com/pgadmin-org/pgadmin4/issues/10428>`_ -  Fix connections crashing on Windows with an access violation, and the utilities failing to find ``gssapi64.dll``, by staging the Kerberos runtime next to libpq.
+  | `Issue #10446 <https://github.com/pgadmin-org/pgadmin4/issues/10446>`_ -  Fix Schema Diff reporting identical tables as different when a foreign key's referenced table has a dropped column.
+  | `Issue #10449 <https://github.com/pgadmin-org/pgadmin4/issues/10449>`_ -  Honour the password file in the Change Server Password dialog, rather than requiring the current password.
+  | `Issue #10462 <https://github.com/pgadmin-org/pgadmin4/issues/10462>`_ -  Fix duplicated content when opening large non-UTF-8 files in the Query Tool.
+  | `Issue #10463 <https://github.com/pgadmin-org/pgadmin4/issues/10463>`_ -  Pass the target database, and every supported connection parameter, to the utilities, so a database set in a service file no longer overrides the one selected.
+  | `Issue #10470 <https://github.com/pgadmin-org/pgadmin4/issues/10470>`_ -  Remove inherited columns from the Columns tab when their parent table is removed after reopening a table.
+  | `Issue #10482 <https://github.com/pgadmin-org/pgadmin4/issues/10482>`_ -  Allow saving files through symbolic links in desktop mode, and stop forcing 0600 permissions on them there.
+  | `Issue #10485 <https://github.com/pgadmin-org/pgadmin4/issues/10485>`_ -  Fix 'Cannot have two HTML5 backends at the same time' errors in dialogs containing a data grid.
+  | `Issue #10511 <https://github.com/pgadmin-org/pgadmin4/issues/10511>`_ -  Fix the Dashboard Logs tab failing on multi-byte characters split across read chunks.
+  | `Issue #10527 <https://github.com/pgadmin-org/pgadmin4/issues/10527>`_ -  Write the cloud deployment wizard's AWS, Azure and Google credentials through to the session store.
+  | `Issue #10531 <https://github.com/pgadmin-org/pgadmin4/issues/10531>`_ -  Fix the Query Tool saving files that were loaded as latin-1 back as UTF-8.
+  | `Issue #10534 <https://github.com/pgadmin-org/pgadmin4/issues/10534>`_ -  Fix the hardcoded table OID in the column properties query, which broke inherited column details.
+  | `Issue #10547 <https://github.com/pgadmin-org/pgadmin4/issues/10547>`_ -  Fix valid escapes below U+0100 being rewritten in SQL_ASCII data and names.
+  | `Issue #10548 <https://github.com/pgadmin-org/pgadmin4/issues/10548>`_ -  Fix negative identity column options being dropped from the generated SQL.
+  | `Issue #10549 <https://github.com/pgadmin-org/pgadmin4/issues/10549>`_ -  Fix Schema Diff not removing a column comment that exists only in the target.
+  | `Issue #10550 <https://github.com/pgadmin-org/pgadmin4/issues/10550>`_ -  Fix changing an identity column's START value also restarting its sequence.
+  | `Issue #10551 <https://github.com/pgadmin-org/pgadmin4/issues/10551>`_ -  Fix the cursor jumping to the start of SQL fields in dialogs after a quick edit and undo.
+  | `Issue #10554 <https://github.com/pgadmin-org/pgadmin4/issues/10554>`_ -  Fix column properties reporting an arbitrary parent for columns merged from several parents.
+  | `Issue #10573 <https://github.com/pgadmin-org/pgadmin4/issues/10573>`_ -  Fix Query Tool state save/restore failing on installations with a legacy ``SECRET_KEY``.
+  | `Issue #10584 <https://github.com/pgadmin-org/pgadmin4/issues/10584>`_ -  Preserve explicit 24-hour mode in date-time picker popups.
+  | `Issue #10597 <https://github.com/pgadmin-org/pgadmin4/issues/10597>`_ -  Fix Schema Diff treating a function whose input argument was renamed as two unrelated functions.
+  | `Issue #10598 <https://github.com/pgadmin-org/pgadmin4/issues/10598>`_ -  Keep the Query Tool execute options when its transaction is re-created.
+  | `Issue #10600 <https://github.com/pgadmin-org/pgadmin4/issues/10600>`_ -  Revert the Query Tool execute option checkboxes when changing an option fails.
+  | `Issue #10603 <https://github.com/pgadmin-org/pgadmin4/issues/10603>`_ -  Fix the Query Tool not re-running the query after reconnecting at a password prompt.
+  | `Issue #10604 <https://github.com/pgadmin-org/pgadmin4/issues/10604>`_ -  Report a failed autocomplete reconnect in the Query Tool instead of ignoring it.
+  | `Issue #10607 <https://github.com/pgadmin-org/pgadmin4/issues/10607>`_ -  Fix Query Tool autocomplete objects being shared between sessions that use the same transaction id.
+  | `Issue #10612 <https://github.com/pgadmin-org/pgadmin4/issues/10612>`_ -  Free Query Tool autocomplete objects when an idle session's connections are released.
+  | `Issue #10613 <https://github.com/pgadmin-org/pgadmin4/issues/10613>`_ -  Reconnect a lost Query Tool connection as the user and role it was changed to.
+  | `Issue #10614 <https://github.com/pgadmin-org/pgadmin4/issues/10614>`_ -  Keep external pages out of the desktop runtime's privileged windows and confine non-prompted downloads to the downloads directory.
+  | `Issue #10618 <https://github.com/pgadmin-org/pgadmin4/issues/10618>`_ -  Keep Query Tool execution disabled until a restored tab's execute options reach the server.
+  | `Issue #10645 <https://github.com/pgadmin-org/pgadmin4/issues/10645>`_ -  Fix connection redirection in the materialized view refresh, where the target database's name was passed straight to psql's ``--dbname``: because libpq expands a value containing an equals sign into a full connection string, a database named like ``host=... port=...``, which any role with only CREATEDB can create, redirected psql to a server of the creator's choosing and leaked the connecting user's saved password (CVE-2026-116252). The name is now passed through the same connection-information helper as the Backup, Restore, Maintenance and Import/Export tools, so libpq treats it strictly as a database name. Reported by Bae Seung-won (@baeseungwon1010).
+  | `Issue #10646 <https://github.com/pgadmin-org/pgadmin4/issues/10646>`_ -  Fix a user's other sessions surviving a password change, which left a session an attacker already held valid after the password was changed or reset (CVE-2026-116251). A self-service change now rotates the user's ``fs_uniquifier``, logging out every other session while the changing session stays signed in with its database connections, and saved passwords, including those of shared servers, are re-encrypted under the new key, with any that cannot be decrypted cleared, and all of them cleared if re-encryption fails. An administrator reset (including ``setup.py update-user``) also rotates ``fs_uniquifier``, ending all of that user's sessions, but does not re-encrypt their saved passwords. Reported by Zohaib.
+  | `Issue #10647 <https://github.com/pgadmin-org/pgadmin4/issues/10647>`_ -  Fix time-of-check to time-of-use symlink races in Import/Export Servers and the File Manager's upload, save and file-open paths, where a path validated against the user's storage directory was then opened by name, so a symbolic link swapped in at the file or any parent directory in between let an export overwrite, or an import read, a file outside the storage directory (CVE-2026-116250). In server mode on POSIX the file is now opened by walking down from the storage directory one component at a time with ``O_NOFOLLOW``; new files are created with mode 0600 and only regular files are read, opened non-blocking so a FIFO cannot hang the request. Symbolic links inside a storage directory are now refused, even when they point elsewhere inside it. Windows and desktop mode are unchanged, so the race remains there. Reported by MUTED CYBERSECURITY S.L.
+  | `Issue #10648 <https://github.com/pgadmin-org/pgadmin4/issues/10648>`_ -  Fix the same symlink races in the files handed to Backup, Restore and Import/Export Data, where the validated path was passed to pg_dump, pg_dumpall, pg_restore or psql, which opened it by name later, extending the fix for the vulnerability tracked in Issue #10647. In server mode on POSIX pgAdmin now opens the file itself with the descriptor-relative ``O_NOFOLLOW`` walk, accepts only a regular file and hands the utility ``/dev/fd/N``, and new backup and export files are created with mode 0600. This applies on Linux only, and not to directory-format Backup and Restore, where the utility opens the files inside the directory by name; on macOS and the BSDs the file is checked safely but the utility still reopens it by name.
+  | `Issue #10649 <https://github.com/pgadmin-org/pgadmin4/issues/10649>`_ -  Refuse hard links and FIFOs in the symlink-race fixes of Issue #10647 and Issue #10648, since ``O_NOFOLLOW`` stops only symbolic links: in server mode on POSIX, a file with more than one link is refused, for reading as well as before it is truncated for writing, and a FIFO can no longer hang an upload, save or export; Windows is not covered. The Import/Export Servers, save, Backup, Restore and Import/Export Data handlers also return the reason for a failure instead of text containing the absolute storage path.
+  | `Issue #10650 <https://github.com/pgadmin-org/pgadmin4/issues/10650>`_ -  Fix connection file paths escaping the user's storage directory, where a password file, SSL certificate, key or CRL, or SSH tunnel identity file such as ``../<another user>/.pgpass`` was joined to the storage directory after stripping only leading slashes, so a user could connect with another user's credentials or key, and where ``sslkeylogfile`` was copied into the connection string unchanged, letting libpq create or append a file as the pgAdmin service account (CVE-2026-116249). In server mode the resolved path, with symbolic links followed, must now stay inside the user's storage directory or the named shared storage directory, and ``sslkeylogfile`` is confined the same way. Connection parameter keys are also validated against the libpq keyword list, since a crafted key could smuggle its own ``keyword=value`` pairs past these checks. Servers whose file paths reach outside the storage directory, through ``..`` or a symbolic link, stop connecting until the files are moved into it or into a ``SHARED_STORAGE`` directory.
+  | `Issue #10651 <https://github.com/pgadmin-org/pgadmin4/issues/10651>`_ -  Fix any user able to register a server being able to share it with every other user in server mode, because the create and update endpoints stored whatever ``shared`` value they were sent, and the servers.json import removed a non-administrator's shared entries only after validation, so an early error left them in place (CVE-2026-116248). Such requests are now refused with a 403, and the import prunes and skips a non-administrator's shared entries before validating. The restriction is not retroactive: servers shared by non-administrators before the upgrade stay shared until the owner un-shares them or an administrator clears the ``shared`` column in the configuration database, and pgAdmin only logs a warning about each of them at startup, so administrators should review those servers and un-share any that should not be shared. ``Shared`` in a servers.json import must now be the JSON value ``true``, and a file that fails validation is refused as a whole.
+  | `Issue #10652 <https://github.com/pgadmin-org/pgadmin4/issues/10652>`_ -  Stop libpq using the pgAdmin service account's own client files in server mode: when a server had no password file, client certificate or client key configured, libpq fell back to the service account's ``~/.pgpass``, ``~/.postgresql/postgresql.crt`` and ``~/.postgresql/postgresql.key`` (or ``PGPASSFILE``, ``PGSSLCERT`` and ``PGSSLKEY``), letting any user connect with the service account's saved passwords or client certificate (CVE-2026-116247). In server mode each of these parameters is now always given a value, the user's own file or a path that can never be opened, in the connection string and for the utilities. Server mode deployments relying on the service account's files, or on ``passfile``, ``sslcert`` or ``sslkey`` in a connection service entry, must configure them on each server instead, and a server with a client certificate must also have a client key.
+  | `Issue #10653 <https://github.com/pgadmin-org/pgadmin4/issues/10653>`_ -  Fix server passwords being left in pgAdmin's own process environment, where the password handed to psql and to the utilities was written into ``os.environ`` and never removed, so another user's later psql session or utility inherited it and libpq used it for any connection made without a password of its own (CVE-2026-116246). The password now goes only into the environment of the process that needs it.
+  | `Issue #10654 <https://github.com/pgadmin-org/pgadmin4/issues/10654>`_ -  Restrict connection services in server mode, where any user could set a server's service, or a ``service`` connection parameter, to an entry in the service account's connection service file and connect with that entry's credentials, and where a ``PGPASSWORD`` or ``PGSERVICE`` variable set for that account was used for every connection (CVE-2026-116245). A service may now only be used if the administrator lists it in the new ``SERVER_MODE_ALLOWED_SERVICES`` setting, which is empty by default; the ``servicefile`` parameter is refused, and ``PGPASSWORD`` and ``PGSERVICE`` are removed from pgAdmin's environment at startup. ``setup.py load-servers`` also refuses an unlisted service. In server mode, servers that use a service stop connecting until the administrator lists it in ``SERVER_MODE_ALLOWED_SERVICES`` in ``config_local.py``, ideally before upgrading. Listing a service shares its credentials with every pgAdmin user, so list only services intended for everyone.
+  | `Issue #10655 <https://github.com/pgadmin-org/pgadmin4/issues/10655>`_ -  Stop libpq using the pgAdmin service account's Kerberos credentials in server mode, where removing ``KRB5CCNAME`` let the Kerberos library fall back to the service account's default credential cache or client keytab (or its logon, through SSPI on Windows), so any user could answer a server's GSSAPI request as the service account's principal (CVE-2026-116244). In server mode ``KRB5CCNAME`` and ``KRB5_CLIENT_KTNAME`` now point at a file that cannot exist, except that a user who logged in with Kerberos gets their own delegated ``KRB5CCNAME`` when connecting to a server with Kerberos authentication enabled. Every other connection also gets ``gssencmode=disable`` and, with libpq 16 or later, ``require_auth=!gss,!sspi``; without ``require_auth``, SSPI and gssproxy are not stopped, so upgrade the libpq used by pgAdmin and its utilities to 16 or later. A server whose ``require_auth`` allows only GSSAPI or SSPI is refused unless the user logged in with Kerberos. A service listed in ``SERVER_MODE_ALLOWED_SERVICES`` takes precedence for psql and the utilities, so it must not set ``require_auth``, ``gssencmode`` or ``gsslib``.
+  | `Issue #10656 <https://github.com/pgadmin-org/pgadmin4/issues/10656>`_ -  Fix the utility binary-path guard accepting a path under ``SHARED_STORAGE``, which ordinary users can write to, so a user could point a server type's binary path at a file placed there and have pgAdmin execute it (CVE-2026-116243). Every ``SHARED_STORAGE`` entry is now rejected alongside ``STORAGE_DIR``, after expanding ``$DIR`` and ``..`` and resolving symbolic links, so an existing binary path under a shared storage directory stops working. An empty ``STORAGE_DIR`` is not covered. Reported by Harsh Singh.
+  | `Issue #10662 <https://github.com/pgadmin-org/pgadmin4/issues/10662>`_ -  Stop SSH tunnels using the pgAdmin service account's own SSH identity, where sshtunnel always loaded the unencrypted private keys in the service account's ``~/.ssh``, read its ``~/.ssh/config`` and could use its ssh-agent, so any user could configure a tunnel that authenticated with the service account's key (CVE-2026-116242). In server mode the tunnel no longer reads those keys or that configuration, or uses the agent, and an identity file that cannot be found in the user's storage is reported. Tunnels relying on the service account's key, config or agent must have an identity file in the user's storage or a password configured on the server.
+  | `Issue #10663 <https://github.com/pgadmin-org/pgadmin4/issues/10663>`_ -  Fix OS command injection in the Import/Export Data tool, where a query-based export could pass a crafted query past the ``\copy (...)`` parenthesis-balance guard through a backslash inside a double-quoted identifier, which psql treats as an escape when ``standard_conforming_strings`` is off, exposing a live ``TO PROGRAM`` clause that runs an arbitrary command on the pgAdmin host, an incomplete fix for CVE-2026-17566 (CVE-2026-116241). A backslash inside a double-quoted identifier is now rejected, and so is a backslash or null byte in the schema, table or column names of an export or import, which reached the same ``\copy`` command through ``qtIdent()``. Reported by Yonghwa Lee (Xint by Theori).
+  | `Issue #10674 <https://github.com/pgadmin-org/pgadmin4/issues/10674>`_ -  Fix the File Manager and the storage-path tools acting on a different path from the one that was checked (CVE-2026-116240): opening, saving and listing files, download, delete, rename, create-folder and upload could name files outside the user's storage directory, or in another user's directory whose name begins with the same characters. Every File Manager and storage-path caller now acts on the absolute path that was checked, and in server mode on POSIX files are opened relative to the storage directory without following symbolic links, so symbolic links to directories and hard-linked files inside it can no longer be opened, downloaded or renamed through. The storage directory itself can no longer be deleted.
+  | `Issue #10675 <https://github.com/pgadmin-org/pgadmin4/issues/10675>`_ -  Fix LDAP and Kerberos authentication logging a user in to a different account that shared their username: Kerberos and LDAP looked the account up by username alone, or accepted the account Flask-Security's internal validation had matched by the email typed, so a Kerberos or LDAP user could be logged in as an Internal account, including the initial administrator, or as another user (CVE-2026-116239). Accounts are now looked up by the authenticated username and the source that authenticated them, and only internal authentication logs in an account from its own form. Webserver users whose username matches an Internal account, and LDAP users with capitals in their username, now log in correctly, and ``setup.py`` can update a user without a role and add one without ``--role``. Users who relied on being logged in to an Internal account of the same name now need an account of their own source. Reported by Yves Soete of Blacksight LLC (@yssoe).
+  | `Issue #10676 <https://github.com/pgadmin-org/pgadmin4/issues/10676>`_ -  Fix bypasses of the failed-login limit and of pgAdmin's own login, password change and password reset checks, where a username in another case or a wrong internal password with LDAP or Webserver authentication also configured was never counted, and where Flask-Security's own ``/login``, ``/verify``, ``/change``, ``/reset`` and ``/reset/<token>`` views accepted submissions that skipped the failed-login count and lock, the change password permission, the re-encryption of saved passwords, and the internal-account check on resets (CVE-2026-116238). Every failed internal login is now counted (when ``MAX_LOGIN_ATTEMPTS`` is set) and only internal authentication is locked, so a locked Internal account no longer blocks other sources. A login form that posts a password is no longer passed to Kerberos, OAuth2 or Webserver authentication, submissions to Flask-Security's views are refused with 405, and password resets act only on the internal account.

docs/en_US/restore_dialog.rst

@@ -77,6 +77,10 @@ tab to provide options related to data or pgAdmin objects that correspond to *pg
    * Move the switch next to *Only schema* to limit the restoration to
      schema-level database objects.
 
+   * Move the switch next to *Only statistics* to the *Yes* position to limit
+     the restoration to optimizer statistics. **Note:** This option is visible
+     only for database server greater than or equal to 18.
+
 .. image:: images/restore_do_not_save.png
     :alt: Restore dialog do not save section
     :align: center
@@ -110,6 +114,22 @@ tab to provide options related to data or pgAdmin objects that correspond to *pg
      Table access methods. **Note:** This option is visible only for
      database server greater than or equal to 15.
 
+   * Move the switch next to *Row security policies* to the *Yes* position to
+     exclude row security policies. **Note:** This option is visible only for
+     database server greater than or equal to 18.
+
+   * Move the switch next to *Data* to the *Yes* position to exclude data from
+     the restore. **Note:** This option is visible only for database server
+     greater than or equal to 18.
+
+   * Move the switch next to *Schema* to the *Yes* position to exclude schema
+     (the data definitions) from the restore. **Note:** This option is visible
+     only for database server greater than or equal to 18.
+
+   * Move the switch next to *Statistics* to the *Yes* position to exclude
+     optimizer statistics from the restore. **Note:** This option is visible
+     only for database server greater than or equal to 18.
+
 .. image:: images/restore_queries.png
     :alt: Restore dialog queries section
     :align: center

docs/en_US/server_deployment.rst

@@ -195,7 +195,7 @@ the Python Wheel (you may need to adjust the path to suit your installation):
     gunicorn  --bind 0.0.0.0:80 \
               --workers=1 \
               --threads=25 \
-              --chdir /usr/lib/python3.7/dist-packages/pgadmin4 \
+              --chdir /usr/lib/python3.13/dist-packages/pgadmin4 \
               pgAdmin4:app
 
 Standalone uWSGI Configuration
@@ -210,9 +210,48 @@ the Python Wheel (you may need to adjust the path to suit your installation):
     uwsgi --http-socket 0.0.0.0:80 \
           --processes 1 \
           --threads 25 \
-          --chdir /usr/lib/python3.7/dist-packages/pgadmin4/ \
+          --chdir /usr/lib/python3.13/dist-packages/pgadmin4/ \
           --mount /=pgAdmin4:app
 
+.. _sub_directory_hosting:
+
+Hosting in a Sub-Directory
+--------------------------
+
+Any of the reverse proxy configurations described below can host pgAdmin in a
+sub-directory of the server (``/pgadmin4`` in each of the examples) rather than
+at its root, but doing so requires that the ``SCRIPT_NAME`` environment
+variable is set for the Gunicorn or uWSGI process, whichever is in use.
+
+pgAdmin reads ``SCRIPT_NAME`` from the process environment once, at startup,
+and uses it to set ``APPLICATION_ROOT`` and ``SESSION_COOKIE_PATH``, so that
+URLs, redirects (including the one issued after a successful login) and
+session cookies are all generated relative to the sub-directory rather than to
+the root of the server. Without it, a successful login redirects to the root of
+the server, which typically presents to the user as a redirect loop.
+
+This is a separate mechanism from the per-request ``X-Script-Name`` header that
+the NGINX Gunicorn example below sets, and neither substitutes for the other.
+It is also separate from uWSGI's ``--manage-script-name``, which only affects
+the per-request WSGI environment that uWSGI builds; the uWSGI examples below
+set ``SCRIPT_NAME`` alongside it so that both mechanisms agree, and so that the
+session cookie is confined to the sub-directory rather than being issued for
+the root of the server.
+
+.. _proxy_headers:
+
+Reverse Proxy Headers
+---------------------
+
+pgAdmin honours the ``X-Script-Name`` and ``X-Scheme`` request headers
+unconditionally, unlike the ``X-Forwarded-*`` headers, which are trusted only
+to the depth configured by the ``PROXY_X_*_COUNT`` settings. A client that
+supplied its own ``X-Script-Name`` could therefore change every URL pgAdmin
+generates, so the reverse proxy must always either overwrite both headers with
+values of its own or remove them outright, rather than passing on whatever the
+client sent. Each of the examples below does one or the other, and a proxy
+configuration not derived from them should do the same.
+
 NGINX Configuration with Gunicorn
 ---------------------------------
 
@@ -228,7 +267,7 @@ command similar to:
     gunicorn --bind unix:/tmp/pgadmin4.sock \
              --workers=1 \
              --threads=25 \
-             --chdir /usr/lib/python3.7/dist-packages/pgadmin4 \
+             --chdir /usr/lib/python3.13/dist-packages/pgadmin4 \
              pgAdmin4:app
 
 And configure NGINX:
@@ -238,11 +277,24 @@ And configure NGINX:
     location / {
         include proxy_params;
         proxy_pass http://unix:/tmp/pgadmin4.sock;
+        proxy_set_header X-Script-Name "";
+        proxy_set_header X-Scheme "";
     }
 
 Alternatively, pgAdmin can be hosted in a sub-directory (/pgadmin4 in this case)
-on the server. Start Gunicorn as when using the root directory, but configure
-NGINX as follows:
+on the server. Start Gunicorn as when using the root directory, but also set the
+``SCRIPT_NAME`` environment variable for the Gunicorn process, as described in
+:ref:`sub_directory_hosting`:
+
+.. code-block:: bash
+
+    SCRIPT_NAME=/pgadmin4 gunicorn --bind unix:/tmp/pgadmin4.sock \
+                                   --workers=1 \
+                                   --threads=25 \
+                                   --chdir /usr/lib/python3.13/dist-packages/pgadmin4 \
+                                   pgAdmin4:app
+
+Then configure NGINX:
 
 .. code-block:: nginx
 
@@ -250,6 +302,7 @@ NGINX as follows:
         include proxy_params;
         proxy_pass http://unix:/tmp/pgadmin4.sock;
         proxy_set_header X-Script-Name /pgadmin4;
+        proxy_set_header X-Scheme "";
     }
 
 NGINX Configuration with uWSGI
@@ -267,7 +320,7 @@ command similar to:
     uwsgi --socket /tmp/pgadmin4.sock \
           --processes 1 \
           --threads 25 \
-          --chdir /usr/lib/python3.7/dist-packages/pgadmin4/ \
+          --chdir /usr/lib/python3.13/dist-packages/pgadmin4/ \
           --manage-script-name \
           --mount /=pgAdmin4:app
 
@@ -279,20 +332,23 @@ And configure NGINX:
     location @pgadmin4 {
         include uwsgi_params;
         uwsgi_pass unix:/tmp/pgadmin4.sock;
+        uwsgi_param HTTP_X_SCRIPT_NAME "";
+        uwsgi_param HTTP_X_SCHEME "";
     }
 
 Alternatively, pgAdmin can be hosted in a sub-directory (/pgadmin4 in this case)
 on the server. Start uWSGI, noting that the directory name is specified in the
-``mount`` parameter:
+``mount`` parameter, and that the ``SCRIPT_NAME`` environment variable should
+be set alongside it, as described in :ref:`sub_directory_hosting`:
 
 .. code-block:: bash
 
-    uwsgi --socket /tmp/pgadmin4.sock \
-          --processes 1 \
-          --threads 25 \
-          --chdir /usr/lib/python3.7/dist-packages/pgadmin4/ \
-          --manage-script-name \
-          --mount /pgadmin4=pgAdmin4:app
+    SCRIPT_NAME=/pgadmin4 uwsgi --socket /tmp/pgadmin4.sock \
+                                --processes 1 \
+                                --threads 25 \
+                                --chdir /usr/lib/python3.13/dist-packages/pgadmin4/ \
+                                --manage-script-name \
+                                --mount /pgadmin4=pgAdmin4:app
 
 Then, configure NGINX:
 
@@ -303,6 +359,161 @@ Then, configure NGINX:
     location @pgadmin4 {
       include uwsgi_params;
       uwsgi_pass unix:/tmp/pgadmin4.sock;
+      uwsgi_param HTTP_X_SCRIPT_NAME "";
+      uwsgi_param HTTP_X_SCHEME "";
+    }
+
+Caddy Configuration with Gunicorn
+----------------------------------
+
+pgAdmin can be hosted by Gunicorn, with Caddy in front of it as a reverse
+proxy. Note that these examples assume pgAdmin was installed using the Python
+Wheel (you may need to adjust the path to suit your installation).
+
+To run with pgAdmin in the root directory of the server, start Gunicorn using
+a command similar to:
+
+.. code-block:: bash
+
+    gunicorn --bind unix:/run/pgadmin4/pgadmin4.sock \
+             --workers=1 \
+             --threads=25 \
+             --chdir /usr/lib/python3.13/dist-packages/pgadmin4 \
+             pgAdmin4:app
+
+And configure Caddy:
+
+.. code-block:: text
+
+    pgadmin.example.com {
+        reverse_proxy unix//run/pgadmin4/pgadmin4.sock {
+            header_up -X-Script-Name
+            header_up -X-Scheme
+        }
+    }
+
+.. _caddy_socket_location:
+
+.. note:: The examples deliberately avoid ``/tmp`` for the socket. The systemd
+    unit shipped with Caddy sets ``PrivateTmp=true``, which gives the Caddy
+    process a private ``/tmp`` directory of its own, so a socket created by
+    Gunicorn or uWSGI in the system ``/tmp`` is invisible to Caddy, which will
+    report a 502 error for every request. Any directory outside ``/tmp`` that
+    both processes can access will do, provided the user Caddy runs as has
+    permission to read and write the socket; alternatively, have Gunicorn or
+    uWSGI listen on a TCP port such as ``127.0.0.1:5050`` and proxy to that
+    instead. Whichever directory is used, it must exist and be writable by the
+    user Gunicorn or uWSGI runs as before the socket can be bound; under
+    systemd, ``RuntimeDirectory=pgadmin4`` in the unit that starts Gunicorn or
+    uWSGI will create ``/run/pgadmin4`` on start and remove it on stop. The
+    same applies to the uWSGI examples below.
+
+.. _caddy_header_stripping:
+
+.. note:: The two ``header_up`` directives remove any ``X-Script-Name`` and
+    ``X-Scheme`` headers that arrive from the client, for the reasons given in
+    :ref:`proxy_headers`. Each of the Caddy examples removes both, except that
+    the Gunicorn sub-directory example sets ``X-Script-Name`` to the
+    sub-directory instead, which likewise replaces whatever the client sent.
+
+Alternatively, pgAdmin can be hosted in a sub-directory (/pgadmin4 in this
+case) on the server. Start Gunicorn as when using the root directory, but
+also set the ``SCRIPT_NAME`` environment variable for the Gunicorn process, as
+described in :ref:`sub_directory_hosting`:
+
+.. code-block:: bash
+
+    SCRIPT_NAME=/pgadmin4 gunicorn --bind unix:/run/pgadmin4/pgadmin4.sock \
+                                   --workers=1 \
+                                   --threads=25 \
+                                   --chdir /usr/lib/python3.13/dist-packages/pgadmin4 \
+                                   pgAdmin4:app
+
+Then configure Caddy. The request path must be passed through to Gunicorn
+unchanged, so do not strip the /pgadmin4 prefix; the ``X-Script-Name`` header
+is set to the sub-directory, both to tell pgAdmin which requests are made
+under it and to replace any value the client may have sent; and the path
+matcher must include both ``/pgadmin4`` and ``/pgadmin4/*``, so that pgAdmin's
+own redirect to the bare sub-directory path (with no trailing slash) is also
+proxied, rather than falling through to Caddy's default (and rather unhelpful)
+empty response for an unmatched path:
+
+.. code-block:: text
+
+    pgadmin.example.com {
+        @pgadmin path /pgadmin4 /pgadmin4/*
+        handle @pgadmin {
+            reverse_proxy unix//run/pgadmin4/pgadmin4.sock {
+                header_up X-Script-Name /pgadmin4
+                header_up -X-Scheme
+            }
+        }
+    }
+
+Caddy Configuration with uWSGI
+-------------------------------
+
+Caddy does not speak the native uwsgi protocol used by NGINX's
+``uwsgi_pass``, so uWSGI must be run in HTTP mode instead, using
+``--http-socket`` rather than ``--socket``. Note that these examples assume
+pgAdmin was installed using the Python Wheel (you may need to adjust the
+path to suit your installation).
+
+To run with pgAdmin in the root directory of the server, start uWSGI using a
+command similar to:
+
+.. code-block:: bash
+
+    uwsgi --http-socket /run/pgadmin4/pgadmin4.sock \
+          --processes 1 \
+          --threads 25 \
+          --chdir /usr/lib/python3.13/dist-packages/pgadmin4/ \
+          --mount /=pgAdmin4:app
+
+And configure Caddy, again keeping the socket out of ``/tmp`` (see
+:ref:`the note above <caddy_socket_location>`) and stripping the headers
+pgAdmin trusts unconditionally (see :ref:`the note above
+<caddy_header_stripping>`):
+
+.. code-block:: text
+
+    pgadmin.example.com {
+        reverse_proxy unix//run/pgadmin4/pgadmin4.sock {
+            header_up -X-Script-Name
+            header_up -X-Scheme
+        }
+    }
+
+Alternatively, pgAdmin can be hosted in a sub-directory (/pgadmin4 in this
+case) on the server. Start uWSGI, noting that the directory name is specified
+in the ``mount`` parameter, and that the ``SCRIPT_NAME`` environment variable
+should still be set alongside it, as described in
+:ref:`sub_directory_hosting`:
+
+.. code-block:: bash
+
+    SCRIPT_NAME=/pgadmin4 uwsgi --http-socket /run/pgadmin4/pgadmin4.sock \
+                                --processes 1 \
+                                --threads 25 \
+                                --chdir /usr/lib/python3.13/dist-packages/pgadmin4/ \
+                                --manage-script-name \
+                                --mount /pgadmin4=pgAdmin4:app
+
+Then configure Caddy as for the Gunicorn sub-directory example above, except
+that no ``X-Script-Name`` header needs to be set: ``--manage-script-name`` has
+uWSGI report the mount point to pgAdmin with every request, as in the NGINX
+uWSGI example above, so the header is only removed:
+
+.. code-block:: text
+
+    pgadmin.example.com {
+        @pgadmin path /pgadmin4 /pgadmin4/*
+        handle @pgadmin {
+            reverse_proxy unix//run/pgadmin4/pgadmin4.sock {
+                header_up -X-Script-Name
+                header_up -X-Scheme
+            }
+        }
     }
 
 Additional Information

docs/en_US/server_dialog.rst

@@ -33,6 +33,18 @@ Use the fields in the *General* tab to identify the server:
 * If the *Shared?* switch is moved to *Yes* then that server can be
   shared with all the other users. This option is available only to admin users.
   For more information on users see :ref:`User Management Dialog <user_management>`.
+  Sharing a server, whether in this dialog, through the API or by importing a
+  servers.json file, is restricted to users with the *Administrator* role.
+  Servers that were shared by non-administrator users before this restriction
+  was introduced remain shared until they are un-shared, so administrators
+  should audit them: look for servers with the shared flag set in the
+  configuration database whose owner does not have the *Administrator* role.
+  pgAdmin logs a warning for each such server when it starts in server mode.
+  Such a server can be un-shared by its owner through the server API (a PUT
+  request on the server with ``"shared": false``), or by an administrator
+  changing the ``shared`` column of the server record in the pgAdmin
+  configuration database. The *Shared?* switch in this dialog is shown only
+  to administrators, and only the owner of a server can change it.
   Users can access the shared servers with some restrictions - the following
   operations on shared servers are not permitted:
 
@@ -41,6 +53,17 @@ Use the fields in the *General* tab to identify the server:
     * Rename the group server
     * Change of host, port, and maintenance database
 
+  Each user of a shared server has their own copy of some of its settings.
+  Tags, colours, the role and the service name are copied from the owner
+  the first time a user opens the server, and each user can then change
+  their copy. The host, port, maintenance database and the general
+  connection parameters (such as *connect_timeout* or *sslmode*) always
+  come from the owner's server definition, so a change the owner makes
+  to them is seen by every user. The owner's password, SSH tunnel
+  credentials, SSL certificate, key and CRL paths, and password file
+  (*passfile*) are never shared: each user must supply their own in the
+  server dialog if they need them.
+
   Please note that once the server is shared, it's icon is changed in the
   object explorer.
 
@@ -85,6 +108,17 @@ Use the fields in the *Connection* tab to configure a connection:
   see
   `Section 33.16 of the Postgres documentation <https://www.postgresql.org/docs/current/libpq-pgservice.html>`_.
 
+  In server mode, services are read from the connection service file of the
+  account that pgAdmin runs as, so a server can use only a service that the
+  administrator has listed in the ``SERVER_MODE_ALLOWED_SERVICES`` setting
+  (see :ref:`config_py`), which is empty by default. A server that uses any
+  other service cannot be saved, and an existing one fails to connect with an
+  error naming the setting. Listing a service shares its credentials, such as
+  a password in its entry, with every pgAdmin user. The ``servicefile``
+  connection parameter cannot be used in server mode, and pgAdmin ignores any
+  ``PGPASSWORD`` or ``PGSERVICE`` environment variable set for the account it
+  runs as.
+
 Click the *Parameters* tab to continue.
 
 .. image:: images/server_parameters.png
@@ -107,6 +141,10 @@ Click on the *+* button to add a new parameter. Some of the parameters are:
   in seconds. Zero or not specified means wait indefinitely. It is not
   recommended to use a timeout of less than 2 seconds. By default it is set to
   10 seconds.
+* *Require authentication* (*require_auth*) field to specify the
+  authentication methods the server may use. In server mode, pgAdmin
+  refuses the GSSAPI and SSPI methods for a connection that may not use
+  Kerberos, as described in :ref:`kerberos`.
 * *SSL mode* field to select the type of SSL connection the server should use.
   For more information about using SSL encryption, see
   `Section 33.18 of the Postgres documentation <https://www.postgresql.org/docs/current/libpq-ssl.html>`_.
@@ -145,6 +183,20 @@ icon that is located to the right of each of the following fields.
     means that administrators of the server may be able to access those files;
     appropriate caution should be taken before choosing to use this feature.
 
+.. note:: In Server mode, every connection file path (the *Password file*,
+    client certificate and key, root certificate, certificate revocation list,
+    CRL directory and SSL key log file) must resolve inside your storage
+    directory, or inside a *SHARED_STORAGE* entry (see :ref:`config_py`)
+    written as *Name:/path*. A path that leaves it through *..* or a symbolic
+    link is refused with an "Access denied (...): the path resolves outside
+    your storage directory..." message when connecting or starting a utility.
+    If you used a symbolic link in your storage directory to reach, for
+    example, */etc/pgadmin/certs*, configure that directory as a
+    *SHARED_STORAGE* entry instead (see :ref:`storage_manager`). Every pgAdmin
+    user can use a file in shared storage, so it should hold only shareable
+    files such as a root certificate or CRL, never a private key or a
+    *.pgpass* file.
+
 Click the *SSH Tunnel* tab to continue.
 
 .. image:: images/server_ssh_tunnel.png
@@ -175,6 +227,9 @@ not be able to connect directly.
 
 * If the SSH host is expecting a private key file for authentication, use the
   *Identity file* field to specify the location of the key file.
+  In server mode, pgAdmin does not use the private keys, ssh-agent or
+  ``~/.ssh/config`` of the account pgAdmin runs as; the identity file must be
+  located inside your storage directory.
 * If the SSH host is expecting a password of the user name or an identity file
   if being used, use the *Password* field to specify the password.
 * Check the box next to *Prompt for password?* to to have pgAdmin prompt for
@@ -211,7 +266,7 @@ Use the fields in the *Advanced* tab to configure a connection:
   that will be used against the pg_database table to limit the databases that you see.
   For example, you might enter: *live_db test_db* so that only live_db and test_db
   are shown in the pgAdmin object explorer.
-* Use the *Password exec command* field to specify a shell command to be executed
+* In desktop mode, use the *Password exec command* field to specify a shell command to be executed
   to retrieve a password to be used for SQL authentication. The ``stdout`` of the
   command will be used as the SQL password. This may be useful when the password
   should be generated as a transient authorization token instead of providing a
@@ -219,8 +274,36 @@ Use the fields in the *Advanced* tab to configure a connection:
   You can pass server hostname, port and DB username to the password exec command as variable by providing placeholders
   like ``%HOSTNAME%``, ``%PORT%`` and ``%USERNAME%`` which will be replace with the server connection information.
   Example: ``/path/to/script --hostname %HOSTNAME% --port %PORT% --username %USERNAME%``
+* In server mode, use the *Password exec command* drop-down list to select one
+  of the commands that the administrator has defined in the
+  ``SERVER_PASSEXEC_COMMANDS`` setting (see :ref:`config_py`). Users cannot
+  enter their own command. The list offers *None* and each configured command
+  name, and is hidden if no commands have been configured. On a shared server,
+  users who do not own the server also see *Inherit from owner*, which is the
+  default for them and uses whatever command the owner has selected; selecting
+  *None* or a named command overrides it for that user only. If a selected
+  command is later removed from the configuration, the server is treated as
+  having no command and a warning is logged.
+
+  The command is run directly, without a shell, and does not receive the full
+  environment of the pgAdmin process. Only ``PATH``, ``HOME``, ``LANG``,
+  ``LANGUAGE``, ``TZ``, ``TMPDIR``, ``TMP``, ``TEMP``, ``USER``, ``LOGNAME``
+  and any ``LC_*`` variable are passed through (and, on Windows,
+  ``SYSTEMROOT``, ``SYSTEMDRIVE``, ``PATHEXT``, ``COMSPEC`` and ``WINDIR``),
+  together with any variables the administrator has named in the
+  ``SERVER_PASSEXEC_ENV_PASSTHROUGH`` setting. The command also receives the
+  following variables describing the connection, which take precedence over
+  any variable of the same name:
+  ``PGADMIN_PASSEXEC_HOST``, ``PGADMIN_PASSEXEC_PORT``,
+  ``PGADMIN_PASSEXEC_USERNAME`` (the username that connection uses, so a
+  non-owner's own username on a shared server), ``PGADMIN_PASSEXEC_DATABASE``
+  (the maintenance database), ``PGADMIN_PASSEXEC_PGADMIN_USER`` (the pgAdmin
+  user making the connection) and ``PGADMIN_PASSEXEC_AUTH_SOURCE`` (how that
+  user authenticated to pgAdmin). The ``stdout`` of the command is used as the
+  SQL password.
 * Use the *Password exec expiration* field to specify a maximum age, in seconds,
-  of the password generated with a *Password exec command*. If not specified,
+  of the password generated with a *Password exec command*. In server mode, this field is
+  enabled only when a named command is selected. If not specified,
   the password will not expire until your pgAdmin session does.
   Zero means the command will be executed for each new connection or reconnection that is made.
   If the generated password is not valid indefinitely, set this value to slightly before it will expire.
@@ -234,7 +317,34 @@ Use the fields in the *Advanced* tab to configure a connection:
 .. note:: The password file option is only supported when pgAdmin is using libpq
     v10.0 or later to connect to the server.
 
-.. note:: The Password exec option is only supported when pgAdmin is run in desktop mode.
+.. note:: In server mode, the *Password exec command* setting is available
+    only when the administrator has defined at least one command in
+    ``SERVER_PASSEXEC_COMMANDS``. Free-text commands are never run in server
+    mode, and when pgAdmin is upgraded, an existing free-text command is kept
+    only if it exactly matches a configured command (its arguments joined by
+    single spaces), in which case it is converted to that command's name; all
+    others are cleared and a warning is logged. This conversion cannot be
+    undone, so ``SERVER_PASSEXEC_COMMANDS`` must be configured before the
+    first start after upgrading. If it is still empty at that point, the
+    conversion is postponed: existing commands are left in the configuration
+    database unused, a warning giving the number of affected servers is
+    logged at each start, and they are converted or cleared on the first
+    start at which at least one command is configured. Placeholders such as
+    ``%HOSTNAME%``, ``%PORT%`` and ``%USERNAME%`` are not substituted in
+    server mode, so a command containing them is converted only if the
+    configured arguments contain the same literal text. On a shared server, a
+    user who does not own the server and whose own command is cleared will
+    then inherit the owner's command, if the owner has one. The
+    ``ENABLE_SERVER_PASS_EXEC_CMD`` setting is deprecated and ignored.
+
+.. warning:: In server mode, only ``PGADMIN_PASSEXEC_PGADMIN_USER`` and
+    ``PGADMIN_PASSEXEC_AUTH_SOURCE`` identify the pgAdmin user on whose behalf
+    the command is run. ``PGADMIN_PASSEXEC_HOST``, ``PGADMIN_PASSEXEC_PORT``,
+    ``PGADMIN_PASSEXEC_USERNAME`` and ``PGADMIN_PASSEXEC_DATABASE`` are set by
+    whoever edits the server definition; on a shared server, a user who does
+    not own the server sets their own username. Commands should therefore
+    decide whether to issue a password based on the pgAdmin identity, and
+    treat the other four variables as untrusted input.
 
 Click the *Post Connection SQL* tab to continue.
 

docs/en_US/statistics_dialog.rst

@@ -0,0 +1,93 @@
+.. _statistics_dialog:
+
+**************************
+`Statistics Dialog`:index:
+**************************
+
+Use the *Statistics* dialog to define extended statistics on one or more columns
+(or expressions) of a table. Extended statistics let PostgreSQL collect
+correlation data across columns that can significantly improve query-plan
+estimates for queries that filter or group by multiple columns.
+
+PostgreSQL introduced ``CREATE STATISTICS`` in PostgreSQL 10, and added
+expression statistics in PostgreSQL 14. This dialog is available for
+PostgreSQL 14 and later, which covers all currently supported PostgreSQL
+versions.
+
+The *Statistics* dialog organizes options across the *General* and *Definition*
+tabs. The *SQL* tab displays the SQL command generated by your selections.
+
+.. image:: images/statistics_general.png
+    :alt: Statistics dialog general tab
+    :align: center
+
+Use the fields in the *General* tab to describe the statistics object:
+
+* Use the *Name* field to enter a descriptive name. On PostgreSQL 16 and later
+  the name is optional, and the server will generate one from the table and the
+  columns or expressions if you leave it blank.
+* Use the *Owner* field to select the role that will own the statistics object.
+* Use the *Schema* field to select the schema in which the statistics object
+  will reside.
+* Use the *Table* field to select the table on which the statistics will be
+  collected. The list is filtered to tables in the selected schema.
+* Use the *Columns* field to select two or more columns. Hold *Ctrl* (or *Cmd*
+  on macOS) to select multiple columns. At least two columns are required when
+  collecting column based statistics, although a single column is enough when
+  it is combined with an expression.
+* Use the *Statistics types* field to choose which kinds of extended statistics
+  to collect:
+
+  * *N-distinct*, which estimates the number of distinct value combinations
+    across the selected columns or expressions.
+  * *Dependencies*, which detects functional dependencies between columns,
+    improving estimates for queries with correlated ``WHERE`` clauses.
+  * *MCV (Most Common Values)*, which records the most common combinations of
+    values.
+
+  If you leave the field empty, PostgreSQL collects every kind it supports.
+  Leave it empty for statistics on a single expression, which do not accept
+  a choice of kinds.
+
+* Use the *Comment* field to store an optional note about the statistics object.
+
+Click the *Definition* tab to continue.
+
+.. image:: images/statistics_definition.png
+    :alt: Statistics dialog definition tab
+    :align: center
+
+* Use the *Expressions* field to enter one or more SQL expressions separated by
+  commas (for example ``lower(col1), (col1 + col2)``). Each expression must be
+  enclosed in parentheses unless it is a function call, and the list is passed
+  to the server exactly as you enter it, so an expression may itself contain
+  commas. Expressions may be given instead of columns, or alongside them when
+  you want statistics over a mixture of the two.
+
+When you open the dialog on an existing statistics object, the *Properties*
+view also reports the statistics target and, for roles with access, the values
+that ``ANALYZE`` has collected. Those values are read through the
+``pg_catalog.pg_stats_ext`` view, which only shows them to roles the server
+allows to see them (the table's owners, on current PostgreSQL releases), so
+the *Computed Statistics* group is hidden when the current role lacks access.
+
+Click the *SQL* tab to continue.
+
+
+Your entries in the *Statistics* dialog generate a SQL command (see an example
+below). Use the *SQL* tab for review; revisit or switch tabs to make any changes.
+
+Example
+*******
+
+The following is an example of the SQL command generated by user selections in
+the *Statistics* dialog:
+
+.. image:: images/statistics_sql.png
+    :alt: Statistics dialog SQL tab
+    :align: center
+
+* Click the *Info* button (i) to access online help.
+* Click the *Save* button to save work.
+* Click the *Close* button to exit without saving work.
+* Click the *Reset* button to restore configuration parameters.

docs/en_US/user_management.rst

@@ -60,7 +60,7 @@ Provide information about the new pgAdmin role in the row:
   specified in the *Email* field. This field is disabled if you select any
   authentication source except *internal*.
 * Re-enter the password in the *Confirm password* field. This field is disabled
-  if you select *ldap* as authentication source.
+  if you select any authentication source except *internal*.
 * *Locked* switch cannot be changed if is turned off. It can only be changed
   when the user is locked by trying unsuccessful login attempts. Turn off the
   switch if you want to unlock the account.
@@ -132,6 +132,56 @@ a role.
 
 
 
+.. _auth_source_accounts:
+
+Accounts from different authentication sources
+##############################################
+
+pgAdmin treats accounts from different authentication sources as separate
+accounts, even when they share a username or an email address. Each has its
+own role, settings and servers:
+
+* A user authenticated by LDAP, Kerberos, OAuth2 or webserver authentication
+  is only ever logged in to the account with their username *and* that
+  authentication source, never to an account from another source with the
+  same username. If there is no such account, and the source does not create
+  one automatically, the login fails; pgAdmin does not log the user in to an
+  account from another source instead.
+* An internal login is checked against, and logs in, only the ``INTERNAL``
+  account.
+* Only an ``INTERNAL`` account has a password, so *Forgotten your password?*
+  resets only the ``INTERNAL`` account with the email address given.
+
+The account-lockout setting *MAX_LOGIN_ATTEMPTS* applies only to ``INTERNAL``
+accounts. pgAdmin never locks an account from another authentication source;
+brute-force protection for those is the responsibility of the directory,
+identity provider or reverse proxy. When ``INTERNAL`` and another source are
+both enabled, a sign-in that fails overall and was tried against an
+``INTERNAL`` account with that username counts towards its lockout; the attempt
+that reaches the limit reports that the account is now locked. A locked
+``INTERNAL`` account stops only internal sign-in: a user of another source with
+the same username can still sign in. On a later sign-in with that username,
+pgAdmin discloses that the ``INTERNAL`` account is locked only when internal is
+the only source able to check the password; while another password source such
+as LDAP is also eligible, it shows a generic failure instead.
+
+The administrator account created when pgAdmin is first set up always uses the
+``INTERNAL`` authentication source. It remains in the pgAdmin database when
+*AUTHENTICATION_SOURCES* does not include *internal*, although it can then no
+longer be used to log in. If you use external authentication only, create an
+administrator account for that source, for example for LDAP:
+
+.. code-block:: bash
+
+    /path/to/python /path/to/setup.py add-external-user ldapuser --auth-source ldap --admin
+
+and then deactivate the initial ``INTERNAL`` administrator account, so that it
+cannot be used if internal authentication is enabled again later:
+
+.. code-block:: bash
+
+    /path/to/python /path/to/setup.py update-user admin@example.com --inactive
+
 Using 'setup.py' command line script
 ####################################
 
@@ -146,7 +196,7 @@ Using 'setup.py' command line script
         without Python interpreter.
 
         Some of the examples:
-        pgadmin4-cli add-user user1@gmail.com password --role 1
+        pgadmin4-cli add-user user1@gmail.com password --role User
         pgadmin4-cli get-prefs
 
 Manage Users
@@ -156,7 +206,8 @@ Add User
 *********
 
 To add user, invoke ``setup.py`` with ``add-user`` command line option, followed by
-email and password. role and active will be optional fields.
+email and password. role and active will be optional fields. When no role is
+given, the user is created with the *User* role.
 
 .. code-block:: bash
 
@@ -166,7 +217,7 @@ email and password. role and active will be optional fields.
     # role using --role. If both are provided --admin will be used:
 
     /path/to/python /path/to/setup.py add-user user1@gmail.com password --admin
-    /path/to/python /path/to/setup.py add-user user1@gmail.com password --role Users
+    /path/to/python /path/to/setup.py add-user user1@gmail.com password --role User
 
     # to specify user's status
 
@@ -177,26 +228,28 @@ Add External User
 *****************
 
 To add external authentication user, invoke ``setup.py`` with ``add-external-user`` command line option,
-followed by email, password and authentication source. email, role and status will be optional fields.
+followed by username, and the authentication source with ``--auth-source`` (*oauth2* if it is not
+given). email, role and status will be optional fields. When no role is given,
+the user is created with the *User* role.
 
 .. code-block:: bash
 
-    /path/to/python /path/to/setup.py add-external-user user1@gmail.com ldap
+    /path/to/python /path/to/setup.py add-external-user user1@gmail.com --auth-source ldap
 
     # to specify an email:
 
-    /path/to/python /path/to/setup.py add-external-user ldapuser ldap --email user1@gmail.com
+    /path/to/python /path/to/setup.py add-external-user ldapuser --auth-source ldap --email user1@gmail.com
 
     # to specify a role, either you can use --admin for Administrator role or provide the
     # role using --role. If both are provided --admin will be used:
 
-    /path/to/python /path/to/setup.py add-external-user ldapuser ldap  --admin
-    /path/to/python /path/to/setup.py add-external-user ldapuser ldap  --role Users
+    /path/to/python /path/to/setup.py add-external-user ldapuser --auth-source ldap --admin
+    /path/to/python /path/to/setup.py add-external-user ldapuser --auth-source ldap --role User
 
     # to specify user's status
 
-    /path/to/python /path/to/setup.py add-external-user user1@gmail.com ldap --active
-    /path/to/python /path/to/setup.py add-external-user user1@gmail.com ldap --inactive
+    /path/to/python /path/to/setup.py add-external-user user1@gmail.com --auth-source ldap --active
+    /path/to/python /path/to/setup.py add-external-user user1@gmail.com --auth-source ldap --inactive
 
 Update User
 ***********
@@ -211,19 +264,20 @@ email address. password, role and active are updatable fields.
     # to specify a role, either you can use --admin for Administrator role or provide the
     # role using --role. If both are provided --admin will be used:
 
-    /path/to/python /path/to/setup.py update-user user1@gmail.com password --admin
-    /path/to/python /path/to/setup.py update-user user1@gmail.com password --role Users
+    /path/to/python /path/to/setup.py update-user user1@gmail.com --admin
+    /path/to/python /path/to/setup.py update-user user1@gmail.com --role User
 
     # to specify user's status
 
-   /path/to/python /path/to/setup.py update-user user1@gmail.com password --active
-   /path/to/python /path/to/setup.py update-user user1@gmail.com password --inactive
+    /path/to/python /path/to/setup.py update-user user1@gmail.com --active
+    /path/to/python /path/to/setup.py update-user user1@gmail.com --inactive
 
 Update External User
 ********************
 
 To update the external user, invoke ``setup.py`` with ``update-external-user`` command line option,
-followed by username and auth source. email, password, role and active are updatable fields.
+followed by username, and the authentication source with ``--auth-source`` (*oauth2* if it is not
+given). email, role and active are updatable fields.
 
 .. code-block:: bash
 
@@ -234,19 +288,19 @@ followed by username and auth source. email, password, role and active are updat
     # to specify a role, either you can use --admin for Administrator role or provide the
     # role using --role. If both are provided --admin will be used:
 
-    /path/to/python /path/to/setup.py update-external-user user1@gmail.com password --role --admin
-    /path/to/python /path/to/setup.py update-external-user user1@gmail.com password --role --role Users
+    /path/to/python /path/to/setup.py update-external-user ldapuser --auth-source ldap --admin
+    /path/to/python /path/to/setup.py update-external-user ldapuser --auth-source ldap --role User
 
     # to change user's status
 
-   /path/to/python /path/to/setup.py update-user ldapuser --auth-source ldap --active
-   /path/to/python /path/to/setup.py update-user ldapuser --auth-source ldap --inactive
+    /path/to/python /path/to/setup.py update-external-user ldapuser --auth-source ldap --active
+    /path/to/python /path/to/setup.py update-external-user ldapuser --auth-source ldap --inactive
 
 Delete User
 ***********
 
 To delete the user, invoke ``setup.py`` with ``delete-user`` command line option, followed by
-username and auth_source. For Internal users, email adress will be used instead of username. the option ``--yes`` is available to skip the confirmation prompt before deleting the user.
+username and auth_source. For Internal users, email address will be used instead of username. the option ``--yes`` is available to skip the confirmation prompt before deleting the user.
 
 .. code-block:: bash
 

docs/en_US/webserver.rst

@@ -20,7 +20,7 @@ and modify the values for the following parameters:
    :widths: 35, 55
 
    "AUTHENTICATION_SOURCES", "The default value for this parameter is *internal*.
-   To enable OAUTH2 authentication, you must include *webserver* in the list of values
+   To enable Webserver authentication, you must include *webserver* in the list of values
    for this parameter. you can modify the value as follows:
 
    * [‘webserver’]: pgAdmin will use only Webserver authentication.
@@ -36,8 +36,60 @@ and modify the values for the following parameters:
     environment variable name which comes from the web server after webserver authentication.
     The default value is REMOTE_USER and the possible values are REMOTE_USER,
     HTTP_X_FORWARDED_USER, X-Forwarded-User."
+    "WEBSERVER_REMOTE_USER_FROM_HEADER", "Set to *True* only if your reverse proxy passes the
+    authenticated identity as an HTTP request header rather than the REMOTE_USER CGI variable.
+    Defaults to *False*. See the warning below before enabling this."
+    "WEBSERVER_TRUSTED_PROXIES", "A list of IP addresses/CIDR ranges of the reverse proxies
+    that are allowed to assert the identity header. Required (non-empty) for
+    WEBSERVER_REMOTE_USER_FROM_HEADER to take effect. Defaults to an empty list."
+    "WEBSERVER_SHARED_SECRET", "An optional shared secret that the trusted proxy must inject
+    into every request, as additional proof that the identity header was set by the proxy
+    and not the client. Defaults to *None* (not checked)."
+    "WEBSERVER_SHARED_SECRET_HEADER", "The header name carrying WEBSERVER_SHARED_SECRET.
+    Defaults to *X-Pgadmin-Webserver-Secret*."
 
-.. note:: If REMOTE_USER does not work, try replacing it with either REMOTE-USER or Remote-user.
+.. warning::
+    Setting WEBSERVER_REMOTE_USER to a header-derived name (such as
+    HTTP_X_FORWARDED_USER, or REMOTE-USER/Remote-user) means the identity is
+    read from a client-controlled HTTP request header, not necessarily a
+    value set by your webserver's authentication plug-in. Any client that
+    can reach pgAdmin can set this header itself and impersonate any user,
+    including an existing Administrator, unless you:
+
+    * Set ``WEBSERVER_REMOTE_USER_FROM_HEADER = True``.
+    * List every reverse proxy allowed to assert the identity in
+      ``WEBSERVER_TRUSTED_PROXIES``.
+    * Configure your reverse proxy to strip *every* inbound spelling of the
+      header (any hyphen/underscore variant, in any case) before it sets its
+      own, so a client cannot smuggle a value past it.
+    * Optionally configure ``WEBSERVER_SHARED_SECRET`` /
+      ``WEBSERVER_SHARED_SECRET_HEADER`` as an additional proof that the
+      header was set by your proxy.
+
+    Without all of the above, pgAdmin does not trust a header-asserted
+    identity and login through it is rejected.
+
+.. warning::
+    A user matched via Webserver authentication is only logged in if their
+    *Authentication source* is *webserver*. This prevents a header-asserted
+    identity from ever logging into an account that was created some other
+    way - most importantly, the default administrator account created by
+    pgAdmin's own setup, whose *Authentication source* is *internal*.
+
+    If you are enabling Webserver authentication on a site that already has
+    users (including that default administrator) with an *Authentication
+    source* other than *webserver*, none of them will be able to log in
+    through Webserver authentication until you change it. To do so, sign in
+    through another configured authentication source and, for each such
+    user, set *Authentication source* to *webserver* on the
+    :ref:`User Management <user_management>` page. If ``AUTHENTICATION_SOURCES``
+    lists only *webserver*, there is no other source to sign in with -
+    temporarily add *internal* back to ``AUTHENTICATION_SOURCES``, sign in
+    with the internal administrator's password, fix the affected users'
+    *Authentication source*, then remove *internal* again.
+
+    See :ref:`Accounts from different authentication sources
+    <auth_source_accounts>` for more information.
 
 Master Password
 ===============

docs/proposals/2026-04-30-eliminate-rce-and-symlink-escape.md

@@ -1,872 +0,0 @@
-# Proposal: Eliminate Insecure Deserialization RCE and Symlink-based Path Traversal
-
-**Status:** Draft (v5 — addresses review findings of 2026-04-30, including end-to-end coherence pass)
-
-> **Note on line numbers:** Citations in this proposal are accurate as of `HEAD` of
-> `fix/pickle-rce` at v5 publication time. If upstream changes land in `session.py` or
-> `file_manager/__init__.py` before PR 1 merges, the implementing PR will recompute line
-> references against the rebase base.
-**Date:** 2026-04-30
-**Author:** Ashesh Vashi
-**Tracking branch:** `fix/pickle-rce`
-**Related:** Independent security report dated 2026-04-29; CVE-2024-2044 (prior RCE in
-SERVER_MODE=False)
-
----
-
-## 1. Problem Statement
-
-A security report dated 2026-04-29 identified two complementary vulnerabilities in pgAdmin 4
-(confirmed on v9.14) that, when combined, allow an authenticated user to achieve OS-level Remote
-Code Execution on the pgAdmin host or container.
-
-### 1.1 Vulnerability 1 — Insecure Deserialization Before HMAC Verification (CWE-502)
-
-**Location:** `web/pgadmin/utils/session.py:240-267` — `FileBackedSessionManager.get()`
-
-The session manager deserializes the session file with `pickle.load()` **before** verifying the
-HMAC integrity signature stored alongside it. Any file an attacker can place in the sessions
-directory is therefore executed unconditionally — `pickle.load()` fires arbitrary
-`__reduce__` hooks during reads, before any of the integrity checks run.
-
-The vulnerable sequence:
-
-1. `open(fname, 'rb')` and read all bytes.
-2. `pickle.load(f)` — RCE here.
-3. Compare the in-body HMAC against the cookie HMAC — too late.
-
-### 1.2 Vulnerability 2 — Symlink Escape in the File Manager (CWE-61 / CWE-22)
-
-**Location:** `web/pgadmin/misc/file_manager/__init__.py` — `check_access_permission()` at
-line 894 and the upload handler `add()` at line 1062.
-
-Both code paths use `os.path.abspath()`, which resolves `.` and `..` but does **not** resolve
-symbolic links. The subsequent `open(path, 'wb')` is performed by the OS kernel, which **does**
-follow symlinks. If a symlink exists inside the user's storage directory pointing outside the
-sandbox, the access check (path-string semantics) passes while the kernel write
-(filesystem semantics) follows the symlink.
-
-The same path-string-vs-kernel mismatch applies to `rename()` (line 990), `delete()` (line
-1037), and `download()` (line 1263), which all call `check_access_permission()` and then
-operate on the literal path via syscall.
-
-A separate timing bug in `add()`: the inline access check runs *before* `open()` (good) but
-`Filemanager.check_access_permission()` is *also* called *after* the file write at line 1104 —
-pointless, because the file is already on disk by then.
-
-### 1.3 Threat Model
-
-- Attacker has a valid pgAdmin login (any role suffices — no admin required).
-- Attacker can reach the file manager and session cookie surfaces.
-- Goal: OS-level command execution as the user running gunicorn/pgAdmin (root in the official
-  Docker image).
-- Out of scope: attackers who already have host shell or Docker volume write access; supply-chain
-  compromise.
-
-### 1.4 Severity
-
-CVSS v3.1 base score (per the report): **8.8 (High)**.
-
-| Attribute | Value |
-|---|---|
-| Attack vector | Network |
-| Privileges required | Low (any authenticated user) |
-| User interaction | None |
-| Confidentiality / Integrity / Availability | High / High / High |
-
-### 1.5 Attack chain feasibility — what the report does and does not prove
-
-The report demonstrates two scenarios. Both rely on a primitive the report **does not prove
-exists inside pgAdmin**:
-
-- **Scenario A (SERVER_MODE=False):** in this mode `check_access_permission()` returns
-  immediately without any check (see line 895). An authenticated user can directly upload a
-  payload to the sessions directory via the file manager. No symlink needed. **This is a
-  complete in-pgAdmin attack chain when `SERVER_MODE=False`** — and it's the likely vector for
-  the prior CVE-2024-2044.
-- **Scenario B (SERVER_MODE=True):** requires a symlink to be planted inside the user's
-  storage directory. The report says "create a symlink" but does not describe how to do this
-  through pgAdmin alone.
-
-A grep over the **entire `web/pgadmin/` tree** (not just file_manager) for symlink-creating
-primitives returns zero matches across all of:
-
-| Audit pattern | Matches in `web/pgadmin/` |
-|---|---|
-| `os.symlink` / `os.link(` / `symbolic_link` / `symlink_to` / `Path.symlink` / `.symlink(` | 0 |
-| `tarfile` / `zipfile` / `unpack_archive` / `extractall` / `extract_archive` / `shutil.copytree` (archive extraction can preserve symlinks from a malicious archive) | 0 |
-| `subprocess` / `os.popen` / shell-invocation primitives in `file_manager/` | 0 |
-
-The download endpoint serves files; the upload endpoint writes file *bodies*; no
-rename/move/extract handler creates links. **Therefore Scenario B is only exploitable when the
-attacker has an out-of-band way to plant a symlink** — host shell, Docker volume mount with
-shared storage, container escape, or a future pgAdmin feature that introduces a symlink
-primitive (e.g., archive extraction). This audit excludes the bundled
-`docker-entrypoint.sh`/runtime startup scripts, which run before user authentication and are
-not part of the user-facing attack surface.
-
-We close Vulnerability 2 anyway, as defense in depth: (a) prevents future regressions if such a
-primitive is introduced, (b) closes the path for deployments where the storage directory is
-shared with another writer, (c) the change is small and low-risk. But the spec does **not**
-claim Vulnerability 2 alone is a current authenticated-user RCE primitive in
-`SERVER_MODE=True`.
-
-### 1.6 Known residual issues not introduced or fixed by this proposal
-
-- **Session-file replay after logout.** A user who saves a copy of their valid, HMAC'd session
-  file and the matching cookie can `cp` the file back into the sessions directory after
-  logout-driven deletion, regaining their session. The current code has this property; the
-  Phase 1 design preserves it. Closing it requires a per-session-revision nonce that's
-  invalidated server-side on logout — out of scope for this proposal, tracked as a follow-up.
-- **Read-side information disclosure via symlink.** `download()` at line 1263 calls
-  `check_access_permission()` and `send_from_directory()`. Once `check_access_permission()`
-  uses `realpath()`, symlink-based reads are also blocked at the access-check layer. The
-  underlying TOCTOU caveat (§4.2.3) applies symmetrically to read.
-- **CSRF-token theft via session-file read (Scenario B step 3 of the report).** The report's
-  Scenario B requires the attacker to read the victim's session file from disk to extract the
-  raw `csrf_token`. This requires file-read access to the sessions directory — either via the
-  same out-of-band primitive needed to plant a symlink (host shell, Docker volume mount), or
-  via the file manager's `download()` endpoint pointed at the sessions directory through a
-  symlink. The realpath fix in §4.2.1 closes the symlink-based read path. Out-of-band
-  file-read access remains out of scope (§1.3 threat model). After this proposal lands, the
-  attacker's only remaining path to a session file's contents is host-level access, which
-  also yields easier RCE primitives directly.
-- **Residual `pickle.loads` callsites that operate on session-stored bytes (Phase 2 scope).**
-  After PR 1's HMAC-header gate on the session file, no attacker-controlled bytes can reach
-  `pickle.loads` via the session-on-disk path. However, several modules unpickle values that
-  were themselves placed inside `flask.session` by pgAdmin's own write paths. These are safe
-  *as long as the write paths cannot be influenced by attackers*, but they remain
-  insecure-deserialization vectors that should be eliminated in Phase 2 / PR 7. Enumerated
-  here so future reviewers see the surface:
-    - `web/pgadmin/tools/sqleditor/__init__.py`: `import pickle` at line 12; `pickle.loads`
-      at lines 320, 795, 854, 1857, 1935; `pickle.dumps` at lines 334, 628, 962, 1178, 1235,
-      1348, 1642, 1698, 1739, 1783, 1992 (the `command_obj` round-trip).
-    - `web/pgadmin/tools/sqleditor/utils/start_running_query.py`: lines 12, 53, 207.
-    - `web/pgadmin/tools/sqleditor/utils/query_tool_connection_check.py`: lines 11, 33.
-    - `web/pgadmin/tools/sqleditor/utils/filter_dialog.py`: lines 11, 97.
-    - `web/pgadmin/tools/schema_diff/__init__.py`: `import pickle` at line 12; `pickle.loads`
-      at line 184; `pickle.dumps` at lines 197, 225 (the `diff_model_obj` round-trip).
-    - `web/pgadmin/misc/bgprocess/processes.py`: `from pickle import dumps, loads` at line 20;
-      used at lines 162, 164, 251, 704, 706 to round-trip the BatchProcess descriptor stored
-      in the SQLite `process` table. This one is interesting because it deserializes from the
-      database, not the session — same risk class but a different threat surface (host-local
-      DB write access).
-
----
-
-## 2. Goals
-
-1. **Close both vulnerabilities** in shippable, independently reviewable units of work.
-2. **Eliminate `pickle` from the pgAdmin web codebase entirely** as a long-term defence-in-depth
-   measure, not just from `session.py`. The same module is also used inside the cloud provider
-   handlers and the SQL editor's grid state.
-3. **No regressions** in: login (internal, OAuth2, LDAP, Kerberos, Webserver, MFA), cloud
-   deployment wizards (RDS, Azure, Google, BigAnimal), Query Tool, Schema Diff, Debugger.
-4. **No silent data loss** for active sessions on upgrade where avoidable. Sessions written by
-   pre-fix code will be invalidated (one-time re-login). Operators are alerted via a single
-   warning log line per rejected sid (see §4.3).
-
-## 3. Non-goals
-
-- Changing the cookie format or HMAC algorithm of the cookie.
-- Changing the session storage backend (still file-backed with HMAC).
-- Refactoring the `Filemanager` class beyond what's needed for the symlink fix.
-- Deprecating `SERVER_MODE=False` (orthogonal concern).
-- Closing session-file replay-after-logout (§1.6).
-
----
-
-## 4. Design
-
-### 4.1 Vulnerability 1 — Two-phase fix
-
-#### Phase 1 (urgent): HMAC-first verification with a plaintext header
-
-`pickle` stays as the on-disk format **temporarily**, but is gated behind an HMAC verified from
-a plaintext header that lives outside the serialized blob.
-
-**File format (new):**
-
-```
-+----------------------------------------------------+
-| H bytes : hex HMAC over the body, ASCII-encoded   |
-+----------------------------------------------------+
-| N bytes : pickle body — (randval, digest, data)   |
-+----------------------------------------------------+
-```
-
-`H` is determined by the chosen digest algorithm: `len(hmac.new(...).hexdigest()) ==
-2 * digest_size`. For SHA-256, `H = 64`. We use **SHA-256** for the file HMAC regardless of
-`config.SESSION_DIGEST_METHOD` (which defaults to SHA-1 — see §8 Open Question 1). The HMAC is
-computed with `app.config['SECRET_KEY']` over the body bytes.
-
-**Read path (new):**
-
-```python
-import hmac
-import hashlib
-import pickle
-import logging
-
-_FILE_HMAC = hashlib.sha256
-_HMAC_HEX_LEN = _FILE_HMAC().digest_size * 2  # 64 for SHA-256
-
-logger = logging.getLogger(__name__)
-
-def _compute_file_hmac(secret, body: bytes) -> bytes:
-    # Flask's SECRET_KEY may be str or bytes; normalize before HMAC.
-    key = secret.encode() if isinstance(secret, str) else secret
-    return hmac.new(key, body, _FILE_HMAC).hexdigest().encode()
-
-def get(self, sid, digest):
-    fname = safe_join(self.path, sid)
-    if fname is None or not os.path.exists(fname):
-        return self.new_session()
-    try:
-        with open(fname, 'rb') as f:
-            header = f.read(_HMAC_HEX_LEN)
-            body = f.read()
-        if len(header) != _HMAC_HEX_LEN or len(body) == 0:
-            # 0-byte file from new_session(), or pre-fix session file. Silently
-            # discard; Phase 1 deployment expects one-time re-login churn.
-            return self.new_session()
-        expected = _compute_file_hmac(self.secret, body)
-        if not hmac.compare_digest(header, expected):
-            logger.warning(
-                "session file rejected: bad file-HMAC for sid=%s", sid[:8]
-            )
-            return self.new_session()
-        randval, hmac_digest, data = pickle.loads(body)  # safe: body is verified
-    except (pickle.UnpicklingError, EOFError, OSError, MemoryError, ValueError, TypeError):
-        # Narrow catch: silently invalidate corrupted/unreadable session files.
-        # Programming errors (AttributeError, NameError, etc.) propagate intentionally
-        # so they show up in tests and logs rather than being masked as new_session().
-        return self.new_session()
-    if hmac_digest != digest:
-        return self.new_session()
-    return ManagedSession(data, sid=sid, randval=randval, hmac_digest=hmac_digest)
-```
-
-**Write path (new):**
-
-```python
-def put(self, session):
-    ...
-    # The existing disk_write_delay and skip_paths skip logic at lines 271-285
-    # is preserved verbatim — only the format step below changes.
-    body = pickle.dumps(
-        (session.randval, session.hmac_digest, dict(session)), -1
-    )
-    header = _compute_file_hmac(self.secret, body)
-    fname = safe_join(self.path, session.sid)
-    with open(fname, 'wb') as f:
-        f.write(header)
-        f.write(body)
-```
-
-**Defensive precondition (`__init__`):** raise on empty `SECRET_KEY`:
-
-```python
-if not self.secret:
-    raise RuntimeError("SECRET_KEY must be non-empty")
-```
-
-`assert` is **not** acceptable here — Python's `-O` flag strips assertions, which would silently
-disable the security-critical check in optimized production builds. Pre-fix code shares the
-implicit non-empty assumption, but an empty `SECRET_KEY` reduces the file-HMAC to a known-key
-MAC, and a security-driven redesign is the right time to fail fast.
-
-**Performance.** HMAC-SHA256 over typical session bodies (<10 KB) costs <100 µs per request on
-modern x86-64. Sessions exceeding 1 MB (rare; large `gridData` with cloud-handler bytes blobs)
-will see sub-millisecond overhead. No measurable production impact expected. Confirmed by
-inspection — the read path was already `f.read()`-bound on full file bytes, so the additional
-work is one `hmac.new(...).hexdigest()` per request.
-
-**Important note on the report's Fix 1.** The report's suggested "HMAC-first" code calls
-`pickle.loads(raw)` once just to read the stored HMAC — which is the exact line that fires
-the RCE. The plaintext-header design above avoids that: the HMAC is verified against raw bytes
-before any deserialization.
-
-**Migration:** files written by the old code (no header) fail the header check and are silently
-discarded — affected sessions get a fresh `new_session()`. One-time re-login on upgrade.
-Operators see a transient burst of `session file rejected` warnings during rollout, then they
-quiesce.
-
-**Empty-file behavior.** `new_session()` at line 218-238 creates a 0-byte placeholder. The next
-`get()` reads short (< 64 bytes) header + empty body, falls through to `new_session()`.
-Subsequent `put()` writes the full header + body. This matches the existing behavior of the old
-code (where `pickle.load` on 0 bytes raised, was caught, and fell through to `new_session()`).
-No regression.
-
-**Concurrent `put()` from multiple workers.** Two workers writing the same sid race on the
-file. `open(fname, 'wb')` truncates atomically; the worst case is interleaved writes producing
-a header/body mismatch. The next `get()` recomputes the file-HMAC, fails verification, logs
-the warning, and returns `new_session()`. **Race-tolerant by design** — partial writes can
-never produce an executable payload because they cannot satisfy the HMAC. The pre-fix code
-shared the same race shape but with `pickle.load` instead of HMAC validation; not a
-regression.
-
-**Caching layer.** `CachingSessionManager` (session.py:104-196) wraps
-`FileBackedSessionManager`. Cache hits use the cached `ManagedSession.hmac_digest` for the
-cookie compare; cache misses go through `parent.get()`, which performs the new file-HMAC
-check. The cache is only populated from a verified disk read (or from `new_session()`), so the
-file-HMAC check is enforced **at every cache miss** — including LRU evictions (`_normalize`
-trims to 80% capacity once size exceeds `num_to_store=1000`) and writes (`put()` invalidates
-the cached entry). No additional change needed here.
-
-#### Phase 2 (defence in depth): switch to plain JSON
-
-After Phase 1 ships, refactor every site that stashes a Python object or `pickle.dumps(...)`
-bytes inside `flask.session` so that the session contains only data primitives. Once the
-session contents are pure JSON-safe types, the on-disk format switches from pickle to plain
-JSON, and `pickle` is removed from the web codebase entirely.
-
-The session's purpose is to hold **identity and state pointers**, not live SDK clients. The
-existing `__pgsql_server_managers` pattern (`web/pgadmin/utils/driver/psycopg3/server_manager.py:519-530` —
-stores `as_dict()` in session, keeps live `ServerManager` instances in module-global state) is
-the template.
-
-**Per-site refactor (verified by grep):**
-
-| Site (file:line) | Current | Replacement |
-|---|---|---|
-| `web/pgadmin/authenticate/__init__.py:113` | `session['auth_obj'] = AuthSourceManager(...)` (live object) | Store source name; reconstruct `AuthSourceManager` in OAuth2 callback (`oauth2.py:55`) |
-| `web/pgadmin/misc/cloud/azure/__init__.py:89` | `session['azure']['azure_obj'] = Azure(...)` (live object) | Store `authentication_record_json` + tenant/auth_type/cache_name; rebuild `Azure` per request via process-local cache keyed by sid. **See §5.4 for an unverified-claims caveat.** |
-| `web/pgadmin/misc/cloud/rds/__init__.py:73` | `session['aws']['aws_rds_obj'] = pickle.dumps(_rds, -1)` | Store credentials dict; rebuild `RDS` from process-local cache. 1 write, 2 reads (lines 73, 100, 129). |
-| `web/pgadmin/misc/cloud/google/__init__.py:110` | `session['google']['google_obj'] = pickle.dumps(...)` (4 write sites: 110, 129, 145, 181) | Store credentials/state dict; rebuild `Google` from process-local cache. |
-| `web/pgadmin/misc/cloud/biganimal/__init__.py:73` | `session['biganimal']['provider_obj'] = pickle.dumps(...)` (4 write sites: 60, 73, 95, 106) | Same pattern. |
-| `web/pgadmin/tools/sqleditor/__init__.py` (lines 338, 632, 699, 740 write `session['gridData']`; the per-trans `command_obj` field holds `pickle.dumps(transaction, -1)` produced in `tools/sqleditor/utils/start_running_query.py:204-208`, where the local `session` parameter is later persisted via `update_session_grid_transaction`) | serialized `Command` bytes inside a session-resident dict | Store command kind + identifying inputs; rebuild `Command` via `from_state()`; cache PG metadata in process-local TTL cache. **High risk — see §5.4.** |
-
-**Process-local cache pattern (illustrative):**
-
-```python
-# Module-level
-_azure_cache: dict[str, tuple[float, Azure]] = {}
-_AZURE_CACHE_TTL = 600  # seconds
-
-def get_azure_for_session(sid: str) -> Azure:
-    now = time.monotonic()
-    cached = _azure_cache.get(sid)
-    if cached and (now - cached[0]) < _AZURE_CACHE_TTL:
-        return cached[1]
-    state = session['azure']                 # JSON-safe dict only
-    obj = Azure.from_state(state)            # new constructor
-    _azure_cache[sid] = (now, obj)
-    return obj
-```
-
-Eviction: lazy on read (TTL check) and on logout (`_azure_cache.pop(sid, None)`).
-
-**Worker-restart UX trade-off (Azure).** Today's behavior pickles the live `Azure` (with its
-populated SDK client cache) into the session file, so a worker restart preserves Azure auth
-state. After Phase 2, the in-memory client cache is gone on restart. Whether the user is
-re-prompted for device-code on the next request depends on whether
-`authentication_record_json` is sufficient to silently rebuild the credential. **This is
-unverified** (see §5.4) and must be confirmed during the Azure refactor PR before merge. If
-re-prompting is unavoidable, that is a UX regression — Phase 1 ships independently and is not
-gated on resolving this.
-
-#### Final state
-
-- `web/pgadmin/utils/session.py`: `from json import dumps, loads` replaces `from pickle import
-  dump, load`. HMAC header retained.
-- All `import pickle` and `from pickle import ...` lines in the web tree removed (except in
-  test fixtures, by deliberate exception).
-- CI guard (proposed): `grep -rEn '^\s*(import pickle\b|from pickle\b)' web/pgadmin/ | grep -v
-  '/tests/'` must return empty.
-
-### 4.2 Vulnerability 2 — `realpath`, syscall hardening, and ordering fix
-
-#### 4.2.1 `check_access_permission` — realpath both sides
-
-At `web/pgadmin/misc/file_manager/__init__.py:913-940` (definition starts at line 913 in the
-implemented branch), replace `os.path.abspath()` with `os.path.realpath()` for both
-`orig_path` and `in_dir`. The `in_dir` argument must also be
-resolved through `realpath()` — otherwise a symlinked storage root would compare unequal to a
-resolved target path, breaking legitimate access.
-
-Python 3.9+ semantics (pgAdmin's documented floor — see `web/pgAdmin4.wsgi:14` and
-`README.md:23`): `os.path.realpath(path)` resolves symlinks for components that exist and
-leaves not-yet-existing tail components as literal text. This is the correct semantics for
-upload paths.
-
-**Windows behavior is believed correct in Python 3.9+ but unverified by this proposal.**
-CPython release notes indicate `ntpath.realpath` resolves NTFS junctions and symbolic links via
-`GetFinalPathNameByHandle`, with several bug fixes landed across 3.10/3.11. Verification on
-Windows is a **PR-1 merge gate**: a smoke test creates a junction, calls `realpath`, and asserts
-the resolved path matches the target. This test must pass on the lowest supported Python
-(3.9.x) before PR 1 merges.
-
-#### 4.2.2 Upload handler `add()` — realpath, ordering, and `O_NOFOLLOW`
-
-Three changes at `web/pgadmin/misc/file_manager/__init__.py:1087-1132` (definition at line
-1087 in the implemented branch):
-
-1. Replace `os.path.abspath` with `os.path.realpath` in the inline check (line 1112), and
-   resolve `the_dir` through `realpath` too (line 1114).
-2. Delete the dead post-write `Filemanager.check_access_permission(the_dir, path)` call.
-   The inline check above already covers it, the file is on disk by the time it
-   runs, and replicating the same check at two granularities is bug-prone.
-3. **Replace `open(new_name, 'wb')` with `os.open(...)` + `O_NOFOLLOW`** (now extracted to
-   the module-level helper `_open_upload_target` at line 52) to close the leaf-component
-   TOCTOU gap between the access check and the syscall:
-
-```python
-fd = os.open(
-    new_name,
-    os.O_WRONLY | os.O_CREAT | os.O_TRUNC
-        | getattr(os, 'O_NOFOLLOW', 0),
-    0o600,
-)
-with os.fdopen(fd, 'wb') as f:
-    while True:
-        data = file_obj.read(4194304)
-        if not data:
-            break
-        f.write(data)
-```
-
-`O_NOFOLLOW` causes the kernel to refuse to open the path if its **final** component is a
-symlink. Combined with `realpath`-based directory resolution at check time, this closes the
-**leaf-component race** where another worker plants a symlink at the leaf between check and
-open. **Intermediate-component races remain unmitigated** and rely on §1.5 reasoning (no
-in-pgAdmin primitive can plant the directory symlinks needed to exploit them).
-
-Windows: `os.O_NOFOLLOW` is not defined on Windows. The `getattr(..., 0)` fallback above makes
-the flag a no-op on Windows. This leaves a small residual leaf-component TOCTOU on Windows,
-mitigated by the absence of the symlink-creation primitive.
-
-**Intentional mode change (0o644 → 0o600).** The pseudocode passes mode `0o600` to `os.open`,
-restricting uploaded files to owner-only. The current code uses `open(name, 'wb')` which
-applies the umask-default (typically `0o644`, world-readable). The change is intentional
-hardening — uploaded files are user-private session artifacts and have no need for
-world-read access — but it **is** a behavioral change. Release notes must call this out so
-operators relying on cross-user readability of uploaded files (uncommon) can adjust.
-
-#### 4.2.3 Cover `rename`, `delete`, `download`
-
-These all call `check_access_permission()` and then operate on the literal path via
-`os.rename`, `os.rmdir`/`os.remove`, and `send_from_directory` respectively. Once
-`check_access_permission()` is realpath-based:
-
-- **`rename` (definition at line 1015 in the implemented branch):** `os.rename` does not follow symlinks at the leaf for either source
-  or destination — it renames the link itself, not the target. Intermediate-component symlinks
-  in the destination path *would* route through the link at the kernel level (same shape as
-  upload TOCTOU). Python's stdlib does not expose `renameat2` flags, so there is no clean
-  `O_NOFOLLOW` analog for rename. **Residual TOCTOU on intermediate components is accepted**
-  under §1.5 reasoning (no in-pgAdmin symlink primitive). Realpath-based access check at T1 is
-  the only layer of defense.
-- **`delete` (definition at line 1062):** `os.rmdir` and `os.remove` operate on the leaf,
-  not the target. No additional change required.
-- **`download` (definition at line 1287):** Werkzeug 3.1.* (`requirements.txt:65`) provides
-  `send_from_directory`, which uses `werkzeug.security.safe_join` for `..`-traversal
-  protection. `safe_join` does NOT call `realpath` and does NOT protect against symlinks —
-  verified by reading the werkzeug 3.x source. Our `check_access_permission()` (post-§4.2.1)
-  is therefore the **sole** symlink defense for downloads. TOCTOU between check and
-  `send_from_directory`'s file open is symmetric to upload (§4.2.2) and not closeable from
-  Python without bypassing `send_from_directory`. Residual TOCTOU accepted under §1.5.
-
-A separate latent bug — `Filemanager.check_access_permission(the_dir,
-"{}{}".format(path, path))` in `download` — concatenates `path` with itself. This is
-unrelated to the security fix and is tracked as a separate cleanup ticket.
-
-#### 4.2.4 `addfolder` (mkdir endpoint)
-
-`addfolder` (definition at line 1256 in the implemented branch) calls
-`Filemanager.check_access_permission(user_dir, path+name)` before `os.mkdir(create_path)`. Once §4.2.1 fixes `check_access_permission`, intermediate-
-symlink resolution is caught at the access-check layer. `os.mkdir` itself does not create
-symlinks — it creates a real directory at the literal path — so even a TOCTOU race cannot
-escalate to symlink creation. No additional change required for this endpoint.
-
-#### 4.2.5 Audit — sites covered by the Vulnerability 2 fix
-
-This table enumerates the sites involved in the symlink-escape fix, not every path-handling
-site in `file_manager/__init__.py`. Other `open()` / `os.path.*` calls in the file (e.g., file
-encoding detection at line 438, `read_file_generator` at line 108) are not security-relevant
-to Vuln 2 and are out of scope.
-
-Line numbers below are as of the implemented branch (`fix/pickle-rce`).
-
-| Line | Function / Site | Resolution |
-|---|---|---|
-| 924 | `check_access_permission` — was `os.path.abspath`, now `os.path.realpath` | §4.2.1 |
-| 936 | `check_access_permission` — `in_dir` realpath | §4.2.1 |
-| 1112 | `add` (inline upload check) — was `os.path.abspath`, now `os.path.realpath` | §4.2.2 |
-| 1119 | `add` — was `open(new_name, 'wb')`, now `_open_upload_target(new_name)` | §4.2.2 |
-| 52 | new module-level `_open_upload_target` helper — `os.open` + `O_NOFOLLOW` + 0o600 | §4.2.2 |
-| (in `rename`, line 1015) | `os.rename(oldpath_sys, newpath_sys)` | Covered by §4.2.1 realpath; intermediate-component TOCTOU accepted (§4.2.3) |
-| (in `delete`, line 1062) | `os.rmdir` / `os.remove` | Leaf-only operation, no additional change (§4.2.3) |
-| (in `download`, line 1287) | `send_from_directory` | Covered by §4.2.1 realpath at access check (§4.2.3) |
-| (in `addfolder`, line 1256) | `os.mkdir` | Covered by §4.2.1 realpath (§4.2.4) |
-
-All identified sites are covered. **Out-of-scope for this proposal:** `os.path.abspath`
-callsites elsewhere in `web/pgadmin/` have not been exhaustively audited. A follow-up
-security review is in scope for tracking, but is not gated on this proposal.
-
-### 4.3 Tests
-
-#### 4.3.1 New regression tests
-
-1. **Unsafe-payload session rejection (Vuln 1):** drop a hand-crafted file in the sessions
-   directory containing a `pickle` payload whose `__reduce__` writes a sentinel file. Issue a
-   request with that sid in the cookie. Assert (a) the sentinel is **not** created, (b) the
-   request gets a fresh session, (c) a single `session file rejected: bad file-HMAC`
-   warning is logged.
-2. **Header-tampered session rejection:** write a session with a corrupted HMAC header (flip
-   one byte). Assert `get()` returns a fresh session, no exception leaks, warning logged.
-3. **Empty-file passthrough:** create a 0-byte file at `sessions/<sid>` (the post-`new_session()`
-   state). Assert `get()` returns a fresh session, **no warning** (this case is expected).
-4. **Symlink escape rejection (Vuln 2, SERVER_MODE=True):** create a symlink inside the user's
-   storage dir pointing to `/tmp` (or another out-of-sandbox path). Attempt an upload. Assert
-   the upload is denied **and** no file is created at the symlink target.
-5. **`O_NOFOLLOW` leaf-symlink rejection (Linux/macOS):** pre-plant a symlink at the upload
-   target leaf path (no race needed — test the *property*, not the timing). Attempt upload.
-   Assert `OSError` is raised with `errno.ELOOP` (Linux) or `errno.EMLINK` (macOS) and no file
-   exists at the symlink target afterward. *Skip on Windows* (no `O_NOFOLLOW`).
-6. **Upload happy path:** confirm legitimate uploads still succeed in both `SERVER_MODE=False`
-   and `SERVER_MODE=True`.
-7. **MFA login flow regression:** cover at least one full MFA email and authenticator login
-   round-trip. The MFA fields are JSON-safe but the test suite should exercise them.
-8. **Cookie-HMAC mismatch with valid file-HMAC:** write a session file with a valid file-HMAC
-   header but a `hmac_digest` inside the body that does NOT match the cookie-supplied digest.
-   Assert `get()` returns a fresh session, **and** assert the `session file rejected:
-   bad file-HMAC` warning is **not** logged (this is a cookie-binding mismatch, not a
-   file-tamper event; current proposal does not log cookie mismatches to avoid noise from
-   normal cookie-tampering attempts).
-9. **Round-trip:** construct a `ManagedSession`, call `session.sign(secret)` to populate
-   `randval` and `hmac_digest` (a `put()` precondition; `put()` itself calls `sign()` on
-   first write but a deterministic test should pre-sign), call `put()`, then `get()` with the
-   matching cookie. Assert the returned `ManagedSession` has the same `data`, `randval`,
-   `hmac_digest` as the input. Without this, a `put()` regression silently breaks every
-   session save.
-10. **SERVER_MODE=False direct upload to sessions dir:** unit test against
-    `FileBackedSessionManager.get()` directly (preferred over a full integration test to
-    avoid Flask/CSRF setup). Write a malicious pickle file to the sessions path that
-    `safe_join(self.path, sid)` would resolve to. Call `get(sid, fake_digest)`. Assert
-    (a) `pickle.loads` does not execute the payload (sentinel not created), (b) `get()`
-    returns a fresh session, (c) the file-HMAC warning is logged. This validates the
-    Scenario A chain from §1.5 is closed at the session-read layer regardless of whether
-    `SERVER_MODE` permits the upload.
-
-#### 4.3.2 Existing tests to update
-
-- `web/pgadmin/browser/tests/test_oauth2_with_mocking.py` — uses `session['oauth2_token']`
-  (already a dict); verify it continues to pass.
-- Cloud-wizard tests using legacy serialized fixtures — update to dict fixtures during the
-  per-provider PR.
-
-#### 4.3.3 Manual verification
-
-- All four cloud deployment wizards end-to-end (RDS, Azure, Google, BigAnimal).
-- OAuth2 login round-trip with a real provider.
-- Query Tool: execute, page, edit cell, transactions, savepoint, BYTEA result.
-- Debugger: at least one direct-debug session.
-
----
-
-## 5. Blast Radius
-
-### 5.1 Phase 1 (PR 1)
-
-| Aspect | Estimate |
-|---|---|
-| Source files modified | 2 (`web/pgadmin/utils/session.py`, `web/pgadmin/misc/file_manager/__init__.py`) |
-| Test files added/modified | ~2 |
-| LOC changed | Source: ~80–110 (session HMAC logic ~50–80, file_manager realpath/O_NOFOLLOW/coverage ~30). Tests: ~250–400 (10 regression tests in §4.3.1, ~25–40 LOC each plus shared fixtures). **Total ~350–500.** |
-| Behavioural change | Sessions written by old code become unreadable → users re-login once on upgrade. One transient warning logged per rejected sid. |
-| Risk | **Low.** Self-contained, well-bounded, easy to review. |
-
-### 5.2 Phase 2 — verified site counts
-
-Per-feature breakdown (all numbers verified by grep):
-
-| Feature | Files | `pickle.dumps` writes | `pickle.loads` reads | Risk | Rationale |
-|---|---|---|---|---|---|
-| `auth_obj` (OAuth2 login) | `authenticate/__init__.py`, `authenticate/oauth2.py` | 0 (live object stored directly) | 0 (live object read directly) | Medium | Login path — regression locks users out. Test against a real OAuth2 provider before merge. |
-| Azure cloud | `misc/cloud/azure/__init__.py` | 0 (live object stored directly at line 89) | 0 (read directly at lines 117, 138, 152, 164, 175, 189, 202, 216, 228, 692, …) | **High (verification gated)** | See §5.4. |
-| AWS RDS cloud | `misc/cloud/rds/__init__.py` | 1 (line 73) | 2 (lines 100, 129) | Medium | Few sites; boto3 client recreation should be cheap (assumed — verify per §5.4). |
-| Google cloud | `misc/cloud/google/__init__.py` | 4 (lines 110, 129, 145, 181) | 10 (lines 95, 127, 143, 161, 179, 199, 220, 241, 307, …) | Medium | Refactor: 1 `from_state()` constructor + ~10 callsites converted from `pickle.loads(...)` to `get_google_for_session(sid)`. |
-| BigAnimal cloud | `misc/cloud/biganimal/__init__.py` | 4 (lines 60, 73, 95, 106) | 11 (lines 57, 83, 93, 104, 115, 125, 137, 150, 162, 528, …) | Medium | Same shape as Google. |
-| SQL editor — `command_obj` producer | `tools/sqleditor/utils/start_running_query.py:204-208` | 1 (`pickle.dumps` at line 207, into a per-trans dict later persisted via `update_session_grid_transaction`) | 0 | **High (verification gated)** | See §5.4 item 4. |
-| SQL editor — Flask-session reads/writes | `tools/sqleditor/__init__.py` | gridData writes at lines 338, 632, 699, 740 | 1 (`pickle.loads` at line 1935) | **High (verification gated)** | The per-trans dict containing `command_obj` lives inside `session['gridData']`. Refactor: store command kind + identifying inputs; rebuild `Command` via `from_state()`; cache PG metadata in process-local TTL cache. |
-| Final swap (`session.py` to JSON) | `utils/session.py` | n/a | n/a | Low | Trivial once Phase 2 lands. |
-
-**Total source files touched (Phase 1 + Phase 2):** 8 (files), 2 of which are big files
-(`misc/cloud/google/__init__.py`, `misc/cloud/biganimal/__init__.py`).
-**Total LOC changed (rough):** 600–900 across Phase 2.
-**PR count target:** 6–7 (one per feature plus the final swap).
-
-> **Note on the two SQL-editor rows above:** they describe the same logical refactor but split
-> by file. The producer row covers where `pickle.dumps` is called; the Flask-session row
-> covers how that pickled blob enters and exits the `flask.session['gridData']` dict. Both
-> rows are addressed by a single PR (PR 7).
-
-### 5.3 Failure modes considered
-
-- **Existing session files lost on upgrade:** users re-login once. Expected; called out in
-  release notes.
-- **Process restart drops in-memory caches (cloud SDKs):** users may need to re-authenticate
-  against the cloud provider on the next request after a worker recycle. **Differs from
-  today's behavior for Azure** (see §5.4 and §4.1 Phase 2).
-- **`session['azure']` grows because state replaces object:** dict holds ~5 primitive fields,
-  far below the file-write size threshold.
-
-### 5.4 Unverified claims that gate merge of specific PRs
-
-These claims appear in the spec or its rationale and are **not yet evidence-backed**. They must
-be verified during the relevant PR before merge:
-
-1. **Azure: `authentication_record_json` is sufficient to silently rebuild the credential
-   without re-prompting the user for device code.** The class clearly persists the auth record
-   and supports rebuilding the credential from it (`misc/cloud/azure/__init__.py:298-322`),
-   *but* whether **all** ~12 Azure endpoints work after a per-request rebuild has not been
-   end-to-end tested. Verification: run the Azure cloud wizard end-to-end after Phase 2 with
-   the in-memory cache disabled; confirm no re-prompt.
-2. **boto3 RDS clients are cheap to recreate from credentials dict.** Generally true; SSO/STS
-   token-cache state may complicate it. Verification: run the RDS wizard end-to-end across a
-   simulated worker restart.
-3. **Google Cloud SDK clients are reconstructable from refresh-token credentials.**
-   Refresh-token flows typically work; OAuth-installed-app flows with one-time auth codes do
-   not. Verification: run the Google wizard end-to-end across a simulated worker restart.
-4. **The `Command` subclass tree in sqleditor is amenable to a `from_state()` constructor.**
-   The proposal author has not yet read the Command hierarchy. The refactor PR (PR 7) starts
-   with an audit that may reveal additional design work; the spec marks this PR as **High
-   risk, scope-revisit on audit**.
-
-   **Fallback if PR 7 is intractable:** If the audit concludes the refactor is more than ~2
-   weeks of work (e.g., the `Command` tree has deep coupling to live cursor state),
-   the spec resolves the conflict as follows:
-   - **Option A (preferred):** ship Phase 2 without sqleditor. The CI guard at PR 8 carves
-     out `web/pgadmin/tools/sqleditor/` as a documented exception, with a TODO and tracking
-     issue. Concrete encoding: sqleditor stores the pickled `Command` bytes
-     **base64-encoded into a JSON string field** inside `session['gridData'][trans_id]`.
-     The outer JSON session body is HMAC-protected by Phase 1's file-HMAC, so the encoded
-     bytes cannot be tampered with from the disk side. **Caveat:** `pickle.loads` still runs
-     on those bytes inside sqleditor on every read. If any other code path can write to
-     `gridData` with attacker-controlled content (an unrelated bug), the RCE primitive
-     returns. This is a strictly weaker guarantee than full pickle removal — Option A is a
-     scope-management choice, not a security equivalence.
-   - **Option B (rejected unless A is infeasible):** keep pickle in `session.py` itself, do
-     not migrate to JSON, accept the ongoing footgun across the entire session surface.
-
-   PR 7 author chooses A or B based on the audit; spec is amended in the PR description with
-   the rationale.
-
----
-
-## 6. Implementation Plan
-
-### 6.1 PR sequencing
-
-1. **PR 1 — Close the CVEs.** HMAC-header redesign in `session.py`; in `file_manager`:
-   `realpath` (§4.2.1), `O_NOFOLLOW` and dead-check removal in upload (§4.2.2),
-   access-check coverage for `rename`/`delete`/`download` (§4.2.3) and `addfolder` (§4.2.4).
-   Tests: **all 10 items** in §4.3.1. *Ships first, separately, with a security advisory.*
-2. **PR 2 — `auth_obj` data-only refactor.** Removes the live `AuthSourceManager` from the
-   session.
-3. **PR 3 — Azure cloud refactor.** Includes verification step §5.4 item 1.
-4. **PR 4 — AWS RDS cloud refactor.** Includes verification §5.4 item 2.
-5. **PR 5 — Google cloud refactor.** Includes verification §5.4 item 3.
-6. **PR 6 — BigAnimal cloud refactor.**
-7. **PR 7 — SQL editor `command_obj` refactor.** Begins with a Command-tree audit
-   (verification §5.4 item 4); scope may grow.
-8. **PR 8 — Final swap: `session.py` to plain JSON, delete `pickle` imports, add CI guard.**
-
-PRs 2–7 are independent and can land in any order. **PR 8 has a hard dependency on PRs 2–7
-all having merged** — until every `pickle` site is removed, the JSON swap will fail to
-serialize live objects or pickled-bytes blobs.
-
-### 6.2 Rollback strategy
-
-Each PR is reverted independently if a regression is discovered post-merge. PR 1 has no
-in-codebase compatibility shim — a revert of PR 1 restores the pre-fix vulnerable behavior,
-which is unacceptable. **The team commits to fix-forward only for PR 1: any post-merge
-regression is resolved by a same-day hotfix, never by a revert.** This commitment requires
-on-call availability during the release window; the security advisory cannot publish without
-this commitment in place.
-
-PRs 2–7 each remove a `pickle` site without changing the on-disk format; reverting any of them
-is safe and does not re-open RCE (since PR 1 already gates the on-disk read).
-
-PR 8 (the JSON swap) carries upgrade risk for sessions written by PRs 1-7's pickle-with-header
-format. Format-detection on read after PR 8: the file-HMAC header is still validated first
-(same algorithm), then `json.loads(body)` is attempted. A pre-PR-8 pickle body fails JSON parse
-with `JSONDecodeError`, falls through to `new_session()`, and a warning is logged. **No
-execution path through `pickle.loads` remains in `session.py` post-PR-8** — a malicious or
-legitimate pickle file is rejected at JSON parse, never deserialized. One-time re-login at PR 8
-release; warning logged per dropped sid.
-
-### 6.3 Multi-instance / HA note
-
-pgAdmin is typically deployed single-instance. If two replicas share a sessions directory, both
-must upgrade together: in **both directions**, the receiver fails to parse the format and
-silently invalidates the session (old code reading a header'd file fails on `pickle.load` of
-ASCII hex; new code reading a header-less file fails the HMAC length check). No data loss
-beyond a one-time re-login per affected user, but operators must coordinate the upgrade window.
-Document in release notes.
-
-**Mixed-version Python workers (rare):** `pickle.dumps(..., -1)` selects `HIGHEST_PROTOCOL`
-which varies by Python version (3.9 → protocol 5; 3.13 → protocol 5; 3.14 → 5). A protocol
-written by a newer worker and read by an older worker may fail to deserialize. Pre-existing
-assumption that all workers in a deployment run the same Python; not introduced by this
-proposal. After PR 8 (JSON swap), this concern disappears entirely.
-
-### 6.4 Acceptance criteria
-
-**PR 1 (security fix):**
-- [ ] All 10 regression tests in §4.3.1 added and passing.
-- [ ] Defensive non-empty-`SECRET_KEY` check added in `FileBackedSessionManager.__init__`
-      (raise, not assert).
-- [ ] `_compute_file_hmac` accepts both `str` and `bytes` for `secret`.
-- [ ] Round-trip test (§4.3.1 test 9) passes — confirms `put()` produces a file readable by
-      `get()`.
-- [ ] Windows realpath smoke test (§4.2.1) passes on Python 3.9.x.
-- [ ] CVE assigned and security advisory drafted; advisory publishes on the PR-1 release.
-- [ ] On-call coverage confirmed for PR-1 release window (per §6.2 fix-forward commitment).
-
-**Each of PR 2-7 (per-feature refactor):**
-- [ ] Corresponding §5.4 verification item passes (where applicable: Azure → item 1, RDS →
-      item 2, Google → item 3, sqleditor → item 4; auth_obj and BigAnimal have no §5.4 entry).
-- [ ] No regression in the relevant feature's existing test suite.
-- [ ] Manual verification per §4.3.3 for the affected feature (cloud wizard end-to-end,
-      OAuth2 round-trip, or Query Tool sweep).
-- [ ] No new `pickle` site introduced in any other file (regression check).
-
-**PR 8 (final pickle removal):**
-- [ ] `grep -rEn '^\s*(import pickle\b|from pickle\b)' web/pgadmin/ | grep -v '/tests/'`
-      returns empty (or returns only the documented sqleditor exception per §5.4 item 4
-      Option A).
-- [ ] All four cloud wizards verified end-to-end in `SERVER_MODE=True` and `SERVER_MODE=False`.
-- [ ] OAuth2 round-trip verified against a real provider.
-- [ ] Query Tool regression sweep passed (pagination, edit, transactions, BYTEA).
-- [ ] Audit table in §9 re-run on the merge commit and the result recorded in the PR
-      description; any drift from the table in this proposal explained.
-
----
-
-## 7. Alternatives Considered
-
-### 7.1 Big-bang refactor in one PR
-
-Rejected. Combines an urgent security fix with a multi-feature refactor; a regression in any
-cloud wizard would block the security fix from shipping. Review surface is too large for
-adequate scrutiny.
-
-### 7.2 Keep pickle, only fix HMAC ordering
-
-Rejected as the long-term answer. Closes the immediate CVE but leaves `pickle` as the de-facto
-session format and inside cloud handlers. Any future bug that lets an attacker influence
-session contents re-opens RCE. Adopted as **Phase 1** only — buys time for Phase 2.
-
-### 7.3 Use `flask.json.tag.TaggedJSONSerializer`
-
-Rejected for the on-disk session format. `TaggedJSONSerializer` handles `bytes`, `datetime`,
-`UUID`, `tuple`, `set` — which would let the in-session serialized blobs (the cloud-handler
-`pickle.dumps` outputs) silently survive the JSON switch. We want those *gone*, not preserved.
-Plain JSON forces the refactor.
-
-### 7.4 Switch to `itsdangerous.URLSafeTimedSerializer` only (no file backend)
-
-Rejected. Cookie size limits make this impractical for pgAdmin's session contents (especially
-`gridData` and server manager state). File-backed sessions stay.
-
-### 7.5 chroot or seccomp-style sandboxing of the worker process
-
-Out of scope. Requires deployment-level changes that vary by environment
-(Docker, Kubernetes, Snap, AppImage, systemd, native pip, conda, etc.) and that operators
-must opt into per-deployment. Worth tracking separately as a defense-in-depth follow-up.
-
----
-
-## 8. Open Questions (resolved before approval)
-
-1. **HMAC algorithm for the file header: SHA-256 vs `config.SESSION_DIGEST_METHOD` (default
-   SHA-1)?**
-   *Resolution:* hard-code SHA-256 in the file header. The primary rationale is **header-length
-   predictability**: the file format needs a fixed prefix length decoupled from operator config,
-   so that file parsing is deterministic. Secondary rationale: SHA-256 is the modern default
-   and avoids a future deprecation step. The cookie HMAC remains tied to
-   `SESSION_DIGEST_METHOD` for backward compatibility — that's an unrelated mechanism.
-2. **TTL for the process-local SDK client cache?**
-   *Resolution:* match `permanent_session_lifetime` (Flask config), with passive eviction on
-   each access.
-3. **Migration strategy for in-flight sessions:** silent drop vs. warning per dropped sid.
-   *Resolution:* warning logged per rejected sid (sid prefix only, to avoid log-leaking
-   active sids). Provides operator visibility without information disclosure.
-4. **CI guard for `pickle`:** add a lint check that fails CI if `import pickle` reappears
-   outside `web/pgadmin/tests/`?
-   *Resolution:* yes. Implementation: a single grep-based check in the existing test
-   makefile, gated on PR 8.
-
-## 9. Audit summary (referenced from §1.5 and §4.2)
-
-This proposal relies on the following grep audits run against the v9.14 branch
-(commit-of-record: head of `fix/pickle-rce` at proposal time). Patterns are listed as
-ripgrep-compatible regex.
-
-**Reproducer:** `rg --type py 'PATTERN' PATH` (or equivalently
-`grep -rEn --include='*.py' 'PATTERN' PATH`). Re-running these audits on the merge commit is
-a PR-8 acceptance criterion (§6.4).
-
-**Audit 1 — symlink-creating primitives:**
-
-```regex
-os\.symlink|os\.link\(|symbolic_link|symlink_to|Path\.symlink|\.symlink\(
-```
-
-Path: `web/pgadmin/`. Result: **0 matches.**
-
-**Audit 2 — archive extraction (could preserve symlinks from a malicious archive):**
-
-```regex
-tarfile\.|zipfile\.|shutil\.unpack_archive|shutil\.copytree|extractall|extract_archive
-```
-
-Path: `web/pgadmin/`. Result: **0 matches.**
-
-**Audit 3 — shell-invocation primitives in file_manager:**
-
-```regex
-subprocess|os\.popen|os\.system|shell=True
-```
-
-Path: `web/pgadmin/misc/file_manager/`. Result: **0 matches.**
-
-**Audit 4 — `os.path.abspath` callers in file_manager:**
-
-```regex
-os\.path\.abspath
-```
-
-Path: `web/pgadmin/misc/file_manager/__init__.py`. Result: **2 matches** at lines 903 and 1086.
-
-**Audit 5 — directory-creation handlers in file_manager:**
-
-```regex
-def (addfolder|add_folder|new_folder|mkdir|create_directory|createfolder)
-```
-
-Path: `web/pgadmin/misc/file_manager/`. Result: **1 match** — `addfolder` at line 1232.
-
-**Audit 6 — `os.mkdir` / `os.makedirs` in file_manager:**
-
-```regex
-os\.mkdir|os\.makedirs
-```
-
-Path: `web/pgadmin/misc/file_manager/`. Result: **1 match** at line 1250 (inside `addfolder`).
-
-These results justify the §1.5 conclusion (no in-pgAdmin symlink primitive) and the §4.2.5
-conclusion (exhaustive audit of file_manager path-handling sites).
-
-## 10. References
-
-- Security report: 2026-04-29 (private)
-- CVE-2024-2044 — pgAdmin RCE in `SERVER_MODE=False`, earlier versions
-- CWE-502 — Deserialization of Untrusted Data
-- CWE-61 — UNIX Symbolic Link (Symlink) Following
-- CWE-22 — Improper Limitation of a Pathname to a Restricted Directory
-- OWASP Top 10 — A08:2021 Software and Data Integrity Failures
-- Existing pattern: `web/pgadmin/utils/driver/psycopg3/server_manager.py:519-530` —
-  `as_dict()` + module-global live state
-- Linux `open(2)` — `O_NOFOLLOW`: refuse to follow symbolic links at the leaf component

pkg/debian/README.md

@@ -5,8 +5,9 @@ Debian and Ubuntu.
 
 ## Supported platforms
 
-* Debian 11, 12 & 13
-* Ubuntu 22.04, 24.04 & 25.04
+The platforms built are the ones in the matrix in
+`.github/workflows/check-deb-build.yml`; see `pkg/linux/PLATFORMS.md` for how
+to add or retire one.
 
 ## Build configuration
 

pkg/docker/entrypoint.sh

@@ -16,26 +16,24 @@ PUID=${PUID:-5050}
 PGID=${PGID:-0}
 
 # Validate PUID/PGID are numeric and in acceptable range
-if ! echo "$PUID" | grep -qE '^[0-9]+$'; then
+if [[ ! $PUID =~ ^[0-9]+$ ]]; then
     echo "ERROR: PUID must be a numeric value, got '$PUID'"
     exit 1
 fi
-if ! echo "$PGID" | grep -qE '^[0-9]+$'; then
+if [[ ! $PGID =~ ^[0-9]+$ ]]; then
     echo "ERROR: PGID must be a numeric value, got '$PGID'"
     exit 1
 fi
-if [ "$PUID" -eq 0 ]; then
+if (( 10#$PUID == 0 )); then
     echo "ERROR: PUID=0 (root) is not allowed. Use a non-root UID."
     exit 1
 fi
 
-if [ "$(id -u)" = "0" ]; then
+if (( EUID == 0 )); then
     # Ensure a group with the target GID exists
-    if ! getent group "$PGID" > /dev/null 2>&1; then
-        if ! addgroup -g "$PGID" pggroup; then
-            echo "ERROR: Failed to create group with GID=$PGID"
-            exit 1
-        fi
+    if ! getent group "$PGID" &>/dev/null && ! addgroup -g "$PGID" pggroup; then
+        echo "ERROR: Failed to create group with GID=$PGID"
+        exit 1
     fi
 
     # Reassign the pgadmin user to the desired UID/GID
@@ -46,17 +44,17 @@ if [ "$(id -u)" = "0" ]; then
 
     # Fix ownership of runtime directories BEFORE any initialization
     for dir in /run/pgadmin /var/lib/pgadmin; do
-        if [ -d "$dir" ]; then
+        if [[ -d $dir ]]; then
             chown -R "$PUID:$PGID" "$dir"
         fi
     done
 
     # Fix ownership of individual files (no -R needed)
-    if [ -e /pgadmin4/config_distro.py ]; then
+    if [[ -e /pgadmin4/config_distro.py ]]; then
         chown "$PUID:$PGID" /pgadmin4/config_distro.py
     fi
 
-    if [ -d /certs ]; then
+    if [[ -d /certs ]]; then
         chown -R "$PUID:$PGID" /certs
     fi
 
@@ -66,12 +64,55 @@ else
     SU_EXEC=""
 
     # Fixup the passwd file, in case we're on OpenShift
-    if ! whoami > /dev/null 2>&1; then
-        if [ "$(id -u)" -ne 5050 ]; then
-            if [ -w /etc/passwd ]; then
-                echo "${USER_NAME:-pgadminr}:x:$(id -u):0:${USER_NAME:-pgadminr} user:${HOME}:/sbin/nologin" >> /etc/passwd
-            fi
+    if ! whoami &>/dev/null && (( EUID != 5050 )) && [[ -w /etc/passwd ]]; then
+        echo "${USER_NAME:-pgadminr}:x:${EUID}:0:${USER_NAME:-pgadminr} user:${HOME}:/sbin/nologin" >>/etc/passwd
+    fi
+fi
+
+# Decide which python interpreter to use for gunicorn.
+#
+# /venv/bin/python3-cap is a symlink to /usr/local/bin/python3-cap, a copy
+# of the system python carrying CAP_NET_BIND_SERVICE. It is needed to bind
+# to privileged ports (the default 80/443) as the non-root pgadmin user.
+#
+# Some platforms refuse to honor file capabilities, in which case execing
+# the capped binary either fails outright or silently strips the caps so
+# bind() to a port <1024 still returns EPERM:
+#
+#   - NoNewPrivs=1 (--security-opt=no-new-privileges, OpenShift's
+#     allowPrivilegeEscalation: false): the kernel silently strips file
+#     capabilities on exec.
+#   - CAP_NET_BIND_SERVICE missing from the bounding set (--cap-drop=ALL,
+#     OpenShift restricted-v2 SCC): exec of the capped binary returns
+#     EPERM.
+#
+# Detect either condition via /proc/self/status. When restricted, fall
+# back to the un-capped venv python and (if the user has not picked a
+# port) default PGADMIN_LISTEN_PORT to 8080/8443 so the server can
+# actually bind.
+PYTHON_BIN=/venv/bin/python3-cap
+restricted=0
+
+if grep -q '^NoNewPrivs:[[:space:]]*1' /proc/self/status 2>/dev/null; then
+    restricted=1
+fi
+
+if (( restricted == 0 )); then
+    cap_bnd=$(awk '/^CapBnd:/ { print $2 }' /proc/self/status 2>/dev/null)
+    if [[ -n $cap_bnd ]] && (( (0x$cap_bnd & 0x400) == 0 )); then
+        restricted=1
+    fi
+fi
+
+if (( restricted == 1 )) || [[ ! -x /venv/bin/python3-cap ]]; then
+    PYTHON_BIN=/venv/bin/python3
+    if [[ -z $PGADMIN_LISTEN_PORT ]]; then
+        if [[ -n $PGADMIN_ENABLE_TLS ]]; then
+            export PGADMIN_LISTEN_PORT=8443
+        else
+            export PGADMIN_LISTEN_PORT=8080
         fi
+        echo "Restricted security context detected; defaulting PGADMIN_LISTEN_PORT to $PGADMIN_LISTEN_PORT."
     fi
 fi
 
@@ -79,30 +120,30 @@ fi
 # (will allow for "$XYZ_DB_PASSWORD_FILE" to fill in the value of
 #  "$XYZ_DB_PASSWORD" from a file, for Docker's secrets feature)
 function file_env() {
-	local var="$1"
-	local fileVar="${var}_FILE"
-	local def="${2:-}"
-	if [ "${!var:-}" ] && [ "${!fileVar:-}" ]; then
-		printf >&2 'error: both %s and %s are set (but are exclusive)\n' "$var" "$fileVar"
-		exit 1
-	fi
-	local val="$def"
-	if [ "${!var:-}" ]; then
-		val="${!var}"
-	elif [ "${!fileVar:-}" ] && [ ! -r "${!fileVar}" ]; then
-		printf >&2 'error: %s is set to "%s" but the file does not exist or is not readable\n' \
-			"$fileVar" "${!fileVar}"
-		exit 1
-	elif [ "${!fileVar:-}" ]; then
-		val="$(< "${!fileVar}")"
-	fi
-	export "$var"="$val"
-	unset "$fileVar"
+    local var="$1"
+    local fileVar="${var}_FILE"
+    local def="${2:-}"
+    if [[ -n ${!var:-} && -n ${!fileVar:-} ]]; then
+        printf >&2 'error: both %s and %s are set (but are exclusive)\n' "$var" "$fileVar"
+        exit 1
+    fi
+    local val="$def"
+    if [[ -n ${!var:-} ]]; then
+        val="${!var}"
+    elif [[ -n ${!fileVar:-} && ! -r ${!fileVar} ]]; then
+        printf >&2 'error: %s is set to "%s" but the file does not exist or is not readable\n' \
+            "$fileVar" "${!fileVar}"
+        exit 1
+    elif [[ -n ${!fileVar:-} ]]; then
+        val="$(<"${!fileVar}")"
+    fi
+    export "$var"="$val"
+    unset "$fileVar"
 }
 
 # Set values for config variables that can be passed using secrets
-if [ -n "${PGADMIN_CONFIG_CONFIG_DATABASE_URI_FILE}" ]; then
-  file_env PGADMIN_CONFIG_CONFIG_DATABASE_URI
+if [[ -n $PGADMIN_CONFIG_CONFIG_DATABASE_URI_FILE ]]; then
+    file_env PGADMIN_CONFIG_CONFIG_DATABASE_URI
 fi
 file_env PGADMIN_DEFAULT_PASSWORD
 
@@ -112,8 +153,8 @@ export CONFIG_DISTRO_FILE_PATH="${PGADMIN_CUSTOM_CONFIG_DISTRO_FILE:-/pgadmin4/c
 # provided by the user through the PGADMIN_CONFIG_* environment variables.
 # Only update the file on first launch. The empty file is created only in default path during the
 # container build so it can have the required ownership.
-if [ ! -e "${CONFIG_DISTRO_FILE_PATH}" ] || [ "$(wc -m "${CONFIG_DISTRO_FILE_PATH}" 2>/dev/null | awk '{ print $1 }')" = "0" ]; then
-    cat << EOF > "${CONFIG_DISTRO_FILE_PATH}"
+if [[ ! -e $CONFIG_DISTRO_FILE_PATH || "$(wc -m "$CONFIG_DISTRO_FILE_PATH" 2>/dev/null | awk '{ print $1 }')" == 0 ]]; then
+    cat <<EOF >"$CONFIG_DISTRO_FILE_PATH"
 CA_FILE = '/etc/ssl/certs/ca-certificates.crt'
 LOG_FILE = '/dev/null'
 HELP_PATH = '../../docs'
@@ -128,29 +169,47 @@ DEFAULT_BINARY_PATHS = {
 }
 EOF
 
-    # This is a bit kludgy, but necessary as the container uses BusyBox/ash as
-    # it's shell and not bash which would allow a much cleaner implementation
-    for var in $(env | grep "^PGADMIN_CONFIG_" | cut -d "=" -f 1); do
+    # Iterate over PGADMIN_CONFIG_* environment variables and writes them to the config file
+    for var in "${!PGADMIN_CONFIG_@}"; do
         # Get the raw value
-        val=$(eval "echo \"\$$var\"")
+        val="${!var}"
         # This normalization step is what makes 'true', 'True'
-        case "$(echo "$val" | tr '[:upper:]' '[:lower:]')" in
-            true)  val="True" ;;
-            false) val="False" ;;
-        esac
-        echo "${var#PGADMIN_CONFIG_} = $val" >> "${CONFIG_DISTRO_FILE_PATH}"
+        if [[ "${val,,}" =~ ^(true|false)$ ]]; then
+            val="${val,,}"
+            val="${val^}"
+        fi
+        echo "${var#PGADMIN_CONFIG_} = $val" >>"$CONFIG_DISTRO_FILE_PATH"
     done
 
     # If running as root with custom config distro path, fix ownership
-    if [ "$(id -u)" = "0" ] && [ "${CONFIG_DISTRO_FILE_PATH}" != "/pgadmin4/config_distro.py" ]; then
-        chown "$PUID:$PGID" "${CONFIG_DISTRO_FILE_PATH}"
+    if (( EUID == 0 )) && [[ $CONFIG_DISTRO_FILE_PATH != "/pgadmin4/config_distro.py" ]]; then
+        chown "$PUID:$PGID" "$CONFIG_DISTRO_FILE_PATH"
     fi
 fi
 
 # Check whether the external configuration database exists if it is being used.
+#
+# The URI is read inside Python via os.environ — the shell no longer
+# participates in Python-literal quoting. `ast.literal_eval` unwraps the
+# legacy `'url'` form that the config_distro.py generation convention
+# requires; raw values pass through unchanged. On any Python failure the
+# "False" default below is preserved so first-launch user setup still
+# runs (see #9984).
 external_config_db_exists="False"
-if [ -n "${PGADMIN_CONFIG_CONFIG_DATABASE_URI}" ]; then
-     external_config_db_exists=$(cd /pgadmin4/pgadmin/utils && $SU_EXEC /venv/bin/python3 -c "from check_external_config_db import check_external_config_db; val = check_external_config_db(\"${PGADMIN_CONFIG_CONFIG_DATABASE_URI}\"); print(val)")
+if [[ -n $PGADMIN_CONFIG_CONFIG_DATABASE_URI ]]; then
+    result=$(cd /pgadmin4/pgadmin/utils && $SU_EXEC /venv/bin/python3 -c "
+import os, ast
+from check_external_config_db import check_external_config_db
+raw = os.environ['PGADMIN_CONFIG_CONFIG_DATABASE_URI']
+try:
+    uri = ast.literal_eval(raw)
+except (ValueError, SyntaxError):
+    uri = raw
+print(check_external_config_db(uri))
+" 2>/dev/null)
+    if [[ -n $result ]]; then
+        external_config_db_exists="$result"
+    fi
 fi
 
 # DRY of the code to load the PGADMIN_SERVER_JSON_FILE
@@ -159,55 +218,70 @@ function load_server_json_file() {
 
     EXTRA_ARGS=""
 
-    if [ "${PGADMIN_REPLACE_SERVERS_ON_STARTUP}" = "True" ]; then
+    if [[ $PGADMIN_REPLACE_SERVERS_ON_STARTUP == "True" ]]; then
         EXTRA_ARGS="--replace"
     fi
 
-    if [ -f "${PGADMIN_SERVER_JSON_FILE}" ]; then
+    if [[ -f $PGADMIN_SERVER_JSON_FILE ]]; then
         # When running in Desktop mode, no user is created
         # so we have to import servers anonymously
-        if [ "${PGADMIN_CONFIG_SERVER_MODE}" = "False" ]; then
-            $SU_EXEC /venv/bin/python3 /pgadmin4/setup.py load-servers "${PGADMIN_SERVER_JSON_FILE}" ${EXTRA_ARGS}
+        if [[ $PGADMIN_CONFIG_SERVER_MODE == "False" ]]; then
+            $SU_EXEC /venv/bin/python3 /pgadmin4/setup.py load-servers "$PGADMIN_SERVER_JSON_FILE" $EXTRA_ARGS
         else
-            $SU_EXEC /venv/bin/python3 /pgadmin4/setup.py load-servers "${PGADMIN_SERVER_JSON_FILE}" --user "${PGADMIN_DEFAULT_EMAIL}" ${EXTRA_ARGS}
+            $SU_EXEC /venv/bin/python3 /pgadmin4/setup.py load-servers "$PGADMIN_SERVER_JSON_FILE" --user "$PGADMIN_DEFAULT_EMAIL" $EXTRA_ARGS
         fi
     fi
 }
 
-if [ ! -f /var/lib/pgadmin/pgadmin4.db ] && [ "${external_config_db_exists}" = "False" ]; then
-    if [ -z "${PGADMIN_DEFAULT_EMAIL}" ] || { [ -z "${PGADMIN_DEFAULT_PASSWORD}" ] && [ -z "${PGADMIN_DEFAULT_PASSWORD_FILE}" ]; }; then
+if [[ ! -f /var/lib/pgadmin/pgadmin4.db && $external_config_db_exists == "False" ]]; then
+    if [[ -z $PGADMIN_DEFAULT_EMAIL || (-z $PGADMIN_DEFAULT_PASSWORD && -z $PGADMIN_DEFAULT_PASSWORD_FILE) ]]; then
         echo 'You need to define the PGADMIN_DEFAULT_EMAIL and PGADMIN_DEFAULT_PASSWORD or PGADMIN_DEFAULT_PASSWORD_FILE environment variables.'
         exit 1
     fi
 
     # Validate PGADMIN_DEFAULT_EMAIL
-    CHECK_EMAIL_DELIVERABILITY="False"
-    if [ -n "${PGADMIN_CONFIG_CHECK_EMAIL_DELIVERABILITY}" ]; then
-        CHECK_EMAIL_DELIVERABILITY=${PGADMIN_CONFIG_CHECK_EMAIL_DELIVERABILITY}
+    #
+    # The settings and the email address are read inside Python via
+    # os.environ rather than interpolated into the Python source. Boolean
+    # settings are normalised in the same way as config_distro.py above, so
+    # 'true' and 'false' in any case are accepted.
+    is_valid_email=$(cd /pgadmin4/pgadmin/utils && $SU_EXEC /venv/bin/python3 -c "
+import ast, os, sys
+from validation_utils import validate_email
+
+
+def setting(name, default):
+    raw = os.environ.get('PGADMIN_CONFIG_' + name, '')
+    if not raw:
+        return default
+    if raw.lower() in ('true', 'false'):
+        return raw.lower() == 'true'
+    try:
+        return ast.literal_eval(raw)
+    except (ValueError, SyntaxError):
+        return raw
+
+
+email_config = {
+    'CHECK_EMAIL_DELIVERABILITY': setting('CHECK_EMAIL_DELIVERABILITY', False),
+    'ALLOW_SPECIAL_EMAIL_DOMAINS': setting('ALLOW_SPECIAL_EMAIL_DOMAINS', []),
+    'GLOBALLY_DELIVERABLE': setting('GLOBALLY_DELIVERABLE', True),
+}
+print(f'email config is {email_config}', file=sys.stderr)
+print(validate_email(os.environ['PGADMIN_DEFAULT_EMAIL'], email_config))
+") || exit 1
+    if [[ $is_valid_email == *False* ]]; then
+        echo "'$PGADMIN_DEFAULT_EMAIL' does not appear to be a valid email address. Please reset the PGADMIN_DEFAULT_EMAIL environment variable and try again."
+        echo "Validation output: $is_valid_email"
+        exit 1
     fi
-    ALLOW_SPECIAL_EMAIL_DOMAINS="[]"
-    if [ -n "${PGADMIN_CONFIG_ALLOW_SPECIAL_EMAIL_DOMAINS}" ]; then
-        ALLOW_SPECIAL_EMAIL_DOMAINS=${PGADMIN_CONFIG_ALLOW_SPECIAL_EMAIL_DOMAINS}
-    fi
-    GLOBALLY_DELIVERABLE="True"
-    if [ -n "${PGADMIN_CONFIG_GLOBALLY_DELIVERABLE}" ]; then
-        GLOBALLY_DELIVERABLE=${PGADMIN_CONFIG_GLOBALLY_DELIVERABLE}
-    fi
-     email_config="{'CHECK_EMAIL_DELIVERABILITY': ${CHECK_EMAIL_DELIVERABILITY}, 'ALLOW_SPECIAL_EMAIL_DOMAINS': ${ALLOW_SPECIAL_EMAIL_DOMAINS}, 'GLOBALLY_DELIVERABLE': ${GLOBALLY_DELIVERABLE}}"
-     echo "email config is ${email_config}"
-     is_valid_email=$(cd /pgadmin4/pgadmin/utils && $SU_EXEC /venv/bin/python3 -c "from validation_utils import validate_email; val = validate_email('${PGADMIN_DEFAULT_EMAIL}', ${email_config}); print(val)")
-     if echo "${is_valid_email}" | grep "False" > /dev/null; then
-         echo "'${PGADMIN_DEFAULT_EMAIL}' does not appear to be a valid email address. Please reset the PGADMIN_DEFAULT_EMAIL environment variable and try again."
-         echo "Validation output: ${is_valid_email}"
-         exit 1
-     fi
     # Switch back to root directory for further process
     cd /pgadmin4
 
     # Set the default username and password in a
     # backwards compatible way
-    export PGADMIN_SETUP_EMAIL="${PGADMIN_DEFAULT_EMAIL}"
-    export PGADMIN_SETUP_PASSWORD="${PGADMIN_DEFAULT_PASSWORD}"
+    export PGADMIN_SETUP_EMAIL="$PGADMIN_DEFAULT_EMAIL"
+    export PGADMIN_SETUP_PASSWORD="$PGADMIN_DEFAULT_PASSWORD"
 
     # Initialize DB before starting Gunicorn
     # Importing pgadmin4 (from this script) is enough
@@ -219,41 +293,41 @@ if [ ! -f /var/lib/pgadmin/pgadmin4.db ] && [ "${external_config_db_exists}" = "
     load_server_json_file
 
     # Pre-load any required preferences
-    if [ -f "${PGADMIN_PREFERENCES_JSON_FILE}" ]; then
-        if [ "${PGADMIN_CONFIG_SERVER_MODE}" = "False" ]; then
+    if [[ -f $PGADMIN_PREFERENCES_JSON_FILE ]]; then
+        if [[ $PGADMIN_CONFIG_SERVER_MODE == "False" ]]; then
             DESKTOP_USER=$(cd /pgadmin4 && $SU_EXEC /venv/bin/python3 -c 'import config; print(config.DESKTOP_USER)')
-            $SU_EXEC /venv/bin/python3 /pgadmin4/setup.py set-prefs "${DESKTOP_USER}" --input-file "${PGADMIN_PREFERENCES_JSON_FILE}"
+            $SU_EXEC /venv/bin/python3 /pgadmin4/setup.py set-prefs "$DESKTOP_USER" --input-file "$PGADMIN_PREFERENCES_JSON_FILE"
         else
-            $SU_EXEC /venv/bin/python3 /pgadmin4/setup.py set-prefs "${PGADMIN_DEFAULT_EMAIL}" --input-file "${PGADMIN_PREFERENCES_JSON_FILE}"
+            $SU_EXEC /venv/bin/python3 /pgadmin4/setup.py set-prefs "$PGADMIN_DEFAULT_EMAIL" --input-file "$PGADMIN_PREFERENCES_JSON_FILE"
         fi
     fi
     # Copy the pgpass file passed using secrets
-    if [ -n "${PGPASS_FILE}" ] && [ -f "${PGPASS_FILE}" ]; then
-        if [ "${PGADMIN_CONFIG_SERVER_MODE}" = "False" ]; then
-            cp "${PGPASS_FILE}" /var/lib/pgadmin/.pgpass
+    if [[ -n $PGPASS_FILE && -f $PGPASS_FILE ]]; then
+        if [[ $PGADMIN_CONFIG_SERVER_MODE == "False" ]]; then
+            cp "$PGPASS_FILE" /var/lib/pgadmin/.pgpass
             chmod 600 /var/lib/pgadmin/.pgpass
             # Fix ownership when running as root
-            if [ "$(id -u)" = "0" ]; then
+            if (( EUID == 0 )); then
                 chown "$PUID:$PGID" /var/lib/pgadmin/.pgpass
             fi
         else
-            PGADMIN_USER_CONFIG_DIR=$(echo "${PGADMIN_DEFAULT_EMAIL}" | sed 's/@/_/g')
-            mkdir -p "/var/lib/pgadmin/storage/${PGADMIN_USER_CONFIG_DIR}"
-            cp "${PGPASS_FILE}" "/var/lib/pgadmin/storage/${PGADMIN_USER_CONFIG_DIR}/.pgpass"
-            chmod 600 "/var/lib/pgadmin/storage/${PGADMIN_USER_CONFIG_DIR}/.pgpass"
+            PGADMIN_USER_CONFIG_DIR="${PGADMIN_DEFAULT_EMAIL//@/_}"
+            mkdir -p "/var/lib/pgadmin/storage/$PGADMIN_USER_CONFIG_DIR"
+            cp "$PGPASS_FILE" "/var/lib/pgadmin/storage/$PGADMIN_USER_CONFIG_DIR/.pgpass"
+            chmod 600 "/var/lib/pgadmin/storage/$PGADMIN_USER_CONFIG_DIR/.pgpass"
             # Fix ownership when running as root
-            if [ "$(id -u)" = "0" ]; then
-                chown -R "$PUID:$PGID" "/var/lib/pgadmin/storage/${PGADMIN_USER_CONFIG_DIR}"
+            if (( EUID == 0 )); then
+                chown -R "$PUID:$PGID" "/var/lib/pgadmin/storage/$PGADMIN_USER_CONFIG_DIR"
             fi
         fi
     fi
 # If already initialised and PGADMIN_REPLACE_SERVERS_ON_STARTUP is set to true, then load the server json file.
-elif [ "${PGADMIN_REPLACE_SERVERS_ON_STARTUP}" = "True" ]; then
+elif [[ $PGADMIN_REPLACE_SERVERS_ON_STARTUP == "True" ]]; then
     load_server_json_file
 fi
 
 # Start Postfix to handle password resets etc.
-if [ -z "${PGADMIN_DISABLE_POSTFIX}" ]; then
+if [[ -z $PGADMIN_DISABLE_POSTFIX ]]; then
     sudo /usr/sbin/postfix start
 fi
 
@@ -264,18 +338,16 @@ TIMEOUT=$(cd /pgadmin4 && $SU_EXEC /venv/bin/python3 -c 'import config; print(co
 # NOTE: currently pgadmin can run only with 1 worker due to sessions implementation
 # Using --threads to have multi-threaded single-process worker
 
-if [ -n "${PGADMIN_ENABLE_SOCK}" ]; then
+if [[ -n $PGADMIN_ENABLE_SOCK ]]; then
     BIND_ADDRESS="unix:/run/pgadmin/pgadmin.sock"
+elif [[ -n $PGADMIN_ENABLE_TLS ]]; then
+    BIND_ADDRESS="${PGADMIN_LISTEN_ADDRESS:-[::]}:${PGADMIN_LISTEN_PORT:-443}"
 else
-    if [ -n "${PGADMIN_ENABLE_TLS}" ]; then
-        BIND_ADDRESS="${PGADMIN_LISTEN_ADDRESS:-[::]}:${PGADMIN_LISTEN_PORT:-443}"
-    else
-        BIND_ADDRESS="${PGADMIN_LISTEN_ADDRESS:-[::]}:${PGADMIN_LISTEN_PORT:-80}"
-    fi
+    BIND_ADDRESS="${PGADMIN_LISTEN_ADDRESS:-[::]}:${PGADMIN_LISTEN_PORT:-80}"
 fi
 
-if [ -n "${PGADMIN_ENABLE_TLS}" ]; then
-    exec $SU_EXEC /venv/bin/gunicorn --limit-request-line "${GUNICORN_LIMIT_REQUEST_LINE:-8190}" --timeout "${TIMEOUT}" --bind "${BIND_ADDRESS}" -w 1 --threads "${GUNICORN_THREADS:-25}" --access-logfile "${GUNICORN_ACCESS_LOGFILE:--}" --keyfile /certs/server.key --certfile /certs/server.cert -c gunicorn_config.py run_pgadmin:app
+if [[ -n $PGADMIN_ENABLE_TLS ]]; then
+    exec $SU_EXEC "$PYTHON_BIN" /venv/bin/gunicorn --limit-request-line "${GUNICORN_LIMIT_REQUEST_LINE:-8190}" --timeout "$TIMEOUT" --bind "$BIND_ADDRESS" -w 1 --threads "${GUNICORN_THREADS:-25}" --access-logfile "${GUNICORN_ACCESS_LOGFILE:--}" --keyfile /certs/server.key --certfile /certs/server.cert -c gunicorn_config.py run_pgadmin:app
 else
-    exec $SU_EXEC /venv/bin/gunicorn --limit-request-line "${GUNICORN_LIMIT_REQUEST_LINE:-8190}" --limit-request-fields "${GUNICORN_LIMIT_REQUEST_FIELDS:-100}" --limit-request-field_size "${GUNICORN_LIMIT_REQUEST_FIELD_SIZE:-8190}" --timeout "${TIMEOUT}" --bind "${BIND_ADDRESS}" -w 1 --threads "${GUNICORN_THREADS:-25}" --access-logfile "${GUNICORN_ACCESS_LOGFILE:--}" -c gunicorn_config.py run_pgadmin:app
+    exec $SU_EXEC "$PYTHON_BIN" /venv/bin/gunicorn --limit-request-line "${GUNICORN_LIMIT_REQUEST_LINE:-8190}" --limit-request-fields "${GUNICORN_LIMIT_REQUEST_FIELDS:-100}" --limit-request-field_size "${GUNICORN_LIMIT_REQUEST_FIELD_SIZE:-8190}" --timeout "$TIMEOUT" --bind "$BIND_ADDRESS" -w 1 --threads "${GUNICORN_THREADS:-25}" --access-logfile "${GUNICORN_ACCESS_LOGFILE:--}" -c gunicorn_config.py run_pgadmin:app
 fi

pkg/docker/gunicorn_config.py

@@ -5,6 +5,14 @@ from config import JSON_LOGGER, CONSOLE_LOG_LEVEL, CONSOLE_LOG_FORMAT_JSON
 
 gunicorn.SERVER_SOFTWARE = "Python"
 
+# Include the authenticated user identity in the access log.
+# %({x-remote-user}o)s reads the X-Remote-User response header set by pgAdmin
+# for authenticated requests; unauthenticated requests log '-'.
+access_log_format = (
+    '%(h)s %(l)s %({x-remote-user}o)s %(t)s "%(r)s" %(s)s %(b)s '
+    '"%(f)s" "%(a)s"'
+)
+
 if JSON_LOGGER:
     logconfig_dict = {
         "version": 1,