Backport jansson 2.14 to jammy from kinetic

[Hon Ming Hui]

[Impact]

 * jansson 2.13 has a symbol conflict with json-c library.(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966398 & https://github.com/akheron/jansson/issues/523). So an application is linking to both jansson and json-c, there will be 50% of chance that it reference to a wrong symbol, which need to SIGSEGV

 * In order to fix this issue, both json-c and jansson need to add symbol versioning. jansson library added this in 2.14(not yet in jammy) while json-c added in 0.15 (already in jammy)

 * And the affecting application should rebuild against the latest json-c and jansson libraries in order to have the correct symbol linked

[Test Plan]
 * jansson is basically available in all of the cpu architecture. So the 1st test will be building in a personal ppa and see if it can be built in every platform.

 * Some of the library mentioned in the upstream issue checker can be used to verify the fix. But since I am working on a package in a private project which is hitting the issue. I am testing with my private packages(which is on arm64 platform)

 * Looking into the packages that depends on jansson. There are a large number of packages including network-manager. So I tried to pick 2 packages on my desktop to verify if there is regression
1. network-manager, since it is widely used in Ubuntu
2. emacs, since jansson is a JSON parser, so I pick an application that I can do some operation on JSON(e.g. formatting in emacs)

[Where problems could occur]

 * jansson upstream is well maintained and there is also CI test job. jansson 2.14 is also packaged and maintained by Debian community. It is available for a few months already. So in general, the risk of regression is low in that perspective.

 * When looking into the changes between 2.13 and 2.14. There are changes in test coverage and some tidy up on the build scripts. The changes look safe but certainly there can be mistake and behaviour changes. But jansson do not depends on other packages and so this kind of regression on build script should be easily caught by test builds in different architecture and a simple integration test with package that depends on jansson.

 * On the library itself, it added symbol versioning to fix the bug and at the same time there are 3 new API added in 2.14. But these changes should be backward compatible. But since there is new symbols added, there can be new symbol conflict with other library but the impact should just be similar to the original bug that it is already conflict with json-c. There are alos misc fixes in like snprintf checking which looks to be safe.

[Hon Ming Hui (hm-hui)]

debdiff with kinetic which shows it is a simple rebuild in jammy

[Hon Ming Hui (hm-hui)]

debdiff with jammy which shows the diff from 2.13 to 2.14

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "jansson_kinetic.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Hon Ming Hui (hm-hui)]

Testing I did
1. I have built jansson 2.14 on all architecture in my personal PPA. https://launchpad.net/~hm-hui/+archive/ubuntu/sru-all/+packages

2. Verified the bug with a private package on arm64 platform on jammy and the bug gone after the package is rebuilt with jansson 2.14 in jammy.

3. Upgrade jansson to 2.14 on an amd64 desktop and performed some basic functions with network-manager without any issue. Also there aren't any interruption during upgrade/downgrade of jansson library

4. Use emacs to do some json file formatting and editing with jansson 2.14 installed. No issues discovered.

[Loïc Minier (lool)]

I reviewed the diff between 2.14 in kinetic and this upload (just changelog), and I carefully reviewed the 2.13 + Ubuntu changes to 2.14 + Debian changes diff again; outside of some autotools noise, the changes were carefully adding symbol versioning, a few symbols for new functions, and on the packaging side bumping the generated dependencies – +1, uploaded to -proposed (waiting for SRU team to review)

[Timo Aaltonen (tjaalton)]

somehow the diff on the sru queue only shows the changelog diff and nothing else

[Robie Basak (racb)]

Is there a specific user story that you're looking to fix here? Eg. crash reports in specific apps? What are you planning to rebuild to use the newly versioned symbols? If possible, I'd like to see these verified in proposed at the same time.

On the specific fix, there is quite a bit of noise here. Did you consider cherry-picking the symbol versioning change only? I think this should be safe and not an ABI break, but I'm not that familiar in this area. Is there something I'm missing - why is a backport required instead?

[Loïc Minier (lool)]

@Timo/SRU team: I think the debdiff you're seeing is between kinetic and jammy, and since it's essential a backport, it would indeed be trivially small.

The debdiff between latest jammy and this SRU corresponds to the new upstream release, and that's the part I've carefully reviewed with Hon Ming and that will bring the relevant fix.

[Hon Ming Hui (hm-hui)]

The package that will experience the symbol conflict and crash is called vvas. We package it for the Xilinx partner project. VVAS is a major video analytic component and it linked with both jansson and json-c . I have some test packages built in my own ppa https://launchpad.net/~hm-hui/+archive/ubuntu/xilinx/+packages

I will also rebuild and test the jansson backport when it is landed to proposed

[Robie Basak (racb)]

OK, so to make sure I understand: nothing in the archive is directly affected by this bug. But if a user builds their own thing with both jansson and json-c, then the symbol conflict arises.

I think this is still fine in principle to SRU, but I would like your out-of-archive component (vvas) tested against the proposed pocket as part of the SRU verification please, and your confirmation that the problem is fixed, before we release it.

Separately, above I asked:

> On the specific fix, there is quite a bit of noise here. Did you consider cherry-picking the symbol versioning change only? I think this should be safe and not an ABI break, but I'm not that familiar in this area. Is there something I'm missing - why is a backport required instead?

I think this question is still outstanding. Why can we not make the minimal necessary changes?

[Loïc Minier (lool)]

Thanks for the review Robie!

Agreed that verification makes sense with a program built against both libraries before and after this fix

Why backport 2.14 rather than cherry-pick the corresponding change? It would be feasible to cherry-pick just the change to add symbol versioning (you can see it here: https://github.com/akheron/jansson/pull/540/files), but IMO:
1) we'd have to autoreconf in a patch or at build-time, which would be a similar amount of noise in build files (the patch touches configure.ac, Makefile.am, CMakeLists.txt)

2) I think it's good to land the actual version number bump along with this kind of change: it reflects through the version number that we have this fix in (I know the proper way to check if a feature is there is to test for the feature and not the upstream version), in particular when it's about adding symbol versioning

3) the other minor changes in the new upstream release all seemed conservative fixes addressing simple issues that seemed LTS worthy (some even seemed to border on improving the security of some functions)

4) taking the backport as a whole seemed simplest and less risky than splitting things up

Hope you see the same pros and cons and why we went this way

[Robie Basak (racb)]

> 3) the other minor changes in the new upstream release all seemed conservative fixes addressing simple issues that seemed LTS worthy (some even seemed to border on improving the security of some functions)

The catch is that these changes then need individual review and consideration as to whether they are acceptable, including by the SRU team. The default is that we expect each change to be individually tested, too, unless the upstream meets the quality criteria detailed at https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases. Is this the case here?

[Robie Basak (racb)]

An upload of jansson to jammy-proposed has been rejected from the upload queue for the following reason: "Questions in https://bugs.launchpad.net/ubuntu/+source/jansson/+bug/1987678 remain unresolved after many months".