Darren Tucker <dtucker@xxxxxxxxxx> writes: >That's explicitly allowed by RFC4256. In addition to allowing zero prompts, >section 3.2 also says: > > "The language tag is deprecated and SHOULD be the empty string." > >and > > "The name and instruction fields MAY be empty strings; the client MUST > be prepared to handle this correctly. The prompt field(s) MUST NOT > be empty strings." In this case the prompts are empty strings. There's no name, no instructions, and no prompts. (It also depends on what you call an empty string, is it a string of length zero or an absent string? Both are means of encoding the empty string). >Do what it says in RFC4256 section 3.4? > > "In the case that the server sends a `0' num-prompts field in the > request message, the client MUST send a response message with a `0' > num-responses field to complete the exchange." Ah, OK, so it's a prompts issue hidden in the responses section of the docs (and one that appears to contradict what's in the previous section)... it does kinda beg the question though as to why a server would request zero responses for a request. (And one more thing to add to my evil-tricks-to-play-on-peers to see how many I can crash when I'm bored :-). Peter. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
