Summary: | app-editors/emacs-22.2 w/ USE=kerberos: support for app-crypt/heimdal | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Martin Mokrejš <mmokrejs> |
Component: | Current packages | Assignee: | Emacs project <emacs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | Hloupy.Honza, kerberos, Martin.vGagern |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://thread.gmane.org/gmane.emacs.devel/102095 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 185899 | ||
Attachments: |
emacs-22.2_ebuild-heimdal.diff
emacs-pop-heimdal.patch emacs-22.2-heimdal-1.x.patch (don't use!) emacs-22.2-heimdal-gentoo.patch Emacs ebuild with heimdal pach |
Description
Martin Mokrejš
2008-03-31 11:33:37 UTC
I have app-crypt/heimdal-0.7.2-r3 installed in FHS paths (no /usr/heimdal/ present). (In reply to comment #1) > I have app-crypt/heimdal-0.7.2-r3 installed in FHS paths > (no /usr/heimdal/ present). I can reproduce the failure (with heimdal). Emacs can be compiled o.k. with mit-krb5. Adding kerberos team to CC; please advise. I can confirm that the bug also occurs with the latest release heimdal-1.1 built with the ebuild from http://bugs.gentoo.org/show_bug.cgi?id=185899. Is it possible that we ran into some kind of incompatibility of mit-krb5 and heimdal-krb5? Despite that I really would suggest to use mit-krb5 if you're using ebuilds out of the portage tree. app-crypt/mit-krb5-1.6.3-r1 is maintained again in gentoo and has the latest security patches applied. Here is the definition of the krb5_error struct in mit-krb5 which seams compatible with emacs-22.2: typedef struct _krb5_error { krb5_magic magic; /* some of these may be meaningless in certain contexts */ krb5_timestamp ctime; /* client sec portion; optional */ krb5_int32 cusec; /* client usec portion; optional */ krb5_int32 susec; /* server usec portion */ krb5_timestamp stime; /* server sec portion */ krb5_ui_4 error; /* error code (protocol error #'s) */ krb5_principal client; /* client's principal identifier; optional */ krb5_principal server; /* server's principal identifier */ krb5_data text; /* descriptive text */ krb5_data e_data; /* additional error-describing data */ } krb5_error; and here is the heimdal code. You can see that the struct members are named differently: typedef struct KRB_ERROR { krb5int32 pvno; MESSAGE_TYPE msg_type; KerberosTime *ctime; krb5int32 *cusec; KerberosTime stime; krb5int32 susec; krb5int32 error_code; Realm *crealm; PrincipalName *cname; Realm realm; PrincipalName sname; heim_general_string *e_text; heim_octet_string *e_data; } KRB_ERROR; You can see the difference: krb5_data text; <-> heim_general_string *e_text; --- text <-> e_text Is it possible to patch pop.c that it supports both versions? I would say that's an issue for emacs upstream - isn't it? g, mueli One more comment on this topic. I've just looked into rfc4120 (2005) (didn't change from RFC1510 (1993) which is referred to in http://web.mit.edu/Kerberos/papers.html#k5-protocol) and found that heimdal is here the standard conform implementation: KRB-ERROR ::= [APPLICATION 30] SEQUENCE { pvno [0] INTEGER (5), msg-type [1] INTEGER (30), ctime [2] KerberosTime OPTIONAL, cusec [3] Microseconds OPTIONAL, stime [4] KerberosTime, susec [5] Microseconds, error-code [6] Int32, crealm [7] Realm OPTIONAL, cname [8] PrincipalName OPTIONAL, realm [9] Realm -- service realm --, sname [10] PrincipalName -- service name --, e-text [11] KerberosString OPTIONAL, e-data [12] OCTET STRING OPTIONAL } Just for information so that emacs@gentoo.org can argue in the right direction ;) g, mueli Thanks for your research, we will discuss it with Emacs upstream soon. For the time being, I've changed the dependency of emacs-22.2 to an explicit app-crypt/mit-krb5. Martin, would you like to report this upstream? Posted to bug-gnu-emacs [at] gnu.org archived at http://lists.gnu.org/archive/html/bug-gnu-emacs/2008-04/index.html Hope my message got though. But I am not subscribed to the list and am not certain I have the intent to do so. Somebody please watch it as well or reopen so we do not forget about this. Per comment #6, wouldn't it be better to mask 22.2 for heimdal users and allow it only for mit-krb5 users? No, I am not going to switch from heimdal to mit-krb5, I rather mask 22.2 then. Anyway I don't use any of its kerberos-related functions. ;-) (In reply to comment #7) > Posted to bug-gnu-emacs [at] gnu.org archived at > http://lists.gnu.org/archive/html/bug-gnu-emacs/2008-04/index.html > Hope my message got though. But I am not subscribed to the list and am not > certain I have the intent to do so. Somebody please watch it as well or reopen > so we do not forget about this. ulm and myself read the emacs-devel list, so we will watch it. You will be cced on the whole discussion, so you won't miss a bit. > Per comment #6, wouldn't it be better to mask 22.2 for heimdal users and allow > it only for mit-krb5 users? No, I am not going to switch from heimdal to > mit-krb5, I rather mask 22.2 then. Anyway I don't use any of its > kerberos-related functions. ;-) Use package.use: app-editors/emacs -kerberos People who want Kerberos functionality with Emacs must install MIT version at the moment. (In reply to comment #4) > One more comment on this topic. I've just looked into rfc4120 (2005) > (didn't change from RFC1510 (1993) which is referred to in > http://web.mit.edu/Kerberos/papers.html#k5-protocol) and found that heimdal > is here the standard conform implementation: But RFC 4120 specifies only the protocol. How internal data structures are implemented is outside its scope. This doesn't say anything about mit-krb5 being standard conform or not. Therefore, I think that we just have two implementations with different API here. Presently, Emacs supports only mit-krb5 but not heimdal. The question is also if we should eventually add virtual/kerberos as dependency again, or just "|| ( app-crypt/mit-krb5 app-crypt/heimdal )". In my understanding, a virtual for a shared library should be used iff you can unmerge one of its providers and merge another one, and the application is still functioning then. This is not the case here. (In reply to comment #9) > But RFC 4120 specifies only the protocol. How internal data structures are > implemented is outside its scope. This doesn't say anything about mit-krb5 > being standard conform or not. But in the case of a library that implements a protocol the API is the important thing for all applications using the library. Therefore the RFC is really exact in [5.9.1. KRB_ERROR definition] and shishi and heimdal are using both the naming convention presented for this ASN.1 structure there. [1] What else can be the reason for defining the ASN.1 structure in the RFC if not as suggestion how the structure should be implemented? > Therefore, I think that we just have two implementations with different API > here. Presently, Emacs supports only mit-krb5 but not heimdal. Of course we have to different APIs and it's not our job to decide which one is the right or better one. Never less both libraries implement the same protocol so they should be exchangeable which they aren't because of the different APIs. You shouldn't forget that the API is identical for a lot of structures but sadly not for all and in fact for a lot of cases heimdal and mit-krb5 are replaceable. > This is not the case here. This is not the case for emacs but for a lot of other applications depending on kerberos. [1] ... http://josefsson.org/shishi/manual/html_node/KRB_002dERROR-Functions.html#KRB_002dERROR-Functions T2 has had for some time a patch for heimdal at http://svn.exactcode.de/t2/branches/7.0/package/security/heimdal/emacs-pop.diff We haven't noticed the problem just because the emacs ebuild haven't had the kerberos USE flag until now. Looking at comment #3 I guess that the patched code might work even with mit-krb5. Depending on the actual content of the data fields, the problem might be just a wrong decision on part of the emacs developers. Created attachment 148081 [details, diff]
emacs-22.2_ebuild-heimdal.diff
Diff from the portage tree emacs-22.2.ebuild to my local overlay emacs-22.2.ebuild using heimdal for kerberos. Incorporates the patch from T2.
Created attachment 148083 [details, diff]
emacs-pop-heimdal.patch
The patch from T2.
Created attachment 148084 [details, diff]
emacs-22.2-heimdal-1.x.patch (don't use!)
My own attempt on the patch before I found the T2 version. Sticks to the field labeled (e_)text, is therefore more complicated and would not compile against mit-krb5. Might be useful if and only if the text and e_text fields actually held equivalent data, the e_data fields contained something completely different, and the T2 patch therefore did not work in practice. Hopefully good just to laugh at me and/or tease the emacs and mit-krb5 developers.
(In reply to comment #11) > Looking at comment #3 I guess that the patched code might work even with > mit-krb5. Depending on the actual content of the data fields, the problem might > be just a wrong decision on part of the emacs developers. That's a good explanation why a lot of apps work pretty well with the different implementations - perhaps they are all using e_data and not {e_}text! The T2 patch looks really promising expect the modification of configure.in. @ulm: Isn't it the job of autoconf to define the HAVE_KRB5_H and HAVE_LIBKRB5. I think you now more about the build system of emacs than me ;) g, mueli (In reply to comment #15) > The T2 patch looks really promising expect the modification of configure.in. But "text" is not the same field as "e_data"? It is used in pop.c to construct a human-readable error message. Does the e_data field even contain a printable string: krb5_data text; /* descriptive text */ krb5_data e_data; /* additional error-describing data */ > @ulm: Isn't it the job of autoconf to define the HAVE_KRB5_H and > HAVE_LIBKRB5. It is, and I've just verified that it works, depending on the --with-kerberos* options given to configure. The patch shouldn't touch config.in. (In reply to comment #16) > But "text" is not the same field as "e_data"? It is used in pop.c to construct > a human-readable error message. Does the e_data field even contain a printable > string: IMHO the problem is that there is no real specification. Cite from shishi: "The “KRB-ERROR” is an ASN.1 structure that can be returned, instead of, e.g., KDC-REP or AP-REP, to indicate various error conditions. Unfortunately, the semantics of several of the fields are ill specified, so the typically procedure is to extract “e-text” and/or “e-data” and show it to the user." So if emacs can't be sure of the content of {e_}text and/or e_data it should be ok for us to show e_data. In case of an error this info is sufficient to investigate the problem. If reading the RFC I would even say e_data is designed to be more exact than {e_}text. But as already mentioned - the spec is to less exact to argument here for multiple libraries. It is one thing how mit-krb5 is handling it - that doesn't mean that the other kerberos implementations do it the same way. > It is, and I've just verified that it works, depending on the --with-kerberos* > options given to configure. The patch shouldn't touch config.in. Perfect. So I would say we should patch pop.c to use e_data rather than {e_}text and report the procedure to emacs upstream. They should really think about enhancing the KRB_ERROR interpretation to make emacs independent from the kerberos implementation used. I can't see any core disadvantages - the worst thing that could happen is that the error we are reporting is less human readable. g, mueli Created attachment 148187 [details, diff]
emacs-22.2-heimdal-gentoo.patch
Alternatively, it is also trivial to use autoconf to test if krb5_error has the .text or .e_text members. This would be better backwards compatible.
Could you try if attached patch works? I've checked that it compiles, but I don't have a kerberos environment where I could really test its function.
Created attachment 148189 [details]
Emacs ebuild with heimdal pach
Have successfully compiled emacs depending on heimdal-1.1 with the attached ebuild.
g, mueli
p.S.: As I don't know exactly what the kerberos support in emacs is for ;) I can't test the functionality - @ulm: can you provide a test case?
(In reply to comment #19) > Have successfully compiled emacs depending on heimdal-1.1 with the > attached ebuild. Thanks. > p.S.: As I don't know exactly what the kerberos support in emacs is for ;) > I can't test the functionality - @ulm: can you provide a test case? It is exclusively used for the Emacs "movemail" program, i.e. for fetching e-mail from a POP server. You'll find a description here: <http://www.gnu.org/software/emacs/manual/html_node/emacs/Rmail.html> and there especially in sub-node "Movemail". I guess a test case would roughly proceed as follows: M-x set-rmail-inbox-list <RET> FILES <RET> where FILES would be PROTO://[USER[:PASSWORD]@]HOST-OR-FILE-NAME with PROTO=pop (or kpop?) in this case. Then new mail can be fetched with: M-x rmail <RET> But you'll need a POP server with Kerberos 5 for the test, which I haven't here. Both alternatives for a patch submitted upstream: <http://lists.gnu.org/archive/html/emacs-devel/2008-04/msg00232.html> Reopening for proper closing. 06 Apr 2008; Ulrich Mueller <ulm@gentoo.org> +files/emacs-22.2-heimdal-gentoo.patch, emacs-22.2.ebuild: Add patch to support compilation with Heimdal, and change dependency back to virtual/krb5; fixes bug 215558. Thanks to Michael Hammer (mueli) <michael@derhammer.net>, Honza Macháček <Hloupy.Honza@centrum.cz> and Martin Mokrejš <mmokrejs@ribosome.natur.cuni.cz> for their help. Patches accepted upstream: <http://cvs.savannah.gnu.org/viewvc/emacs/configure.in?root=emacs&r1=1.553&r2=1.554> <http://cvs.savannah.gnu.org/viewvc/emacs/lib-src/pop.c?root=emacs&r1=1.51&r2=1.52> This will be fixed in upstream Emacs versions 22.3 and 23.1. Nice! Thx for fixing the issue - heimdal is getting continuously nearer a stable state. g, mueli |