Project

General

Profile

Feature Request #3347

Updated by bill-auger over 1 year ago

archlinux32-keyring and archlinuxarm-keyring are already on the blacklist with no BR reference; so this ticket serves that purpose, at least

the original reason was [technical], mainly to avoid sync-ing it during the normal db-import (and possibly to make them available to all arches? - not sure if that is an implicit part of the db-import procedure)
the replacement PKGBUILD has no "# parabola changes and rationale:" specified either; so i will explain for documentation

> Blacklisted to avoid import by db-import-pkg; import separately with db-import-keyring

furthermore, since that time, both of those keyrings, and now archlinux-keyring as well, have been problematic in "bug-like" way - 'db-import-keyring' only does "what it says on the tin" - it could not ensure that anyone could actually install the package, and assume that the packages are acceptable, as is - i have had to rebuild archlinuxarm-keyring once and archlinux32-keyring several times manually; way; so i also decided to blacklist archlinux-keyring, and rebuild them all manually from now on, for the reasons given below: archlinux-keyring

h3. archlinux-keyring:

recently added a systemd service, which imports updated keys from archlinux.org - some users complaine that this was a privacy concern; so i looked into it - i had originally devised a hook to add to 'your-freedom', which neutralizes the service

the feature itself is only useful when people forget to upgrade the system - no one should ever need to referesh-keys - if the keys need updating, a new keyring package should be built, and they normally are - so this feature seems to be catering to or encouraging a bad habit

as we already rebuild the other keyrings, it seems reasonable to avoid the clumsy fix with a proper fix - that is: remove the "timers wants" declaration from the timer - people could still enable it manually

digression: IMHO that is a rather pesky feature of systemd really - i tried to find some way to over-ride it (to avoid blacklisting the package to change one LOC); but there does not appear to be a mechanism for it - any service which "wants" to be "wanted" by some other service, is dutifully invoked by that "other service" - services apparently has no mechanism to white-list or black-list collaborators - services simply invite (impose) themselves into the init routines of other services

h3. archlinux32-keyring:

unless archlinux32-keyring (and archlinuxarm-keyring) are installed on every liveISO, and users install them during the initial pacstrap, they pose a chicken-and-egg problem for anyone who wants to install them later

archlinux32-keyring has always been a PITA, generally (see #1527) - even with 'archlinux32-keyring' installed, new keyring packages have routinely still had verification problems

the solution that isacdaavid and i devise at that time, was to make pacman for all arches depend on the keyring of all arches; but the verification problems became a routine annoyance, blocking system upgrades for everyone - so recently, i adapted the pacman PKGBUILD to depend only on specific keyrings, per-arch

h3. archlinuxarm-keyring:

in addition to the signature verification chicken-and-egg problem, archlinuxarm-keyring declares itself to be in the 'base-devel' group - as an 'any' package, which we include in the repo of all arches, it has the same drawback as it did when pacman required it - that is o/c similar to that systemd deal, where any program may invite (impose) itself into your system, beyond the control of the local admin - meta-packages are clearly a better approach than package groups - nonetheless, we have them, and the only way to remove 'archlinuxarm-keyring' from the 'base-devel' gruop of all arches, is to blacklist it

maybe we could convince the upstream to remove that declaration - the keyrings requirement should be via pacman (as parabola's does); but for some reason archarm's pacman does not require any keyrings

Back