Bug 459691 - [PPC] SMTP CRAM-MD5 AUTH failure
Status: CLOSED DUPLICATE of bug 456561
Product: Fedora
Classification: Fedora
Component: evolution-data-server (Show other bugs)
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Matthew Barnes
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2008-08-21 05:07 EDT by David Woodhouse
Modified: 2009-06-17 09:04 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-17 09:04:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Bugzilla 548863 None None None Never

  None (edit)
Description David Woodhouse 2008-08-21 05:07:39 EDT
For some reason, Evolution has started failing to authenticate to the SMTP server. I get an endless stream of...

sending : AUTH CRAM-MD5
CamelException.setv(0xf35febc0, 3, 'AUTH command failed: Interrupted system call')
sending : AUTH CRAM-MD5
CamelException.setv(0xf35febc0, 3, 'AUTH command failed: Interrupted system call')
sending : AUTH CRAM-MD5
CamelException.setv(0xf35febc0, 3, 'AUTH command failed: Interrupted system call')
sending : AUTH CRAM-MD5
CamelException.setv(0xf35febc0, 3, 'AUTH command failed: Interrupted system call')
sending : AUTH CRAM-MD5
CamelException.setv(0xf35febc0, 3, 'AUTH command failed: Interrupted system call')

... and no error dialog or anything else. I'm not sure _why_ the authentication is failing; I'm about to debug that. But I haven't changed anything at the server side either. Whatever the underlying reason for the failure, Evolution's _handling_ of it is broken.

The server is saying:
2008-08-21 09:00:20 +0000 cram authenticator failed for pmac.infradead.org [2001:8b0:10b:1:20d:93ff:fe7a:3f2c]: 535 Incorrect authentication data (set_id=dwmw2)
Comment 1 David Woodhouse 2008-08-21 05:11:36 EDT
I've tried changing my configuration to use AUTH PLAIN and I've restarted Evolution (and checked that it really thinks it's supposed to use PLAIN). But it's _still_ in an endless loop trying CRAM-MD5 after I hit Send/Receive.
Comment 2 David Woodhouse 2008-08-21 05:45:51 EDT
I managed to flush my Outbox by double-clicking to re-edit the first mail in it, then deleting that mail from the Outbox. After that, the other mails queued there went out OK.

When I looked at the compose window which opened when I double-clicked on that mail, it seems it was set to use my News account (which has an SMTP config which did still use CRAM-MD5; I'd forgotten about that and hadn't changed it). So part of the problem (or just _another_ problem) seems to be that Evolution uses the wrong account settings to send mail it finds in the Outbox at startup.
Comment 3 David Woodhouse 2008-08-21 06:21:37 EDT
Having reminded myself how CRAM-MD5 works, it looks like the underlying fault is with Evolution. It's giving incorrect responses -- and it's the md5 part which is incorrect, so I can't see why.
Comment 4 Milan Crha 2008-08-21 10:19:12 EDT
Moved upstream [1], as I promised.

[1] http://bugzilla.gnome.org/show_bug.cgi?id=548863
Comment 5 David Woodhouse 2008-08-26 07:24:17 EDT
Reopening here, because the CRAM-MD5 brokenness seems to be Fedora-specific. It seems that our glib2-devel-2.16.4-1.fc9.ppc package was shipped with this in glibconfig.h: #define G_BYTE_ORDER G_LITTLE_ENDIAN.

This seems to have happened because of an autohell change, where $ac_cv_c_bigendian ended up defined as 'universal' rather than 'yes', and this results in glib assuming little-endian:

You can see this failure in the build log. The offending one is at http://kojipkgs.fedoraproject.org/packages/glib2/2.16.4/1.fc9/data/logs/ppc/build.log and says:

     checking whether byte ordering is bigendian... 

This is 'fixed' in glib2-2.16.5, and doesn't seem to have been broken in the previous F-9 package 2.16.3-7.fc9 either.

The broken glib2-2.16.4 was built on July 2nd, and the fixed glib2-2.16.5 was built on July 20th. Anything using G_BYTE_ORDER which was built between those times (and a little after, depending on when the fixed on got into the buildroot repos) may well be broken, and need rebuilding.

(The repeated retries on failure are GNOME bug 532472, for which a patch exists)
Comment 6 Milan Crha 2009-01-06 09:07:00 EST
Hi David, I've a report in bug #456561, where reporter says the MD5 login is broken for him on a PPC even in Fedora 10. Are you able to checkout that, please? 

I looked to the build.log as you wrote above, on glib2-2.18.2-3.f10 and it seems correct, at least the answer for the "...is bigendian..." is 'yes', same as in the 2.16.5-1.fc9.

(changing platform to powerpc)
Comment 7 Bug Zapper 2009-06-09 22:31:28 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 8 Milan Crha 2009-06-17 09:04:47 EDT
Marking this as a duplicate of the other.

*** This bug has been marked as a duplicate of bug 456561 ***

Note You need to log in before you can comment on or make changes to this bug.