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/546433b4fd8a3ede5d04d56b3d... -- https://sleepmap.de