From ArchWiki
Jump to navigation Jump to search

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)

How much of a risk is overwriting /etc/pacman.d/mirrorlist by default? Reflector has a filter for mirror score. What are the chances a high 'mirror score' will be malicious? Manual inspection is, well, manual. Users can assess the relative risk and decide for themselves. Perhaps use a note for it instead of a warning. Stuthtle (talk) 19:09, 26 September 2021 (UTC)

Pacman hook

Removing the pacman hook is probably silly. Generating a mirrorlist every time the list moves is no more arbitrary than putting it on a timer or running it at boot, and a systemd hook is certainly less useful for many kinds of deployments. Options are good here, and any method is a convenience that won't prevent a user from needing to use their brain to occasionally intervene manually when pacman starts spitting out http errors.

Granted, the pacman hook in its current form is also probably silly as it relies on the systemd service and deletes the pacnew as opposed to dealing with it in pacman config, but I wouldn't be too quick to throw the baby out with the bathwater. I think servers can weather a small text file being basically used as just a trigger by a handful of people, and keeping a small demonstrative script in the wiki is better than ignoring a completely valid use case for pacman hooks. Gnubeest (talk) 13:06, 3 May 2021 (UTC)

I agree that the section should be kept, but I don't think it's silly to use the systemd service. The service is has hardening options, so it's arguably more secure than running reflector directly. -- nl6720 (talk) 08:00, 4 May 2021 (UTC)
I used this mirrorlist hook for a few months on my machines when I noticed my desktop's kernel version was quite outdated compared to another laptop that I had reinstalled Arch on. Because it hadn't refreshed mirrors for a while given the sparse update schedule of the mirrorlist package, it had fallen well behind on updates. It's a really insidious error because it happens silently, since you will still be able to update your device without ever knowing how behind you might be. I don't think this is a good method to keep around. -- Nasdack (talk) 04:57, 28 June 2021 (UTC)