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

[Timothy Brownawell]

Thomas Keller wrote:
> Am 22.11.09 20:26, schrieb Thomas Keller:
>> Am 22.11.09 01:09, schrieb Timothy Brownawell:

>>> 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.

We actually already have automate read_packets.

> 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.

Yeah, I guess it probably would be. Unless you're trying to do something
silly like run without a local database, but we probably don't care to
support that right now.

> 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".