Fedora Account System
Red Hat Associate
Red Hat Customer
This affects both the Fedora 41 and the RHEL 9 AppStream packages. After `systemctl enable --now unbound`, `rpm -V unbound unbound-libs ` shows: ``` .M....... g /etc/unbound/unbound_control.key .M....... g /etc/unbound/unbound_server.key S.5..UGT. c /var/lib/unbound/root.key ``` root.key is always updated by unbound-anchor, which is started before unbound by default (unbound-anchor.service for Fedora, ExecStartPre directive in unbound.service for RHEL 9). It might be reasonable to have `rpm -Va` ignore changes to this file. The other two key files seem to be changed to 600 by unbound, while the RPM spec expects 640. Reproducible: Always Steps to Reproduce: 1. dnf install unbound 2. rpm -V unbound unbound-libs 3. systemctl enable --now unbound 4. rpm -V unbound unbound-libs Actual Results: file modifications detected Expected Results: no modifications detected
Is more info needed? A fix would be very appreciated.
FEDORA-2025-a237ebb1f0 (unbound-1.23.0-3.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-a237ebb1f0
/var/lib/unbound/root.key is updated by unbound-anchor.service, which is enabled by default, but does not have to be installed. Because its contents would be indeed modified if it run successfully, it is correct to indicate that. But control key should be readable by group, where the server key should fix expected permissions to only owner readable file.
Thank you very much. Regarding the root.key file: In RHEL 9, the command that updates it is in an ExecStartPre directive in unbound.service, so the change to the file is not caused by a manual action by an administrator, yet it is tracked by RPM. Being able to override this file like a drop-in config would allow unbound-anchor to avoid overwriting a tracked file.
FEDORA-2025-93c022516f (unbound-1.23.0-3.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2025-93c022516f
If root.key would be ignored by the RPM, it would cause deleting the modified file and replacing it with package prepared content on each package upgrade. But that is not desired, new root DNSKEY can already be rolled securely. root.key has to remain marked modified whenever it is modified. /etc/unbound/unbound_control.key would be fixed on newly generated key and would have to be modified manually. unbound_server.key were corrected just in spec and should be fixed.
I see in the spec file that /var/lib/unbound/root.key is a symlink to dnssec-root.key, created during package installation. A solution without upstream changes could be to create the symlink with an ExecStartPre in unbound.service, if no root.key file/symlink exists yet. But I understand if it isn't worth the hassle. Is there any workaround to get a clean RPM state even if unbound-anchor is installed?
FEDORA-2025-a237ebb1f0 has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-a237ebb1f0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-a237ebb1f0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2025-93c022516f has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-93c022516f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-93c022516f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Nevermind, I can just change auto-trust-anchor-file in an override config file and change the unbound-anchor command line with a systemd override.
FEDORA-2025-a237ebb1f0 (unbound-1.23.0-3.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-93c022516f (unbound-1.23.0-3.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
With the clamav package (which distributes files that can later be updated by its 'freshclam' utility, the updatable .cvd files in its clamav-data subpackage are listed this way in the spec: %files data %defattr(-,%{updateuser},%{updateuser},-) # use %%config to keep files which were updated by 'freshclam' # already. Without this tag, they would be overridden with older # versions whenever a new -data package is installed. %config %verify(not size md5 mtime) %{homedir}/*.cvd (They're also listed as ghost files, in the accompanying clamav-freshclam subpackage:) %files freshclam %{_bindir}/freshclam %{_libdir}/libfreshclam.so.3* %{_mandir}/*/freshclam* %{_unitdir}/clamav-freshclam.service %{_unitdir}/clamav-freshclam-once.service %{_unitdir}/clamav-freshclam-once.timer %config(noreplace) %verify(not mtime) %{_sysconfdir}/freshclam.conf %ghost %attr(0644,%{updateuser},%{updateuser}) %{homedir}/bytecode.cld %ghost %attr(0644,%{updateuser},%{updateuser}) %{homedir}/bytecode.cvd %ghost %attr(0644,%{updateuser},%{updateuser}) %{homedir}/freshclam.dat %ghost %attr(0644,%{updateuser},%{updateuser}) %{homedir}/daily.cld %ghost %attr(0644,%{updateuser},%{updateuser}) %{homedir}/daily.cvd %ghost %attr(0644,%{updateuser},%{updateuser}) %{homedir}/main.cld %ghost %attr(0644,%{updateuser},%{updateuser}) %{homedir}/main.cvd ...As a result, daily.cvd doesn't fail verification even after it's been updated by freshclam. Could something like that work for unbound?