On Thu, 22 Oct 2015 at 08:02:01 +0800, Matt Johnston wrote: > On Thu 22/10/2015, at 1:21 am, Guilhem Moulin <[email protected]> wrote: >> Thanks. However on second thought, the downside of this solution is >> that it might render remote systems unreachable after upgrade (at least >> for the users not reading changelogs or distrib NEWS files). Worse, it >> might not be noticed before a reboot, since upgrading typically doesn't >> kill existing SSH connections. > > Even enabling bundling could result in dropbear failing to start if > there were trailing options that weren't valid.
Fair enough, but — assuming that distributions didn't change compiling options, and that users didn't rely on dropbear ignoring trailing flags — the failure would have to come from a typo, right? Then I think it's fine to croak, from a distro perspective at least. > Perhaps I should just make the failure a warning instead, it'll be > visible on "service dropbear restart"? 'Ignored extra trailing "jk" of > "-sjk"' Combined with a changelog entry (and a NEWS entry on the distro side), that would indeed allow smooth upgrade. However note that you can't rely on the warning being visible on the error output since it depends on the init system. But AFAIK they all log in the system log when available (hence not in the initrd). >> By the way, out of curiosity, is there a reason why you're not using >> getopt()? It's POSIX after all, and you're already using it for scp. > > I think I looked into it a long time ago and it resulted in a larger > static binary size. It might be worth revisiting though. Backward > compatibility would still be an issue. Alright, I'll give it a try when time allows. I don't understand your last sentence though: backward compatibility for what? -- Guilhem.
signature.asc
Description: PGP signature
