[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] [bug #28805] Global --key option (and possibly othe
From: |
Stephen Leake |
Subject: |
Re: [Monotone-devel] [bug #28805] Global --key option (and possibly others) are not reset between stdio commands |
Date: |
Wed, 03 Feb 2010 19:49:05 -0500 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (windows-nt) |
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