Hide Forgot
Description of problem: Attempting to authorize via GSSAPI on various clients (alpine, thunderbird) isn't working. The error logs throw "cannot BASE64 decode" on the base64 encoded ticket that the clients send. My guess is it's related to the encode/decode changes that happened with the cyrus-sasl library and sendmail, but I haven't read up on the issues. Pulling down sendmail 8.14.3 from their website, compiling it, and using the same configuration results in successful GSSAPI negotiation. Version-Release number of selected component (if applicable): sendmail-8.13.8-8.el5 How reproducible: Consistently. Steps to Reproduce: 1. Configure sendmail for GSSAPI 2. Get a kerberos ticket on the client machine. 3. Attempt to auth via GSSAPI Actual results: Sendmail throws: 501 5.5.4 cannot BASE64 decode <LONG BASE64 STRING> AUTH decode64 error [1 for <LONG BASE64 STRING> Expected results: Successful authentication.
Created attachment 412683 [details] simple maxinpline patch Looking deeper into it, it looks like this was fixed in Sendmail 8.14.1. It's less BASE64 decoding and more the AUTH procedure running against the defined MAXLINE. This is a simple patch that implements what looks to have been done in 8.14.1 that works in my environment. (Not sure where to look to find the patch actually applied to sendmail)
Created attachment 412684 [details] maxinpline patch w/ auth sanity check included Adding this one which, while more complicated, implements a sanity check on length commands (found in sendmail 8.14.3) that I suspect was implemented when MAXINPLINE was as well - this also works in my environment (though admittedly I've not done extensive testing).
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
This request was erroneously denied for the current release of Red Hat Enterprise Linux. The error has been fixed and this request has been re-proposed for the current release.
Red Hat Enterprise Linux 5 entered Production 2 phase. The focus for minor releases during this phase lies on resolving urgent or high priority bugs. For more details see https://access.redhat.com/support/policy/updates/errata/. As this bug is not qualified as urgent or high priority it is closed with resolution WONTFIX. This issue is already fixed in Red Hat Enterprise Linux 6. If this issue is critical for your business you can escalate it through the support channel (http://www.redhat.com/support/).