Security concerns with untrustworthy mirrors
The article warns the user to check the resulting list for untrustworthy mirrors. This seems nonsensical to me, as the packages are signed, to mitigate exactly this security concern. Checking the version history reveals, that the warning first appeared very early in the editing process (compare ), being reworded and moved by multiple users since then. The original note does not warn the users of "untrustworthy mirrors", but rather of "strange entries", leaving an ambiguity, whether the note is about malicious mirrors, or malformed entries (as might occur through a bug in reflector itself). As the ArchMirrorStatus-page does not carry a warning about malicious mirrors and as signing should make creating malicious mirrors impossible, I assume that the latter is the case.
As this is possibly a security-relevant issue, I have put this discussion thread up first and will only modify the page if nobody raises concerns.
- Packages are signed, but the package databases are not. i.e. an attacker could add or replace arbitrary packages with his own. -- Alad (talk) 11:47, 20 April 2016 (UTC)
- However this would (according to ) require the attacker to be a trusted user, as the key signing the forged package needs to be cross-signed with one of the master signing keys. Or am I mistaken? -- Nuvanda (talk) 16:02, 20 April 2016 (UTC)
Overwriting Default Mirrorlist
The warning at the top of the page stated that reflector overwrites /etc/pacman.d/mirrorlist by default. That is untrue. By default it prints a mirrorlist to STDOUT. The user must pass an option with a path to the default file to overwrite it (or any other file), which is what the following examples do, but that is a choice of the page's author(s), not reflector. Incidentally, I do not recommend using reflector for automatic updating of the system mirrorlist. It should be used to generate a list that is inspected by the user and only then move to the default location for system use. Xyne (talk) 23:08, 7 July 2016 (UTC)
- Good correction on that it actually just prints to STDOUT by default. Concerning the potential untrustworthiness of a mirror, how do you determine that? I thought reflector uses the official mirror list and that all packages were signed (see above)? -- Rdeckard (talk), ArchWiki Maintainer 01:48, 8 July 2016 (UTC)
- It does use the official mirrorlist API. Although the packages are signed, the databases are not. There are discussions on the forum and elsewhere about the potential exploits. I believe that replay attacks were the main concern, i.e. a malicious mirror could push old (signed) versions of packages with known vulnerabilities. As for which mirrors to trust, there is no simple answer. All of the mirrors are implicitly trusted but I do not know how they vet potential mirrors before inclusion. There is no way that the devs can rigorously verify the trustworthiness of each mirror. Beyond the mirror hosts, some users may wish to avoid mirrors in some countries due to possible government or corporate interference. As a rule of thumb, choose a mirror in a country with decent privacy and protection laws with a host that you know or at least one which has been around for a while and maybe involved in the open source community in other ways. Note that security concerns are only for database synchronization. Once you have those, you can download the signed packages from any host you want (which is what powerpill/bauerbill do for parallel package downloads). Xyne (talk) 20:53, 13 July 2016 (UTC)
Remove either reflector-timer or reflector-timer-weekly
The aur script reflector-timer currently, be default, updates every week, thus having no real difference (except for how the configuration works) with the other package, reflector-timer-weekly. I would at least update the article to mention that both update the mirror list once very week. But in my humble opinion I would remove at least one of them. But I'm not sure whether this is correct to do it. Bjarno (talk) 22:23, 24 October 2016 (UTC)