Today this package includes /var/lib/unbound/root.key xref https://src.fedoraproject.org/rpms/unbound/blob/rawhide/f/unbound.spec#_314 This is not compatible with an image-based updates model (e.g. ostree) where /var should be machine local state. A bit more information at https://ostreedev.github.io/ostree/adapting-existing/#system-layout and https://coreos.github.io/rpm-ostree/architecture-core/ Is this file actually intended to be mutable? Any reason it's not in e.g. /usr/lib/unbound/root.key ?
Yes, this file IS maintained by unbound-anchor.service and it is periodically modified. It implements RFC 5011 key rollover in case the package would not be updated after the root key, it will update to the new key automatically and in secure way. Other packages using unbound-libs use that file as a maintained trust anchor, specifically libreswan and stubby relies on it. Therefore it is very correct in where it is and why it resides in /var and not somewhere under /usr. If you think there has to be done with the current way, please reopen the bug and be more verbose, how it causes problems on coreos.
> If you think there has to be done with the current way, please reopen the bug and be more verbose, how it causes problems on coreos. It's not just coreos, we use rpm-ostree in other places, notably RHEL for Edge for example. Further, there's an increasing consensus on applying a similar model (i.e. rules) around /var with *other image based update systems*. For example, people may want to use dm-verity for OS updates, not ostree. You need the same logic and rules there. A bit better way to do this would be to ship the default key in `/usr/lib/unbound/root.key` (read-only, owned by the OS vendor) and any rollover key (AIUI, only if it actually changes) is stored locally in /var.
Problem is it requires the same path in both variants. The read-only version is just initial version for further maintenance. Other packages has hardcoded default to current path, which provides the best possible data. Because we prefer DNSSEC verification enabled by default, possibility to NOT install unbound-anchor package is just optional way done recently. The only alternative I can think about would be symlink from /var/lib/unbound/root.key to /usr/share/unbound/root.key in default installation. Which would get removed with real file as soon as unbound-anchor.service starts. But the symlink would still reside under /var directory, where unbound-libs consumers would read it. Would it help that way? Manual changing of path from every service wishing to do DNSSEC validation is not considered an option by me. The purpose of using unbound libraries is possibility of doing DNSSEC validation, otherwise they could use ldns library instead.
Would it work for you if the initial state were static content, but symlinked from /var? Here is what I tried and it seems works fine: Initial state, what might the package propose. I use /etc here, because it already has correct SELinux context in existing policy. $ LC_ALL=C.UTF-8 ls -l /var/lib/unbound/root.key lrwxrwxrwx. 1 unbound unbound 36 Oct 10 15:04 /var/lib/unbound/root.key -> ../../../etc/unbound/dnssec-root.key # /etc/unbound/root.key contains root anchor but in different format. $ cat /etc/unbound/dnssec-root.key . 172800 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= # emulate trigger by timer after unbound-anchor package installed $ sudo systemctl restart unbound-anchor # now the symlink is gone and normal file is there instead $ LC_ALL=C.UTF-8 ls -lZ /var/lib/unbound/root.key -rw-r--r--. 1 unbound unbound system_u:object_r:named_cache_t:s0 759 Oct 10 15:09 /var/lib/unbound/root.key # containing auto-managed root anchor. $ cat /var/lib/unbound/root.key ; autotrust trust anchor file ;;id: . 1 ;;last_queried: 1665407363 ;;Mon Oct 10 15:09:23 2022 ;;last_success: 1665407363 ;;Mon Oct 10 15:09:23 2022 ;;next_probe_time: 1665443484 ;;Tue Oct 11 01:11:24 2022 ;;query_failed: 0 ;;query_interval: 38085 ;;retry_time: 7617 . 172800 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b} ;;state=2 [ VALID ] ;;count=0 ;;lastchange=1665407363 ;;Mon Oct 10 15:09:23 2022 Is content under /etc/ okay? Is there reason why it should be under /usr only?
Then "danetool --check nlnetlabs.nl" still can be used, both before and after this change. I just expect other uses would work as well. Because the unbound-anchor tool uses atomic move, it does not need anything else. I think it should point to /etc/unbound for initial static key, because it is possible the key would need manual update from the administrator. Therefore /usr/share does not seem a good match.
> Is content under /etc/ okay? Is there reason why it should be under /usr only? It's definitely better. > I think it should point to /etc/unbound for initial static key, because it is possible the key would need manual update from the administrator. Therefore /usr/share does not seem a good match. OK. That said, bear in mind that that being in /usr doesn't mean it can't be changed (or to avoid double negatives) - content in /usr can be changed by overriding the package or component. It's still not entirely clear to me why we don't promote a workflow instead of applying package hotfixes for new keys, and keep the unbound-anchor.timer disabled by default for the (IMO less common) case of people not updating the OS but who do want new keys.
>> Is content under /etc/ okay? Is there reason why it should be under /usr only? > It's definitely better. Sorry, this was unclear. I meant to say that having it in /etc is better than /var. ostree actually imposes /usr/etc for content that comes from RPM so that one always has the default values. But not every system does this, so there's a convention to have static read-only content in /usr/lib/$component instead. But for the purposes here, /etc is completely fine. Thanks for looking at this!
Built in rawhide
FEDORA-2023-f1a7ba0307 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-f1a7ba0307
FEDORA-2023-f1a7ba0307 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-f1a7ba0307` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-f1a7ba0307 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-f1a7ba0307 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
Random variant idea: Only have the timer fire if the OS hasn't been updated in $timeframe. Where $timeframe might be e.g. 3 months. And we assume that if there was a key update, it would have been shipped in the package. This avoids penalizing everyone who *is* properly updating their OS and would be getting the key via OS updates with having to think about (e.g. proxy/IDS) random other external traffic from their systems.