Upgrade io.netty:netty-codec-http

[ALRubinger]

Patches sec vuln.

[worstell]

@ALRubinger we pull this dependency in through io.grpc:grpc-core, which it appears we're already on the latest version of. we could depend explicitly on a later version of io.netty:netty-codec-http but it seems like diverging these dependencies introduces other risks - do you have a perspective/preference here?

[ALRubinger]

@worstell Yep typically in these instances I'll force an upgrade of the transitive dependency and run it through the testsuite. If ✅, I assume all is good - but of course this depends on a testsuite w/ sufficient coverage.

[ALRubinger]

Note that in this instance I'd expect the risk of upgrade to be small; it's a patch update which shouldn't remove any deprecated API calls and it should be designed to be forward-compatible. Testsuites at runtime are the only way to know for sure :)

[alecthomas]

Can you link to the CVE for this?

[alecthomas]

This seems like it might be relevant issue, and the maintainers state that gRPC is not impacted.

[ALRubinger]

Can you link to the CVE for this?

https://nvd.nist.gov/vuln/detail/CVE-2024-29025

[alecthomas]

Ah different to the one above.

[ALRubinger]

Yup and I follow where you're going with this - determining if you're using any vulnerable code paths. My recommendation is to try the upgrade regardless, because any consumers of FTL are going to have their vuln scanners light up even if we legitimately "ignore" this for us. Ideally io.grpc:grpc-core would address this (you can even file an issue with them requesting it!) so that us and every other downstream consumer of it gets this fixed at the root where it was introduced.

[ALRubinger]

Ha, Sonatype does threat scanning too and sent this report:

So ideally our fixing it up or getting the root to do it helps. We can ignore in FOSSA but it'd still flag in Sonatype :)

[stuartwdouglas]

No longer relevant after the JVM rewrite.