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

[Thomas Keller]

Am 04.02.10 01:49, schrieb Stephen Leake:
> Thomas Keller <address@hidden> writes:
> 
>> URL:
>>   <http://savannah.nongnu.org/bugs/?28805>
>>
>> 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.

Since changes to the bug go to the list now anyways, we can discuss it
right here as well. I mainly opened this and a couple of other bugs to
track stuff, i.e. remind myself and others fiddling around with this and
other things.

> 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.

Right, but changing the workspace requires more than just setting a new
working directory for the running process, the lua context f.e. would
have to be switched completly (remember we read and process custom
_MTN/monotonerc files!), so this use case will probably always require a
separate / new process.

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

Thomas Moschny proposed to cache the mtime of .mtn-ignore together with
its contents and re-read it when the mtime changes, which is a
reasonable implementation. We could probably do the same for
_MTN/options, though the workspace code which determines when some of
the options have to remain and when not (i.e. "sticky" branch option)
is, well, weird to say at least and probably a beast to refactor.

> 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?

Certainly not for a local setup (its still disgusting to work around
like this to fix bugs in mtn however), but remember we also serve stdio
remotely - whats the proposed fix there? Restart the server...? Probably
not :)

> 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.

This would mean that all the startup initialization would have to be
refactored in order to be callable when everything already happened -
ideally this "app state" (hey, we already have a name for it! :) would
be nestable, so every automate command would be executed in its own
state / environment. But on the other hand this sounds like hell-a-lot
of work for only little mid-term outcome. Fixing the option
initialization code to properly reset --key and other options seems to
be more straight forward to me, no?

>> 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.

I'm pretty sure read-permissions handles that already, so 'allow "*"'
should include anonymous users and everything else only includes the
known, given identities. Its an interesting question though if there is
the usecase for "*" also meaning "only users which I already know by
public key".

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature