Subject: last-call issues..

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 13 Mar 2001 18:44:31 -0500

I believe that this is the current list of issues raised in the last
call on the core documents.  If I missed anything, let me know.

Issues in core documents:

 - Trademark verbiage needs to be struck completely.
	(editorial change only)

 - Niels Moeller: RSA signature encoding should be described as mpuint
rather than as "string"
	(editorial change only; touches architecture and transport drafts)

 - Subsystem robustness:

The ".cshrc output mixed into subsystem output" issue is purely a
local implementation issue; subsystem cookie text should be deleted.

Advice to implementors should state that server implementations which
allow for subsystems to be "plugged in" in should to define an
interface to subsystem implementations to prevent any extraneous
output (perhaps from a shell) from being mixed into the subsystem
output sent over the wire.  (no wire protocol change involved)

Resolution:
	need volunteer to provide text for this.

 - Wei Dai pointed out a discrepancy between the zlib spec and the
code actually in use which needs to be documented for interoperability
reasons relating to zlib partial flush.	

Resolution: wei dai provided corrected text (see archive)
	this corrects the spec to match what people have actually 
	implemented and deployed.

 - Wei Dai pointed out that the compression system should be referred
to as "zlib", not "GNU zlib"	
	resolution: trivial editorial change.

 - Darren Moffat: Should be rationale for why every message gets a
language tag.

 - Niels M. pointed out that there are current interop problems
between OpenSSH and lsh relating to channel EOF and channel close;
lshd attempts graceful shutdown but doesn't ever get an EOF from
OpenSSH's client.  

Resolution: the "forward output until EOF, then close channel"
	behavior should be documented as an implementors note.
	(need volunteer to supply text)

Possible additional work items raised in last call.

 - "denis bider" <[email-masked]> mentioned the lack of a
standard for presenting key fingerprints.

Resolution: need volunteer to write a draft for this.

 - Wei Dai requested an extension to allow for forwarding of a
server-chosen port ("pick a port, forward it to me, and tell me what
it is").

Resolution: Unresolved.  Do we need a new opcode for this or can we
overload the meaning of "forward port zero"?

---

From: [email-masked] (Niels M�ller)
Date: 14 Mar 2001 11:48:12 +0100

> 	(need volunteer to supply text)

I've changed the lsh/lshd behaviour now, and I wrote up a summary in
http://www.lsaytor.liu.se/~nisse/lsh/doc/NOTES, appended below. This
description is a little lsh specific, but perhaps it could be edited
to fit in the draft?

> overload the meaning of "forward port zero"?

Even if the "tcpip-forward" global request, with zero port, is reused
for this, a new reply message is still needed.

/Niels

CLOSING CHANNELS

The right conditions for closing a channel, and in particular a
session, are even more subtle. The basic rules are:

1. When SSH_MSG_CHANNEL_CLOSE is both sent and received, the channel
   is killed. This is unconditionally required by the spec.

2. When SSH_MSG_CHANNEL_EOF is both sent and received,
   SSH_MSG_CHANNEL_CLOSE is sent. This is a rule with a few
   exceptions, controlled by the CHANNEL_CLOSE_AT_EOF flag, see below.

These two rules are sufficient for most channel types.

When looking at the channel close logic for session channels, one has
to consider these three events that may occur in arbitrary order:

 * The client sends SSH_MSG_CHANNEL_EOF on the channel.

 * The server sends SSH_MSG_CHANNEL_EOF on the channel (this happens
   when there are no more processes which have the files the server
   has opened for stdout or stderr open).

 * The child process created by the server dies. An exit-status or
   exit-signal message is sent to the client.

Previous versions of lshd handled these conditions as follows: It
closed the channel according to rule (2) above, no exceptions. This
causes other clients to hang, because they never send any
SSH_MSG_CHANNEL_EOF. Using lsh did work right, only because it
responded to the exit-status message with a SSH_MSG_CHANNEL_EOF.

But the server can't rely on clients sending SSH_MSG_CHANNEL_EOF.
Instead, it must treat process death in much the same way as reception
of SSH_MSG_CHANNEL_EOF. The channel is closed once the server has both
encountered EOF on the process' stdout and stderr (resulting in a
SSH_MSG_CHANNEL_EOF), and sent an exit-status or exit-signal message.

As a further complication, rule (2) must be relaxed, because otherwise
the channel may get closed before the exit-status message is sent.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 14 Mar 2001 12:57:31 +0200 (EET)

> local implementation issue; subsystem cookie text should be deleted.

I don't agree on this change. I think the current text should be in
the connect document, but it might need some polishing:

----------------------------------------------------------------------
... As the user's shell is usually used to execute the
subsystem, it is advisable for the subsystem protocol to have a "magic
cookie" at the beginning of the protocol transaction to distinguish from
arbitrary output from shell initialization scripts etc. This spurious
output from the shell may be filtered out either at the server or at the
client.
----------------------------------------------------------------------

->

----------------------------------------------------------------------
As the user's shell might be used to execute the subsystem, it is good
subsystem protocol design to include a "magic cookie" at the beginning
of the protocol transaction to distinguish from arbitrary output from
shell initialization scripts etc. For example the subsystem protocol
version number packet might act as a this kind of "magic cookie". In
this case the subsystem protocol can be defined so that it ignores
everything before this "magic cookie" version number packet (similar
thing is already done for example the transport layer for the protocol
version strings).
----------------------------------------------------------------------

> output sent over the wire.  (no wire protocol change involved)

No, I think it more advisable to suggest that subsystem protocols
should be desing so that they can ignore the extra data before the
actual protocol starts. It makes things much easier for the
implementator, adminstrators and users.

Note, this "magic cookie" stuff is not part of the transport layer
protocol, it is part of the subsystem protocol specification, and we
just give here a hint for subsystem protocol designers how to make
their protocol resistant to this kind of invalid usage from the
adminstrators or from the users. 

> 	need volunteer to provide text for this.

Is the text above acceptable. 
-- 
[email-masked]                               Work : +358 303 9870
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Markus Friedl <[email-masked]>
Date: Wed, 14 Mar 2001 12:12:57 +0100

> the connect document, but it might need some polishing:

no. it's an issue of how your sftp-server implementation
and your sshd talk to each other. the can exchange as many
cookies as they like before speaking the sftp protocol.
the sftp _protocol_ does not need to be touched.

the server implementing sftp can print what ever cookies
it likes and the sshd has to filter the cookies out.
but this is not a _protocol_ issue.

-m

---

From: Markus Friedl <[email-masked]>
Date: Wed, 14 Mar 2001 12:13:58 +0100

> Resolution: need volunteer to write a draft for this.

INTERNET-DRAFT                                             Markus Friedl
draft-friedl-secsh-fingerprint-00.txt                The OpenBSD Project
Expires in six months                                         March 2001

                         SSH Fingerprint Format

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other docu- ments at
   any time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Distribution of this memo is unlimited.

Abstract

   This document formally documents the fingerprint format in use for
   verifying public keys from SSH clients and servers.

Introduction

   The security of the SSH protocols relies on the verification of
   public host keys.  Since public keys tend to be very large, it is
   difficult for a human to verify an entire host key.  Even with a PKI
   in place, it is useful to have a standard for exchanging short
   fingerprints of public keys.

   This document formally describes the simple key fingerprint format.

Fingerprint Format

   The fingerprint of a public key consists of the output of the MD5
   message-digest algorithm [RFC-1321].  The input to the algorithm is
   the public key blob as described in [SSH-TRANS].  The output of the
   algorithm is presented to the user as a sequence of 16 bytes printed
   as hexadecimal with lowercase letters and seperated by colons.

   For example: "4b:69:6c:72:6f:79:20:77:61:73:20:68:65:72:65:21"

References

   [SSH-TRANS] Ylonen, T., et al: "SSH Transport Layer Protocol",
   Internet Draft, draft-secsh-transport-09.txt

   [RFC-1321] R. Rivest: "The MD5 Message-Digest Algorithm", April 1992.

   [RFC-2026] S. Bradner: "The Internet Standards Process -- Revision
   3", October 1996.

Author's  Address:

   Markus Friedl
   [email-masked]
   Ganghoferstr. 7
   Munich, Germany

---

From: Damien Miller <[email-masked]>
Date: Wed, 14 Mar 2001 22:40:25 +1100 (EST)

> the connect document, but it might need some polishing:

I disagree - the current text mandates that subsystems be executed
through a login shell. IMO how subsystems are invoked should be left
completely up to the implementation.

-d

-- 
| Damien Miller <[email-masked]> \ ``E-mail attachments are the poor man's
| http://www.mindrot.org          /   distributed filesystem'' - Dan Geer

---

From: Simon Tatham <[email-masked]>
Date: Wed, 14 Mar 2001 14:03:10 +0000

Tero Kivinen <[email-masked]> wrote:
> shell initialization scripts etc.

This is a horrifyingly ugly way to separate subsystem output from
startup script output; not only is it ugly, it's also fragile. Why
not do it the ordinary way, by means of using different file
descriptors?

Here's a Unix implementation sketch, which is roughly similar to one
I already suggested to the OpenSSH people (but marginally more
coherent in details):

 - When invoking a subsystem, _don't_ open pipes on the child
   process's stdin/stdout. Instead, open pipes on some _different_
   fds passed to the child. Open /dev/null on the child's stdin and
   stdout.

 - The user's login scripts now run, and if they generate any output
   at all it goes to /dev/null.

 - The command you pass to the user's login shell is not
   `subsystem-program'. Instead, it's `subsystem-wrapper <rfd> <wfd>
   subsystem-program', where subsystem-wrapper is a small helper
   program (in /usr/lib, say). <rfd> and <wfd> are the file numbers
   of the pipes provided by sshd.

 - subsystem-wrapper first closes its stdin/stdout file descriptors.
   Then it uses dup2() to move the <rfd> provided on to fd 0, and
   move the <wfd> on to fd 1. Finally, it execs the real subsystem
   program.

So sshd ends up talking directly to the subsystem program, and vice
versa. Output from the init scripts automatically goes to /dev/null
and doesn't ever need to be filtered out of the same stream.

Best of all, the subsystem program _itself_ doesn't need to change
in the slightest. It still reads and writes on its stdin and stdout,
so it's still easy for people to write custom subsystems.

(It could be argued that if the user's startup scripts do anything
really interesting involving opening extra fds in the shell, this
mechanism might still blow up. Even more robust would be to open
named pipes in an appropriately secured subdirectory of /tmp, and
pass the names of the pipes to subsystem-wrapper.)

I think that, given the existence of properly robust solutions like
this, it's inelegant to suggest that implementors should use as
fragile a mechanism as magic cookies.

Cheers,
Simon
-- 
Simon Tatham         "Thieves respect property; they only wish the property to
<[email-masked]>    be their own, that they may more properly respect it."

---

From: Markus Friedl <[email-masked]>
Date: Wed, 14 Mar 2001 15:08:04 +0100

>    of the pipes provided by sshd.

the shell will probably close rfd and wfd (you don't need rfd, since
stdin is clean, only stdout is a mess).

-m

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 14 Mar 2001 16:47:13 +0200 (EET)

> the sftp _protocol_ does not need to be touched.

I don't really understand what you are saying above. The
transport/connection layer client will talk to transport/connection
layer server. The sftp-client will talk to sftp-server. The
sftp-client/server will NOT talk to the transport/connection layer
server nor client.

The transport/connection layer just assumes that when the subsystem is
started then everything is up to the subsystem to take care of the
input/output, it does not do anything else than pass those bytes from
server to client and vice versa.

The subsystem can assume that it has some connection between the
server and client, and the connection might be transport/connection
layer, but it might be rsh, tls, tcp/ip socket or anything. This
connection is completely transparent, i.e all characters goes thru.

The problem is that in quite common case there is some extra junk
involved before the actual protocol starts (linefeeds, some
warning/debug messages etc), and if the subsystem protocol has clear
and good design it can be ignore that junk, and start processing its
own messages only when it sees for example the version number exchange 
packet from the other end.

> but this is not a _protocol_ issue.

If we make it that way, then each subsystem implementation is tied to
each connection layer implementation, i.e you cannot take SSH
Communications Security's sftp-server and run it using lsh server,
because the lsh does not know which kind of cookies the sftp-server is 
going to use.

If we define that it is good protocol desing in the subsystems to
exchange version number etc any fixed packet in the beginning, which
can be used as a "magic cookie", then when the sftp-server of the SSH
Communications Security sends this packet the other ends client can
ignore everything until it sees this byte stream coming from the
connection. The transport/connection layer between does not have to
know anything about the subsystems, the subsystems must know about
each other. 
-- 
[email-masked]                               Work : +358 303 9870
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 14 Mar 2001 16:52:20 +0200 (EET)

> completely up to the implementation.

Where?

Only place I can find any reference to such text is this:
----------------------------------------------------------------------
As the user's shell is usually used to execute the subsystem, ...
----------------------------------------------------------------------

That does not mandate them to be executed using login shell, it just
says that they are usually executed using the login shell, and because 
of that you should desing the subsystem protocols so that they can
handle that situation also.

Whether the subsystems are executed using the login shell, or if they
are built-in to the server or if they are executed using the
/usr/games/nethack, is completely up the implementation.

In my text I changed that to say:
----------------------------------------------------------------------
As the user's shell might be used to execute the subsystem, ...
----------------------------------------------------------------------

to make it even more clear that subsystems are not necessarely
executed using login shell. 
-- 
[email-masked]                               Work : +358 303 9870
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 14 Mar 2001 17:04:13 +0200 (EET)

> not do it the ordinary way, by means of using different file

Because doing so is very hard if you try to port it to all possible
unix environments that there are. Also quite a lot of shells close ALL 
filedescriptors when they execute any program, just to get rid of
filedescriptors that are accidently left open by the system libraries
(like getpwent/getpwnam/getpwuid, which might leave the /etc/passwd
filedescriptor open).

Also I don't want to even think how this should be done on VMS or IBM
Mainframes. Somebody might want to have sftp for those systems also...

> fragile a mechanism as magic cookies.

Cookies work fine, and they are standard way of detecting that data
stream is ok. I think they are much more robust than playing around
with file descriptors etc. Also even if you can use file descriptors,
it does not mean that the other end can and will, thus you still might 
end up having non working subsystem, because other end sent something
you didn't want to ignore before starting the subsystem. 
-- 
[email-masked]                               Work : +358 303 9870
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Wei Dai <[email-masked]>
Date: Wed, 14 Mar 2001 07:52:42 -0800

> overload the meaning of "forward port zero"?

FYI, the latest SOCKS 5 draft overloads the meaning of "forward port zero" 
for this purpose. See
http://www.socks.nec.com/draft/draft-ietf-aft-socks-pro-v5-04.txt.

As a seperate issue, I'd also like to see UDP forwarding some time in the
future.

---

From: Jason R Thorpe <[email-masked]>
Date: Wed, 14 Mar 2001 09:31:07 -0800

> but this is not a _protocol_ issue.

Hm, this doesn't really strike me as good design -- if we all agree that
subsystems require only a bi-directional stream communication channel,
then it seems like a cop-out to rely on some special in-band-but-filtered-out
communication between the sftp server and the transport server.

Who's to say one couldn't use sftp over some generic TLS pipe (say, like
the one that the stunnel package implements)?

I'm with Tero on this one -- recommend that subsystems ignore unrecognized
data sent over the channel, up until the subsystem version exchange occurs,
and require that no non-subsystem data appear on the channel once the version
exchange is complete.

-- 
        -- Jason R. Thorpe <[email-masked]>

---

From: [email-masked] (Niels M�ller)
Date: 14 Mar 2001 18:33:57 +0100

> sftp-client/server will NOT talk to the transport/connection layer

I think he's saying that if filtering is done at the server end,
clients need not know about it, and it's therefore not a protocol
issue at all.

I agree that using cookies are a real ugly hack for working around
random configuration errors. I can understand that you may want to do
that under some circumstances, but if so, please do on the server end,
in order to localize the ugliness.

> because the lsh does not know which kind of cookies the sftp-server is 

If you just use the first SSH_FXP_VERSION packet as the cookie, that's
no problem (except that lshd doesn't do any filtering).

A different problem is that the server needs to know how to recognize
the start of the real communication for each subsystem. That's a
little painful for those who implement filtering, but I think that is
the price you have to pay in order to keep the clients from knowing
about the ugliness. And it shouldn't be too difficult, you can have a
simple table like

  # Subsystem name  program                         cookie
  sftp              /usr/local/sbin/sftp-subsystem  00000033

and that's all the server needs to know.

/Niels

---

From: [email-masked] (Niels M�ller)
Date: 14 Mar 2001 19:06:05 +0100

> communication between the sftp server and the transport server.

It relies only on a clean bi-directional stream. If you have that (as
is usually the case), none of this cookies-and-filtering stuff is
needed at all. The problem is that on systems where both of the
conditions below are true,

 * Subsystems are implemented as external programs that are exec:ed
   via the user's login shell.

 * The shell startup scripts, either system global scripts or the user's
   personal scripts, are broken and send some random junk to the shell's
   stdout.

the connection between the ssh server and the sub-system server is
*not* a clean stream, it is polluted. Tero and others that advocate
cookies believe that it is important that the protocol works even in
this case, where you don't have a clean and tidy channel. There are
several possible solutions for cleaning it up:

1. Don't start the login shell, just exec the sub-system server
   directly. I think the convention to use the login shell is peculiar
   to unix. Tero seems to believe that VMS and mainframes have similar
   problems, I don't know but that sounds quite unlikely to me.

2. Fix the scripts. You'd want to do that anyway, a .bashrc that
   writes to stdout is utterly broken and may cause all sorts of
   trouble.

3. Let the server tidy up, by looking for some data that resembles the
   real sub-system protocol data, and filter out everything before that.

4. Require clients to perform the same filtering.

Tero seems to argue that (4) is the preferable solution. I think (2)
is the only good solution, and if that for some reason is impractical,
I'd choose between (1) and (3) (or other local tricks like the fd juggling
that someone else proposed). I.e. solve the problem locally.

Pushing a server side configuration error over to the clients to deal
with seems wrong.

And for *all* the solutions but (1), it's *still* possible for both
users and sysadms to screw things up by writing stuff in the shell
startup scripts. Consider this .bashrc:

  #! /bin/bash
  
  (sleep 17; echo "I'm alive!") &

/Niels

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 14 Mar 2001 14:00:08 -0500

[working group chair hat off.  raving lunatic anti-csh bigot hat on.]

So, this whole issue is caused by a well-known and well-understood
interaction between naive users and csh; while it is possible to
misconfigure other shells in the same way, it appears that, in
practice, it happens much less frequently.

Simon Tatham's alternative would be perfect, except for one fatal
problem -- csh and csh-derived shells (stupidly) close descriptors
other than 0, 1, and 2.  Traditional sh-derived shells (including ksh,
bash, zsh, and others) do not have this bug.

This is clearly a local issue, easily fixed by removing the offending
shell.

[if you take this message seriously, you need a vacation..]

					- Bill

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 14 Mar 2001 21:00:55 +0200 (EET)

> clients need not know about it, and it's therefore not a protocol

I don't want the transport/connection layer server/client to know too
much about the subsystem protocol. The subsystem client/server DO know 
about the subsystem protocol and they CAN detect if the input is valid 
subsystem protocol or not. If it is not, then they can ignore stuff
until they see something familiar....

> no problem (except that lshd doesn't do any filtering).

Yes, I exactly think that SSH_FXP_VERSION would be used as a magic
cookie, but transport/connection layer server/client does not need to
know anything about that. They just let everything through. The other
end sftp client/server will know that the first packet will contain
xxxx xxxx 02 0000 0003 ... and they should ignore everything before
they see that coming from the stdin. 

> about the ugliness. And it shouldn't be too difficult, you can have a

Simply make the client to say:

	while (check_if_valid_subsystem_version_packet(input_packet, len) == FAIL) {
		input_packet++, len--;
		/* Read more data if there isn't enough in the
		  input_buffer. */
	}

and then when succeeds, then start the real protocol code. Both your
server and client MUST do that already, because there can be extra
junk before the SSH-2.0-xxxx version string.

I don't want to put this code to the transport/connection
server/client, I want to put to the subsystem server/client, as it
knows about the subsystem protocol. Also it is not MUST to specify
such thing in the subsystem protocol, but it might be good idea to add 
the text saying so to the subsystem protocol specificiation. 
-- 
[email-masked]                               Work : +358 303 9870
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Jason R Thorpe <[email-masked]>
Date: Wed, 14 Mar 2001 11:23:07 -0800

>    problems, I don't know but that sounds quite unlikely to me.

Possibly peculiar to current unix implementations.  Unix certainly
doesn't require a shell to intervene for programs started by e.g.
inetd(8).  I seems reasonable to me to do it this way, as well.  However,
read on :-)

 > Pushing a server side configuration error over to the clients to deal

Well, it's not clear that it's a "configuration error".  It could be
debugging information that the client could choose to display on the
user interface.

Let's take a broader look.  You say that SFTP requires a "clean
bi-directional stream", which is provided by a transport layer.
Well, really, the SSH protocol transport layer itself requires
the same thing -- it happens to be provided by TCP.

However, in the SSH transport setup, we allow "junk" to exist on
the "channel" (the TCP connection) up until the protocol version
exchange message, and it is the responsibility of the client to
cope with this.  While the transport document describes the intended
use of this feature, it doesn't *require* that it be the only use.

Now, since no one is arguing (as far as I can tell) that the transport
document should be changed in this regard, I personally see no reason
not to be consistent with it when dealing with subsystems.

Seriously -- in concept, what is *really* different from the transport
that the SSH transport protocol runs over and the transport (the SSH
transport) that a subsystem runs over?  Nothing!  They're both bi-directional
streams -- the latter happens to be secured.  If they're both conceptually
the same, then I think we should treat them the same way.

 >   (sleep 17; echo "I'm alive!") &

Sure, and you could have a buggy TCP implementation on the peer, as well
(say, which transmits garbage in one of the segments).  What happens in
that case?  The "channel" that the SSH transport runs on gets killed (by
the SSH transport implementation -- presumably, the MAC would fail,
or something).  If we get a bogus clump of data on the "channel" that
the subsystem is using, then the subsystem can kill the channel (by exiting,
for example) if it causes a protocol error for the subsystem.

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 14 Mar 2001 14:37:17 -0500

I continue to have difficulty seeing this as anything other than a
purely local implementation issue, not a matter which requires BIZARRE
HACKS in the protocol.

My understanding is that the motivation for the "subsystem cookie"
hacks originated from vendors of clients for non-UNIX systems who
didn't want to have to do basic UNIX support.  Given that a client
vendor already has to be able to say "it's the server's fault, talk to
your server vendor", I don't see what the big deal is, but..

>   (sleep 17; echo "I'm alive!") &

That's a contrived example.

Here are some non-contrived examples which will do similar damage (or
worse); I've seen all of the following in practice:

	- catastrophic error which kills the shell 
	- prompting the user for input and waiting for an answer
	  (with no read timeout)
	- exec'ing a different shell with different arguments.
	- running programs such as the X11 "resize" program (which
	  sends an ANSI escape sequence to trigger an answerback
	  message)
	- starting backgrounded X programs (which will then
	  asynchronously spew error messages into the output stream
	  when they can't find the X server)

If we want to be robust against user configuration errors, where do we
draw the line?  I don't think it's worthwhile to even start down this
road.

					- Bill

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 14 Mar 2001 14:46:18 -0500

> As a seperate issue, I'd also like to see UDP forwarding some time in the

"Please send draft".

					- Bill

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 14 Mar 2001 15:23:34 -0500

> because the lsh does not know which kind of cookies the sftp-server is 

Each server implementation which wants to allow subsystems to plug in
needs to define an "API" or "ABI" for this.  Such an API/ABI is
necessarily OS-family-specific.

It would be very cool if all the unix server vendors were to get
together and define a common subsystem interface.. but that's not a
plausible work item for this working group -- API's are out of scope
for the IETF..

						- Bill

---

From: [email-masked] (Niels M�ller)
Date: 14 Mar 2001 22:48:53 +0100

> debugging information that the client could choose to display on the

Any such debugging information should be sent to *stderr*. I've not
written any sftp client yet, but I believe any reasonable one should
tolerate stderr data and redirect it either to the client's own stderr
or to /dev/null.

But sending debugging information (from shell startup scripts) to
stdout *is* seriously broken, and a configuration error.

/Niels

---

From: [email-masked] (Niels Möller)
Date: 14 Mar 2001 22:58:54 +0100

> until they see something familiar....

I think I have talked too much about this already, but let me write a
short summary and then I'll try hard to stay quiet for a day or two:

You think about filtering as knowledge about the sub-system protocol,
which makes it natural to think that the sub-system client should know
about it.

I think about it as knowing about possible brokenness in the
exec-by-login-shell mechanism, which is a somewhat obscure
implementation detail in (most) ssh servers on Un*x, and working
around that. From that point of view, requiring the client to do the
working around is clearly not the right thing to do.

It's the transport layer's responsibility to provide a clean channel,
with no garbage, for the sub-system layer to use. If the transport
layer fails to do that, for any reason, it's not the sub-system's
fault.

/Niels

---

From: Simon Tatham <[email-masked]>
Date: Wed, 14 Mar 2001 22:49:41 +0000

> This is clearly a local issue, easily fixed by removing the offending

I did propose a modified method using named pipes which would even
work with csh.

This was clearly a bug; it sounds as if you'd prefer a method that
actively discouraged csh :-)

Cheers,
Simon
-- 
Simon Tatham         "I'm cross. I'm going to have a tantrum.
<[email-masked]>    <pause> How do I start?"            - my uncle