This seems a bit odd as it suggests that 'token' is None when offlineimap tries to unwrap it. The code above the call to reads as if it expects that it's ensured that wouldn't be the case - I'm kinda figuring that it believes that so long as `self.gss_vc.complete` is truthy, it'll have a token.

AFAICS the code in offlineimap is as it was when the patch to migrate to gssapi (by rharwood) was first merged, and the code on the gssapi side has not changed in several years, so the change here is simply that the patch to migrate to gssapi itself landed in Fedora 29 (Fedora 28 is still on pykerberos).

CCing Robbie - Robbie, do you know what might be the problem here?

From staring at what was backported, offlineimap in Fedora will also need 17cfb63db6684fccefb27552f57aeb77bd5f9acd .  (This is present in v7.2.1; Dodji, please update rawhide to that version.  I'm surprised there haven't been other issues, and I'm not sure whether this will work without it.)

The traceback you have indicates a crash beneath __gsshandler - specifically, that the token is None.  However, in order to get there, the context must not be complete already.  So the server sent something weird and I think noncomplaint.

So: I'd like to know whether it still yields a traceback with that patch applied.  If so, can you try modifying imapserver.py to `return ""` if token is None *after* the check `if not self.gss_vc.complete` (i.e., right before the call to unwrap that's crashing)?

Since neither Google nor GitHub searches yield any results for 17cfb63db6684fccefb27552f57aeb77bd5f9acd, could you show a link to that commit, for people who would like to patch their installations before updated packages are available?

Specific commits for a git repository can always be found by cloning a repository and then inspecting `git log` (use / for search).  In this case, as I mentioned, you could also go get a source tarball for 7.2.1 and it would be present - those are typically made available by upstreams on their websites (offlineimap has a github repo, so click the "releases" link and it can be downloaded from there).  Additionally, github has a handy feature where you can visit a link like https://github.com/OfflineIMAP/offlineimap/commit/17cfb63db6684fccefb27552f57aeb77bd5f9acd and see the diff for a commit.

If Dodji doesn't respond to this relatively soon, I'll do the backport and Rawhide update with provenpackagers privileges.

(In reply to Robbie Harwood from comment #4)
> https://github.com/OfflineIMAP/offlineimap/commit/17cfb63db6684fccefb27552f57aeb77bd5f9acd

Thanks. I was mostly not sure what repo we are talking about.

I have built 7.2.1 in Rawhide at https://koji.fedoraproject.org/koji/taskinfo?taskID=31278488.

Could you check it out and tell me if you still have the issue?

In the mean time I'll go ahead and build it for f29.

offlineimap-7.2.1-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-8cf345e653

offlineimap-7.2.1-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-8cf345e653

Thanks Dodji!

Thanks for the build.  Unfortunately I'm still getting the error.  Am I doing something wrong?

$ rpm -qa
offlineimap-7.2.1-1.fc29.noarch
python2-gssapi-1.5.1-1.fc29.x86_64

$ offlineimap
OfflineIMAP 7.2.1
  Licensed under the GNU GPL v2 or any later version (with an OpenSSL exception)
imaplib2 v2.57 (bundled), Python v2.7.15, OpenSSL 1.0.2o-fips  27 Mar 2018
...
 ERROR: ERROR in syncfolder for RedHat folder dpdk-dev: Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/offlineimap/accounts.py", line 614, in syncfolder
    cachemessagelists_upto_date(maxage)
  File "/usr/lib/python2.7/site-packages/offlineimap/accounts.py", line 510, in cachemessagelists_upto_date
    min_date=time.gmtime(time.mktime(date) + 24*60*60))
  File "/usr/lib/python2.7/site-packages/offlineimap/folder/IMAP.py", line 272, in cachemessagelist
    imapobj = self.imapserver.acquireconnection()
  File "/usr/lib/python2.7/site-packages/offlineimap/imapserver.py", line 561, in acquireconnection
    self.__authn_helper(imapobj)
  File "/usr/lib/python2.7/site-packages/offlineimap/imapserver.py", line 425, in __authn_helper
    if func(imapobj):
  File "/usr/lib/python2.7/site-packages/offlineimap/imapserver.py", line 335, in __authn_gssapi
    imapobj.authenticate('GSSAPI', self.__gsshandler)
  File "/usr/lib/python2.7/site-packages/offlineimap/bundled_imaplib2.py", line 734, in authenticate
    typ, dat = self._simple_command('AUTHENTICATE', mechanism.upper())
  File "/usr/lib/python2.7/site-packages/offlineimap/bundled_imaplib2.py", line 1740, in _simple_command
    return self._command_complete(self._command(name, *args), kw)
  File "/usr/lib/python2.7/site-packages/offlineimap/bundled_imaplib2.py", line 1466, in _command
    literal = literator(data, rqb)
  File "/usr/lib/python2.7/site-packages/offlineimap/bundled_imaplib2.py", line 2331, in process
    ret = self.mech(self.decode(data))
  File "/usr/lib/python2.7/site-packages/offlineimap/imapserver.py", line 282, in __gsshandler
    response = self.gss_vc.unwrap(token)
  File "<decorator-gen-6>", line 2, in unwrap
  File "/usr/lib64/python2.7/site-packages/gssapi/_utils.py", line 167, in check_last_err
    return func(self, *args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/gssapi/sec_contexts.py", line 231, in unwrap
    return rmessage.unwrap(self, message)
  File "gssapi/raw/message.pyx", line 257, in gssapi.raw.message.unwrap
TypeError: object of type 'NoneType' has no len()

Probably not your fault!  Would you mind trying the change suggested at #c2 and see if that does anything?

(In reply to Robbie Harwood from comment #12)
> Probably not your fault!  Would you mind trying the change suggested at #c2
> and see if that does anything?

Yes, adding the 'return ""' eliminated the backtraces!  I'll keep this as a workaround for now.  Thanks!

(In reply to Stefan Hajnoczi from comment #13)
> (In reply to Robbie Harwood from comment #12)
> > Probably not your fault!  Would you mind trying the change suggested at #c2
> > and see if that does anything?
> 
> Yes, adding the 'return ""' eliminated the backtraces!  I'll keep this as a
> workaround for now.  Thanks!

Great.

Robbie, is it possible that you submit a patch upstream with that fix (the so-called "return fix"), so that I can add the patch to Fedora? Please CC me when you submit the patch so that I am aware of it.

Thanks!

Sure thing!  It's https://github.com/OfflineIMAP/offlineimap/pull/587

(In reply to Robbie Harwood from comment #15)
> Sure thing!  It's https://github.com/OfflineIMAP/offlineimap/pull/587

The upstream patch has been applied. Any changes of a new downstream package with the update? Thanks.

Was not really intending to change it from ON_QA to ASSIGNED, although it's probably valid (given the package being tested doesn't fix this bug). Anyway, I'm sorry for the noise if this new status is wrong.

Please try offlineimap-7.2.4-1.fc31 in rawhide.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days