Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 215558

Summary: app-editors/emacs-22.2 w/ USE=kerberos: support for app-crypt/heimdal
Product: Gentoo Linux Reporter: Martin Mokrejš <mmokrejs>
Component: Current packagesAssignee: 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 used to have installed 22.1-r3 and before app-editors/emacs-21.4-r14. Now I cannot emerge the emacs-22.2:

 * Configuring to build with GTK+ support
 * econf: updating emacs-22.2/config.guess with /usr/share/gnuconfig/config.guess
 * econf: updating emacs-22.2/config.sub with /usr/share/gnuconfig/config.sub
./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --program-suffix=-emacs-22 --infodir=/usr/share/info/emacs-22 --without-carbon --with-sound --with-x --without-toolkit-scroll-bars --with-jpeg --with-tiff --with-gif --with-png --with-xpm --with-x-toolkit=gtk --without-hesiod --with-kerberos --with-kerberos5 --build=i686-pc-linux-gnu
...
checking for tparm in -lncurses... yes
checking for com_err in -lcom_err... yes
checking for mit_des_cbc_encrypt in -lk5crypto... no
checking for mit_des_cbc_encrypt in -lcrypto... no
checking for krb5_init_context in -lkrb5... yes
checking krb5.h usability... yes
checking krb5.h presence... yes
checking for krb5.h... yes
checking com_err.h usability... yes
checking com_err.h presence... yes
checking for com_err.h... yes
...
cd lib-src; make all  \
          CC='i686-pc-linux-gnu-gcc' CFLAGS='-O2 -march=pentium4 -pipe' CPPFLAGS='-D_BSD_SOURCE  ' \
          LDFLAGS='-Wl,-znocombreloc ' MAKE='make'
make[1]: Entering directory `/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src'
i686-pc-linux-gnu-gcc -D_BSD_SOURCE -DHAVE_CONFIG_H -I. -I../src -I/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src -I/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/../src -Wl,-znocombreloc  -D_BSD_SOURCE   -O2 -march=pentium4 -pipe -o test-distrib /var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/test-distrib.c
./test-distrib /var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/testfile
i686-pc-linux-gnu-gcc -D_BSD_SOURCE -DHAVE_CONFIG_H -I. -I../src -I/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src -I/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/../src -Wl,-znocombreloc  -D_BSD_SOURCE   -O2 -march=pentium4 -pipe /var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/make-docfile.c -lc -o make-docfile
i686-pc-linux-gnu-gcc -D_BSD_SOURCE -DHAVE_CONFIG_H -I. -I../src -I/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src -I/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/../src -Wl,-znocombreloc  -D_BSD_SOURCE   -O2 -march=pentium4 -pipe /var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/profile.c -lc -o profile
i686-pc-linux-gnu-gcc -D_BSD_SOURCE -DHAVE_CONFIG_H -I. -I../src -I/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src -I/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/../src -Wl,-znocombreloc  -D_BSD_SOURCE   -O2 -march=pentium4 -pipe /var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/digest-doc.c -lc -o digest-doc
i686-pc-linux-gnu-gcc -D_BSD_SOURCE -DHAVE_CONFIG_H -I. -I../src -I/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src -I/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/../src -Wl,-znocombreloc  -D_BSD_SOURCE   -O2 -march=pentium4 -pipe /var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/sorted-doc.c -lc -o sorted-doc
i686-pc-linux-gnu-gcc -c -D_BSD_SOURCE -DHAVE_CONFIG_H -I. -I../src -I/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src -I/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/../src -D_BSD_SOURCE   -O2 -march=pentium4 -pipe -Demacs  /var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/movemail.c
i686-pc-linux-gnu-gcc -c -D_BSD_SOURCE -DHAVE_CONFIG_H -I. -I../src -I/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src -I/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/../src -D_BSD_SOURCE   -O2 -march=pentium4 -pipe  /var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/pop.c
/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/pop.c: In function ‘socket_connection’:
/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/pop.c:1203: error: ‘krb5_error’ has no member named ‘text’
/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/pop.c:1210: error: ‘krb5_error’ has no member named ‘text’
/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/pop.c:1210: error: ‘krb5_error’ has no member named ‘text’
/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src/pop.c:1210: error: ‘krb5_error’ has no member named ‘text’
make[1]: *** [pop.o] Error 1
make[1]: Leaving directory `/var/tmp/portage/app-editors/emacs-22.2/work/emacs-22.2/lib-src'
make: *** [lib-src] Error 2
 * 
 * ERROR: app-editors/emacs-22.2 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_compile
 *             environment, line 3086:  Called die
 * The specific snippet of code:
 *       emake CC="$(tc-getCC)" || die "emake failed";
 *  The die message:
 *   emake failed


# emerge --info
Portage 2.1.4.4 (default-linux/x86/2007.0/desktop, gcc-4.2.3, glibc-2.7-r2, 2.6.24.3 i686)
=================================================================
System uname: 2.6.24.3 i686 Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz
Timestamp of tree: Fri, 28 Mar 2008 16:00:04 +0000
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
app-shells/bash:     3.2_p33
dev-java/java-config: 1.3.7, 2.1.5
dev-lang/python:     2.3.6-r4, 2.4.4-r9, 2.5.1-r5
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 1.12.11.1
sys-apps/sandbox:    1.2.18.1-r2
sys-devel/autoconf:  2.13, 2.61-r1
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1
sys-devel/binutils:  2.18-r1
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   1.5.26
virtual/os-headers:  2.6.24
ACCEPT_KEYWORDS="x86 ~x86"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium4 -mmmx -msse -msse2 -fomit-frame-pointer -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /var/bind /var/qmail/alias /var/qmail/control /var/spool/torque /var/vpopmail/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-O2 -march=pentium4 -mmmx -msse -msse2 -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LINGUAS="en cs cz"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="7zip R X Xaw3d a52 aac aalib ace acl acpi alsa amr amrnb amrwb apache2 audacious audiofile bash-completion bcmath berkdb blas boost bzip2 cairo cblas cddb cdparanoia cdr clamav cli colordiff compress cpio cracklib crypt cscope css ctype cups curl curlwrappers cxx dbus dga dia directfb djbfft dri dts dv dvb dvd dvdr dvdread eds emacs emboss emf enblend encode enscript exif expat fam fame fat fbcon ffmpeg fftw firefox flac flash foomaticdb fortran fpx ftp gcj gd gdbm ggi gif gimp gimpprint glibc-compat20 glibc-omitfp glitz glut gmp gnuplot gnutls gpgme gphoto2 gpm graphviz gs gsl gstreamer gtk gtkhtml hal hdf hdf5 i8x0 icc iconv icu id3 ieee1394 ifc imagemagick imlib inifile innodb isdnlog ithreads jack java javascript jbig jikes jpeg jpeg2k kdtree kerberos lame lapack lcms leim libcaca libedit libwww live lzo lzw mad maildir matroska mhash midi mikmod mime ming mjpeg mmap mmx mng mod_python modperl modplug motif mozilla moznoirc mp2 mp3 mp4 mpeg mpi mpi_njtree mplayer mudflap mule musepack mxdatetime mysql mysqli ncurses netcdf netpbm network nls nntp nptl nptlonly nsplugin ntfs numeric ogg opengl openmp oss pam pango pcmcia pcntl pcre pdf perl plotutils plugin png pnm postproc postscript ppds pppd procmail pymol python qt3 qt3support qt4 quicktime rar raw readline real recode reflection reiserfs rpm rtc samba sasl scanner scp seamonkey server session sftp sift slp smime sndfile soap sockets spell spl sqlite srt sse sse2 ssl subtitles subversion svg svgz sysfs sysvipc t1lib tcl tcpd tetex theora threads tidy tiff tk transcode truetype unicode urandom usb userlocales uuencode v4l v4l2 vcd vim-syntax vim-with-x vorbis wifi win32codecs wmf wxwindows x264 x86 xanim xcb xcf xfs xft xinetd xml xorg xpm xprint xsl xslt xv xvid xvmc yv12 zip zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config mem_cache mime mime_magic rewrite setenvif speling status unique_id userdir usertrack vhost_alias negotiation" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en cs cz" USERLAND="GNU" VIDEO_CARDS="radeon"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 1 Martin Mokrejš 2008-03-31 11:35:29 UTC
I have app-crypt/heimdal-0.7.2-r3 installed in FHS paths (no /usr/heimdal/ present).
Comment 2 Ulrich Müller gentoo-dev 2008-03-31 20:24:02 UTC
(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.
Comment 3 Michael Hammer (RETIRED) gentoo-dev 2008-04-01 10:36:54 UTC
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
Comment 4 Michael Hammer (RETIRED) gentoo-dev 2008-04-01 10:57:57 UTC
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
Comment 5 Christian Faulhammer (RETIRED) gentoo-dev 2008-04-01 11:41:02 UTC
Thanks for your research, we will discuss it with Emacs upstream soon.
Comment 6 Ulrich Müller gentoo-dev 2008-04-01 11:45:49 UTC
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?
Comment 7 Martin Mokrejš 2008-04-01 20:54:49 UTC
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. ;-)
Comment 8 Christian Faulhammer (RETIRED) gentoo-dev 2008-04-01 21:01:14 UTC
(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.
Comment 9 Ulrich Müller gentoo-dev 2008-04-02 12:25:04 UTC
(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.
Comment 10 Michael Hammer (RETIRED) gentoo-dev 2008-04-02 12:50:19 UTC
(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
Comment 11 Honza Macháček 2008-04-02 13:24:25 UTC
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.
Comment 12 Honza Macháček 2008-04-02 13:27:04 UTC
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.
Comment 13 Honza Macháček 2008-04-02 13:27:53 UTC
Created attachment 148083 [details, diff]
emacs-pop-heimdal.patch

The patch from T2.
Comment 14 Honza Macháček 2008-04-02 13:32:38 UTC
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.
Comment 15 Michael Hammer (RETIRED) gentoo-dev 2008-04-02 13:46:42 UTC
(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
Comment 16 Ulrich Müller gentoo-dev 2008-04-02 16:52:21 UTC
(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.
Comment 17 Michael Hammer (RETIRED) gentoo-dev 2008-04-03 07:58:06 UTC
(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
Comment 18 Ulrich Müller gentoo-dev 2008-04-03 08:51:52 UTC
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.
Comment 19 Michael Hammer (RETIRED) gentoo-dev 2008-04-03 09:07:06 UTC
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?
Comment 20 Ulrich Müller gentoo-dev 2008-04-03 13:02:29 UTC
(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.
Comment 21 Ulrich Müller gentoo-dev 2008-04-04 12:44:33 UTC
Both alternatives for a patch submitted upstream: <http://lists.gnu.org/archive/html/emacs-devel/2008-04/msg00232.html>
Comment 22 Ulrich Müller gentoo-dev 2008-04-06 22:06:08 UTC
Reopening for proper closing.
Comment 23 Ulrich Müller gentoo-dev 2008-04-06 22:06:47 UTC
  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.
Comment 24 Ulrich Müller gentoo-dev 2008-08-06 05:52:14 UTC
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.
Comment 25 Michael Hammer (RETIRED) gentoo-dev 2008-08-06 06:07:34 UTC
Nice! Thx for fixing the issue - heimdal is getting continuously nearer a stable state.

g, mueli