Repository navigation
Update Rust crate opentelemetry_sdk to 0.32 [SECURITY] - #220
renovate[bot] wants to merge 1 commit into
Conversation
vu1n
left a comment
There was a problem hiding this comment.
VPS review of 3b4711f: 1 finding(s), 1 blocking.
The change upgrades only the OpenTelemetry SDK to 0.32 while retaining the 0.30 API and exporter. This introduces incompatible telemetry traits and prevents compilation, so it is not safe to merge.
| # span.start_time is meaningful. | ||
| opentelemetry = "0.30" | ||
| opentelemetry_sdk = { version = "0.30", default-features = false, features = ["logs", "trace"] } | ||
| opentelemetry_sdk = { version = "0.32", default-features = false, features = ["logs", "trace"] } |
There was a problem hiding this comment.
P1 Upgrade the OpenTelemetry API and exporter alongside the SDK
The API and OTLP exporter remain at 0.30 while the SDK moves to 0.32. These versions have distinct Rust types and traits: the exporters passed to with_simple_exporter in logs.rs and spans.rs implement the 0.30 SDK traits, and the imported logger/tracer API traits also belong to 0.30. Consequently, the unconditionally compiled telemetry code no longer builds. Upgrade opentelemetry and opentelemetry-otlp to compatible versions together with the SDK, regenerate the lockfile, and adapt any changed APIs.
This PR contains the following updates:
0.30→0.32opentelemetry_sdk has unbounded memory allocation in W3C Baggage propagation
CVE-2026-48504 / GHSA-w9wp-h8wv-79jx
More information
Details
Summary
BaggagePropagator::extract_with_contextinopentelemetry_sdkdid not enforce the W3C Baggage size limits before parsing an inboundbaggageheader. A large attacker-controlled header could cause unnecessary CPU work and short-lived heap allocations while parsing entries that would later be discarded by the SDK's baggage storage limits.The SDK now applies limits aligned with the W3C Baggage limits:
Impact
Services that accept untrusted inbound propagation headers may experience increased per-request resource usage when processing oversized
baggageheaders. This can contribute to denial-of-service risk, especially when application or transport-level header limits are absent or configured above the W3C Baggage limits.The impact is limited to availability. This issue does not expose telemetry data, modify telemetry data, or allow code execution.
Patches
Upgrade
opentelemetry_sdkto version0.32.1or later.Version
0.32.1rejectsbaggageheader values larger than 8192 bytes and limits extraction to the first 64 list-members.Workarounds
If upgrading immediately is not possible, reject or limit inbound
baggageheaders larger than 8192 bytes before invoking OpenTelemetry propagation extraction. This can be enforced at a proxy, gateway, middleware layer, or custom carrier boundary.Resources
Credit
tonghuaroot
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:LReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Release Notes
open-telemetry/opentelemetry-rust (opentelemetry_sdk)
v0.32.1Released 2026-May-23
BaggagePropagatornow enforces the W3C Baggage maximum header length(8192 bytes) and maximum list-member count (64) when extracting an inbound
baggageheader. Headers exceeding 8192 bytes are dropped at thepropagator boundary; headers with more than 64 list members are
truncated to the first 64 entries. The change keeps the propagator from
parsing attacker-controlled input beyond the W3C limits instead of doing
per-entry parse, decode, and allocation work only to discard the excess
on
Baggageinsert. See https://www.w3.org/TR/baggage/#limits.SimpleSpanProcessortelemetry suppression added in 0.32.0(see #3494), which caused a
RefCell already borrowedpanic when a spanwas started and dropped inside a
get_active_span(orContext::map_current)closure. Tracked in #3510. A proper fix for the underlying
Context::map_currentre-entrancy will be investigated separately, afterwhich the suppression can be safely re-applied.
name(set viaStream::builder().with_name(...))is no longer validated against the instrument name syntax, per
spec clarification.
unitand other stream parameters continue to be validated.v0.32.0Compare Source
Released 2026-May-08
SimpleSpanProcessornow suppresses telemetry during export, preventingtelemetry-induced-telemetry feedback loops. This aligns with the existing
behavior in
BatchSpanProcessorandSimpleLogProcessor.SimpleConcurrentLogProcessorand theexperimental_logs_concurrent_log_processorfeature flag. The use cases it was designed for (ETW/user_events exporters) are
better served by modeling those exporters as processors directly.
Counter::bind()andHistogram::bind()SDK implementations thatreturn pre-bound measurement handles (
BoundCounter<T>,BoundHistogram<T>).Bound instruments resolve the attribute-to-aggregator mapping once at bind time
and cache the result, eliminating per-call HashMap lookups. View attribute
filtering is applied at bind time so the hot path stays free of per-call
attribute processing. Bound and unbound recordings with the same (post-view)
attribute set always aggregate into the same data point, including the empty
attribute set. Bound entries are never evicted during delta collection while
a handle exists — idle cycles produce no export but the tracker persists. If
bind()is called at the cardinality limit, the handle binds directly tothe overflow tracker — its writes stay on the same direct (no-lookup) hot
path and consistently land in the
otel.metric.overflow=truebucket forthe lifetime of the handle. To recover a bound handle after delta collection
frees space, drop the existing handle and call
bind()again. Gated behindthe
experimental_metrics_bound_instrumentsfeature flag. Benchmarks show~28x speedup for counter operations and ~9x for histograms.
HashMap on every collect cycle. Stale attribute sets that received no measurements
since the last collection are evicted. Note: recovery from cardinality overflow
now requires 2 collect cycles — the first marks entries as stale, the second
evicts them.
testingfeature is now runtime agnostic. #3407TokioSpanExporterandnew_tokio_test_exporterhave been renamed toTestSpanExporterandnew_test_exporter.tokio/rt,tokio/time,tokio/macros,tokio/rt-multi-thread,tokio-stream,experimental_async_runtimeInstrumentationScopeinArcinternally inSdkTracer, making tracer clones cheaper (Arc refcount increment instead of deep copy).portable-atomicforAtomicI64andAtomicU64in the metrics module. This enables compilation on 32-bit ARM targets (e.g.,armv5te-unknown-linux-gnueabi,armv7-unknown-linux-gnueabihf).Aggregationenum andStreamBuilder::with_aggregation()are now stable and no longer require thespec_unstable_metrics_viewsfeature flag.service.nameResource attribute fallback to follow OpenTelemetryspecification by using
unknown_service:<process.executable.name>format whenservice name is not explicitly configured. Previously, it only used
unknown_service.SpanExporter::shutdown()default timeout from 5 nanoseconds to 5 seconds.SpanExportertrait methodsshutdown,shutdown_with_timeout, andforce_flushnow take&selfinstead of&mut selffor consistency withLogExporterandPushMetricExporter. Implementers using interior mutability (e.g.,Mutex,AtomicBool) require no changes.Resource::get_ref(&self, key: &Key) -> Option<&Value>to allow retrieving a reference to a resource value without cloning.SdkTracer#3227:id_generator,should_sampleopentelemetry::tracetoopentelemetry_sdk::trace#3277:SamplingDecision,SamplingResultopentelemetry_sdk::traceinstead.StreamBuilder::build()now rejectsusize::MAXas a cardinality limitwith a validation error. #3506
TracerProviderBuilder::with_samplerallows to pass boxed instance ofShouldSample[#3313][3313]SpanProcessor::on_endcallsContext::current()(#3262).SpanProcessor::on_enddocumentation to clarify thatContext::current()returns the parent context, not the span's contexttraceparentheaders with unknown flags (e.g. W3C random-trace-id flag0x02) being incorrectly rejected. Unknown flags are now accepted and zeroed out as required by the W3C trace-context spec. #3435InMemoryExporterErrorhas been removed and replaced byOTelSdkError, and a newJaegerRemoteSamplerBuildErrorintroduced to replace last uses ofTraceError. #3458backing specification) is now stable and is enabled by default. #3278
v0.31.0Compare Source
Released 2025-Sep-25
Updated
opentelemetryandopentelemetry-httpdependencies to version 0.31.0.Feature: Add span flags support for
isRemoteproperty in OTLP exporter (#3153)Updated span and link transformations to properly set flags field (0x100 for local, 0x300 for remote)
TODO: Placeholder for Span processor related things
Fix: Restore true parallel exports in the async-native
BatchSpanProcessorby honoringOTEL_BSP_MAX_CONCURRENT_EXPORTS(#2959). A regression in #2685 inadvertently awaited theexport()future directly inopentelemetry-sdk/src/trace/span_processor_with_async_runtime.rsinstead of spawning it on the runtime, forcing all exports to run sequentially.Feature: Added
Cloneimplementation toSdkLoggerfor API consistency withSdkTracer(#3058).Fix: batch size accounting in BatchSpanProcessor when queue is full (#3089).
Fix: Resolved dependency issue where the "logs" feature incorrectly
required the "trace" feature flag
(#3096).
The logs functionality now operates independently, while automatic correlation
between logs and traces continues to work when the "trace" feature is
explicitly enabled.
Fix: Fix shutdown of
SimpleLogProcessorand asyncBatchLogProcessor.Default implementation of
LogProcessor::shutdown_with_timeout()will now warn to encourage users to implement proper shutdown.Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.