Mirror hardening - complementing RFC 29
The idea was to not force requirements on existing mirrors, as they had no chance to agree on the requirements. But we'll attempt to convert existing mirrors to the new requirements.
But we also want to give leeway wherever needed, at the mirror admins discretion. Considering some mirror regions have different pre-existing conditions such as average speed in that region etc.
Perhaps we can emphasise this better, as it becomes more and more clear that the message we want to get across can still be interpreted in a variety of personal ways.
@wahrwolf & @pitastrudl - note for next meeting.
Edited by Anton Hvornum
Calendar days should be preferred as it's hard to account for holidays, even what calendar the recipient is using.
But lets either increase this or add that there's leeway before actions are taken @pitastrudl & @wahrwolf
I'm wondering whether what you are referring to as "domain hijacking" is actually guarded against at all, following the linked to Wikipedia definition:
Domain hijacking or domain theft is the act of changing the registration of a domain name without the permission of its original registrant, or by abuse of privileges on domain hosting and registrar software systems.
IIUC, what is proposed in this section is tooling, that is supposed to (automatically) sign a token file, which is used to evaluate when a given host has last synced. This means, that
mirrorctl
has to be used in an automated fashion on that host (as a post action to syncing). In consequence an attacker has access to these key material used to sign the token file and can sign anything they want.When it comes to actual "domain hijacking" I think what you would want to have is a proof in the domain records that you can validate or something like that.
As is, this section appears to conflate two topics.
From what I know, our largest issue with mirror security (or rather the payloads on those mirrors) at this point in time is, that we do not sign the repository sync databases.
How does cryptographic proof of the sync process improve on this, if an attacker can alter the repository sync database after a (signed) sync? More specifically: Which attack vector does this cryptographic proof improve upon?
Providing container images is orthogonal to using management tools like docker-compose and providing config files for those. While both might be useful in practice, they should be described as separate things. Or even better, the commitment should be generic without needlessly referring to specific tools. The motivation section even promises to define "Arch Linux commitment towards community in improving security goals".
The RFC has taken this into account and it produces no unwanted results other than old mirrors not supporting new features.
Doesn't !35 (diffs) argue for decommissioning of mirrors not in line with these specs?
Let's set the record straight, what are the real security issues of using a mirror:
archlinux-keyring
.In conclusion, we should sign our repository databases for extra security. This RFC does not address that issue.
+1, I'd also rather not move forward with this RFC.
All this crypto-identity-protocol requires an agent on every mirror and could be replaced with a "does the mirror currently serve the .db files we expect them to" monitoring script that automatically removes defunct mirrors from the official mirror list (which would be a more effective security control than what this RFC proposes).
The protocol described in the RFC is trying to "solve domain-hijacking", but the idea of domain-hijacking doesn't really apply in a system that is open-submission.