> 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 larger
>> static binary
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 users not reading changel
On Thu 22/10/2015, at 1:21 am, Guilhem Moulin wrote:
> 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 rend
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
Hi Guilhem,
Thanks for pointing that out, I’ve made -sjk fail rather than be dropped
silently.
I’ve applied the other patch to avoid MOTD when there’s a command.
Thanks,
Matt
> On Wed 14/10/2015, at 3:13 am, Guilhem Moulin wrote:
>
> Hi,
>
> It's fine not to implement bundling in dropbear's
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 12