FS#76761 - [libsasl] [subversion] svn commit segfaults with libsasl 2.1.28-3

Attached to Project: Arch Linux
Opened by Drew Holzworth (hol430) - Wednesday, 07 December 2022, 00:50 GMT
Last edited by David Runge (dvzrv) - Saturday, 02 September 2023, 13:28 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To David Runge (dvzrv)
Levente Polyak (anthraxx)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: Attempting to `svn commit` fails with segmentation fault when libsasl 2.1.28-3 is installed. Downgrading libsasl to 2.1.28-1 causes the command to run successfully. Changing installed versions of svn makes no difference. I can commit successfully to the same repo using the same version of svn (1.14.2) from another computer (MacOS) with no problems.

I have attached to this issue a stacktrace of the svn process at time of failure.

This problem started occurring after I upgraded several packages (including libsasl) via `pacman -Syu`. Prior to this upgrade, I was able to commit with impunity.


I'm unsure what additional info would be available and useful. I don't know what logging options are available for libsasl/openssl and I don't think I can increase svn's verbosity for a commit. However I'm happy to run any tests as needed.

I also apologise if this is the wrong place to report the issue -- I'm not sure if this is a packaging problem or an upstream bug (or some kind of local mis-configuration on my part).

Package Versions:

libsasl 2.1.28-3
subversion 1.14.2-1
openssl 3.0.7-2


Steps to reproduce:

```
$ svn checkout -q $repo repo
$ cd repo
$ touch file
$ svn commit file -m "test commit"
Segmentation fault (core dumped)
```

   svn.trace (2.6 KiB)
This task depends upon

Closed by  David Runge (dvzrv)
Saturday, 02 September 2023, 13:28 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed with libsasl 2.1.28-4
Comment by Toolybird (Toolybird) - Wednesday, 07 December 2022, 06:28 GMT
The trace mentions "dec_rc4". RC4 algorithm is no longer supported by openssl3 unless "legacy" providers [1] are enabled. We've seen similar reports for other apps when openssl3 first landed in Arch. svn is used internally for Arch pkg maintenance and it seems to work there. cyrus-sasl should not be crashing like this so I suppose it's an upstream issue. Possibly related [2]?

[1] https://www.openssl.org/docs/man3.0/man7/OSSL_PROVIDER-legacy.html
[2] https://github.com/cyrusimap/cyrus-sasl/issues/665
Comment by Drew Holzworth (hol430) - Thursday, 08 December 2022, 05:09 GMT
Thanks for pointing me in the right direction. I've filed an upstream bug report [1], and will wait and see what the response is.

Do you know if you're using sasl auth on your Arch pkg svn server? If not, that will be why it's working for you. I uploaded a full repro script to [1], and if I disable sasl authentication on the svn server, then I have no problems at all.

[1] https://github.com/cyrusimap/cyrus-sasl/issues/751
Comment by loqs (loqs) - Sunday, 11 December 2022, 15:18 GMT
@hol340 please try building libsasl and if needed cyrus-sasl with the attached diffs applied. The first three patches have been applied by upstream, the final two are the last two patches from [1].

[1] https://github.com/cyrusimap/cyrus-sasl/pull/668
   PKGBUILD.libsasl.diff (3.6 KiB)
   PKGBUILD.cyrus-sasl.diff (4 KiB)
Comment by Drew Holzworth (hol430) - Sunday, 11 December 2022, 23:34 GMT
Thanks for the follow-up. Yes, those patches fix the problem for me and svn (client and server) are now happily working with the patched libsasl. I actually don't have cyrus-sasl installed, so I'm unsure if it was similarly broken; however the patch seems sensible/equivalent to my eye, and I can successfully build/install cyrus-sasl with that patch.
Comment by loqs (loqs) - Tuesday, 17 January 2023, 19:29 GMT
@hol430 upstream intends to remove RC4 support with cyrus-sasl 2.2.0 [1]. Could you change whatever currently requires RC4 to another protocol?

[1] https://github.com/cyrusimap/cyrus-sasl/issues/751#issuecomment-1352087781
Comment by Drew Holzworth (hol430) - Thursday, 19 January 2023, 04:24 GMT
Yeah, in the short term I will continue using my patched libsasl. In the longer term, I need to work out what the problem was; if the server I'm using requires rc4, then I will follow up with the admin of our svn server and see if we can get the server patched. My hope is that the problem was ultimately fixed by upstream commit [1], and that if sasl is able to gracefully handle an init failure, or if that protocol is unavailable in the first place, then it will be able to negotiate with the server to use a different protocol. I just need to find time to test that theory by tweaking the set of patches I'm applying in the PKGBUILD.

[1] https://github.com/cyrusimap/cyrus-sasl/commit/887dbc0435056ec58ee48c4d803f110ade1e4c39
Comment by loqs (loqs) - Sunday, 29 January 2023, 00:30 GMT
Can you confirm the issue is fixed in libsasl 2.1.28-4?
Comment by Drew Holzworth (hol430) - Wednesday, 08 February 2023, 03:16 GMT
Yep, I can commit successfully with libsasl 2.1.28-4. So problem solved for me, at least until upstream drops support for rc4.

Loading...