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" ways way - 'db-import-keyring' only does "what it says on the tin" - it could not ensure that anyone could actually install the package, and assumes assume that the packages are acceptable, as is - i have had to rebuild archlinuxarm-keyring once and archlinux32-keyring several times manually (just manually; so that i could sign them myself); so i also decided to blacklist archlinux-keyring, and rebuild them all manually from now on, for the reasons given below:
h3. archlinux-keyring:
recently added a systemd service, which imports updated keys from archlinux.org - some users complained complaine that this was a privacy concern; so i looked into it - i had originally devised a ALPM hook to add via to 'your-freedom', which neutralizes the service intrusively (by resetting the executable bit on the service exec target, IIRC)
the feature itself is only useful when people forget to upgrade the system - no one should ever need to refresh-keys or import keys from any third party referesh-keys - arch is not exactly a third party; but still we try to maintain a standard, such that no parabola user should ever need to use a web browser, nor to contact any network server automatically, nor to contact any network server intentionally, other than those operated by if the parabola project, or an endorsed upper-tier mirror - if maintainer's keys need updating, a new keyring package should be built, and they normally are - so this feature seems to be only compensating for, catering to, to or otherwise encouraging a bad habit
as we already blacklist rebuild the other keyrings, it seems reasonable to avoid the clumsy fix with a proper fix - such as, to that is: remove the "timers wants" declaration from the service file; so that timer - people could still enable it manually, but only if "i wants" (that a presumption, i have not tried it yet) 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, only so 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 "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 (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 devised devise at that time, was to make pacman for all arches depend on the keyrings 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, that it has the same drawback as it did when pacman required it - not unlike that is o/c similar to that systemd deal, packages simply where any program may invite (impose) themselves itself into standard configurations 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' group gruop of all arches, is to re-package 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
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" ways way - 'db-import-keyring' only does "what it says on the tin" - it could not ensure that anyone could actually install the package, and assumes assume that the packages are acceptable, as is - i have had to rebuild archlinuxarm-keyring once and archlinux32-keyring several times manually (just manually; so that i could sign them myself); so i also decided to blacklist archlinux-keyring, and rebuild them all manually from now on, for the reasons given below:
h3. archlinux-keyring:
recently added a systemd service, which imports updated keys from archlinux.org - some users complained complaine that this was a privacy concern; so i looked into it - i had originally devised a ALPM hook to add via to 'your-freedom', which neutralizes the service intrusively (by resetting the executable bit on the service exec target, IIRC)
the feature itself is only useful when people forget to upgrade the system - no one should ever need to refresh-keys or import keys from any third party referesh-keys - arch is not exactly a third party; but still we try to maintain a standard, such that no parabola user should ever need to use a web browser, nor to contact any network server automatically, nor to contact any network server intentionally, other than those operated by if the parabola project, or an endorsed upper-tier mirror - if maintainer's keys need updating, a new keyring package should be built, and they normally are - so this feature seems to be only compensating for, catering to, to or otherwise encouraging a bad habit
as we already blacklist rebuild the other keyrings, it seems reasonable to avoid the clumsy fix with a proper fix - such as, to that is: remove the "timers wants" declaration from the service file; so that timer - people could still enable it manually, but only if "i wants" (that a presumption, i have not tried it yet) 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, only so 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 "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 (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 devised devise at that time, was to make pacman for all arches depend on the keyrings 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, that it has the same drawback as it did when pacman required it - not unlike that is o/c similar to that systemd deal, packages simply where any program may invite (impose) themselves itself into standard configurations 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' group gruop of all arches, is to re-package 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