[IPython-dev] "Unsigned Message" error in a forking kernel manager

[MinRK]

On Tue, May 29, 2012 at 4:36 PM, Jason Grout <jason-sage at creativetrax.com>wrote:

> On 5/29/12 6:04 PM, Jason Grout wrote:
> > On 5/29/12 3:36 PM, Fernando Perez wrote:
> >> Hi Jason,
> >>
> >> On Tue, May 29, 2012 at 1:08 PM, Jason Grout
> >> <jason-sage at creativetrax.com>   wrote:
> >>> Is there a key or something that I should be
> >>> doing to "sign" my messages?  If someone could give this a quick
> >>> look-over and see if there are any obvious problems, that would be
> great.
> >>
> >> Yes, kernels sign their messages, to make it harder for other
> >> processes in the same machine to send them arbitrary commands
> >> (remember, our protocol is openly explained, so without this any
> >> ipython process would basically be a user shell listening on a  port
> >> for the first clown to say 'rm -rf $HOME').  See the code in
> >> zmq/session.py around line 423 for the signing, and the key is a
> >> member of the Session class which you can change/reassign (which will
> >> trigger a recomputation of the auth field used to sign the messages,
> >> see line 298).
> >
> > Thanks.  I remember being a part of the original authentication
> > conversation last year (we implemented the same thing for the sage cell
> > server).  The question is: how do I get the key the kernel expects
> > messages to be signed with?  Should I be initializing the kernel with
> > that?  If so, how should I initialize a kernel to use a specific key for
> > its sessions?  It seems that the initializing code is in the KernelApp
> > class in kernelapp.py.  If I understand traits correctly, the various
> > *_port traits can be initialized by passing in keyword arguments into
> > the constructor, and that is how the ports are being correctly
> > initialized in my gist.  However, the key for the session seems to be
> > only initialized if I read a connection file (in load_connection_file).
> >    So a more specific question is: can I initialize a session key using
> > embed_kernel using just the arguments to embed_kernel?  Or equivalently,
> > using just initialization arguments to KernelApp, can I set the kernel's
> > session key?
>
> Just a follow-up: changing the first few lines of embed_kernel to:
>
>     if IPKernelApp.initialized():
>         app = IPKernelApp.instance()
>     else:
>         app = IPKernelApp.instance(**kwargs)
>         if key:
>             app.config.Session.key=key
>         app.initialize([])
>
>
> and adding a `key` keyword argument to embed_kernel seems to work.
> Should I submit a pull request, or is there a better way to do this?
>

That should be unnecessary, because you can just pass a config object:

cfg = Config()
cfg.Session.key = foo

embed_kernel(config=cfg)

There should be nothing at all that you cannot specify with the current
call as it is.

But that's all beside the point, because the normal way to communicate
connections to the kernel is through a *file* (App.connection_file
configurable).  I know it may seem odd to use files when you are using
fork, but this will still be required if you want to start other frontends
against that kernel.

Here is a fork of your script that only passes the connection file, and
lets the existing machinery do the work: https://gist.github.com/2831998

The main change that had to happen was specifying KM.session.key *before*
launching the kernel, since it's used when writing the connection file.


I would also note that I think the entry point should probably *not* be
embed_kernel, rather a variation of the standard
ipkernel.launch_new_instance entry point, which doesn't skip all of the
normal namespace initialization like embed_kernel does, for the sake of
embedding.

-MinRK


> Thanks,
>
> Jason
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20120529/a01db593/attachment.html>