Subversion sasl authentication fails with openssl3.1

[Fischer, Michael]

I have many repositories configured for sasl authentication.  The svn client for Mac osx, built using MacPorts, recently stopped working.  I first reported the problem to the MacPorts bug list but have been advised to report it to the subversion developers.  (See below.)

Here's the error I get when trying to update a working directory.

> svn update
Updating '.':
svn: E170013: Unable to connect to a repository at URL 'svn://ohia.cs.yale.edu/cs414-2022f'
svn: E170001: SASL authentication error: SASL(-1): generic failure: internal error: failed to init cipher 'rc4'

The problem seems to be that Sasl3.1 is not upwards compatible with sasl2.   This causes the Macports build of svn to fail when attempting to log into a server configured to use_sasl.  A workaround is to rebuild the openssl3 port with the command

sudo port upgrade --enforce-variants openssl3 +legacy

I reported this as MacPorts bug #67931.  A comment by ryandesign said,

 A port "can't" depend on a variant of another port (see #126). It can use
 the active_variants 1.1 portgroup, but that requires manual intervention
 from the user, and prevents the buildbot from automatically creating
 binary archives of the port.

 Have you reported this problem to the developers of Subversion? If not,
 please do, and put the URL of the report here.

I am attempting to do so here.  Apparently the email is required before I can make a bug report.

Please let me know how to proceed with the bug report.

Sincerely,
--Michael Fischer

[Daniel Sahlberg]

Den sön 20 aug. 2023 kl 17:14 skrev Fischer, Michael <michael...@yale.edu>:

I have many repositories configured for sasl authentication.  The svn client for Mac osx, built using MacPorts, recently stopped working.  I first reported the problem to the MacPorts bug list but have been advised to report it to the subversion developers.  (See below.)

Here's the error I get when trying to update a working directory.

> svn update
Updating '.':
svn: E170013: Unable to connect to a repository at URL 'svn://ohia.cs.yale.edu/cs414-2022f'
svn: E170001: SASL authentication error: SASL(-1): generic failure: internal error: failed to init cipher 'rc4'

What is the version of Subversion on the above server? What version of Sasl and OpenSSL?

The problem seems to be that Sasl3.1 is not upwards compatible with sasl2.  

Are you confusing Sasl with OpenSSL here? I believe Sasl is only on version 2.1 while OpenSSL recently released versions 3.0 and 3.1 (there never was an OpenSSL 2.x).

This causes the Macports build of svn to fail when attempting to log into a server configured to use_sasl.  A workaround is to rebuild the openssl3 port with the command

sudo port upgrade --enforce-variants openssl3 +legacy

I'm guessing, based on the "+legacy" argument, that the server you try to connect to is using RC4 and since this is deprecated in OpenSSL 3 (see https://www.openssl.org/docs/man3.0/man7/OSSL_PROVIDER-legacy.html) you are unable to connect.

If this assumption is correct, then this is neither a bug in Subversion, nor in Sasl or OpenSSL. Rather it is a case of mismatching configuration and software versions between the server and the client. Updating the server to support newer chiphers should probably resolve the situation.

I reported this as MacPorts bug #67931.  A comment by ryandesign said,

 A port "can't" depend on a variant of another port (see #126). It can use
 the active_variants 1.1 portgroup, but that requires manual intervention
 from the user, and prevents the buildbot from automatically creating
 binary archives of the port.

 Have you reported this problem to the developers of Subversion? If not,
 please do, and put the URL of the report here.

I am attempting to do so here.  Apparently the email is required before I can make a bug report.

Please let me know how to proceed with the bug report.

You've done absolutely correct in sending an e-mail here. I assume you have already seen the guidance on the website (https://subversion.apache.org/docs/community-guide/issues.html) on why we don't want anything added to the issue tracker before it has been accepted as a bug on the mailing list.

Kind regards,

Daniel Sahlberg

[Fischer, Michael]

Dear Daniel,

Thank you for the careful reply.  Some answers are interspersed below.

On 8/22/23 7:40 AM, Daniel Sahlberg wrote:

Den sön 20 aug. 2023 kl 17:14 skrev Fischer, Michael <michael...@yale.edu>:

I have many repositories configured for sasl authentication.  The svn client for Mac osx, built using MacPorts, recently stopped working.  I first reported the problem to the MacPorts bug list but have been advised to report it to the subversion developers.  (See below.)

Here's the error I get when trying to update a working directory.

> svn update
Updating '.':
svn: E170013: Unable to connect to a repository at URL 'svn://ohia.cs.yale.edu/cs414-2022f'
svn: E170001: SASL authentication error: SASL(-1): generic failure: internal error: failed to init cipher 'rc4'

What is the version of Subversion on the above server? What version of Sasl and OpenSSL?

subversion:  1.14.2
cyrus-sasl: 2.1.28
GNU sasl library (libgsasl): 1.10.0
OpenSSL: 3.09; also 1.1.1q

The server is running Fedora 38 linux.  I don't know which sasl library the server is actually linked to, but the server works find with all clients except for the MacPorts one.

The problem seems to be that Sasl3.1 is not upwards compatible with sasl2.  

Are you confusing Sasl with OpenSSL here? I believe Sasl is only on version 2.1 while OpenSSL recently released versions 3.0 and 3.1 (there never was an OpenSSL 2.x).

Yes, I'm afraid so.  😅
I believe MacPorts is linking to openssl3, which is why my workaround (below) fixes the problem.

This causes the Macports build of svn to fail when attempting to log into a server configured to use_sasl.  A workaround is to rebuild the openssl3 port with the command

sudo port upgrade --enforce-variants openssl3 +legacy

I'm guessing, based on the "+legacy" argument, that the server you try to connect to is using RC4 and since this is deprecated in OpenSSL 3 (see https://www.openssl.org/docs/man3.0/man7/OSSL_PROVIDER-legacy.html) you are unable to connect.

If this assumption is correct, then this is neither a bug in Subversion, nor in Sasl or OpenSSL. Rather it is a case of mismatching configuration and software versions between the server and the client. Updating the server to support newer chiphers should probably resolve the situation.

I think you are correct in your analysis of why the MacPorts client fails to connect without the "+legacy" argument.

I reported this as MacPorts bug #67931.  A comment by ryandesign said,

 A port "can't" depend on a variant of another port (see #126). It can use
 the active_variants 1.1 portgroup, but that requires manual intervention
 from the user, and prevents the buildbot from automatically creating
 binary archives of the port.

 Have you reported this problem to the developers of Subversion? If not,
 please do, and put the URL of the report here.

I am attempting to do so here.  Apparently the email is required before I can make a bug report.

Please let me know how to proceed with the bug report.

You've done absolutely correct in sending an e-mail here. I assume you have already seen the guidance on the website (https://subversion.apache.org/docs/community-guide/issues.html) on why we don't want anything added to the issue tracker before it has been accepted as a bug on the mailing list.

Kind regards,

Daniel Sahlberg

You've convinced me that this is not a subversion problem but rather one of attempting to build it against the openssl3 library rather than against the cyrus-sasl2 library.  This would seem to be a problem with the MacPorts build script attempting to use the wrong library for subversion.  MacPorts does know about cyrus-sasl2 (and in fact it is installed on my node).  Unfortunately, I do not know enough about how MacPorts works to suggest the fix, but I think it is clear now what needs to be done.

Thank you once again for your help and for the effort you put into addressing my concerns.

Best regards,
--Mike

-- 
===============================================
| Michael Fischer <michael...@yale.edu>  |
| Professor of Computer Science               |
===============================================

[Daniel Sahlberg]

Den sön 27 aug. 2023 kl 22:28 skrev Fischer, Michael <michael...@yale.edu>:

Dear Daniel,

Thank you for the careful reply.  Some answers are interspersed below.

On 8/22/23 7:40 AM, Daniel Sahlberg wrote:

Den sön 20 aug. 2023 kl 17:14 skrev Fischer, Michael <michael...@yale.edu>:

I have many repositories configured for sasl authentication.  The svn client for Mac osx, built using MacPorts, recently stopped working.  I first reported the problem to the MacPorts bug list but have been advised to report it to the subversion developers.  (See below.)

Here's the error I get when trying to update a working directory.

> svn update
Updating '.':
svn: E170013: Unable to connect to a repository at URL 'svn://ohia.cs.yale.edu/cs414-2022f'
svn: E170001: SASL authentication error: SASL(-1): generic failure: internal error: failed to init cipher 'rc4'

What is the version of Subversion on the above server? What version of Sasl and OpenSSL?

subversion:  1.14.2
cyrus-sasl: 2.1.28
GNU sasl library (libgsasl): 1.10.0
OpenSSL: 3.09; also 1.1.1q

The server is running Fedora 38 linux.  I don't know which sasl library the server is actually linked to, but the server works find with all clients except for the MacPorts one.

So it seems you have recent versions of all the libraries, in particular OpenSSL. Then there should be newer ciphers available on the server side.

The problem seems to be that Sasl3.1 is not upwards compatible with sasl2.  

Are you confusing Sasl with OpenSSL here? I believe Sasl is only on version 2.1 while OpenSSL recently released versions 3.0 and 3.1 (there never was an OpenSSL 2.x).

Yes, I'm afraid so.  😅
I believe MacPorts is linking to openssl3, which is why my workaround (below) fixes the problem.

This causes the Macports build of svn to fail when attempting to log into a server configured to use_sasl.  A workaround is to rebuild the openssl3 port with the command

sudo port upgrade --enforce-variants openssl3 +legacy

I'm guessing, based on the "+legacy" argument, that the server you try to connect to is using RC4 and since this is deprecated in OpenSSL 3 (see https://www.openssl.org/docs/man3.0/man7/OSSL_PROVIDER-legacy.html) you are unable to connect.

If this assumption is correct, then this is neither a bug in Subversion, nor in Sasl or OpenSSL. Rather it is a case of mismatching configuration and software versions between the server and the client. Updating the server to support newer chiphers should probably resolve the situation.

I think you are correct in your analysis of why the MacPorts client fails to connect without the "+legacy" argument.

I reported this as MacPorts bug #67931.  A comment by ryandesign said,

 A port "can't" depend on a variant of another port (see #126). It can use
 the active_variants 1.1 portgroup, but that requires manual intervention
 from the user, and prevents the buildbot from automatically creating
 binary archives of the port.

 Have you reported this problem to the developers of Subversion? If not,
 please do, and put the URL of the report here.

I am attempting to do so here.  Apparently the email is required before I can make a bug report.

Please let me know how to proceed with the bug report.

You've done absolutely correct in sending an e-mail here. I assume you have already seen the guidance on the website (https://subversion.apache.org/docs/community-guide/issues.html) on why we don't want anything added to the issue tracker before it has been accepted as a bug on the mailing list.

Kind regards,

Daniel Sahlberg

You've convinced me that this is not a subversion problem but rather one of attempting to build it against the openssl3 library rather than against the cyrus-sasl2 library.  This would seem to be a problem with the MacPorts build script attempting to use the wrong library for subversion.  MacPorts does know about cyrus-sasl2 (and in fact it is installed on my node).  Unfortunately, I do not know enough about how MacPorts works to suggest the fix, but I think it is clear now what needs to be done.

I think you are mixing up the functions of openssl and cyrus-sasl.

OpenSSL provide encryption while Sasl provide authentication (over an encrypted channel provided by OpenSSL). So there is no "built against X rather than against Y", you need both if you want encrypted authentication.

I would look at the server configuration and check the enabled ciphers, comparing with the your Mac and make sure there is at least one common cipher. Since both computers have OpenSSL 3, I'm guessing there is a configuration disabling the newer ciphers on at least one of the machines.

Kind regards,

Daniel