Hi all,

I've started a discussion [1] around a potential improvement for dealing
with archlinux-keyring and pacman-key.

Lately we have been facing quite a few issues (e.g. initialization and
ordering issues in archiso and arch-boxes) again, that emerge from how
gnupg is used in the context of pacman-key.

The discussion linked to above is a bit more midterm in regards to what
the proposed idea represents, but it tries to draw out a possible
scenario of using key data in the future.

When looking at pacman-key I noticed, that it does not do locking of the
gnupg keyring data [2]. This means, that in environments in which we
bootstrap the system (e.g. archiso/arch-boxes) we may run into
inconsistent state if we use pacman too early, or generally if we modify
the keyring concurrently.
Unfortunately, (to my knowledge) there is no way of telling when is "too
early" or whether we are already using the keyring, due to the missing
locking mechanism.

In the past days there have also been a multitude of reports of people
with keyring issues on reddit. While some of theme have been due to
initialization issues in archiso with pacman < 6.0.1-8, there is
apparently also a set of issues on existing systems where it is unclear
why pacman-key would have issues validating keys that are already
present on the user system (trying to get more info from the users).

Overall this is a bit worrying and I think we should work towards
addressing the problem that we have with signing and verifying packages.
The discussion in archlinux-keyring is only one possible solution,
others are implementing a locking mechanism (;_;) or working towards a
signing enclave for our packages and databases to minimize the keys in
use.
IMHO, removing the use of gnupg as proposed in the linked discussion
could reduce complexity quite a bit, but it of course also requires
implementation in archlinux-keyring and pacman.

I'd be happy to get more input and thoughts on this entire topic.

Best,
David


[1] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/199
[2] 
https://gitlab.archlinux.org/pacman/pacman/-/blob/546433b4fd8a3ede5d04d56b3d07ab9f671c0f89/scripts/pacman-key.sh.in#L238

-- 
https://sleepmap.de

Attachment: signature.asc
Description: PGP signature

Reply via email to