Re: [Monotone-devel] [bug #28805] Global --key option (and possibly others) are not reset between stdio commands

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> URL:
>   <http://savannah.nongnu.org/bugs/?28805>
>
>                  Summary: Global --key option (and possibly others) are not
> reset between stdio commands
>                  Project: monotone
>             Submitted by: tommyd
>             Submitted on: Mi 03 Feb 2010 23:17:14 CET
>                 Category: automation interface
>                 Severity: 3 - Normal
>               Item Group: incorrect behavior
>                   Status: None
>                  Privacy: Public
>              Assigned to: None
>              Open/Closed: Open
>          Discussion Lock: Any
>       mtn version --full: mtn-0.46
>
>     _______________________________________________________
>
> Details:
>
> If the user once selected a specific --key for an operation, like f.e. push,
> pull or sync, it is impossible for him to remove that option between the
> execution of two commands in stdio.

I'm not clear if we are supposed to discuss this here, or by replying
to the bug. I suggest that discussion of proposed changes like this
should be here, possibly recording decisions on the bug.

I think there is a similar issue with changing workspaces;
the stdio process has one current directory, and there is no mtn
command to change that.

bug #28789 is also similar; .mtn-ignore and _MTN/options are cached.

The current approach for these and similar issues is to close the stdio
session and start a new one to change the key and workspace. Is that
really such a large cost?

The advantage of caching such things between separate stdio commands
is speed; that seems appropriate for the typical case.

We could add a single "reset all options" command that would redo the
startup initialization; that would not allow changing the workspace.

> Additionally, an --anonymous option could be added to all netsync commands
> which explicitely circumvents key authentication.

Should the server be able to reject connections that don't provide
keys? Otherwise this seems like a security hole.

-- 
-- Stephe