Key decryption for automate stdio usage Was: Re: [Monotone-devel] review of nvm.automate_out_of_band

[Thomas Keller]

Am 22.11.09 20:26, schrieb Thomas Keller:
> Am 22.11.09 01:09, schrieb Timothy Brownawell:
>>> My next task is to bring nvm.automate-netsync to life again, where the
>>> ticker stuff was one of the missings pieces which needed to be done
>>> beforehand. I'm still open for discussions / brainstorming in this area
>>> and also f.e. automate cert, how we can gracefully handle
>>> password-encrypted private keys without trying to prompt, which would be
>>> particularily bad over stdio.
>>
>> Especially remote_stdio, since our network connections aren't encrypted.
> 
> Ah, I haven't thought of that, good catch. We don't really want to allow
> the decryption of a private key from a remote connection anyways, I guess.
> 
>> I guess one possibility for local stdio would be to allow the password
>> to be given in an --option, and return a particular error if it's
>> invalid or needed and not given.
> 
> As an --option on stdio startup or for a particular command? How would
> we prevent that this option is in the latter case then given for a
> command which is run remotely?
> 
> 
>> For remote_stdio... I guess have a special check to blacklist that
>> option until we get encrypted transport, possibly unless some
>> --i-dont-care-about-security option is given at startup time? I guess
>> another possibility would be a command that actually generates the cert
>> on the client, and then looks like read_packets over the wire (so, it'd
>> still have to be a special case in the remote_stdio loop :-/ ).
> 
> I think my task is two-step: Firstly prevent that the password prompt
> happens at all over stdio and breaks the whole process and secondly give
> stdio some easy way to specify passwords for key decryption. If encoding
> the password into stdio is not an option security-wise, we might already
> have everything in place for that then - just give the command an
> additional --rcfile with a get_password() lua hook.

Hrm... it was late that day (it is again, actually), but when I re-read
what I wrote here I felt I should say a few more words about this option.

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.

I can't however imagine how this would help my authorization use case.
For sure, I could create a cert locally and transport it via remote
read_packet to the server, but it would be easier to just "automate cert
&& automate push" it there.

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.

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