On 2022-07-24 12:23:29 (+1000), Allan McRae wrote:
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...
The likelyhood for a packager to have three signatures or more (fast) has not been very high over the past year. However, the website is also only showing the signatures correctly, if any given packager setup their current (e.g. new) key in their archweb profile. As notified about earlier [a][b] this is currently not the case and renders the overview a bit useless. Tbh, it would make more sense to automate the population of that subpage and make it completely unreliant on user input, as packagers may have more than one key at a given time. For figuring out current trust (in the yet unreleased keyring), it is possible to list keys with given trust level using `./keyringctl` (see e.g. `./keyringctl list -h`) in the archlinux-keyring repository.
(Is it correct that Giancarlo has signed zero keys? I thought they were bought on to replace me almost a year ago!)
Unfortunately yes. I have asked about this probably a dozen times and given up due to lack of action by now.
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.
That is a lot of "ifs" :)
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...).
After reading some of the responses (e.g. Brett's [c] and Filipe's [d]) it might make indeed more sense to envision a system in which we grab updated keys (if we need them) using pacman upon system upgrade (I guess this action can not be paired with that of pulling new keys though as that happens upon package validation AFAIK). This would lower the amount of requests significantly if no update is needed (i.e. only one HTTP request is needed to retrieve a timestamp file) and only update keys if there is a new version of the keyring data deployed to WKD (e.g. timestamp is newer, we are synchronizing the existing keys). Even if we went with the service, a timestamp file would make sense there as well. As mentioned in my reply to Brett [e] I am not sure how to achieve that in the context of pacman and I do see a configuration overhead there that needs addressing, but if you could point me in the right direction, I might be able to figure it out! :) Best, David [a] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.or... [b] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.or... [c] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.or... [d] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.or... [e] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.or... -- https://sleepmap.de