Skip to content

fix: Enforce baggage limits on the Jaeger extract path - #2299

Open
serhiy-bzhezytskyy wants to merge 3 commits into
open-telemetry:mainfrom
serhiy-bzhezytskyy:fix/jaeger-baggage-limits
Open

fix: Enforce baggage limits on the Jaeger extract path#2299
serhiy-bzhezytskyy wants to merge 3 commits into
open-telemetry:mainfrom
serhiy-bzhezytskyy:fix/jaeger-baggage-limits

Conversation

@serhiy-bzhezytskyy

Copy link
Copy Markdown

The Jaeger propagator extracts every uberctx- header into baggage with no bound: context_with_extracted_baggage walks all carrier keys and sets each one, so an inbound carrier decides how much baggage enters the context.

The Jaeger format defines no limits, so this borrows the W3C Baggage spec limits — 180 entries, 4096 bytes per entry, 8192 bytes total, byte-denominated — dropping members once a limit is reached and keeping the earlier ones. opentelemetry-java caps its own Jaeger propagator the same way and for the same reason (CVE-2026-45292); the W3C propagator in this repo is being brought to parity in #2298.

Adds four extract tests: entry count, per-entry bytes, per-entry bytes measured in bytes rather than characters, and the total-bytes cap. Each fails without the change.

Assisted-By: Claude Fable 5

The Jaeger propagator extracts every uberctx- header into baggage with
no bound. The Jaeger format defines no limits, so borrow the W3C
Baggage spec limits (180 entries / 4096 bytes per entry / 8192 bytes
total, byte-denominated): over-limit members are dropped once a limit
is reached and the earlier ones are kept. opentelemetry-java caps its
Jaeger propagator the same way, for the same reason (CVE-2026-45292).

Adds four extract tests (entry count, per-entry bytes, byte-vs-char,
total bytes); each fails without the change.

Assisted-By: Claude Fable 5

@simi simi left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure we need all those comments

Keep only the byte-vs-character note, which is not obvious from the
code; the rationale for the limit values lives in the PR description.

Assisted-By: Claude Fable 5
@serhiy-bzhezytskyy

Copy link
Copy Markdown
Author

Thanks — dropped the explanatory comments and kept one line where the byte-vs-character distinction is not obvious from the code. @simi

baggage_key = carrier_key.start_with?(BAGGAGE_KEY_PREFIX) && carrier_key[BAGGAGE_KEY_PREFIX.length..]
next unless baggage_key

raw_value = getter.get(carrier, carrier_key)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add next unless raw_value to ignore the case when raw_value=nil?
This can also prevent the undefined method 'bytesize' issue when raw_value is nil

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, you're right. Fixed and covered it with a test.

Rubocop then hit 8/7 on Metrics/CyclomaticComplexity and 101/100 on Metrics/ClassLength, so the limit check moved into within_baggage_limits? and the private_constant list is reflowed. bundle exec rake is green.

getter.get returns nil for a carrier key whose value is nil, so the byte
accounting raised NoMethodError before any limit was applied. Guard on the
value and cover it with a test that fails without the guard.

The extra branch tripped Metrics/CyclomaticComplexity (8/7), and extracting
the limit check tripped Metrics/ClassLength (101/100), so the check now lives
in within_baggage_limits? and the private_constant list is reflowed.

Assisted-By: Claude Fable 5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants