RE: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation
Peter Gutmann <[email protected]>
| Newsgroups | gmane.ietf.secsh |
|---|---|
| Message-ID | <9A043F3CF02CD34C8E74AC1594475C73F4B5BDE2@uxcn10-5.UoA.auckland.ac.nz> |
Niels Möller <[email protected]> writes: >Is this a bug or not? The reserved field is intended for extensions, but from >a quick look I can't see that the spec (RFC 4253) defines any valid behaviour >when a client or server receives a non-zero value there. I think a complient >implementation ought to disconnect. I would consider it a bug in the spec, indicating that there's a reserved field but not saying how it's meant to be handled. My code checks for its presence, but explicitly doesn't try and interpret it in any way. OTOH the following: execl("/usr/games/hack", "#pragma", 0); // try to run the game NetHack would also be perfectly valid behaviour. Or at least, you could argue that rejecting it if it's nonzero is valid, not rejecting it if it's nonzero is valid, and ignoring it is valid. It's a bit of a strange field in any case, unless your entire protocol extension is a single bitflag it's more or less useless for specifying extensions because there's no room for anything. >Is the intention that the endpoints should buffer arbitrarily large amounts >of data, or is the receiver of the data stream allowed to block and stop >processing ssh messages while delivering the data? The latter. Implementations would, I assume, be doing this anyway, if your incoming data stream is faster than what you can write to disk (or whatever), you use TCP's flow control to manage things. (Oh, and as Denis pointed out, I'd definitely support this one :-). Peter.