[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPP under emacs [was: Re: Post-22.1 development?]

From: Ken Raeburn
Subject: Re: IPP under emacs [was: Re: Post-22.1 development?]
Date: Fri, 8 Jun 2007 14:37:55 -0400

On Jun 8, 2007, at 10:25, Vinicius Jose Latorre wrote:
Some time ago, Eric Marsden created the ipp.el package, see the links:


Skimming the code (via the "permanent" link on the former page, not the latter, which seems to be out of date), it looks like at least some of the security aspects of the protocol have been omitted. As opposed to some other protocols Emacs implements, where you can use it directly without any security, or you can use a helper program in a subprocess.

(putting my Network Security Geek hat on...)

I think it would be helpful for Emacs to grow some more network- protocol building blocks in this area. Exactly what functionality would be needed and what the APIs should look like, I don't know off the top of my head, but it seems that Emacs has to call out to helper programs currently for protocols using Kerberos, GSSAPI, SASL, and TLS/SSL at least. Making primitives for some of these available in Emacs (perhaps via helper programs, at least initially) would make it possible for Emacs to more directly implement application protocols like IMAP, IPP, and SMTP even with security features enabled, instead of adding helper programs for every application protocol that can negotiate security.

Like I said, I'm not sure what the APIs should look like in general. From my own work, I'm pretty sure that GSSAPI primitives would be easy to implement with a helper program; the GSSAPI itself mostly operates by doing work on data blocks, leaving the caller to manage the low-level wire encoding and transmission as specified by the application protocol; that would fit in with the helper subprocess approach pretty easily. I seem to recall seeing some work on TLS for Emacs done too, but I don't recall how general it was.

An obvious drawback to moving the support into Emacs itself is that we probably don't want to require that people have Kerberos/GSSAPI/ SASL/TLS/whatever installed in order to install a pre-packaged Emacs, nor do we want to inflate the number of Emacs packages that get put together by exploding the power set of options. There are other approaches, though: dlopen on the libraries in question, helper programs in separate packages, Emacs extensions in C loadable at run time, etc.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]