monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Key decryption for automate stdio usage Was: Re: [Monotone-devel] re


From: Thomas Keller
Subject: Re: Key decryption for automate stdio usage Was: Re: [Monotone-devel] review of nvm.automate_out_of_band
Date: Sat, 28 Nov 2009 21:48:06 +0100
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1.5) Gecko/20091121 Lightning/1.0b1pre Thunderbird/3.0

Am 28.11.09 20:49, schrieb Timothy Brownawell:
> Thomas Keller wrote:
>> Your idea of introducing an automate read_packets wouldn't actually be
>> so hard to do, we already have f.e. automate put_file which takes its
>> data as argument, rather than from stdin and the usefulness for these
>> commands is stdio-only anyways already.
> 
> We actually already have automate read_packets.

Right, I missed that. automate is getting large :)

>> I came across the following use cases for stdio netsync operations:
>>
>> 1) local stdio, push/pull/sync with some remote node
>>    -> we talk via netsync with the remote node, so we need to
>>       authorize ourselves with a key.
>> 2) remote stdio, push/pull/sync with local node
>>    -> not possible with netsync as of now, because there is no code
>>       path which would allow us to push a client connection from
>>       the server. Probably also not very useful, since the user
>>       could also simply open a local stdio connection and run "pull"
>>       instead of a remote stdio connection to run "push".
>> 3) remote stdio, push/pull/sync with another remote node
>>    -> again we need to authorize ourselves with a key, but this time
>>       with a private key which exists on the remote side. Hairy...
>>       and probably also not a use case, because server-to-server
>>       synchronization would most likely happen via external hooks
>>       or cron jobs, but not via stdio.
>>
>> So this leaves me with 1) as my main use case and in this case a local
>> solution via the existing --rcfile option might already be enough.
> 
> I think that would have to be given at startup, so you somewhat lose the
> possibility of "oops, sorry, try again".

I'd have to test this out, but I'm sure you can give --rcfile to every
command invocation and since this particularily extends the functional
namespace of lua the more recent functions there should overwrite "old"
versions, i.e.

function get_passphrase()
        return "foo"
end

function get_passphrase()
        return "bar"
end

io.write(get_passphrase())

should print "bar" to stdout, so it shouldn't be a problem.

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]