Re: svr_getopts should either support bundling or fail if bundling is used

> On Thu 22/10/2015, at 8:24 am, Guilhem Moulin wrote: > >>> 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

Re: svr_getopts should either support bundling or fail if bundling is used

Hi Matt, On Wed, 21 Oct 2015 at 22:11:43 +0800, Matt Johnston wrote: > Thanks for pointing that out, I’ve made -sjk fail rather than be > dropped silently. Thanks. However on second thought, the downside of this solution is that it might render remote systems unreachable after upgrade (at least

Re: svr_getopts should either support bundling or fail if bundling is used

On Thu, 22 Oct 2015 at 08:02:01 +0800, Matt Johnston wrote: > On Thu 22/10/2015, at 1:21 am, Guilhem Moulin 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

svr_getopts should either support bundling or fail if bundling is used

Hi, It's fine not to implement bundling in dropbear's option parsing function (svr-runopts.c's svr_getopts), but it should at least croak if argv[i][2] != '\0'. For instance dropbear -rdropbear.key -p127.0.0.1: -sjk should either fail, or be parsed as dropbear -r dropbear.key -p