Netty 4.1.128 with support for lenient default line ending

[AndreKurait]

Description
Follow-up to Proposed PR #1938, which upgraded Netty from 4.1.124 → 4.1.128 to address GHSA-jq43-27x9-3v86 and GHSA-fghv-69vj-qj49.

The previous bump introduced stricter request-parsing checks in Netty 4.1.125, causing possible failures where clients use LF instead of CRLF. That change aligned behavior with the current HTTP spec but could break compatibility with some older clients.

This PR adds configuration support for lenient line-ending parsing by default, disabling strict line checks to preserve backward compatibility with legacy clients. This ensures we can continue handling replayed or proxied traffic that doesn’t fully conform to modern HTTP formatting.

Netty Reviewed CVE: GHSA-fghv-69vj-qj49 (Marked as Low)
Original Netty Issue: netty/netty#15522
Original Netty PR: netty/netty#15611

Key Changes

• Retains Netty 4.1.128 for security compliance (GHSA-jq43-27x9-3v86 and GHSA-fghv-69vj-qj49).
• Leverage's netty's built in system property flag io.netty.handler.codec.http.defaultStrictLineParsing to disable strict line parsing by default.
• Defaults to lenient mode for proxy/replayer use cases.

Note: Includes an update to the JIB building to include the JVM flags we've been applying to our existing docker builds.

Testing

Existing tests broke with the change, adding system property during test runs reverts to existing behavior shown by the tests passing

Check List

• New functionality includes testing
• Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.52%. Comparing base (ee020ba) to head (4176321).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #1942      +/-   ##
============================================
+ Coverage     78.50%   78.52%   +0.01%     
  Complexity       21       21              
============================================
  Files           599      599              
  Lines         23592    23599       +7     
  Branches       1824     1825       +1     
============================================
+ Hits          18521    18531      +10     
+ Misses         4175     4171       -4     
- Partials        896      897       +1     

Flag	Coverage Δ
gradle	76.33% <ø> (+0.02%)	⬆️
node	90.02% <ø> (+<0.01%)	⬆️
python	79.95% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[peternied]

@AndreKurait thanks for spending the time to look into this. Is there a way to do this without using jvm parameters? While its nice that we can keep the more lenient default, it creates yet another configuration path for how netty operates that seems previously unused.

[gregschohn]

Thanks for picking this up...

I agree w/ Peter & would add that for the capture proxy, this should be one of the most visible and loudest options to configure. One application of replaying traffic is to confirm that security bugs have been fixed. We wouldn't want to have a source getting attacked, and having the proxy neutralize those so that users never find out if their targets are resilient to the attacks.

I was expecting to see a command line flag for our programs - at least the proxy (I don't think that it will matter for the replayer since the replayer will generally always be contacting newer services - not legacy ones w/ CVEs). That said, with where we're going for workflows, we could also say - here's an options flag for all of our programs and here's how we route it appropriately. We DO set JVM properties from argo workflows today to override log4j properties.

Should we have any way to test both policies here?

[gregschohn]

How would a user override this setting/flip it to true? They'd have to eschew this file or edit it, right? That's a rough UX.

[gregschohn]

Same question as before - how does jib wire up the java properties - are they env variables? How would a user override this?