From 81d2608c4c4e0d9b22121d98311dd80fad8ed131 Mon Sep 17 00:00:00 2001 From: Thomas Kluyver Date: Fri, 8 Jul 2011 21:51:33 +0100 Subject: [PATCH] Update info in parallel docs. --- docs/source/parallel/parallel_mpi.txt | 5 -- docs/source/parallel/parallel_security.txt | 69 ---------------------- 2 files changed, 74 deletions(-) diff --git a/docs/source/parallel/parallel_mpi.txt b/docs/source/parallel/parallel_mpi.txt index a135171182c..3f6733c29a1 100644 --- a/docs/source/parallel/parallel_mpi.txt +++ b/docs/source/parallel/parallel_mpi.txt @@ -4,11 +4,6 @@ Using MPI with IPython ======================= -.. note:: - - Not adapted to zmq yet - This is out of date wrt ipcluster in general as well - Often, a parallel algorithm will require moving data between the engines. One way of accomplishing this is by doing a pull and then a push using the multiengine client. However, this will be slow as all the data has to go diff --git a/docs/source/parallel/parallel_security.txt b/docs/source/parallel/parallel_security.txt index ea8b773b59f..7b96a936c65 100644 --- a/docs/source/parallel/parallel_security.txt +++ b/docs/source/parallel/parallel_security.txt @@ -248,75 +248,6 @@ capabilities based authentication model, in conjunction with SSH tunneled TCP/IP channels, address the core potential vulnerabilities in the system, while still enabling user's to use the system in open networks. -Other questions -=============== - -.. note:: - - this does not apply to ZMQ, but I am sure there will be questions. - -About keys ----------- - -Can you clarify the roles of the certificate and its keys versus the FURL, -which is also called a key? - -The certificate created by IPython processes is a standard public key x509 -certificate, that is used by the SSL handshake protocol to setup encrypted -channel between the controller and the IPython engine or client. This public -and private key associated with this certificate are used only by the SSL -handshake protocol in setting up this encrypted channel. - -The FURL serves a completely different and independent purpose from the -key pair associated with the certificate. When we refer to a FURL as a -key, we are using the word "key" in the capabilities based security model -sense. This has nothing to do with "key" in the public/private key sense used -in the SSL protocol. - -With that said the FURL is used as an cryptographic key, to grant -IPython engines and clients access to particular capabilities that the -controller offers. - -Self signed certificates ------------------------- - -Is the controller creating a self-signed certificate? Is this created for per -instance/session, one-time-setup or each-time the controller is started? - -The Foolscap network protocol, which handles the SSL protocol details, creates -a self-signed x509 certificate using OpenSSL for each IPython process. The -lifetime of the certificate is handled differently for the IPython controller -and the engines/client. - -For the IPython engines and client, the certificate is only held in memory for -the lifetime of its process. It is never written to disk. - -For the controller, the certificate can be created anew each time the -controller starts or it can be created once and reused each time the -controller starts. If at any point, the certificate is deleted, a new one is -created the next time the controller starts. - -SSL private key ---------------- - -How the private key (associated with the certificate) is distributed? - -In the usual implementation of the SSL protocol, the private key is never -distributed. We follow this standard always. - -SSL versus Foolscap authentication ----------------------------------- - -Many SSL connections only perform one sided authentication (the server to the -client). How is the client authentication in IPython's system related to SSL -authentication? - -We perform a two way SSL handshake in which both parties request and verify -the certificate of their peer. This mutual authentication is handled by the -SSL handshake and is separate and independent from the additional -authentication steps that the CLIENT and SERVER perform after an encrypted -channel is established. - .. [RFC5246] .. [OpenSSH]