Fix stale ondrej/php RSA-1024 key warning on alpha; document the gotcha

add-apt-repository --remove silently no-op'd against the existing
non-standard-named .sources file left over from an earlier release
upgrade. Removed the stale source/key manually and re-added the PPA
fresh - now embeds Signed-By inline, no more separate trusted.gpg.d
keyring file. Verified clean apt update, no package churn, dyndns and
sanity-check still pass.
This commit is contained in:
2026-07-26 20:55:36 +02:00
parent c2e2c8f2a1
commit 67d6d30cc4
2 changed files with 46 additions and 11 deletions
+23
View File
@@ -645,6 +645,29 @@ the release upgrade completes is what actually finishes the job. Check
assuming a completed `do-release-upgrade` run means everything is
current.
**A `Signature ... uses weak algorithm (rsa1024)` warning on this PPA is
a Launchpad-wide artifact, not a sign this PPA is untrustworthy or
compromised** — Launchpad signed every PPA with one shared RSA-1024 key
from 2009 until re-signing everything with RSA-4096 by August 2024;
newer apt versions just started warning about the *old* cached copy of
that key wherever it's still present locally. If it shows up, don't
just live with it or assume something's wrong with the PPA — remove the
stale source file and key and re-add the PPA fresh:
```bash
sudo rm /etc/apt/sources.list.d/ondrej-ubuntu-php-*.sources \
/etc/apt/trusted.gpg.d/ondrej_ubuntu_php.gpg # if present - old key file
sudo add-apt-repository -y ppa:ondrej/php
```
**`add-apt-repository --remove` doesn't reliably work here if the
existing source file has a non-standard name** (e.g. a
`...-focal.sources` file left over from an earlier release-upgrade
rename, as happened on this host) — its matching logic can silently no-op
or touch an unrelated entry instead. Deleting the old `.sources`/key
files directly and re-adding fresh, as above, is the reliable path.
A freshly-added PPA now embeds the signing key inline via `Signed-By:`
in the `.sources` file itself (modern deb822 style) rather than a
separate `/etc/apt/trusted.gpg.d/*.gpg` keyring file.
For each subdomain (static site, dyndns, mail webmail-proxy, any
Docker-backed app): create `/etc/apache2/sites-available/<name>.conf` with
a `:80` vhost, `a2ensite`, then let certbot handle TLS + the redirect: