The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped automatically by the mailing list software.
--- Begin Message ---Hi all, For OpenWrt routers, writing to NVRAM by default can serve useful purposes in several contexts: 1. Saving a /dev/urandom seed file after boot, to prevent early- boot entropy starvation in the next boot. This was first discussed in 2016 [0], and raised again in 2022. [1] 2. Saving the last-known system date and time to /etc/dnsmasq.time for DNSSEC timestep validation, on every SIGTERM and reboot. Discussed in [2]. 3. Saving the current IPv6 prefix on the WAN port (obtained from the ISP) to a file. If the router reboots due to power loss, and the ISP changes the IPv6 prefix in the next boot, the old prefix can be invalidated in a Router Advertisements to prevent IPv6 outages in the LAN due to stale addresses. This is known as "Flash Renumbering Workaround Across Reboot", a recommended feature by RFC 9096 to work around broken ISPs. This need is raised in a recent odhcpd devolopment discussion [3], and is my motivation of sending this mail. An obvious objection to all of these behaviors is that, writing to the filesystem by default can cause unwanted NVRAM wears. As a result, any project discussion that involves writing to the filesystem would quickly become an off-topic one about "whether one should write to NVRAM by default" rather than its original problem. Although the answer seems to be "No, we shouldn't", but those discussions had an extremely limited audience - only a few developers (perhaps 3) who happened to work on that specific project were involved, their ideas and conclusions are not known to others. The next time the same problem is raised in a different context, the whole discussion repeats again. For example, in [1], Etienne Champetier said that they "would love to have more devs comment". While I was writing this mail, I just found it was also discussed on the context of https-dns-proxy [4] in 2024 - dnsmasq config was changed on every https-dns-proxy service restart, which was reported as a bug. Therefore, I think it would be a good idea to define a clear OpenWrt project policy on default writes to NVRAM in this mailing list, so all future developers could refer to the policy. We need to answer these questions: 1. In the current OpenWrt Stable Release or Development Build, do we have anything that writes to the filesystem by default (e.g. do we still have /etc/dnsmasq.time)? If yes, do we have a full list of them? 2. When is it acceptable to write to NVRAM by default? Always banned? Or is it conditionally allowed, with a rate limit (based on the file's timestep and NTP time, via NTP hotplug)? My impression is that rate-limited writes are allowed by the project, but this needs clarification. 3. Should we set a filesystem default-write policy for all OpenWrt packages? 4. In a previous discussion, an alternative solution was suggested by John Crispin that "let's add a system.system.write_state_to_ flash_on_boot=0/1 UCI option, and lock this and the DNSSEC time stuff with it, and default it to 0". Should we consider this idea? Thanks, Tom Li [0] https://www.mail-archive.com/[email protected]/msg01225.html [1] http://lists.openwrt.org/pipermail/openwrt-devel/2022-March/038340.html [2] https://www.mail-archive.com/[email protected]/msg01265.html [3] https://github.com/openwrt/odhcpd/issues/244 [4] https://github.com/openwrt/packages/issues/23469
--- End Message ---
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
