On 24/7/22 06:49, Evangelos Foutras wrote:
On Sat, 23 Jul 2022 at 19:39, David Runge <d...@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
