Thanks for continued testing related to this problem. As suggested by earlier discussion, this issue is delicate, and I think what we have managed to do is to get the 'socket-wrapper' self-tests working by modifying various compiler parameters, but this makes the self-tests no longer test real-world application usage of socket-wrapper, so it is merely covering up the real problem.
One "simple" solution is to drop armhf support. That has consequences for other packages though (they have to make socket-wrapper an optional dependency, or arrange so it is not run on armhf). If we could find a way to make it easier for consumers of this package to not have to special-case armhf, I'm for this solution. I assume what you are seeing is the same problem discussed in this bug report, so it feels fine to continue discuss it here. If it is caused by something else (not entirely impossible) then a separate bug is in order. But until we have confirmation one way or another, having all armhf+32vs64bit issues in this bug report seems fine. /Simon Aron Xu <[email protected]> writes: > Hi, > > I would like to add a downstream runtime example to the time64 discussion > here. This is distinct from the original socket-wrapper build failure. > > The ocserv 1.6.0-2 autopkgtest on testing/armhf [1] installs: > > libsocket-wrapper 1.5.2-2+b2 > python3.14-minimal 3.14.10-1 > libopenconnect5 9.21-5 > > Two tests fail while setting TCP_NODELAY under > LD_PRELOAD=libsocket_wrapper.so: > > haproxy-auth, in the OpenConnect client: > Failed setsockopt(TCP_NODELAY) on TLS socket:: Operation not supported > > test-gssapi-opt-pass, in Python's http.client connection setup: > self.sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1) > OSError: [Errno 95] Operation not supported > > The latter fails before reaching the intended GSSAPI-to-password fallback > exchange. These are not the OIDC test privilege issues fixed in ocserv > 1.6.0-2; those tests pass in this run. > > I downloaded the exact armhf package versions listed above and inspected > their dynamic symbol tables with readelf. The results are: > > libsocket_wrapper.so exports: > setsockopt > getsockopt > > /usr/bin/python3.14 and libopenconnect.so.5.10.0 import: > __setsockopt64@GLIBC_2.34 > __getsockopt64@GLIBC_2.34 > > The wrapper has no exported __setsockopt64 or __getsockopt64 symbols. > Python's _socket module is built into the inspected interpreter. This points > to an interposition gap for time64-built applications. > > This seems relevant to the earlier caution in this report that passing > socket-wrapper's own tests does not necessarily establish correctness for > applications using it. It also appears related to upstream bug #15720 [4], > although that report does not explicitly discuss these socket-option > symbols. > > Would you prefer to track the missing time64 socket-option interception > here, or should this be filed as a separate runtime bug? > > Thanks, > Aron > > [1] > https://ci.debian.net/data/autopkgtest/testing/armhf/o/ocserv/77442865/log.gz > [2] https://raw.githubusercontent.com/bminor/glibc/master/socket/sys/socket.h > [3] > https://sources.debian.org/data/main/s/socket-wrapper/1.5.2-2/src/socket_wrapper.c > [4] https://bugzilla.samba.org/show_bug.cgi?id=15720 > > > _______________________________________________ > Pkg-sssd-devel mailing list > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-sssd-devel >
signature.asc
Description: PGP signature
