Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes

[Robin Green]

On Fri, Jan 30, 2004 at 03:56:40PM +0000, Scott Parish wrote:
> I was thinking about this some last week; i've completely given up on
> the smart server as a cgi concept--it would work, but its too much
> of a hackish mess.

If you literally meant CGI, CGI is inefficient - separate process
spawned per request, which has to start up and restore state each
time. As opposed to a module or servlet or dedicated server or
whatever which can keep state in memory. So I agree.

> Having discarded that, and not really wanting to
> completely start from scratch on a whole new lead me to the idea of
> creating an ssh subsystem that would be a smart server.

AFAIK, any ssh approach requires shell access for every user, which
cannot be disabled. IMO this is broken - it should be possible to
reuse the authentication+encryption+compression+protocol aspects of
SSH without having to give people complete shell access (which allows
them to e.g. do local root exploits more easily). For a project
which is supposedly focused on security, this seems to me a major
oversight. Someone correct me if I'm wrong.

You could argue that that was never a goal of ssh and it contradicts
the name "Secure Shell". But I maintain that it's a logical next
step for ssh. It would allow reusing not only code but also some
sysadmin knowledge. It's like "Why set up a whole new system to
provide the same benefits as ssh, with a new set of stuff to learn,
and a new set of code to audit and worry about for vulnerabilities,
when ssh already provides it and is battle-hardened?"

> One could either
> take and largely extend the existing sftp subsystem, or start from
> scratch. It seems that this would be a very clean, as well as secure
> approach.

If ssh gets fixed as I just described.

>   + protocol negotiation
> 
>     I'd like to see a command in the protocol that identifies which
>     commands the server supports. This way a smart client could figure
>     out just how smart a given server is and act accordingly, and we
>     wouldn't have to force the whole world to upgrade at the same time.

+5 insightful.

>     Additionally it could be nice if individual protocol commands were
>     versioned. This could easily be achieved by having a required
>     protocol command "capabilities" (or something) that would return a
>     table of a| command name, b| command version.

I like the end goal of "don't force everyone to upgrade". But let's
try and keep an eye on simplicity. More protocol complexity with tons
of versions to track (and branches of versions!) means more code
complexity. I believe versioning commands is too much and is 
unnecessary.

Just use one version number for the entire protocol, and formally specify
each protocol version _before_ it comes out of beta. Then no need to make
complex queries about what the protocol supports. This also saves on
bandwidth and latency.

More rules could make it simpler still for client implementors. For example,
following UNIX .so versioning, have major and minor version numbers for
protocols, where:

- If there is a major incremement and the client doesn't support it,
it is incompatible, so give up immediately.

- If there is a minor incremement, the protocol authors guarantee that it is
backward-compatible, so older clients can talk using the old version protocol
and it's guaranteed to still work.

Or something like that. That scenario could mean NO complex hacks to work with
different protocol versions, excepting protocol implementation bugs.
-- 
Robin