[Monotone-devel] [bug #28805] Global --key option (and possibly others) are not reset between stdio commands
Update of bug #28805 (project monotone): Status:None = Fixed Open/Closed:Open = In Test ___ Follow-up Comment #3: --anonymous added for pull and clone... I doubt that it's meaningful or makes sense for sync. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?28805 ___ Meddelandet skickades via/av Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #28805] Global --key option (and possibly others) are not reset between stdio commands
Update of bug #28805 (project monotone): Assigned to:None = rlevitte ___ Reply to this item at: http://savannah.nongnu.org/bugs/?28805 ___ Meddelandet skickades via/av Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #28805] Global --key option (and possibly others) are not reset between stdio commands
Follow-up Comment #1, bug #28805 (project monotone): Just a though, would it be enough if --anonymous was added? ___ Reply to this item at: http://savannah.nongnu.org/bugs/?28805 ___ Meddelandet skickades via/av Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [bug #28805] Global --key option (and possibly others) are not reset between stdio commands
Am 04.02.10 01:49, schrieb Stephen Leake: Thomas Keller invalid.nore...@gnu.org 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 | tommyd3...@jabber.ccc.de | 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #28805] Global --key option (and possibly others) are not reset between stdio commands
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. Additionally, an --anonymous option could be added to all netsync commands which explicitely circumvents key authentication. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?28805 ___ Nachricht geschickt von/durch Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [bug #28805] Global --key option (and possibly others) are not reset between stdio commands
Thomas Keller invalid.nore...@gnu.org 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
