Re: [Monotone-devel] --non-interactive: run in non-interactive
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen Leake schrieb: Thomas Keller [EMAIL PROTECTED] writes: So, while its perfectly possible to do some rcfile tickery like William wrote in an earlier email, I think it would be better if we would include some kind of native support for asking for a key passphrase over stdio and/or even have some explicit need_key_password (which returns a boolean) and set_key_password (which could be used if a user has no get_passphrase / ssh-agent setup whatsoever) automation commands. I know this probably might not be very secure, but it would be damn convenient for automate developers like me... [...] I don't see what the security issue is. Unless the connection between the front-end and the back-end is over an unencrypted network? Well, I thought more about the implementation in an automate client which ideally should store the password somewhere securely to not have to prompt the user over and over again. But then there surely might exist a neat possibility to use native keychaining on some platforms (kde wallet on Linux, keychain on osx, and maybe there is even something available on Windows). And maybe the prompting is not that huge problem if the stdio process in the background keeps running for all tasks. Thomas. - -- GPG-Key 0x160D1092 | [EMAIL PROTECTED] | 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHot7vaf7NlBYNEJIRAqh7AJ9cclNJz/1Q79ZWSRIq9FI1gGIR0QCeOsMy +O5PfUGngdrTWYp1l/YLYhA= =41dF -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] --non-interactive: run in non-interactive
2008/1/31, William Uther [EMAIL PROTECTED]: Why not just make sure the user has a lua hook with a passphrase in it. Perhaps something like this (untested): cat newhook.lua EOF function get_passphrase_bogus(keypair_id) return this is probably not the passphrase end if (get_passphrase == nil) then get_passphrase = get_passphrase_bogus end EOF Because mtn treats password from lua hook as weak. If it's nil, empty or wrong then monotone asks for correct password on tty. We could fix this, it's one thing, but it's only specific behaviour of one hook. My reasoning is it would be good to have contract between user and monotone which clearly says don't touch stdin/tty and don't ask questions because for example you are part of some automation interface.. On the other hand i don't know how current code can enforce this contract esp in lua hooks. I'll look at that ... ... The other option would be to encourage people to use ssh-agent. Perhaps automating that process for them would help: Export their keys in the right form, check if the SSH_AUTH_SOCK environment variable is set, and if it is then see if the key is loaded and if not, load it in for the user (prompting for the password yourself). I don't know how it works currently for default but when i'm on unix box and have ssh-agent env setup (aka connected via ssh) mtn always automatically adds my key to agent so I enter password only once in such agent life. However on windows i don't see this behaviour. I always have pageant running and key can be added only by explicit command. -- Zbigniew -zbigg- Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] --non-interactive: run in non-interactive
Zbigniew Zagórski schrieb: PS. I know that commit from automate would be the best way but we can't wait for it (sadly, it's too big task for me to do it now ). mtteam is in almost usable state and the only blocking issue is commit. We'll gladly switch to 'automate commit' when it will be done. PS2. I'm sure guitone also looks for solution to commit from GUI problem. Actually guitone can commit from the GUI, just it has no support for entering a passphrase. I'm using automate put_revision, automate put_file and automate cert to emulate the behaviour of commit and it works quite fine. Two things with respect to that: 1) It's possible to enter a passphrase even in stdio if mtn asks for it. The prompt is displayed twice, but after the phrase has been entered the operation succeeds. I think I'll add some support for that in the next guitone release (just haven't cared until now) - the thing is just that the key prompt is localized and therefor not nice to parse. 2) If the password has been given once, mtn won't ask for it again on subsequent actions which require a key password until stdio is killed. So, while its perfectly possible to do some rcfile tickery like William wrote in an earlier email, I think it would be better if we would include some kind of native support for asking for a key passphrase over stdio and/or even have some explicit need_key_password (which returns a boolean) and set_key_password (which could be used if a user has no get_passphrase / ssh-agent setup whatsoever) automation commands. I know this probably might not be very secure, but it would be damn convenient for automate developers like me... On a related note, if you think of doing commits over automate like I currently do, what is really _lacking_ in automate is a way to let mtn return a valid restricted revision for a given set of paths (i.e. I currently just feed put_revision with the complete output of get_revision). One could of course do the node restriction logic in the client (f.e. for renames), but this is very ugly. Thomas. -- GPG-Key 0x160D1092 | [EMAIL PROTECTED] | 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
Re: [Monotone-devel] --non-interactive: run in non-interactive
2008/1/31, Zack Weinberg [EMAIL PROTECTED]: 2008/1/30 Zbigniew Zagórski [EMAIL PROTECTED]: ... In current state this option will affect password prompt only, but it can be used in future commands to check if user wants to make decisions. I approve of the concept in general; however ... Good. After five minutes it appeared that almost all functions from keys.hh must accept app_state instead of lua_hooks only: I have to veto anything that does anything like that, because we're in the process of removing the app_state structure altogether. I'm in I was not aware of this fact :/ That's a pity. the middle of rototilling keys.cc and key_store.cc right now and I can't guarantee what they will look like when I'm done, but - I expect that the right thing for you to do is save the option in the key_store object when that object is constructed, if that makes sense? I'll look at this and in general i'll look at those changes. I understand that you're speaking about experiment.encapsulation branch. Also, I wonder if a --passphrase-fd=NUMBER option would make sense for your work. This idea comes from GPG - if the option is given, monotone would read any passphrase it needs from that file descriptor rather than the terminal. You'd make the file descriptor a pipe, and if monotone tries to read from it, pop up a password-prompt dialog box. (I don't actually know how to code that on your end but I'm sure it's possible.) Well it's a great idea, i though about that. However ... I'm almost sure that we don't want to touch file handles inheritance/passing between process on win32. Simply I don't know how to do that (I know only about inheritance). (+1 for simple and clear POSIX/unix architecture) Second. For example java library gives you possibility to control only stdin/stdout/stderr inputs of subprocess. And we want/need some java interfaces to monotone. -- Zbigniew -zbigg- Zagórski / software developer / geek / happy daddy / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] --non-interactive: run in non-interactive
On Wednesday 30 January 2008, Zbigniew Zagórski wrote: Safe means that I'm sure that monotone will not ask anything from stdin/tty user but fail miserably with some error message. Thus it's guarantee that it will never hang up. Couldn't we simply teach monotone to only ask the user for a password (or whatever) if it is running in a terminal? - Thomas signature.asc Description: This is a digitally signed message part. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] --non-interactive: run in non-interactive
Thomas Keller [EMAIL PROTECTED] writes: So, while its perfectly possible to do some rcfile tickery like William wrote in an earlier email, I think it would be better if we would include some kind of native support for asking for a key passphrase over stdio and/or even have some explicit need_key_password (which returns a boolean) and set_key_password (which could be used if a user has no get_passphrase / ssh-agent setup whatsoever) automation commands. I know this probably might not be very secure, but it would be damn convenient for automate developers like me... I agree this would be a good thing. When using monotone via automate, monotone is a back-end, and the front-end should assume all responsibility for prompting. I don't see what the security issue is. Unless the connection between the front-end and the back-end is over an unencrypted network? -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] --non-interactive: run in non-interactive
Hello,
I'm hacking silently at mtteam again I hit the wall of safe commit.
Safe means that I'm sure that monotone will not ask anything from
stdin/tty user but fail miserably with some error message. Thus it's
guarantee that it will never hang up.
The only two places that monotone interacts with user are:
- commit
- cert, approve, testresult
- merge*
- genkey (doesn't count, because it has automate counterpart)
From my point of view interesting commands are commit and cert*
derivatives. They can ask for password. GUI doesn't like it.
So i invented --never-prompt-password, and started to hack ;). Later
on I've decided that --non-interactive global option will be better.
When you'll specify this option to mtn it will never ask for a
password. If the password is needed (no lua hook, no key in ssh-agent)
it will clearly fail with some informative message.
In current state this option will affect password prompt only, but it
can be used in future commands to check if user wants to make decisions.
back to the patch ...
After five minutes it appeared that almost all functions from keys.hh
must accept app_state instead of lua_hooks only:
-get_private_key(lua_hooks lua, ...
+get_private_key(app_state app, ...
...
-get_passphrase(lua_hooks lua, ...
+get_passphrase(app_state app, ...
...
-void encrypt_rsa(lua_hooks lua,
+void encrypt_rsa(app_state app,
...
-void decrypt_rsa(lua_hooks lua,
+void decrypt_rsa(app_state app,
...
and so on. Is it ok for you ?
Core of patch consist of
1. adding --non-interactive run in non-interactive mode (never ask
questions)
2. modification of get_passphrase(keys.cc):
@@ -75,7 +75,7 @@ void
// 'force_from_user' means that we don't use the passphrase cache,
// don't use the get_passphrase hook.
void
-get_passphrase(lua_hooks lua,
+get_passphrase(app_state app,
rsa_keypair_id const keyid,
utf8 phrase,
bool confirm_phrase,
...
string lua_phrase;
- if (!force_from_user lua.hook_get_passphrase(keyid, lua_phrase))
+ if (!force_from_user app.lua.hook_get_passphrase(keyid,
+ lua_phrase))
{
phrase = utf8(lua_phrase);
N(phrase != utf8(),
F(got empty passphrase from get_passphrase() hook));
}
+ else if( app.opts.non_interactive )
+{
+ F(reading passphrase from terminal forbidden by explicit
+option);
+}
else
{
char pass1[constants::maxpasswd];
Do you like this idea ? I'll send finished patch for review.
PS. I know that commit from automate would be the best way but we
can't wait for it (sadly, it's too big task for me to do it now ).
mtteam is in almost usable state and the only blocking issue is
commit. We'll gladly switch to 'automate commit' when it will be done.
PS2. I'm sure guitone also looks for solution to commit from GUI
problem.
Best regards,
--
Zbigniew Zagórski
/ software developer / geek / happy daddy /
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] --non-interactive: run in non-interactive
On 31/01/2008, at 9:58 AM, Zbigniew Zagórski wrote:
I'm hacking silently at mtteam again I hit the wall of safe commit.
Safe means that I'm sure that monotone will not ask anything from
stdin/tty user but fail miserably with some error message. Thus it's
guarantee that it will never hang up.
That makes perfect sense.
string lua_phrase;
- if (!force_from_user lua.hook_get_passphrase(keyid, lua_phrase))
+ if (!force_from_user app.lua.hook_get_passphrase(keyid,
+ lua_phrase))
{
phrase = utf8(lua_phrase);
N(phrase != utf8(),
F(got empty passphrase from get_passphrase() hook));
}
+ else if( app.opts.non_interactive )
+{
+ F(reading passphrase from terminal forbidden by explicit
+option);
+}
else
{
char pass1[constants::maxpasswd];
Why not just make sure the user has a lua hook with a passphrase in
it. Perhaps
something like this (untested):
cat newhook.lua EOF
function get_passphrase_bogus(keypair_id)
return this is probably not the passphrase
end
if (get_passphrase == nil) then
get_passphrase = get_passphrase_bogus
end
EOF
You could then add this with the --rcfile option and you'd be set.
PS. I know that commit from automate would be the best way but we
can't wait for it (sadly, it's too big task for me to do it now ).
mtteam is in almost usable state and the only blocking issue is
commit. We'll gladly switch to 'automate commit' when it will be done.
Yes - that would be a nice automate command. I'm not sure it would
really
change much here though. You'd still need a way of getting the
passphrase
for the key.
The other option would be to encourage people to use ssh-agent.
Perhaps automating
that process for them would help: Export their keys in the right form,
check if the SSH_AUTH_SOCK
environment variable is set, and if it is then see if the key is
loaded and if not, load it in for the user (prompting for the password
yourself).
Cheers,
Will :-}
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] --non-interactive: run in non-interactive
2008/1/30 Zbigniew Zagórski [EMAIL PROTECTED]: So i invented --never-prompt-password, and started to hack ;). Later on I've decided that --non-interactive global option will be better. When you'll specify this option to mtn it will never ask for a password. If the password is needed (no lua hook, no key in ssh-agent) it will clearly fail with some informative message. In current state this option will affect password prompt only, but it can be used in future commands to check if user wants to make decisions. I approve of the concept in general; however ... After five minutes it appeared that almost all functions from keys.hh must accept app_state instead of lua_hooks only: I have to veto anything that does anything like that, because we're in the process of removing the app_state structure altogether. I'm in the middle of rototilling keys.cc and key_store.cc right now and I can't guarantee what they will look like when I'm done, but - I expect that the right thing for you to do is save the option in the key_store object when that object is constructed, if that makes sense? Also, I wonder if a --passphrase-fd=NUMBER option would make sense for your work. This idea comes from GPG - if the option is given, monotone would read any passphrase it needs from that file descriptor rather than the terminal. You'd make the file descriptor a pipe, and if monotone tries to read from it, pop up a password-prompt dialog box. (I don't actually know how to code that on your end but I'm sure it's possible.) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
