[SOLVED] How does archlinux keep the updates from mirrors secure?

jronald · 2024-10-09 01:03:29

I'm using a mirror to update archlinux.
Is there a mechanism that can keep the updates same to the official ones?
I see there are keys for this, but is it possible that the keys are replaced by the mirrors?

Last edited by jronald (2024-10-09 09:26:16)

Allan · 2024-10-09 01:06:06

The keyring setup during install means you can only install packages signed by the Arch packagers. A malicious mirror can not replace this without having a packager on board.

jronald · 2024-10-09 02:31:37

Allan wrote:

The keyring setup during install means you can only install packages signed by the Arch packagers. A malicious mirror can not replace this without having a packager on board.

But the keyring will also update, if it is updated from the mirror, it can be edited, right?

Scimmia · 2024-10-09 03:02:33

They keyring package is still protected by a key

jronald · 2024-10-09 04:45:46

Scimmia wrote:

They keyring package is still protected by a key

Can the key be replaced maliciously?

Last edited by jronald (2024-10-09 04:46:09)

mpan · 2024-10-09 06:24:35

If you choose the right threat model, everything can be replaced. For example a maintainer owning the master key may be abducted and forced to act maliciously.

For threat models that are plausible for you as a typical user: if you followed the installation instructions on the wiki, the answer is:
NO, IT CAN’T.

The archlinux-keyring package is signed, and the key with which it’s signed is trusted, tracking trust back to the cross-signed master keys.

If you wish to continue asking that kind of questions, please:

Provide the threat model you expect.
Explain what is the exact mechanism you imagine, which would lead to a breach of the security.

Neither databases themselves nor non-publication of databases is signed, so an adversary may prevent updates from arriving to your system. But not provide a package, that wasn’t signed by a trusted packager at some point.

Last edited by mpan (2024-10-09 06:26:51)

cryptearth · 2024-10-09 07:29:25

mpan wrote:

Neither databases themselves nor non-publication of databases is signed

although I asked it before I just got a "because" as reply: does anyone know a/the reason why the package databases are not signed?
pacman supports it and even tries to get the signatures when syncing - and looking at the current development of archzfs it seems no problem to integrate it into some automatic workflow

Awebb · 2024-10-09 07:58:14

cryptearth wrote:

mpan wrote:
Neither databases themselves nor non-publication of databases is signed
although I asked it before I just got a "because" as reply

I remember that. I'd go and ask in a new thread or the on the mailing list, this isn't the kind of topic people wanna answer dive-by.

jronald · 2024-10-09 09:25:43

mpan wrote:

If you wish to continue asking that kind of questions, please:
Provide the threat model you expect.
Explain what is the exact mechanism you imagine, which would lead to a breach of the security.

I trust the master key, and it's easy to check manually if the master key on my machine is the same to the official one.
Well, it seems no big problem for me now, just find out how to do this.

Thanks

Awebb · 2024-10-09 10:38:56

By the way: There is a wiki article called "Security" with a brief chapter about this with links to more information.

Head_on_a_Stick · 2024-10-09 10:48:38

cryptearth wrote:

does anyone know a/the reason why the package databases are not signed?

Time and resources, at a guess. Valve have just bought out Arch and they will add database signing, if that helps.

Allan · 2024-10-09 10:55:22

Head_on_a_Stick wrote:

Valve have just bought out Arch and they will add database signing, if that helps.

cryptearth · 2024-10-09 12:26:58

Head_on_a_Stick wrote:

cryptearth wrote:
does anyone know a/the reason why the package databases are not signed?
Time and resources, at a guess. Valve have just bought out Arch and they will add database signing, if that helps.

As far as I got that news Valve didn't "bought" Arch but they started an even closer relationship.
And even IF - ValveOS/Arch would be a Linux I sure would pay for (looking at steam account calculator: 2.500+ spent since x-mas 2007 - actual value: 450)

Head_on_a_Stick · 2024-10-09 12:42:00

cryptearth wrote:

As far as I got that news Valve didn't "bought" Arch but they started an even closer relationship

Most open source software projects operate as a do-ocracy so if Valve want changes all they have to do is assign staff :-)

EDIT: I would like to take this opportunity to welcome and praise our benign new Valve Overlords

Last edited by Head_on_a_Stick (2024-10-09 12:47:11)

mpan · 2024-10-09 21:28:02

Signing is neither a silver bullet nor you can make things secure by simply pouring enough of signing over them.

cryptearth wrote:

although I asked it before I just got a "because" as reply: does anyone know a/the reason why the package databases are not signed?

I can’t give you an authoritative answer.

The last few times the topic popped up, the explanation was the same: nobody sees a way to easily implement signing for a databases that are continuously updated by a large number of people. It’s very different than something managed by a single person (as Caleb’s aleque) or projects making huge releases a dozen times a year.

cryptearth wrote:

pacman supports it and even tries to get the signatures when syncing - and looking at the current development of archzfs it seems no problem to integrate it into some automatic workflow

Not really. It’s more complicated than that.

First of all, pacman doesn’t have the separation of purpose for keys. To use a key for database signing, that key must be trusted by the pacman keyring. Which means it may also be used to sign individual packages. That wouldn’t be relevant, if current signing model would only establish authentication between an organisation or some build environment, and the recipient. But Arch already gives a much stronger guarantee: the authentication goes all the way to the packager. This is undermined, if automated database signing is introduced without pacman being able to separate purposes of the keys.

Secondly, neither pacman nor the database deployment process supports signing of non-publication. Meaning that an adversary may circumvent the entire database signing process by not updating the database. As simple as that.

cryptearth · 2024-10-09 23:16:34

I don'T see any issue - likely as I miss some important information
the repo database is generated how? by some automated workflow - likely triggered when some package gets updated by some background task - I don't see any issue with implementing signing
I also don't see any issue about key usage - arch has its keyring which is signed by itself - so there already is some master key as root of the arch trust chain - either re-use it or create a new one signed by that key or the keyring
for me there's no difference between the archzfs auto-build and whatever generates the main repo db - as it is in fact the very same
and to bring it up again: why is pacman written with support for database signing when it's not implemented for the main repo anyway? it's not a problem of pacman or pgp - just the signing is missing on updating the database - which, broken down to its base steps, is even the same as that secureboot crap with a pacman hook to auto-sign the new UKI after a kernel update

the only caveat I see that it's maybe not adviseable to have such a master key loaded at all times on some auto-updating repo package list - but this can be mitigated by sub-keys and key rotation (that's one of the reasons why PKIs use intermediate certificates - to have something operational while keep the master root key offline)

loqs · 2024-10-09 23:47:29

My understanding is before the secure enclave to be paid for by Valve is implemented there has been no consensus on how to store the private database signing key securely.

Allan · 2024-10-10 07:43:23

mpan wrote:

First of all, pacman doesn’t have the separation of purpose for keys. To use a key for database signing, that key must be trusted by the pacman keyring. Which means it may also be used to sign individual packages. That wouldn’t be relevant, if current signing model would only establish authentication between an organisation or some build environment, and the recipient. But Arch already gives a much stronger guarantee: the authentication goes all the way to the packager. This is undermined, if automated database signing is introduced without pacman being able to separate purposes of the keys.

This claim of the blockage for database signing appears all the time and I find it to be nothing more than an excuse... If you really need to trace who signed with the organisational key, just log every single use of that key. From what I have seen, generally access to organisational sorts of keys is done by uploading to a signing enclave (requiring authenticiation) or directly on some sort of build service. All readily loggable and traceable.

mpan wrote:

Secondly, neither pacman nor the database deployment process supports signing of non-publication. Meaning that an adversary may circumvent the entire database signing process by not updating the database. As simple as that.

I'm not familiar of the phrase "signing of non-publication", but it would be easy for pacman to only accept databases updates when they were signed less than 24 hours (or similar time frame) ago. I half implemented it a decade ago, but did not finish it given the lack of use of database signatures... I will happily finish that when databases approach a state of being signed.

Arch Linux

#1 2024-10-09 01:03:29

[SOLVED] How does archlinux keep the updates from mirrors secure?

#2 2024-10-09 01:06:06

Re: [SOLVED] How does archlinux keep the updates from mirrors secure?

#3 2024-10-09 02:31:37

Re: [SOLVED] How does archlinux keep the updates from mirrors secure?

#4 2024-10-09 03:02:33

Re: [SOLVED] How does archlinux keep the updates from mirrors secure?

#5 2024-10-09 04:45:46

Re: [SOLVED] How does archlinux keep the updates from mirrors secure?

#6 2024-10-09 06:24:35

Re: [SOLVED] How does archlinux keep the updates from mirrors secure?

#7 2024-10-09 07:29:25

Re: [SOLVED] How does archlinux keep the updates from mirrors secure?

#8 2024-10-09 07:58:14

Re: [SOLVED] How does archlinux keep the updates from mirrors secure?

#9 2024-10-09 09:25:43

Re: [SOLVED] How does archlinux keep the updates from mirrors secure?

#10 2024-10-09 10:38:56

Re: [SOLVED] How does archlinux keep the updates from mirrors secure?

#11 2024-10-09 10:48:38

Re: [SOLVED] How does archlinux keep the updates from mirrors secure?

#12 2024-10-09 10:55:22

Re: [SOLVED] How does archlinux keep the updates from mirrors secure?

#13 2024-10-09 12:26:58

Re: [SOLVED] How does archlinux keep the updates from mirrors secure?

#14 2024-10-09 12:42:00

Re: [SOLVED] How does archlinux keep the updates from mirrors secure?

#15 2024-10-09 21:28:02

Re: [SOLVED] How does archlinux keep the updates from mirrors secure?

#16 2024-10-09 23:16:34

Re: [SOLVED] How does archlinux keep the updates from mirrors secure?

#17 2024-10-09 23:47:29

Re: [SOLVED] How does archlinux keep the updates from mirrors secure?

#18 2024-10-10 07:43:23

Re: [SOLVED] How does archlinux keep the updates from mirrors secure?

Board footer