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)
I think the systemd service should contain some configurations to restrict malicious behavior to a minimum if reflector is exploited. I use the following options (may contain redundances) but I'm unsure if it would clutter the article.
... [Service] ProtectSystem=strict ProtectHome=yes PrivateDevices=yes ProtectKernelModules=yes ProtectKernelTunables=yes ProtectControlGroups=yes PrivateTmp=yes PrivateUsers=yes NoNewPrivileges=yes MemoryDenyWriteExecute=yes SystemCallArchitectures=native RestrictNamespaces=net PrivateMounts=yes SystemCallFilter=@system-service ReadWritePaths=/etc/pacman.d/mirrorlist Type=oneshot ExecStart=/usr/bin/reflector --age 12 --protocol https --sort rate --save /etc/pacman.d/mirrorlist ...
- This information is better given once in a "how to harden systemd services" article rather than copy-pasting almost the exact same 13 lines into every example service listed anywhere on the wiki. So I disagree with listing this on any article, whether it is reflector or not. -- Eschwartz (talk) 16:32, 16 December 2018 (UTC)
- If one of you wants to contribute, please join in at Talk:Security#Using systemd for more secure services. I agree it would sure make sense to have something on it. With respect to individual services, it can easily get a little catch-22 though. Because a general article obviously can not determine what works for an individual unit (reflector) and what not.
- Brolf, for your example what may also make sense is that you contact the maintainer of Indigo (talk) 22:04, 6 January 2019 (UTC) AUR to add your service. Then, you can refer/crosslink into the package from the article. --