[Top][All Lists]
[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: |
Timothy Brownawell |
Subject: |
Re: Key decryption for automate stdio usage Was: Re: [Monotone-devel] review of nvm.automate_out_of_band |
Date: |
Sat, 28 Nov 2009 13:49:23 -0600 |
User-agent: |
Mozilla-Thunderbird 2.0.0.22 (X11/20091109) |
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".
- [Monotone-devel] review of nvm.automate_out_of_band, Thomas Keller, 2009/11/17
- Re: [Monotone-devel] review of nvm.automate_out_of_band, Timothy Brownawell, 2009/11/21
- Re: [Monotone-devel] review of nvm.automate_out_of_band, Thomas Keller, 2009/11/22
- Key decryption for automate stdio usage Was: Re: [Monotone-devel] review of nvm.automate_out_of_band, Thomas Keller, 2009/11/26
- Re: Key decryption for automate stdio usage Was: Re: [Monotone-devel] review of nvm.automate_out_of_band,
Timothy Brownawell <=
- Re: Key decryption for automate stdio usage Was: Re: [Monotone-devel] review of nvm.automate_out_of_band, Thomas Keller, 2009/11/28
- Re: Key decryption for automate stdio usage Was: Re: [Monotone-devel] review of nvm.automate_out_of_band, Timothy Brownawell, 2009/11/28
- Re: Key decryption for automate stdio usage Was: Re: [Monotone-devel] review of nvm.automate_out_of_band, Thomas Keller, 2009/11/28
- Re: Key decryption for automate stdio usage Was: Re: [Monotone-devel] review of nvm.automate_out_of_band, Stephen Leake, 2009/11/29
- Re: [Monotone-devel] review of nvm.automate_out_of_band, Thomas Keller, 2009/11/26
- Re: [Monotone-devel] review of nvm.automate_out_of_band, Stephen Leake, 2009/11/27
- Re: [Monotone-devel] review of nvm.automate_out_of_band, Timothy Brownawell, 2009/11/27
- Re: [Monotone-devel] review of nvm.automate_out_of_band, Thomas Keller, 2009/11/27
- Re: [Monotone-devel] review of nvm.automate_out_of_band, Timothy Brownawell, 2009/11/28
- Re: [Monotone-devel] review of nvm.automate_out_of_band, Thomas Keller, 2009/11/28