Re: Systemd service and timer for refreshing archlinux-keyring keys via WKD
On 24/07/2022 20:56, Johannes Löthberg wrote: Excerpts from David Runge's message of July 23, 2022 18:38: 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. I'm fine with it existing, and I would be fine with it being enabled in a vendor preset, but I'm against it being statically enabled in /usr. This is not something that's critical for the regular functioning of the system, and so is not something I think users should have to mask to get rid of rather than be able to just disable it. But daily seems a bit frequent to me. Anything more frequent than weekly feels too often to me, and even that feels a bit frequent. I'm aligning probably against such systemd unit. Mainly because or privacy issues and given the options users will probably set something like refresh every 1 hour and then we need to go into rate-limiting just to keep our gitlab up. -- Leonidas Spyropoulos PGP: 59E43E106B247368 OpenPGP_0x59E43E106B247368.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Systemd service and timer for refreshing archlinux-keyring keys via WKD
On 2022-07-24 10:53:24 (-0700), Brett Cornwall wrote: > Just wanna point out that just because we already do something it > doesn't validate doing a similar thing. :) No. That was not the point I was trying to make. :) It serves as a good example as to why such a thing does not have to be a privacy disaster automatically. After all, we are already dealing with this scenario (hopefully in a successful way). > I'm fine with centralized WKD but only because of the absence of a > functional key trust network. I do think that auto-key-updates are > probably the wrong way forward as it sets a precedent of automatic > network connectivity in the base system. NetworkManager's connectivity > check can be argued is a core part of the software package in the same > way that Firefox's is. I agree with Debian/Ubuntu setting automatic > updates since it's a general-user-facing OS, but IMO Arch should > remain more hands-on and empower the user to do the right thing but > expect them to do it themselves. If there is no network connectivity available, there is no keyring update and there is also no package upgrade. To run Arch a user will likely (at some point) want to upgrade the system. FWIW, the use-case of automatically updating valid and existing keys to allow to upgrade the system normally is a different from automatically upgrading packages. Quite objectively it will be impossible to prevent less proficient or new users in the current setup to not run into an issue with our keyring and ask the same questions for the millionth time (or give up). This would all be fine as long as noone else had to care about this, but affected packagers and keyring maintainers *will be* contacted by those users. > I do agree that the current situation of upgrading a system with an > outdated keyring is annoying at best and very confusing at worst. Last > year I kept receiving emails months after my old key expiration date. This is indeed unfortunately quite common and I am sure I will be contacted many more times over the next few months myself. Sure, I could just start ignoring those messages, but that is neither nice nor does it prevent me from spending time on reading a message half-way to figure out that it has to do with this issue. ;-) IMHO, trying to solve this issue with the approach of upgrading the keyring first, is solving a technological problem with "tribal knowledge" (you just "have to know" that this is an issue with the most central and common of all actions on this operating system to not be affected). This does not scale and it creates friction for users and contributors. > What about a pacman flag that hooks into keyringctl so that the > upgrade command extends to e.g. pacman -Syuk? Much like how we don't > have automatic package list updates, we can expect the user to update > the key trust. If not integrated with pacman, why not just expect the > user to update keys via keyringctl as part of the normal upgrade > process? More useful error messages than "package may be invalid or > corrupt" could point the user to know where the issue is and how best > to solve it. > > Keep it simple. :) This may sound simple at first, but would in fact not be as trivial as one might think. The keyring provided by archlinux-keyring provides old keys (e.g. revoked by issuer or with revoked signatures) and keys (and UIDs!) using non archlinux.org domains. All of those need to be ignored as they are not relevant for (Arch Linux) packages and would lead to many more queries to our and the WKDs of others. To integrate a "sync all locally available keys before upgrade" functionality in pacman, it would need to implement a configurable(!) subsystem which implements the above filtering mechanism domain agnostic (as the package manager is used by others as well). Not saying that this can not be done (it is what the proposed service does standalone), but I know that this will likely not be trivial in the context of pacman and that I do not believe I would be able to write it myself. FTR: Keyringctl is currently very tightly integrated with archlinux-keyring (upstream). It is not really a user-facing application yet (there is no separate upstream for it) and serves the purpose of allowing us to manage the keyring in such a way that it can be maintained in a git repository as source of truth. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: Systemd service and timer for refreshing archlinux-keyring keys via WKD
On 2022-07-24 21:56:28 (+0200), Johannes Löthberg wrote: > I'm fine with it existing, and I would be fine with it being enabled > in a vendor preset, but I'm against it being statically enabled in > /usr. This is not something that's critical for the regular > functioning of the system, and so is not something I think users > should have to mask to get rid of rather than be able to just disable > it. At the time of writing only fwupd [1] and systemd [2] make use of systemd preset [3]. Could you elaborate on what you see as the fundamental difference (from a user's perspective) between `systemctl disable --now ` and `systemctl mask --now `? My reasons for the proposed vendor enabling would be: * we are the vendor * no complicated actions required in an .install file of archlinux-keyring to add a file to the administrative layer (/etc/systemd/) of a user system (if not using a systemd preset file) * the disabling of a default unit is obvious to the user (by the existence of the /dev/null symlink) * the unit's activation state survives damaging/removing the administration layer > But daily seems a bit frequent to me. Anything more frequent than > weekly feels too often to me, and even that feels a bit frequent. I have been looking at this issue from the perspective of "how can a user system gain (mostly) functional keys before upgrading?" by looking at these two scenarios: 1. "A key gains full trust and locally has marginal trust" 2. "A key's expiry date has been extended and is locally expired" In 1. the duration between release of a new keyring to [core] and release of a package that is signed by the now fully trusted key in any of our repositories can be minutes and therefore may even affect systems that are upgraded every few hours or once daily. With a daily timer we could eradicate the issue in this scenario with a rule of "only add packages signed with a key that gains full trust in a new version of archlinux-keyring after one day of its move to [core]" (that is still a big "if", as it relies on us doing the right thing). In 2. let's assume that the release of a new archlinux-keyring is made at least two days before expiry of the key (FWIW, we've had worse!). The *persistent* daily timer (e.g. also directly triggered after having the machine powered off for a longer while) would synchronize the keys very likely before a system upgrade can be attempted. Again, this assumes that we catch the expiry early enough (for which now there is a proposed fix available, thanks to Brett [4] - thanks again for working on that!) for systems being upgraded in short intervals (e.g. daily) and do not have to emergy rebuild someone's packages (which is usually also already too late for some users). Best, David [1] https://archlinux.org/packages/community/x86_64/fwupd/ [2] https://archlinux.org/packages/core/x86_64/systemd/ [3] https://man.archlinux.org/man/systemd.preset.5 [4] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/merge_requests/127 -- https://sleepmap.de signature.asc Description: PGP signature
Re: Systemd service and timer for refreshing archlinux-keyring keys via WKD
On 2022-07-25 09:23:53 (+0100), Leonidas Spyropoulos wrote: > I'm aligning probably against such systemd unit. Mainly because or > privacy issues and given the options users will probably set something > like refresh every 1 hour and then we need to go into rate-limiting > just to keep our gitlab up. As mentioned in another mail [1], I believe that the privacy issues and the approach towards them do not differ from the existing setup with networkmanager and pacman querying the WKD for new keys before upgrade. On IRC a high load on the gitlab pages runner serving the WKD has been discussed. If this indeed affects the performance of gitlab (now already?), then gitlab pages is not the right tool to serve the WKD. Given that we still lack numbers on the current load and the to be expected future load, I'd suggest starting out with a longer interval than daily (e.g. weekly), although this will only solve the issues as discussed in my reply to Johannes [2] if we ensure, that packagers wait one week from gaining full trust to their first package release. Best, David [1] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/message/4JRPZCQZGKKN6I5LIA276WNBWWVMIOHD/ [2] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/message/KB3CB56NGY3YFVIQJTFSZOUVBONYUMWY/ -- https://sleepmap.de signature.asc Description: PGP signature
Re: Systemd service and timer for refreshing archlinux-keyring keys via WKD
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
