[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:
http://www.emacswiki.org/cgi-bin/wiki/EricMarsden
http://www.emacswiki.org/cgi-bin/wiki/InternetPrintingProtocol
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.
Ken
- Re: Post-22.1 development?, (continued)
- Re: Post-22.1 development?, Tom Tromey, 2007/06/07
- Re: Post-22.1 development?, David House, 2007/06/07
- Re: Post-22.1 development?, Tom Tromey, 2007/06/07
- Re: Post-22.1 development?, Jan Djärv, 2007/06/08
- IPP under emacs [was: Re: Post-22.1 development?], Thien-Thi Nguyen, 2007/06/08
- Re: IPP under emacs [was: Re: Post-22.1 development?], Vinicius Jose Latorre, 2007/06/08
- Re: IPP under emacs [was: Re: Post-22.1 development?],
Ken Raeburn <=
- Re: IPP under emacs [was: Re: Post-22.1 development?], Jason Rumney, 2007/06/08
- Re: IPP under emacs [was: Re: Post-22.1 development?], Ken Raeburn, 2007/06/08
- Re: IPP under emacs [was: Re: Post-22.1 development?], Jason Rumney, 2007/06/08
- Re: IPP under emacs [was: Re: Post-22.1 development?], Ken Raeburn, 2007/06/08
- Re: IPP under emacs [was: Re: Post-22.1 development?], Jason Rumney, 2007/06/08
- Re: IPP under emacs [was: Re: Post-22.1 development?], Ken Raeburn, 2007/06/08
- Re: IPP under emacs [was: Re: Post-22.1 development?], Richard Stallman, 2007/06/09
- Re: IPP under emacs [was: Re: Post-22.1 development?], Vinicius Jose Latorre, 2007/06/09
- Re: IPP under emacs [was: Re: Post-22.1 development?], Jan Djärv, 2007/06/10
- Re: IPP under emacs [was: Re: Post-22.1 development?], Richard Stallman, 2007/06/10