openssh unix dev - Apr 2018 - draft-miller-ssh-agent-02: extensions and success messages

On 04/04/18 21:56, Damien Miller wrote:
> 
> I don't follow - clients always have to know that the last message sent
> was, otherwise they wouldn't be able to disambiguate the shared
> SSH_AGENT_SUCCESS / SSH_AGENT_FAILURE.
The format of that message doesn't change though -- it's always a single
byte (so you don't need that information in the function that actually
parses the message). With this proposal that is no longer the case. I
mean, maybe it's a pointless concern and things are fine as proposed. I
wrote my client implementation to not have any of that state there for
parsing messages to make it easier to test and fuzz. I know other
implmentations don't necessarily do the same thing.
> 
> If it's a problem in practice, then I guess I could add an extension-
> specific reply message to a future draft, but I'm struggling to think
of
> a situation in which it would be needed.
> 
> BTW nothing at present implements any extensions AFAIK.
> 
In case you want an example, in the prototype code I've been working on
for a hypervisor-controlled SSH agent for each VM/machine at work I'm
presently squatting on some high message ID numbers for retreiving
additional information from the agent. I would like to change these to
use the extension mechanism as soon as it's finalised.

Thanks for entertaining my question anyway. :)

On Thu, 5 Apr 2018, Alex Wilson wrote:
> On 04/04/18 21:56, Damien Miller wrote:
> > 
> > I don't follow - clients always have to know that the last message
sent
> > was, otherwise they wouldn't be able to disambiguate the shared
> > SSH_AGENT_SUCCESS / SSH_AGENT_FAILURE.
> 
> The format of that message doesn't change though -- it's always a
single
> byte (so you don't need that information in the function that actually
> parses the message). With this proposal that is no longer the case. I
> mean, maybe it's a pointless concern and things are fine as proposed. I
> wrote my client implementation to not have any of that state there for
> parsing messages to make it easier to test and fuzz. I know other
> implmentations don't necessarily do the same thing.
ok, so what behaviour would you prefer?

AFAIK the only way to be completely unambiguous would be to echo the
full extension name in the reply, which seems unnecessarily verbose.

-d

On 06/04/18 05:19, Damien Miller wrote:
> On Thu, 5 Apr 2018, Alex Wilson wrote
>>
>> The format of that message doesn't change though -- it's always
a single
>> byte (so you don't need that information in the function that
actually
>> parses the message). With this proposal that is no longer the case. I
>> mean, maybe it's a pointless concern and things are fine as
proposed. I
>> wrote my client implementation to not have any of that state there for
>> parsing messages to make it easier to test and fuzz. I know other
>> implmentations don't necessarily do the same thing.
> 
> ok, so what behaviour would you prefer?
> 
> AFAIK the only way to be completely unambiguous would be to echo the
> full extension name in the reply, which seems unnecessarily verbose.
> 
I would be fine with echoing the full name of the extension, personally.
An extra 20-30 bytes or so over AF_UNIX is not far off being free
performance-wise on modern systems.

If you think that's a non-starter though, then maybe a next-best option
could be an "extension reply" message? That way there's no
ambiguity
about the structure of the "success" message at least.

As I said, though, do feel free to tell me you think it's not worth the
effort and I should stop whinging. I'll still use the extension
mechanism as proposed. :)