[pkg-uWSGI-devel] Bug#996879: uwsgi-core: Dependency to libjansson causes symbol conflicts in applications using json-c

[Maxime Besson]

Package: uwsgi-core
Version: 2.0.20-1
Severity: normal

Dear Maintainer,

I am encountering an issue when trying to run a PSGI application under
UWSGI.

My application depends on libcrypt-u2f-server-perl, which in turn
depends on libu2f-server, which is build again libjson-c.

libjson-c has known symbol conflicts with libjansson 
see https://github.com/json-c/json-c/issues/621

Because of those symbol conflicts, my application works under Apache,
Plackup, Starman, and just about any PSGI server, but not UWSGI. 

Here is a very simple test case:

	use Crypt::U2F::Server::Simple;
	use MIME::Base64 qw(decode_base64url);

	my $c = Crypt::U2F::Server::Simple->new(
	    appId     => 'http://example.com',
	    origin    => 'http://example.com',
	    keyHandle => 'xqrFVqvymzLlrdh9HyBSC5vy_3feWzh2gge'
	      . 'Jpx03_5D8t5w1LpcPcSirvMNnOgCLRyjkjnMlYDwh6I8QdGfPpA',
	    publicKey => decode_base64url(
		    'BM4M55Vu4ZriaFrk9J273SVb2PUEFNKU-q2W-lt'
		  . 'rUT2OlnXncwlTYw1V0pDXALP36qbaFcwejqfSsPVXL0FL0rc'
	    ),
	);

	my $app = sub {
	    return [
		200,
		[ 'Content-Type' => 'text/plain' ],
		[ $c->authenticationChallenge ]
	    ];
	  }


This test works with plackup (libplack-perl):

	plackup test.psgi
	curl http://localhost:5000 | json_pp

	# As expected:
	{
	   "appId" : "http://example.com",
	   "challenge" : "z_HKSxGvUuefsJOEFRMpAHbWaFdyOiy6DtbdBaKmmuU",
	   "keyHandle" : "xqrFVqvymzLlrdh9HyBSC5vy_3feWzh2ggeJpx03_5D8t5w1LpcPcSirvMNnOgCLRyjkjnMlYDwh6I8QdGfPpA",
	   "version" : "U2F_V2"
	}



But not with uwsgi (uwsgi-plugin-psgi):

	uwsgi --http-socket 127.0.0.1:5000  --plugins psgi --psgi test-u2f.psgi
	curl http://localhost:5000 | json_pp

	# incorrect
	{
	   "appId" : null,
	   "challenge" : null,
	   "keyHandle" : null,
	   "version" : null
	}


The reason is the json_object_get symbol used by libu2f-server
conflicting. As indicated by LD_DEBUG=bindings:

Plackup case (working):
      4604:     binding file /lib/x86_64-linux-gnu/libu2f-server.so.0 [0] to /lib/x86_64-linux-gnu/libjson-c.so.5 [0]: normal symbol `json_object_get' [JSONC_0.14]

UWSGI case (failing): 
      4601:     binding file /lib/x86_64-linux-gnu/libu2f-server.so.0 [0] to /lib/x86_64-linux-gnu/libjansson.so.4 [0]: normal symbol `json_object_get' [JSONC_0.14]


I am able to work around this issue with LD_PRELOAD, but this does not
feel like a long term solution to me.

I'm not very familiar with symbol resolution rules, but the GitHub
discussion above suggests that building libjansson with versionned
symbols would fix this issue. I'm however not entirely sure what the
correct course of action is:

* Should I also report this issue to the libjansson Debian maintainers?

* Is it possible for Debian to build uwsgi against libyajl instead? This
  seems like a possibility in UWSGI 2.0, and libyajl does not seem to
  have symbol conflicts 


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/6 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages uwsgi-core depends on:
ii  libc6        2.32-4
ii  libcap2      1:2.44-1
ii  libcrypt1    1:4.4.25-2
ii  libjansson4  2.13.1-1.1
ii  libpam0g     1.4.0-10
ii  libpcre3     2:8.39-13
ii  libssl1.1    1.1.1l-1
ii  libsystemd0  249.5-1
ii  libuuid1     2.37.2-3
ii  libxml2      2.9.12+dfsg-5
ii  libyaml-0-2  0.2.2-1
ii  libzmq5      4.3.4-1
ii  zlib1g       1:1.2.11.dfsg-2

uwsgi-core recommends no packages.

Versions of packages uwsgi-core suggests:
pn  nginx-full | cherokee | libapache2-mod-proxy-uwsgi | libapache2-mod  <none>
pn  uwsgi-dev                                                            <none>
pn  uwsgi-extra                                                          <none>
pn  uwsgi-plugins-all                                                    <none>

-- no debconf information