[PATCH] Fix a gssapi issue where threads beyond the first would not be able to authenticate against the imap server. This is done by using the connection lock around the gssapi authentication code and resetting (and releasing) the kerberos state after success so that subsequent connections may make use of kerberos.

[sjh at foolishpride.org]

From: Scott Henson <shenson at redhat.com>

---
 offlineimap/imapserver.py |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/offlineimap/imapserver.py b/offlineimap/imapserver.py
index 7703879..a20bd88 100644
--- a/offlineimap/imapserver.py
+++ b/offlineimap/imapserver.py
@@ -213,6 +213,7 @@ class IMAPServer:
                     try:
                         # Try GSSAPI and continue if it fails
                         if 'AUTH=GSSAPI' in imapobj.capabilities and have_gss:
+                            self.connectionlock.acquire()
                             self.ui.debug('imap',
                                 'Attempting GSSAPI authentication')
                             try:
@@ -223,8 +224,12 @@ class IMAPServer:
                                     'GSSAPI Authentication failed')
                             else:
                                 self.gssapi = True
+                                kerberos.authGSSClientClean(self.gss_vc)
+                                self.gss_vc = None
+                                self.gss_step = self.GSS_STATE_STEP
                                 #if we do self.password = None then the next attempt cannot try...
                                 #self.password = None
+                            self.connectionlock.release()
 
                         if not self.gssapi:
                             if 'AUTH=CRAM-MD5' in imapobj.capabilities:
-- 
1.7.5.1