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
