[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RFC: Fixing golang-github-tidwall-gjson's RC bugginess for bookworm


As usual, with my crowdsec maintainer hat, I'm interested in keeping it
in testing, and the next problem is golang-github-tidwall-gjson's
autoremoval due to its security bugs (cc'd).

Currently, we have a 1.6.7 version, those bugs are supposed to be fixed
in 1.9.x, and upstream is at 1.14.4…

This library is about parsing JSON, is basically one big go file (along
with another one for the tests), and I'm not exactly sure what the best
way to go would be.

Since that's about parsing things, I suppose it wouldn't be trivial to
backport the security fixes from 1.9.2 and 1.9.3 without understanding
how parsing works, and why it was buggy in 1.6.7. Shipping the latest
1.9.x would probably be safer. But then, if we're going to have a bump
in upstream releases, maybe considering the latest would make most
sense? We would get those fixes, possible other ones, and that would
minimize the delta whenever other security fixes come up?

The reverse dependencies are quite limited:

1. according to dak:

    Checking reverse dependencies...
    # Broken Depends:
    golang-github-appleboy-gin-jwt: golang-github-appleboy-gin-jwt-dev
    golang-github-tidwall-buntdb: golang-github-tidwall-buntdb-dev
    golang-github-tidwall-grect: golang-github-tidwall-grect-dev

    # Broken Build-Depends:
    g10k: golang-github-tidwall-gjson-dev
    golang-github-appleboy-gin-jwt: golang-github-tidwall-gjson-dev
    golang-github-tidwall-buntdb: golang-github-tidwall-gjson-dev
    golang-github-tidwall-grect: golang-github-tidwall-gjson-dev
    wuzz: golang-github-tidwall-gjson-dev

(crowdsec appears in the picture via golang-github-appleboy-gin-jwt)

2. according to ratt, a straightforward update to 1.14.4 would seem
   rather reasonable:

    (unstable-amd64-crowdsec)kibi@genova:~/work/clients/crowdsec/git/salsa$ ratt -dist sid -sbuild_dist sid golang-github-tidwall-gjson_1.14.4-1_amd64.changes 
    2023/03/04 22:57:32 Loading changes file "golang-github-tidwall-gjson_1.14.4-1_amd64.changes"
    2023/03/04 22:57:32  - 1 binary packages: golang-github-tidwall-gjson-dev
    2023/03/04 22:57:32 Corresponding .debs (will be injected when building):
    2023/03/04 22:57:32     golang-github-tidwall-gjson-dev_1.14.4-1_all.deb
    2023/03/04 22:57:32 Figuring out reverse build dependencies using dose-ceve(1). This might take a while
    2023/03/04 22:57:51 Building package 1 of 10: crowdsec-firewall-bouncer 
    2023/03/04 22:58:54 Building package 2 of 10: garagemq 
    2023/03/04 22:59:59 Building package 3 of 10: crowdsec 
    2023/03/04 23:02:04 Building package 4 of 10: wuzz 
    2023/03/04 23:02:41 Building package 5 of 10: golang-github-tidwall-buntdb 
    2023/03/04 23:03:16 Building package 6 of 10: golang-github-tidwall-grect 
    2023/03/04 23:03:46 Building package 7 of 10: g10k 
    2023/03/04 23:04:21 Building package 8 of 10: crowdsec-custom-bouncer 
    2023/03/04 23:05:21 Building package 9 of 10: golang-github-appleboy-gin-jwt 
    2023/03/04 23:06:01 Building package 10 of 10: golang-github-crowdsecurity-go-cs-bouncer 
    2023/03/04 23:06:56 Build results:
    2023/03/04 23:06:56 PASSED: crowdsec
    2023/03/04 23:06:56 PASSED: wuzz
    2023/03/04 23:06:56 PASSED: golang-github-tidwall-buntdb
    2023/03/04 23:06:56 PASSED: golang-github-tidwall-grect
    2023/03/04 23:06:56 PASSED: golang-github-crowdsecurity-go-cs-bouncer
    2023/03/04 23:06:56 PASSED: crowdsec-firewall-bouncer
    2023/03/04 23:06:56 PASSED: garagemq
    2023/03/04 23:06:56 PASSED: g10k
    2023/03/04 23:06:56 PASSED: crowdsec-custom-bouncer
    2023/03/04 23:06:56 PASSED: golang-github-appleboy-gin-jwt

My initial plan would be to upload this 1.14.4-1 to experimental,
leaving space (version-wise) in unstable in case someone pushes for an
1.6.7 update, or something 1.9.x-based.

I think (but I'm not sure) uploading to experimental would trigger
autopkgtest in reverse dependencies, which should tell us more about
possible fallouts from this update (as ratt running locally only tests
builds on amd64). If that's indeed the case, this would mean being a
little more reassured regarding proposing this update for unstable, then
have it considered for testing? In any case, I think filing an unblock
request before any upload to unstable would make sense, asking for
pre-approval for whatever we end up considering as the target for

TL;DR, current plan:
 1. upload 1.14.4-1 to experimental;
 2. watch for fallouts;
 3. decide what to consider for unstable and put the release team in the

And of course, I'm happy to sign up to deal with any side effects that
might appear in the 10 reverse dependencies listed above…

Comments, yay, nay, alternative takes, etc. are welcome!

Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Attachment: signature.asc
Description: PGP signature

Reply to: