After upgrading to net-mail/fetchmail-6.3.17, I can no longer authenticate to any servers that use cram-md5 to authenticate. Downgrading back to 6.3.14 restores cram-md5, so it is not the server. Reproducible: Always Steps to Reproduce: 1. Setup fetchmail to use cram-md5 2. Run fetchmail 3. Get an authentication failure. Actual Results: fetchmail: IMAP< A0004 NO Invalid authentication credentials fetchmail: IMAP> A0005 * fetchmail: Authorization failure on hakimian@magnus.aha.com Expected Results: Should have accepted the authentication. Server log says May 11 08:48:13 magnus imapd.alt[1125]: AUTHENTICATE CRAM-MD5 failure host=serenity.aha.com [x.x.x.x]
Created attachment 231301 [details] LC_ALL=C fetchmail --nodetach -vvv --nosyslog It works here. Not sure what your problem is. Compare the verbose output of both fetchmail version.
Created attachment 231317 [details] Output from older working version Output that does what was expected.
Created attachment 231319 [details] Output from newer non working version Auth failure. There is a pause before it tells me it fails
Created attachment 231321 [details] config file that used to work and now does not
Matthias, it seems that the cram-md5 authentication suddenly fails with fetchmail 6.3.17 for one person while fetchmail 6.3.14 works. The only thing i know that we changed was the removal of our bad-header patch in version 6.3.16. @Karl: Can you please test the other two versions too?
I have now emerged and tried both .15 and .16. Both fail the same way as .17, so the last working one (for me anyway) appears to be .14.
Confirmed on Cygwin for .17 without checking older versions yet. Thank you for reporting this, narrowing this down, and providing relevant configuration and logs. There were compiler warnings and signedness bug fixups for .15, they might possibly have broken things. I'll investigate this. Can I ask in this particular case to also provide the config.log and config.h, files from the build directory (after ./configure) AND the output of "ldd /path/to/fetchmail" and - if present - compiler warnings in this particular case, to see how exactly fetchmail was configured, built, and how it links at run-time?
I need to withdraw confirmation - appears to be misentry of password, or server hicc-up. CRAM-MD5 works for me.
Do you still want the requested files? If so, which version? Or do you want them from all three?
I have compiled ebuild path_to_fetchmail compile all four versions. The working one is installed, the others are still in their build directories. I can retrieve any files you need and the build logs. One interesting things I have noted is the working version does not use an external md5 lib. Working version: ldd /usr/bin/fetchmail linux-vdso.so.1 => (0x00007fff89953000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007ff8965b1000) libresolv.so.2 => /lib/libresolv.so.2 (0x00007ff89639a000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007ff8960fd000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007ff895ed5000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x00007ff895cd1000) libdl.so.2 => /lib/libdl.so.2 (0x00007ff895acd000) libssl.so.0.9.8 => /usr/lib64/libssl.so.0.9.8 (0x00007ff895873000) libcrypto.so.0.9.8 => /usr/lib64/libcrypto.so.0.9.8 (0x00007ff8954d7000) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007ff8952aa000) libc.so.6 => /lib/libc.so.6 (0x00007ff894f51000) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007ff894d49000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007ff894b2d000) /lib64/ld-linux-x86-64.so.2 (0x00007ff8967e9000) libz.so.1 => /lib/libz.so.1 (0x00007ff894916000) Non working version: ldd /var/tmp/portage/net-mail/fetchmail-6.3.15/work/fetchmail-6.3.15/fetchmail linux-vdso.so.1 => (0x00007fff59b5d000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007ff667607000) libmd5.so.0 => /usr/lib64/libmd5.so.0 (0x00007ff667404000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007ff667167000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007ff666f3f000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x00007ff666d3b000) libresolv.so.2 => /lib/libresolv.so.2 (0x00007ff666b24000) libdl.so.2 => /lib/libdl.so.2 (0x00007ff666920000) libssl.so.0.9.8 => /usr/lib64/libssl.so.0.9.8 (0x00007ff6666c6000) libcrypto.so.0.9.8 => /usr/lib64/libcrypto.so.0.9.8 (0x00007ff66632a000) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007ff6660fd000) libc.so.6 => /lib/libc.so.6 (0x00007ff665da4000) libz.so.1 => /lib/libz.so.1 (0x00007ff665b8d000) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007ff665985000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007ff665769000) /lib64/ld-linux-x86-64.so.2 (0x00007ff66783f000) I wonder if this is really a libmd5 issue.
More information. If I remove the package libwww, which is where my external libmd5 came from and rebuild fetchmail, it works fine. Apparently, the libmd5 provided by libwww is not compatible with fetchmail and crammd5. Offhand, I don't see how to force fetchmail to use its internal md5 instead of one available on the system, but that would solve the problem.
Created attachment 231829 [details, diff] Patch to remove external md5 This patch will cause fetchmail to ignore a libmd5 already on the system. I don't know if this is a good idea, but it does solve the problem I have.
I can reproduce the problem on FreeBSD 8 amd64 by forcing (with LD_PRELOAD) libwww's libmd5.so underneath fetchmail, which changes (thus breaks) CRAM-MD5, while the fetchmail with system libmd.so (not md5) works just fine. The patch might work for Gentoo, but isn't fit for inclusion upstream - configure is a generated file (from configure.ac).
I was trying to find a way of working with configure to remove this and I looked at the .14 version's configure to see what it did. Basically, when they added the check for libmd5, things broke and there does not appear to be a way to not use it if it is found. The patch was a quick and dirty (could be added to the ebuild) attempt to work around the problem. One idea would be to apply the patch only when libwww was detected.
Thanks for the libwww pointer, this was the most valuable part in this bug hunt. So, the cause is: libwww contains 18-year-old code from RSA Inc, and this code fucks up type sizes. It assumes "long" were 32-bit, which doesn't hold on amd64/x86_64, where it's 64-bit. Fetchmail uses proper 32-bit types, so the arguments passed to libmd5.so are too narrow on machines with non-32bit "long" types. I was testing the new 6.3.15 MD5 code and also libmd5 inclusion on 32-bit computers, so this went unnoticed. Sorry for that. I'll clone this bug to point fingers at the real culprit, libwww, but I don't hope for much, libwww looks essentially abandoned. WRT fetchmail, version 6.3.18 is more conservative about picking up libraries for MD5Init/MD5Update/MD5Finish. It will avoid libmd5 altogether and only probe libmd if md5.h is provided by the system. Please test the tarball from http://gitorious.org/fetchmail/fetchmail/archive-tarball/bb67b781 and let me know if it fixes the problem for you on 64-bit computers. The actual change can be perused at http://gitorious.org/fetchmail/fetchmail/commit/bb67b781f9b26a06f3f66a9db8b297920467d0db
OK. I unpacked, ran autogen.sh then I gave it the configure line from the config.log file that .17 generated and then compiles. No external md5 library and it seems to be working. Looking forward to this version being in portage. :-)
Thanks for the test. This confirms that the fix in Git works as I'd hoped, and it also works on Solaris 10 (SPARC and SPARC64), FreeBSD 8 (amd64), NetBSD 5 (amd64), and openSUSE 11.2 (i686). Until the next release, I'd propose that the Portage/Emerge system adds your "md5patch" at least on machines where sizeof(unsigned long) != sizeof(uint32_t). It would be safe to use the patch for all architectures. By the way, I have enjoyed working on this. This was one of the - regretfully rare - bug reports that was accurate, useful, where further information was available without fuss and long delays.
(In reply to comment #1) > Created an attachment (id=231301) [details] > LC_ALL=C fetchmail --nodetach -vvv --nosyslog > > It works here. Not sure what your problem is. Torsten, to ask final confirmation: did you run this test on a 32-bit operating system?
(In reply to comment #18) > (In reply to comment #1) > > Created an attachment (id=231301) [details] [details] > > LC_ALL=C fetchmail --nodetach -vvv --nosyslog > > > > It works here. Not sure what your problem is. > > Torsten, to ask final confirmation: did you run this test on a 32-bit operating > system? No, 64-bit too. But I didn't had libwww installed, so no libmd5.
6.3.17-r1 is in the tree with the patch applied. Thank you very much, Matthias and Karl.
