On Sat, 2022-07-23 at 18:38 +0200, David Runge wrote: > Hi all, > > I currently have a MR open against archlinux-keyring [1], that adds a > systemd service and timer, which would automatically refresh valid and > existing keys on user systems. For people without access to the > repository's ticket and merge request features, it is possible to browse > the commits in question on the respective branch [2]. > > To quote from the accompanying ticket [3]: > ``` > For situations in which we do have new signatures which have been > released, we may want a service on user systems that update existing > keys via WKD to have an updated set of keys before updating > archlinux-keyring. > > Rationale: > Keys are updated in WKD after a release of archlinux-keyring (currently > this is still done in the https://gitlab.archlinux.org/archlinux/wkd > repo). > User systems may upgrade any time after that and pacman will pull new > keys from WKD automatically, however it will not pull updates for > existing keys. > Packages that are signed with a key that still had marginal trust in > release A (and therefore already existed on the user system since > release A) and gained full trust in release B will not be updated before > the user does a system upgrade. This leads to the requirement of > installing archlinux-keyring before doing a system upgrade, as otherwise > the key will still have marginal trust on the user system and the > signatures of other updated packages using the key in question will fail > to validate. > > To remedy this situation I think it would be helpful to have a service > update existing keys from WKD twice daily on a timer. > > I am not 100% sure whether this has side-effects in regards to > revocations, but as we only ever update WKD after issuing a release and > not when updating the default branch, this should be fine(?). > ``` > > In short: The service in question will update any valid keys in the > pacman keyring on user systems, that use Arch Linux's relevant domains > as UID to retrieve updated keys (e.g. extended expiration, additional > signatures). Invalid keys and those of other domains are ignored. > > This feature is implemented to circumvent (some, but not all) cases of > "update archlinux-keyring before doing a system upgrade". > Cases not covered are (in no particular order): > * *long* outdated system is updated > * new main signing key is required for a packager key to gain full > trust for the packages about to be updated > * local system's archlinux-keyring does not yet offer this feature > * local system's pacman does not yet offer the feature of downloading > package signatures for new keys from WKD > * packager key on local system does not yet have any main key signatures > and would gain full trust with an update of archlinux-keyring > > Currently the timer which triggers this service is supposed to be vendor > enabled (i.e. symlink in /usr/lib/systemd/system/timers.target.wants/) > and run daily with a deviation of up to 12h. > Members of the DevOps team have raised concerns about the interval as we > do not really have a clear picture about how many Arch Linux > installations there are world-wide to get numbers on expected median > load for this. > > If you have ideas for improvement or general questions, please direct > them at the merge request. > > Best, > David > > [1] > https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/merge_requests/138 > [2] > https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/tree/wkd_sync_service > [3] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/184 >
I am +1 on this, but I don't think this is the cleanest solution, and similar to others, I think the frequency should be lowered. Alan, is there any reason pacman couldn't update the keys on sync operations, avoiding this issue altogether? Cheers, Filipe Laíns
signature.asc
Description: This is a digitally signed message part
