On Sat, May 20, 2023 at 07:47:46PM +0200, Florian Obser wrote: > On 2023-05-20 19:37 +02, Paul de Weerd <we...@weirdnet.nl> wrote: > > On Sat, May 20, 2023 at 05:33:11PM +0200, Florian Obser wrote: > > | In case this turns out to be useful for unlocking work in the kernel. > > | > > | It's a minimum diff, if we want to go this way we probably want to move > > | init_soiikey() to the engine process and stop bouncing through the main > > | process when an interface changes. > > | > > | This changes behaviour: in -current we can change the sysctl and down/up > > | an interface to read the new value, with this diff that no longer > > | works. slaacd will (and can) only read the file on startup.
Having to restart slaacd when changing soii.key at runtime seems fine to me, it's a seed and not really a config file, anyway. > > | > > | This has consequences for the installer: slaacd starts before > > | /mnt/etc/soii.key is available in the upgrade case. Which in turn means > > | that we get a different IPv6 address in the installer than in the > > | running system. I don't know how big of an issue that is. > > > > Can't speak for others, but my use case for soii-addresses is for > > incoming connections - outgoing ones should use the temporary privacy > > addressed. So for the installer it doesn't matter. > > > > My guess is that this goes for many (most? all?) users of > > soii-addresses, so it should be safe to not have those in the > > installer during upgrades. > > I'm worried that someone runs a completely locked down network. > They installed a server, figured out the random but stable IP address > and added it to their firewall and only allow communication from known > IP addresses. > > They will be fine if they use sysupgrade(8). The installed base is > probably smaller than 6. Lots of time still until release to find out for real.
