Bug 589788 - Can't seem to authorize to GSSAPI due to error in base64 decoding
Summary: Can't seem to authorize to GSSAPI due to error in base64 decoding
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: sendmail
Version: 5.5
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Jaroslav Škarvada
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-06 21:19 UTC by melson
Modified: 2013-03-06 12:59 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-06 12:59:03 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
simple maxinpline patch (1.28 KB, patch)
2010-05-09 23:04 UTC, melson
no flags Details | Diff
maxinpline patch w/ auth sanity check included (3.02 KB, patch)
2010-05-09 23:07 UTC, melson
no flags Details | Diff

Description melson 2010-05-06 21:19:46 UTC
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.

Comment 1 melson 2010-05-09 23:04:19 UTC
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)

Comment 2 melson 2010-05-09 23:07:45 UTC
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).

Comment 3 RHEL Program Management 2011-01-11 20:31:27 UTC
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.

Comment 4 RHEL Program Management 2011-01-12 15:09:24 UTC
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.

Comment 5 RHEL Program Management 2011-05-31 13:24:16 UTC
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.

Comment 6 RHEL Program Management 2011-09-23 00:13:59 UTC
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.

Comment 7 RHEL Program Management 2012-06-12 01:05:03 UTC
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.

Comment 8 Jaroslav Škarvada 2013-03-06 12:59:03 UTC
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/).


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