Robin Candau

Critical rsync security release 3.4.0

We'd like to raise awareness about the rsync security release version 3.4.0-1 as described in our advisory ASA-202501-1.

An attacker only requires anonymous read access to a vulnerable rsync server, such as a public mirror, to execute arbitrary code on the machine the server is running on. Additionally, attackers can take control of an affected server and read/write arbitrary files of any connected client. Sensitive data can be extracted, such as OpenPGP and SSH keys, and malicious code can be executed by overwriting files such as ~/.bashrc or ~/.popt.

The sshd service needs to be restarted after upgrading to openssh-9.8p1

After upgrading to openssh-9.8p1, the existing SSH daemon will be unable to accept new connections (see https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/issues/5).
When upgrading remote hosts, please make sure to restart the sshd service using systemctl try-restart sshd right after upgrading.

We are evaluating the possibility to automatically apply a restart of the sshd service on upgrade in a future release of the openssh-9.8p1 package.

Increasing the default vm.max_map_count value

The vm.max_map_count parameter will be increased from the default 65530 value to 1048576.

This change should help address performance, crash or start-up issues for a number of memory intensive applications, particularly for (but not limited to) some Windows games played through Wine/Steam Proton. Overall, end users should have a smoother experience out of the box with no expressed concerns about potential downsides in the related proposal on arch-dev-public mailing list.

This vm.max_map_count increase is introduced in the 2024.04.07-1 release of the filesystem package and will be effective right after the upgrade.