Matthias Urlichs <[EMAIL PROTECTED]> writes: > Hi, > > Simon Josefsson: >> Further, I'm not sure I understand _why_ this is done. Perhaps if you >> describe why you want to execvpe and carry over the TLS-protected >> socket to the new process, we can suggest better solutions. >> > One application of this idea, not related to execve()ing yourself, is to > be able to pass the connection on to another process by way of a Unix > socket and sendmsg(). > > That'd allow you to use one applicationto accept a connection, estabish > SSL, and thn dispatch it to another, which helps with privilege > separation.
Right. > The connection already is established (as far as the other side is > concerned, anyway), the handshake has happened, so this call shouldn't > be there. Just resume sending/receiving. (Assuming that the data > structures are set up correctly, which they probably are not...) > > Fixing that shouldn't be *that* difficult, but I'd suggest writing a > completely different API for this, which just marshals the full internal > state of a connection into one area of memory / restores it from there. I agree. The resumption data API may be a starting pointer, that should include most of the required internal state. Patches to implement this are very welcome. I have added the following to the TODO list: - Make it possible to extract the internal state of a session, to be able to execve a new process that take over the current living socket (using the fcntl close-on-exec flag) and continue the TLS session as well. Thanks, Simon _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
