Re: [Monotone-devel] merging branch to allow 'automate stdio' over the network

[Stephen Leake]

Timothy Brownawell <address@hidden> writes:

> I think branch net.venge.monotone.tbrownaw.serve_automate.single_port
> is ready for merging. Instead of putting raw 'automate stdio' on the
> network, this encapsulates it as netcmds and keeps the same initial
> negotiation/authentication sequence (and the same 'bye' sequence) as
> netsync.

Excellent!

All tests pass on MinGW (more precisely, the tests that fail also fail
on the main branch).

> This splits netsync.cc into multiple files, and splits the negotiation
> and teardown out of the 'session' class. 

Much clearer than it used to be, and good preparation for replacing
netxx with something else.

> Then it adds 'automate_cmd' as an alternative to
> 'anonymous_cmd'/'auth_cmd' so that network clients can request
> either an automate connection or a netsync connection. This also
> adds an "automate remote_stdio <address>" command to make use of
> these changes, 

One nit: in monotone.texinfo, the 'hostname' argument to 'automate
remote_stdio' should be 'URI-or-HOSTNAME', as it is for sync. It
appears ssh: and file: are supported here. ssh: is clearly required.
file: doesn't make much sense, since you can just run automate
directly on it, but there's no point in forbidding it.

> and on the server side a get_remote_automate_permitted(identity,
> command, options) hook which is checked for each automate command
> received and defaults to "deny everything".

It would be useful to define a "safe subset" of commands that a
"typical server" should allow, and provide an alternate definition of
get_remote_automate_permitted that implements it. Every read-only
command would be a good candidate.


-- 
-- Stephe