Re: [Monotone-devel] Monotone 0.40 and SSH-Agent: broken?

[Justin Patrin]

On Sun, Apr 13, 2008 at 10:43 AM, Justin Patrin <address@hidden> wrote:
> On Sun, Apr 13, 2008 at 6:30 AM, Ralf S. Engelschall
>  <address@hidden> wrote:
>  > On Sun, Apr 13, 2008, Ralf S. Engelschall wrote:
>  >
>  >  > On Sun, Apr 13, 2008, Richard Levitte wrote:
>  >  >
>  >  > > In message <address@hidden> on Sun, 13 Apr 2008 10:11:07 +0200, "Ralf 
> S. Engelschall" <address@hidden> said:
>  >  > >
>  >  > > rse+monotone-devel> Please apply my posted patch and run the
>  >  > > rse+monotone-devel> "ssh_agent" test. Does it fail or succeed for you?
>  >  > >
>  >  > > Just did on my Linux laptop, and it fails.
>  >  > >
>  >  > > Ralf, please commit the changed ssh_agent test so it gets out there.
>  >  > > That's the best way to activate people ;-)
>  >  >
>  >  > I've now committed two more checks which show the problem.
>  >  > Now remains just the task to still fix this nasty new problem... ;-)
>  >
>  >  I'm currently digging and according to "mtn --debug" outputs it looks
>  >  like Monotone on "commit" doesn't contact the SSH-agent initially at
>  >  all. My first impression was that perhaps the communication protocol
>  >  itself got broken. But this doesn't seem to be the problem. Monotone
>  >  just starts fiddling with the SSH-agent once one has entered the
>  >  pass-phrase (and this way very late). So, for me it looks like in
>  >  Monotone 0.40 we have any change with now prevents the SSH-agent from
>  >  being correctly consulted on "commit" at all...
>  >
>
>  I *thought* I'd taken this into account in the tests but it appears I
>  hadn't. This is why I was so confused. Thanks for catching this. It
>  looks like someone added a call to decrypt_private_key earlier in the
>  chain as make_signature isn't called by the time the password is asked
>  for. :-/ I'm looking around.
>

The offender, at least for the first instance of asking for the
password the first time, is revision
43df0ce4206510d364c401d4dd17db17b9a389b7 which added a cache_user_key
method and added calls to it in cmd_ws_commit.cc in several places.

cache_decrypted_key also seems to be doing this before make_signature
gets called. At this point I'm not sure exactly what these things were
added for or what the best way to deal with ssh-agent signing is now.
I could add a check to see if the key is loaded into ssh-agent in
these 2 functions and skip their normal code-path but I suspect that
this would break any operations that do anything but signing (such as
running a netsync server).


-- 
Justin Patrin