Re: [PLUG] Possible Break in on Arch Linux Systems:

[Will via plug <plug@lists.phillylinux.org>]

The Pacman Keyring getting regularly updated has been such a regular event, the following steps were added for my automation with Terraform for deployments. 
https://gitlab.com/buzzdeploy/infrastructure/appbuzz-infrastructure/-/blob/main/appCluster/archlinode.tf#L28-31

Nothing has been hacked but I will say that I have had many an update interrupted by the keyring issue. The link provided highlights a repeatable process (with a reboot afterwards) to patch and restart an Arch system in Linode upon deployment. 

-Will C

On Tue, Dec 27, 2022 at 5:48 PM Rich Freeman via plug <plug@lists.phillylinux.org> wrote:

On Tue, Dec 27, 2022 at 5:30 PM Rich Mingin (PLUG) via plug
<plug@lists.phillylinux.org> wrote:
>
> Seems normal. Good to be vigilant, but so far nothing to see here.
>

Two comments: one arch-specific, one general.

Arch seems to have individual developers sign their packages, and that
is the key that the package manager uses to validate integrity.  This
means that every time a dev joins/leaves their project or updates
their personal key anybody who uses arch needs to update their
keyring.  Most distros tend to do that sort of thing internally, but
then some release server validates this and then adds a distro-level
signature, and the key for that rarely changes, which is why on most
distros you don't see that kind of churn.  For example, on Gentoo
developers sign everything themselves, and if you look at the Gentoo
git repo you'll see a ton of individual dev keys used.  Then the CI
server grabs the top master commit, does a validation of all
signatures vs the internal LDAP records of what keys everybody is
supposed to be using, checking all commits since the last validation
cycle.  If everything is good it applies a merge commit and signature
on top of the branch, and then pushes that to a stable branch that is
used for syncing.  The result is that the top commit is always signed
by the distro key and this is what is checked when the package manager
does a sync on an end-user system.

You could argue that using individual dev keys shields you from a
distro-level compromise, but instead the compromise of any dev key is
exposed to the user until their keychain is updated, and now users
have to stay on top of every dev key.  Of course the arch way is
probably simpler - their repo can just be a repo, though since it is a
binary distro I imagine they still have build servers to build
official packages (an issue Gentoo does not have - our CI just does
quality checks).

Then the general comment: if you really think that a distro might be
compromised you might do better to ask the devs of that distro.
They're going to be most familiar with what is or isn't expected
behavior on that distro, and of course if they are compromised they
would greatly appreciate knowing about it ASAP.  Such a thing tends to
be unlikely because most distros take this stuff seriously and try to
safeguard against it.  I get though that the Arch keyring behavior
could be unexpected if you have experience in some other distro.

--
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug