Regardless of which GSSAPI option one chooses, cyrus-sasl-gssapi is not pulled in as a dependency, and GSSAPI is not available for authentication without this. However, the default package, which doesn't evidently enable any GSSAPI option by default, is able to authenticate using GSSAPI if the cyrus-sasl-gssapi package is installed. Something's a bit fishy here.
Is this SMTP or IMAP auth that works once security/cyrus-sasl-gssapi is installed? If it's IMAP then maybe something is fishy however for SMTP it seems by design. GSSAPI options set GSS IMAP auth and SASL is for SMTP. SASL is enabled by default and security/cyrus-sasl is built without gss support due gss being split off in 2013. Perhaps this has been "broken" in the mutt port since then or users followed UPDATING's directions (20131226) and installed security/cyrus-sasl-gssapi? I guess the port just doesn't know if the user needs GSS SASL auth. Do we need another port option to control if security/cyrus-sasl-gssapi should be installed or can we assume if you want IMAP GSS auth it's safe to assume you're going to need SMTP GSS auth as well?
On Fri, Apr 28, 2017 at 01:32:27AM +0000, bugzilla-noreply@freebsd.org wrote: > Is this SMTP or IMAP auth that works once security/cyrus-sasl-gssapi is > installed? Sorry, I should have noted that. The failure to authenticate was with IMAP. I don't have a set-up that will let me test Kerberized SMTP, unfortunately. > Do we need another port option to control if security/cyrus-sasl-gssapi > should be installed or can we assume if you want IMAP GSS auth it's safe to > assume you're going to need SMTP GSS auth as well? Unless it's unreliable for some reason of which I'm unaware, perhaps a pkg-message noting that GSSAPI for IMAP will work if cyrus-sasl-gssapi is installed would suffice. -- Mason Loring Bliss mason@blisses.org http://blisses.org/ The sand bats of Manark IV look like inanimate rock crystals until they attack.
Ok I stand corrected after reading mutt docs (and your comment). No, I think it makes sense to have the port install cyrus-sasl-gssapi if any of the GSS options are selected.
Created attachment 182144 [details] Install security/cyrus-sasl2-gssapi if GSSAPI options are selected
Something confusing to me, though, is just what the GSSAPI options are accomplishing. Or perhaps, what the base option accomplishes. I've installed the Mutt package, which is built without any of them, and I'm able to authenticate using GSSAPI/Kerberos with the cyrus-sasl-gssapi installed. It's not at all clear what's different if any of the GSSAPI options are selected in the build, if what's actually required is the cyrus-sasl-gssapi package, not the options themselves. I'd be inclined to look for bugs with the non-base options, although it's conceivable that from cyrus-sasl-gssapi's perspective the programmatic interface to Kerberos tickets doesn't change.
I think we're starting to get in to mutt-user's mailing list questions due to my limited (0) use of these features. However, I'd like to guess without GSSAPI_* selected this disables mutt's ability to authenticate directly with IMAP servers with GSSAPI. But if SASL is enabled mutt will attempt to use SASL with cyrus-sasl via the cyrus-sasl-gssapi plugin will attempt to authenticate with GSSAPI. This would move the GSSAPI code from mutt to cyrus-sasl and its plugins? If you look at cyrus-sasl-gssapi you'll see almost the same GSSAPI_* options as mail/mutt's Makefile. I'm unsure if you tested this from comment 0 but does GSS authentication work if you disable SASL and enable a compatible GSS implementation with mail/mutt? Based off mutt's manual mutt should attempt SASL then GSSAPI however it needs to be compiled in. http://www.mutt.org/doc/manual/#imap-authentication If you've only tested with the default options or the FreeBSD repo package then I would like to guess mutt would never attempt to try GSSAPI directly since --with-gss (Compile in GSSAPI authentication for IMAP) wouldn't be set at compile time. Looking at this a bit more it seems that maybe cyrus-sasl-gssapi shouldn't be installed if a non-GSSAPI_NONE is picked and the attached patch should be replaced. Possible changes: - Install cyrus-sasl-gssapi if you have SASL selected. - Add a new option to install cygrus-sasl-gssapi. - A pkg-message explaining if you need GSSAPI install cyrus-sasl-gssapi (security/cyrus-sasl2 already does this)
On Fri, Apr 28, 2017 at 11:51:08PM +0000, bugzilla-noreply@freebsd.org wrote: > However, I'd like to guess without GSSAPI_* selected this disables mutt's > ability to authenticate directly with IMAP servers with GSSAPI. But if SASL > is enabled mutt will attempt to use SASL with cyrus-sasl via the > cyrus-sasl-gssapi plugin will attempt to authenticate with GSSAPI. This > would move the GSSAPI code from mutt to cyrus-sasl and its plugins? That would match the behaviour I saw - even with GSSAPI_BASE selected, Mutt didn't try to authenticate using GSSAPI itself, and evidently shoved it off to the SASL code. When that failed, it didn't try to authenticate using GSSAPI itself. Maybe this is a bug in Mutt, not our packaging of it...? > I'm unsure if you tested this from comment 0 but does GSS authentication > work if you disable SASL and enable a compatible GSS implementation with > mail/mutt? I haven't tested this yet, but I will later today, and I'll report back within 12 hours of my submitting this comment. > If you've only tested with the default options or the FreeBSD repo package > then I would like to guess mutt would never attempt to try GSSAPI directly > since --with-gss (Compile in GSSAPI authentication for IMAP) wouldn't be > set at compile time. No, I tested with GSSAPI_BASE as well, and I wasn't able to authenticate with GSSAPI until I popped in the cyrus-sasl-gssapi package, so its native GSSAPI code path was evidently never tried. -- Mason Loring Bliss mason@blisses.org http://blisses.org/ "I am a brother of jackals, and a companion of ostriches." (Job 30 : 29)
PS, apologies for the odd formatting of my replies. I'm pasting in interleaved, quoted responses, and the web form is taking strange liberties with newlines.
FreeBSD is better off this way. Sorry for the bother.