On 24/7/22 06:49, Evangelos Foutras wrote:
On Sat, 23 Jul 2022 at 19:39, David Runge <dave@sleepmap.de> wrote:
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.
This is solvable by not cutting a release with marginally trusted keys. Having all Arch Linux installations make 100-ish requests daily to cover such an edge case is a misutilization of resources (on both sides). I'm certain there are also privacy concerns about enabling this service by default.
Not shipping keys that are marginally trusted is ideal in principle... However we have seen it many times recently as main/master keys were cycled. Hopefully this is less of an issue moving forward. This is why the keyring was set up to have five main keys, to ensure packager keys were signed by at least 3 at all times. However, not everyone has all five main key signatures. Or even 4. In fact, according to the web page [1], we are screwed if anything happens to Pierre's of Florian's keys, and to a lesser extent with other keys. I am not sure the extent that page reflects current reality, but note Pierre's key is schedule for retirement... (Is it correct that Giancarlo has signed zero keys? I thought they were bought on to replace me almost a year ago!) [1] https://archlinux.org/master-keys/ We have also had marginal trust happen when a new packager (or packager with a new key) starts packaging having gotten all relevant signatures, but not having their key in WKD yet. A version of the key is attempted to be retrieved from a key server that may not have any signatures. I think this is less of an issue going forward given WKD is updated alongside new keyring changes now. Finally, this deals with keys that have expiry dates. We have hit a few cases where expiry and updating keyring happens in a period where a user has not updated their system in a while. We could monitor this and have packagers be reminded to extend their expiry date at an early enough point in time. I suggest an update needs to be at least 6 months in advance of expiry. My conclusion is the reality of the keyring is not perfect. If all packager keys were signed by all main key holders, and WKD was updated before packages were released using a key, and if expiry dates were extended at least 6 months in advance, and .... , then this would not be an issue. David has put a lot of effort into the keyring to allow us to expose these issues more easily, and has been pushing for main key holders to increase their signing coverage, but this has not progressed at any great rate. The service suggestion really works around limitations in key signing activity. It would not be needed if main key holders signed everything and packagers with keys that expire updated their keys with extensive notice. Onto the service. If the server load and privacy issues were not issues, this would "solve" the problems above. Daily is probably too often, even weekly/monthly would be fine. But I guess the concerns raised mean we should focus on fixing the keyring instead (as futile as that may seem to David currently...). Allan