[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: |
Thomas Keller |
Subject: |
Re: [Monotone-devel] [bug #28805] Global --key option (and possibly others) are not reset between stdio commands |
Date: |
Thu, 04 Feb 2010 20:48:02 +0100 |
User-agent: |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b2pre Thunderbird/3.0.1 |
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