Bug#1075146: libauthen-sasl-xs-perl: ftbfs with GCC-14; patch ready

[Russ Allbery]

Niko Tyni <ntyni at debian.org> writes:
> On Fri, Jul 26, 2024 at 10:26:29PM +0200, Étienne Mollier wrote:

>> Control: tags -1 + patch

>> I pushed a patch[1] to salsa to proceed to targeted changes to
>> the libauthen-sasl-xs-perl, but I'm not entirely confident
>> touching a library that seems security sensitive.  I'm notably
>> feeling a bit bugged by the initial type discrepancy of a
>> variable passed to an IV.
>> 
>> I'll hold my horses a couple of days before upload, in case
>> someone is interested to have a look over the weekend.
>> 
>> [1]: https://salsa.debian.org/perl-team/modules/packages/libauthen-sasl-xs-perl/-/raw/debian/latest/debian/patches/gcc-14.patch?ref_type=heads

> Thanks for your work on this.

> The explicit casts of the callbacks look good to me FWIW.  But I also
> wonder about the pointer to integer cast in XS.xs:1886.

> If it's really the right thing to do, I suppose casting to an IV would
> be more correct than either int or long int.  But I suspect that the
> intention might be to dereference the pointer instead. FWIW I tried that
> at home and the test suite still passed, so clearly it's not covering
> these parts.

I agree.  I think the upstream code is buggy here and was incorrectly
returning the value of the pointer rather than the underlying property
value.

sasl_getprop has a unified interface for all properties of whatever type.
It sets the third argument to a pointer pointing to a const representation
of the property.  The Authen::SASL::XS API, though, is trying to return
the actual underlying value, and therefore should return whatever the
pointer points to, coerced to the appropriate type.  This looks correct
for the string properties, but for the SASL_SSF and SASL_MAXOUTBUF integer
properties, I think it's returning the value of the pointer instead and it
needs another layer of dereferencing.

The property method is undocumented and doesn't seem to be called
internally, which is probably why no one ever noticed this.

> I don't see any reverse dependencies, so removal is also an option.
> Particularly as this seems security sensitive and abandoned upstream...

The lack of dependencies is somewhat deceptive because this module is
transparently used by Authen::SASL (which is, somewhat surprisingly,
missing any relevant dependency, even at the Suggests level; that's
probably a different bug).  I believe it prefers Authen::SASL::XS if it is
installed.

The Perl implementation for Authen::SASL works fine for clients, but if
you want to write a server, you need Authen::SASL::XS if you're using any
mechanism other than the simple password ones.  See Authen::SASL::Perl:

    As for server support, only *PLAIN*, *LOGIN* and *DIGEST-MD5* are
    supported at the time of this writing.

-- 
Russ Allbery (rra at debian.org)              <https://www.eyrie.org/~eagle/>