Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 409897 - dev-libs/cyrus-sasl-2.1.25-r2 breaks when using GSSAPI with MAXSSF=0
Summary: dev-libs/cyrus-sasl-2.1.25-r2 breaks when using GSSAPI with MAXSSF=0
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal major (vote)
Assignee: No maintainer - Look at if you want to take care of it
Depends on:
Reported: 2012-03-27 16:15 UTC by Andreas Turriff
Modified: 2022-02-23 06:46 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---

Reverse a change to do with flags when extra confidentiality is requested. (ssf.patch,696 bytes, patch)
2014-07-24 03:28 UTC, Alex Orange
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Turriff 2012-03-27 16:15:22 UTC
After upgrading to cyrus-sasl 2.1.25 and rebuilding my SASL clients, I 
am seeing strange behavior when attempting to set maxssf=0 while using 
GSSAPI (the use case is authenticating against Windows 2008 R2 active 
directory with LDAP). Output from ldapsearch attached. This used to work 
with version 2.1.23.

freya ~ # ldapsearch -d 1 -H ldap:// -O 
maxssf=0 -Y gssapi
ldap_sasl_interactive_bind: user selected: gssapi
ldap_int_sasl_bind: gssapi
ldap_new_connection 1 1 0
ldap_connect_to_host: TCP
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 2001:470:e904:1:0:8000:3:0 389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
SASL/GSSAPI authentication started
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 1734 bytes to sd 3
ldap_result ld 0x190d030 msgid 1
wait4msg ld 0x190d030 msgid 1 (infinite timeout)
wait4msg continue ld 0x190d030 msgid 1 all 1
** ld 0x190d030 Connections:
* host:  port: 389  (default)
   refcnt: 2  status: Connected
   last used: Fri Mar 16 09:29:59 2012

** ld 0x190d030 Outstanding Requests:
  * msgid 1,  origid 1, status InProgress
    outstanding referrals 0, parent count 0
   ld 0x190d030 request count 1 (abandoned 0)
** ld 0x190d030 Response Queue:
   ld 0x190d030 response count 0
ldap_chkResponseList ld 0x190d030 msgid 1 all 1
ldap_chkResponseList returns ld 0x190d030 NULL
read1msg: ld 0x190d030 msgid 1 all 1
ber_get_next: tag 0x30 len 18 contents:
read1msg: ld 0x190d030 msgid 1 message type bind
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x190d030 0 new referrals
read1msg:  mark request completed, ld 0x190d030 msgid 1
request done: ld 0x190d030 msgid 1
res_errno: 14, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_int_sasl_bind: gssapi
ber_scanf fmt ({eAA) ber:
ber_scanf fmt (O) ber:
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (x) ber:
ber_scanf fmt (}) ber:
sasl_client_step: -1
ldap_sasl_interactive_bind_s: Local error (-2)
         additional info: SASL(-1): generic failure: GSSAPI Error: A 
required input parameter could not be read (Unknown error)
ldap_free_connection 1 1
ber_flush2: 7 bytes to sd 3
ldap_free_connection: actually freed

Reproducible: Always

Steps to Reproduce:
1. Build LDAP with cyrus-sasl support
2. Try to authenticate an LDAP client connection to a Windows 2008 R2 domain controller with GSSAPI and MAXSSF=0
Actual Results:  
The GSSAPI module throws an error.

Expected Results:  
I expected authentication to work.

Dan White pointed me at a bugzilla entry with a patch for the problem; I believe this should be applied to Gentoo's build of cyrus-sasl.
Comment 1 Andreas Turriff 2012-03-27 16:16:22 UTC
Having tried this with the patch applied, this is now working for me.
Comment 2 Alex Orange 2014-07-24 03:27:44 UTC
I'm having the same issue with pidgin as the cyrus-sasl user. I'm attaching a patch that fixed it for me. Redhat has included this patch apparently:
Comment 3 Alex Orange 2014-07-24 03:28:47 UTC
Created attachment 381474 [details, diff]
Reverse a change to do with flags when extra confidentiality is requested.
Comment 4 Jonas Stein gentoo-dev 2018-10-09 18:18:01 UTC
Confirmed by Alex.

What is the status now? We have 
 2.1.26-r9 ~2.1.26-r10 ~2.1.26-r11
in the tree. Is it fixed?
Comment 5 Larry the Git Cow gentoo-dev 2022-02-23 00:54:20 UTC
The bug has been referenced in the following commit(s):

commit a065bacc267e31d5dd4a64d416de800cb6bc6fdd
Author:     Sam James <>
AuthorDate: 2022-02-23 00:52:37 +0000
Commit:     Sam James <>
CommitDate: 2022-02-23 00:53:47 +0000

    dev-libs/cyrus-sasl: add 2.1.28
    Java bindings dropped upstream. Fair amount of autotools changed upstream
    too so hopefully those issues are fixed.
    Signed-off-by: Sam James <>

 dev-libs/cyrus-sasl/Manifest                       |   1 +
 dev-libs/cyrus-sasl/cyrus-sasl-2.1.28.ebuild       | 220 +++++++++++++++++++++
 ...yrus-sasl-2.1.28-fix-configure-time-check.patch |  50 +++++
 3 files changed, 271 insertions(+)