Re: draft-miller-ssh-agent-02: extensions and success messages

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



On Wed, 4 Apr 2018, Alex Wilson wrote:

> Hi,
> 
> I've been reading the RFC draft for the OpenSSH agent protocol and
> trying to understand the extension mechanism. It seems like a client,
> after sending an extension message, will have to then interpret any
> following success (0x6) message differently according to the extension
> request just sent. The example with the "query" extension returning a
> success message with extra data appended would seem to imply that, too.
> Is that correct?
> 
> If so, I would love to get some insight into why this was chosen over
> having an "extension reply" message number or something like that. It
> seems to me that the protocol up until now has always been stateless --
> you didn't have to know what you sent last in order to parse and
> validate received data -- which generally makes implementations nice and
> simple. After this change, client impls will have to change their
> parsing of the success message dramatically after sending each extension
> request message (and will have to track which ext they last sent etc),
> since it doesn't include enough information in the message itself any
> more to figure out what it should contain.

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.

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.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux