cyrus-sasl2 @2.1.25_4 doesn't contain LOGIN/PLAIN mechanism

[congling@…]

Compile and run the following code after install cyrus-sasl2, it would show just "EXTERNAL". But when using cyrus-sasl 2.1.26 source from ​ftp://ftp.cyrusimap.org/cyrus-sasl/cyrus-sasl-2.1.26.tar.gz, it would return the following mechanism. This issue will let the svn client unable to connect to the server with LOGIN/PLAIN authentication mechanism

mech:EXTERNAL
mech:APOP
mech:DHX
mech:WEBDAV-DIGEST
mech:ANONYMOUS
mech:CRAM-MD5
mech:DIGEST-MD5
mech:GSSAPI
mech:LOGIN
mech:NTLM
mech:OTP
mech:PLAIN
mech:PPS
mech:MS-CHAPv2
mech:SMB-NT
mech:SMB-NTLMv2

source code:

#include <stdio.h>
#include <sasl/sasl.h>

int main(){
        const char* np;
	const char** p;
	int result;
	
	result=sasl_client_init(NULL);
            
       /* check to see if that worked */
        if (result!=SASL_OK) {
		printf("failed to init\n");
		return 1;
	}
	else
		printf("success to init\n");
	p = sasl_global_listmech();
        for (np= *p; np != NULL; np=*(++p)) {
            printf("mech:%s\n",np);
        }

	return 0;
}

[max-arnold (Max Arnold)]

Same here (can be related to OS X Mavericks):

$ /opt/local/sbin/saslauthd -v
saslauthd 2.1.25
authentication mechanisms: getpwent kerberos5 pam rimap

[carter.tjoseph@…]

I just edited the Portfile to change version to 2.1.26, revision to 0, nuked all of the patch files (all of which show as previously applied), and updated the rmd160/sha256 checksums. Then I upgraded. SASL now works. :) Tested with mutt-devel and svn.

[carter.tjoseph@…]

Someone suggested attaching the updated Portfile on irc

[carter.tjoseph@…]

It's apparently not as simple as a new Portfile. This break's cyrus-sasl2's binaries because upstream uses a version of libtool 1.3.5. *sobs*

I've gone through and quickly updated libtool in the port the quick and dirty way, but … it's quick and it's dirty. Basically I started with a distclean'd tree and ran glibtool --copy and did everything it told me I ought to do: AC_CONFIG_MACRO_DIR([config]) in configure.in, ACLOCAL_AMFLAGS = -I config in Makefile.am, abd adding several files to aclocal.m4. Didn't see something resembling autogen.sh/bootstrap.sh so I had to do that by hand. I did not generate one patch per file as is the custom because it'd be absolutely nuts to do it.

This "fixes" cyrus-sasl2 as far as port is concerned, but recreates the original bug this ticket is trying to address.

[carter.tjoseph@…]

Fix 2.1.26's libtool to fallback to $rpath if $LD_RUN_PATH is unset

[carter.tjoseph@…]

BOOM! A one line patch fixes the 2.1.26 build. I'm not 100% sure this is the most "correct" solution, but it is the most correct solution given the upstream choice to use LD_RUN_PATH as if it contains a single directory. Mutt still works, and so now do the included utilities such as pluginviewer.

[vallon (Justin)]

[Started looking at this last night, and just finished digging into the cause. It appears there might be a proposed patch, but I'll comment anyway]

Previously, there were /opt/local/lib/sasl2/lib*.la files generated by GNU libtool. However, those files no longer exist (any of them). I have not looked into why.

The plugin mechanism searches the plugin directory for *.la and *.plugin (strcmps around lib/dlopen.c:_sasl_load_plugins:509), but finds neither. With the *.la files, it scans them for /dlname='(.*)'/ to determine the name of the shared library. In my build, LA_SUFFIX=".la" and SO_SUFFIX=".plugin" (lib/dlopen.c).

I copied libplain.la and libsasldb.la from backup, and PLAIN/sasldb started working again.

[vallon (Justin)]

Cc Me!

[max-arnold (Max Arnold)]

Cc Me!

[pmetzger (Perry E. Metzger)]

Cc Me!

[pmetzger (Perry E. Metzger)]

Variations on this are breaking libetpan's SASL support (which comes from cyrus-sasl2) and things that depend on it in turn like claws-mail. Any thoughts on a final fix?

[post@…]

Cc Me!

[post@…]

Cc Me!

[carter.tjoseph@…]

Cc Me!

[iKarith (Joseph Carter)]

Cc Me!

[raimue (Rainer Müller)]

Cc Me!

[raimue (Rainer Müller)]

Replying to JustinVallon@…:

Previously, there were /opt/local/lib/sasl2/lib*.la files generated by GNU libtool. However, those files no longer exist (any of them). I have not looked into why.

MacPorts >= 2.2.0 removes/modifies glibtool's .la files to prevent overlinking, see #38010 for the discussion and details.

[pmetzger (Perry E. Metzger)]

Raimue: so what is the correct solution here? Is there a way to override the removal of the .la files during install?

[raimue (Rainer Müller)]

Yes, that can be changed using

destroot.delete_la_files no

in the Portfile.

I am not sure whether this would be a real solution. It is solved in different ways in other distributions. For example, ​Debian patches cyrus-sasl2 to load plugins directly by the *.so name instead of looking for the *.la files.

[pmetzger (Perry E. Metzger)]

Just adding that to the portfile doesn't seem to change the output of /opt/local/sbin/saslauthd -v to indicate (for example) cram-md5....

[post@…]

Thanks raimue, it solves my problem. Now subversion works again.

[raimue (Rainer Müller)]

Updated to cyrus-sasl2 to 2.1.26 in r112740. The test code given in the original report returns multiple mechanisms for me, marking as fixed.

[jmroot (Joshua Root)]

Are you sure it was OK to remove patch-utils_Makefile.in.diff? That change has not been applied in the new version.

[raimue (Rainer Müller)]

You are right, I restored it in r112766.

[vallon (Justin)]

In 2.1.26_4, shared libs in /opt/local/lib/sasl2 are now named lib*.plugin, and the dlopen code finds and opens them. The PLAIN and SASLDB plugins are working for me (without needing the lib*.la files).

In follow up to response #2: "saslauthd -v" output is unchanged, but I don't know either way what the correct output should be.