Hi,
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
bookworm.
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
loop.
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!
Cheers,
--
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
Attachment:
signature.asc
Description: PGP signature