On 2022-07-23 23:30, David Runge wrote:
On 2022-07-23 21:24:38 (+0200), Kristian Klausen wrote:
The load aspect should be solvable, worst-case DevOps gets annoyed ;)
My main concern is putting ourselves in a position, where we know every arch installation, yes it is just the IP addresses, but still. At the same time it becomes easier to detect that a computer is running arch, by just look at the network traffic (yes you can already do that today, by checking if the computer is connecting to a arch mirror).
Maybe I'm blowing it out of proportion, but with our user base being more privacy aware than most people, I think it is worth mentioning.
Fair point, however, a similar concern was networkmanager doing a connectivity check [1]. It is up to us to configure our webserver accordingly and be as privacy conserving as possible.
E.g. If we wanted to track users (which we don't), we could do so on a rudimentary basis now already by tracking downloads of packager keys. The Web Key Directory is a way more centralistic approach than e.g. SKS was, but we also have better control over how and what we provide there.
Just wanna point out that just because we already do something it doesn't validate doing a similar thing. :) 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. 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. Updating the repo list and installing archlinux-keyring before updating the system breaks our own partial update rules as well. 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. :)