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. > | > | 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. > > Paul > -- In my defence, I have been left unsupervised.
