chore(release): proposal for libdd-capabilities-impl, libdd-common, libdd-data-pipeline, libdd-li... by dd-octo-sts[bot] · Pull Request #2199 · DataDog/libdatadog

dd-octo-sts · 2026-07-06T15:35:43Z

Release proposal for libdd-capabilities-impl, libdd-common, libdd-data-pipeline, libdd-library-config, libdd-sampling, libdd-telemetry, libdd-tinybytes, libdd-trace-utils and their dependencies

This PR contains version bumps based on public API changes and commits since last release.

libdd-capabilities

Next version: 2.1.0
Semver bump: minor
Tag: libdd-capabilities-v2.1.0

Commits

feat(data-pipeline)!: add stdout log trace exporter (feat(data-pipeline)!: add stdout log trace exporter #2074)

libdd-common

Next version: 5.1.0
Semver bump: minor
Tag: libdd-common-v5.1.0

Commits

fix: update rustls-webpki to 0.103.13 (fix: update rustls-webpki to 0.103.13 #2187)
fix: update anyhow for unsoundness (fix: update anyhow for unsoundness #2186)
feat(machine id): Add helpers in ddcommon to fetch the machine UUID l… (feat(machine id): Add helpers in ddcommon to fetch the machine UUID l… #2163)

libdd-ddsketch

Next version: 1.1.0
Semver bump: minor
Tag: libdd-ddsketch-v1.1.0

Commits

feat(data-pipeline)!: export client-computed span stats as OTLP trace metrics (feat(data-pipeline)!: export client-computed span stats as OTLP trace metrics #2067)
test(ddsketch): add microbenchmarks for add/encode/collapse (test(ddsketch): add microbenchmarks for add/encode/collapse #2125)

libdd-trace-protobuf

Next version: 4.0.0
Semver bump: major
Tag: libdd-trace-protobuf-v4.0.0

Commits

chore!: update protobufs to be in sync with datadog-agent (chore!: update protobufs to be in sync with datadog-agent #2180)
feat(stats)!: add whole key cardinality limit (feat(stats)!: add whole key cardinality limit #2158)
feat(remote-config)!: use the proto file from the agent (feat(remote-config)!: use the proto file from the agent #2165)
feat(data-pipeline): OTLP HTTP/protobuf trace export (feat(data-pipeline): OTLP HTTP/protobuf trace export #2115)

libdd-capabilities-impl

Next version: 3.0.0
Semver bump: major
Tag: libdd-capabilities-impl-v3.0.0

⚠️ major bump forced due to:

libdd-common: ^4.1.0 → ^5.0.0

Commits

feat(data-pipeline)!: add stdout log trace exporter (feat(data-pipeline)!: add stdout log trace exporter #2074)

libdd-library-config

Next version: 3.0.0
Semver bump: major
Tag: libdd-library-config-v3.0.0

Commits

feat(library-config)!: caller-supplied threadlocal schema and extra process-context attributes (feat(library-config)!: caller-supplied threadlocal schema and extra process-context attributes #2162)
fix(otel-thread-ctx): put the threadlocal attributes at the right place in the context (fix(otel-thread-ctx): put the threadlocal attributes at the right place in the context #2167)

libdd-trace-normalization

Next version: 2.1.0
Semver bump: minor
Tag: libdd-trace-normalization-v2.1.0

Commits

feat(data-pipeline)!: CSS Trace Filters (feat(data-pipeline)!: CSS Trace Filters #1985)

libdd-shared-runtime

Next version: 2.0.0
Semver bump: major
Tag: libdd-shared-runtime-v2.0.0

⚠️ major bump forced due to:

libdd-common: ^4.1.0 → ^5.0.0

Commits

feat(shared-runtime)!: SharedRuntime Borrowed & Owned mode (feat(shared-runtime)!: SharedRuntime Borrowed & Owned mode #2061)
feat(shared-runtime)!: use weak waker in trigger [APMSP-3371] (feat(shared-runtime)!: use weak waker in trigger [APMSP-3371] #2050)

libdd-trace-utils

Next version: 9.0.0
Semver bump: major
Tag: libdd-trace-utils-v9.0.0

⚠️ major bump forced due to:

libdd-common: ^4.2.0 → ^5.0.0

Commits

ci(miri): skip slow miri tests (ci(miri): skip slow miri tests #2188)
chore!: update protobufs to be in sync with datadog-agent (chore!: update protobufs to be in sync with datadog-agent #2180)
feat(data-pipeline): add agentless export (feat(data-pipeline): add agentless export #2081)
feat(data-pipeline)!: add stdout log trace exporter (feat(data-pipeline)!: add stdout log trace exporter #2074)
feat(data-pipeline): OTLP HTTP/protobuf trace export (feat(data-pipeline): OTLP HTTP/protobuf trace export #2115)
feat(otlp)!: Export OTLP spans with attribute-level OTel compatibility (feat(otlp)!: Export OTLP spans with attribute-level OTel compatibility #2091)
test(trace-utils): add V05 msgpack decode microbenchmark (test(trace-utils): add V05 msgpack decode microbenchmark #2127)
feat(data-pipeline)!: export client-computed span stats as OTLP trace metrics (feat(data-pipeline)!: export client-computed span stats as OTLP trace metrics #2067)
test(trace-utils): add VecMap microbenchmarks (test(trace-utils): add VecMap microbenchmarks #2126)
chore(stats)!: submit p0 telemetry in stats (chore(stats)!: submit p0 telemetry in stats #2130)
refactor(change-buffer)!: replace slot index with span_id, fix segment isolation (refactor(change-buffer)!: replace slot index with span_id, fix segment isolation #2105)
feat(data-pipeline)!: CSS Trace Filters (feat(data-pipeline)!: CSS Trace Filters #1985)
feat(trace-exporter): add v1 span and its encoder (feat(trace-exporter): add v1 span and its encoder #2039)
fix(trace-utils): mark decoded span maps as deduped (fix(trace-utils): mark decoded span maps as deduped #2110)
feat(trace-utils)!: change buffer implementation (feat(trace-utils)!: change buffer implementation #2055)
feat(native-spans)!: change buffer foundation (feat(native-spans)!: change buffer foundation #2046)
refactor(span)!: use VecMap for meta, metrics and meta_struct for v04 spans (refactor(span)!: use VecMap for meta, metrics and meta_struct for v04 spans #2043)
test: fix timeouts on heavily contended scenarios (test: fix timeouts on heavily contended scenarios #2093)

libdd-telemetry

Next version: 6.0.0
Semver bump: major
Tag: libdd-telemetry-v6.0.0

⚠️ major bump forced due to:

libdd-common: ^4.2.0 → ^5.0.0

Commits

ci(miri): skip slow miri tests (ci(miri): skip slow miri tests #2188)
refactor(libdd-telemetry)!: avoid leaking libdd-common types in the public API (refactor(libdd-telemetry)!: avoid leaking libdd-common types in the public API #2152)
feat(shared-runtime)!: SharedRuntime Borrowed & Owned mode (feat(shared-runtime)!: SharedRuntime Borrowed & Owned mode #2061)

libdd-trace-obfuscation

Next version: 5.0.0
Semver bump: major
Tag: libdd-trace-obfuscation-v5.0.0

⚠️ major bump forced due to:

libdd-common: ^4.2.0 → ^5.0.0

Commits

ci(miri): skip slow miri tests (ci(miri): skip slow miri tests #2188)
fix: update anyhow for unsoundness (fix: update anyhow for unsoundness #2186)

libdd-trace-stats

Next version: 6.0.0
Semver bump: major
Tag: libdd-trace-stats-v6.0.0

⚠️ major bump forced due to:

libdd-common: ^4.2.0 → ^5.0.0

Commits

chore!: update protobufs to be in sync with datadog-agent (chore!: update protobufs to be in sync with datadog-agent #2180)
feat(stats)!: send telemetry for cardinality limits (feat(stats)!: send telemetry for cardinality limits #2159)
feat(stats)!: add whole key cardinality limit (feat(stats)!: add whole key cardinality limit #2158)
fix(trace-stats)!: add grpc_method to aggregation key (fix(trace-stats)!: add grpc_method to aggregation key #2151)
feat(shared-runtime)!: SharedRuntime Borrowed & Owned mode (feat(shared-runtime)!: SharedRuntime Borrowed & Owned mode #2061)
feat(data-pipeline)!: export client-computed span stats as OTLP trace metrics (feat(data-pipeline)!: export client-computed span stats as OTLP trace metrics #2067)
refactor(span)!: use VecMap for meta, metrics and meta_struct for v04 spans (refactor(span)!: use VecMap for meta, metrics and meta_struct for v04 spans #2043)

libdd-data-pipeline

Next version: 7.0.0
Semver bump: major
Tag: libdd-data-pipeline-v7.0.0

⚠️ major bump forced due to:

libdd-common: ^4.2.0 → ^5.0.0

Commits

feat(trace_exporter): enable telemetry in stats exporter (feat(trace_exporter): enable telemetry in stats exporter #2160)
refactor(libdd-telemetry)!: avoid leaking libdd-common types in the public API (refactor(libdd-telemetry)!: avoid leaking libdd-common types in the public API #2152)
feat(stats): emit canonical gRPC status name for OTLP rpc.response.status_code (feat(stats): emit canonical gRPC status name for OTLP rpc.response.status_code #2183)
feat(data-pipeline): add agentless export (feat(data-pipeline): add agentless export #2081)
feat(stats)!: send telemetry for cardinality limits (feat(stats)!: send telemetry for cardinality limits #2159)
feat(stats)!: add whole key cardinality limit (feat(stats)!: add whole key cardinality limit #2158)
fix(trace-stats)!: add grpc_method to aggregation key (fix(trace-stats)!: add grpc_method to aggregation key #2151)
feat(data-pipeline)!: add stdout log trace exporter (feat(data-pipeline)!: add stdout log trace exporter #2074)
feat(shared-runtime)!: SharedRuntime Borrowed & Owned mode (feat(shared-runtime)!: SharedRuntime Borrowed & Owned mode #2061)
feat(data-pipeline): OTLP HTTP/protobuf trace export (feat(data-pipeline): OTLP HTTP/protobuf trace export #2115)
feat(otlp)!: Export OTLP spans with attribute-level OTel compatibility (feat(otlp)!: Export OTLP spans with attribute-level OTel compatibility #2091)
feat(data-pipeline)!: export client-computed span stats as OTLP trace metrics (feat(data-pipeline)!: export client-computed span stats as OTLP trace metrics #2067)
chore(stats)!: submit p0 telemetry in stats (chore(stats)!: submit p0 telemetry in stats #2130)
feat(data-pipeline)!: CSS Trace Filters (feat(data-pipeline)!: CSS Trace Filters #1985)
feat(shared-runtime)!: use weak waker in trigger [APMSP-3371] (feat(shared-runtime)!: use weak waker in trigger [APMSP-3371] #2050)
refactor(span)!: use VecMap for meta, metrics and meta_struct for v04 spans (refactor(span)!: use VecMap for meta, metrics and meta_struct for v04 spans #2043)
feat(stats)!: add endpoint gating to client-side stats [APMSP-3361] (feat(stats)!: add endpoint gating to client-side stats [APMSP-3361] #2040)

libdd-dogstatsd-client

Next version: 4.0.0
Semver bump: major
Tag: libdd-dogstatsd-client-v4.0.0

⚠️ major bump forced due to:

libdd-common: ^4.1.0 → ^5.0.0

libdd-sampling

Next version: 5.0.0
Semver bump: major
Tag: libdd-sampling-v5.0.0

⚠️ major bump forced due to:

libdd-common: ^4.2.0 → ^5.0.0

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

… bumps Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

…bumps Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

github-actions · 2026-07-06T15:40:00Z

🔒 Cargo Deny Results

⚠️ 37 issue(s) found, showing only errors (advisories, bans, sources)

📦 `datadog-ffe` - 2 error(s)

Show output

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:118:1
    │
118 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      └── (dev) libdd-common v5.1.0
          ├── datadog-ffe v1.0.0
          └── libdd-remote-config v1.0.0
              ├── datadog-ffe v1.0.0 (*)
              └── (dev) libdd-remote-config v1.0.0 (*)

error[vulnerability]: Denial of Service via Stack Exhaustion
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:169:1
    │
169 │ time 0.3.41 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0009
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0009
    ├ ## Impact
      
      When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of
      service attack via stack exhaustion is possible. The attack relies on formally deprecated and
      rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary,
      non-malicious input will never encounter this scenario.
      
      ## Patches
      
      A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned
      rather than exhausting the stack.
      
      ## Workarounds
      
      Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of
      the stack consumed would be at most a factor of the length of the input.
    ├ Announcement: https://github.com/time-rs/time/blob/main/CHANGELOG.md#0347-2026-02-05
    ├ Solution: Upgrade to >=0.3.47 (try `cargo update -p time`)
    ├ time v0.3.41
      └── libdd-remote-config v1.0.0
          ├── datadog-ffe v1.0.0
          └── (dev) libdd-remote-config v1.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 `datadog-sidecar` - 3 error(s)

Show output

error[unmaintained]: Bincode is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:37:1
   │
37 │ bincode 1.3.3 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
   │
   ├ ID: RUSTSEC-2025-0141
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0141
   ├ Due to a doxxing and harassment incident, the bincode team has taken the decision to cease development permanently.
     
     The team considers version 1.3.3 a complete version of bincode that is not in need of any updates.
     
     ## Alternatives to consider
     
     * [wincode](https://crates.io/crates/wincode)
     * [postcard](https://crates.io/crates/postcard)
     * [bitcode](https://crates.io/crates/bitcode)
     * [rkyv](https://crates.io/crates/rkyv)
   ├ Announcement: https://git.sr.ht/~stygianentity/bincode/tree/v3.0/item/README.md
   ├ Solution: No safe upgrade is available!
   ├ bincode v1.3.3
     ├── datadog-ipc v0.1.0
     │   └── datadog-sidecar v0.0.1
     └── datadog-sidecar v0.0.1 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:302:1
    │
302 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── datadog-sidecar v0.0.1
      ├── libdd-common v5.1.0
      │   ├── datadog-ffe v1.0.0
      │   │   └── datadog-sidecar v0.0.1 (*)
      │   ├── datadog-ipc v0.1.0
      │   │   └── datadog-sidecar v0.0.1 (*)
      │   ├── datadog-live-debugger v0.0.1
      │   │   └── datadog-sidecar v0.0.1 (*)
      │   ├── datadog-sidecar v0.0.1 (*)
      │   ├── libdd-capabilities-impl v3.0.0
      │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   ├── libdd-data-pipeline v7.0.0
      │   │   │   ├── datadog-live-debugger v0.0.1 (*)
      │   │   │   └── datadog-sidecar v0.0.1 (*)
      │   │   ├── libdd-shared-runtime v2.0.0
      │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
      │   │   │   ├── libdd-telemetry v6.0.0
      │   │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   │   ├── libdd-crashtracker v1.0.0
      │   │   │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   │   │   └── libdd-crashtracker-ffi v37.0.0
      │   │   │   │   │       └── datadog-sidecar v0.0.1 (*)
      │   │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
      │   │   │   │   └── libdd-trace-stats v6.0.0
      │   │   │   │       ├── datadog-ipc v0.1.0 (*)
      │   │   │   │       ├── datadog-sidecar v0.0.1 (*)
      │   │   │   │       └── libdd-data-pipeline v7.0.0 (*)
      │   │   │   └── libdd-trace-stats v6.0.0 (*)
      │   │   ├── libdd-trace-stats v6.0.0 (*)
      │   │   └── libdd-trace-utils v9.0.0
      │   │       ├── (dev) datadog-sidecar v0.0.1 (*)
      │   │       ├── libdd-data-pipeline v7.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v5.0.0
      │   │       │   └── libdd-trace-stats v6.0.0 (*)
      │   │       ├── libdd-trace-stats v6.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v9.0.0 (*)
      │   ├── libdd-common-ffi v37.0.0
      │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   └── libdd-crashtracker-ffi v37.0.0 (*)
      │   ├── (build) libdd-crashtracker v1.0.0 (*)
      │   ├── libdd-crashtracker-ffi v37.0.0 (*)
      │   ├── libdd-data-pipeline v7.0.0 (*)
      │   ├── libdd-dogstatsd-client v4.0.0
      │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   ├── libdd-data-pipeline v7.0.0 (*)
      │   │   └── libdd-trace-stats v6.0.0 (*)
      │   ├── libdd-remote-config v1.0.0
      │   │   ├── datadog-ffe v1.0.0 (*)
      │   │   ├── datadog-live-debugger v0.0.1 (*)
      │   │   ├── (dev) datadog-sidecar v0.0.1 (*)
      │   │   └── (dev) libdd-remote-config v1.0.0 (*)
      │   ├── libdd-shared-runtime v2.0.0 (*)
      │   ├── libdd-telemetry v6.0.0 (*)
      │   ├── libdd-trace-obfuscation v5.0.0 (*)
      │   ├── libdd-trace-stats v6.0.0 (*)
      │   └── libdd-trace-utils v9.0.0 (*)
      ├── libdd-crashtracker v1.0.0 (*)
      ├── (dev) libdd-data-pipeline v7.0.0 (*)
      ├── (dev) libdd-ddsketch v1.1.0
      │   ├── datadog-ipc v0.1.0 (*)
      │   ├── libdd-data-pipeline v7.0.0 (*)
      │   ├── libdd-telemetry v6.0.0 (*)
      │   └── libdd-trace-stats v6.0.0 (*)
      ├── (dev) libdd-trace-normalization v2.1.0
      │   ├── libdd-data-pipeline v7.0.0 (*)
      │   └── libdd-trace-utils v9.0.0 (*)
      ├── (dev) libdd-trace-stats v6.0.0 (*)
      ├── libdd-trace-utils v9.0.0 (*)
      └── proptest v1.5.0
          └── (dev) libdd-tinybytes v1.1.1
              ├── datadog-ipc v0.1.0 (*)
              ├── datadog-sidecar v0.0.1 (*)
              ├── libdd-data-pipeline v7.0.0 (*)
              ├── (dev) libdd-tinybytes v1.1.1 (*)
              └── libdd-trace-utils v9.0.0 (*)

error[vulnerability]: Denial of Service via Stack Exhaustion
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:395:1
    │
395 │ time 0.3.41 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0009
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0009
    ├ ## Impact
      
      When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of
      service attack via stack exhaustion is possible. The attack relies on formally deprecated and
      rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary,
      non-malicious input will never encounter this scenario.
      
      ## Patches
      
      A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned
      rather than exhausting the stack.
      
      ## Workarounds
      
      Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of
      the stack consumed would be at most a factor of the length of the input.
    ├ Announcement: https://github.com/time-rs/time/blob/main/CHANGELOG.md#0347-2026-02-05
    ├ Solution: Upgrade to >=0.3.47 (try `cargo update -p time`)
    ├ time v0.3.41
      ├── libdd-remote-config v1.0.0
      │   ├── datadog-ffe v1.0.0
      │   │   └── datadog-sidecar v0.0.1
      │   ├── datadog-live-debugger v0.0.1
      │   │   └── datadog-sidecar v0.0.1 (*)
      │   ├── (dev) datadog-sidecar v0.0.1 (*)
      │   └── (dev) libdd-remote-config v1.0.0 (*)
      └── tracing-appender v0.2.3
          └── libdd-log v1.0.0
              └── (dev) libdd-data-pipeline v7.0.0
                  ├── datadog-live-debugger v0.0.1 (*)
                  └── datadog-sidecar v0.0.1 (*)

advisories FAILED, bans ok, sources ok

📦 `libdd-agent-client` - 3 error(s)

Show output

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:83:1
   │
83 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0118
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0118
   ├ The NSEC3 closest-encloser proof validation in `hickory-proto`'s
     `DnssecDnsHandle` walks from the QNAME up to the SOA owner name, building a
     list of candidate encloser names. The iterator used assumes the
     QNAME is a descendant of the SOA owner, terminating only when the current
     candidate equals the SOA name. When the SOA in a response's authority section
     is not an ancestor of the QNAME, the loop stalls at the DNS root and never
     terminates, repeatedly calling `Name::base_name()` and pushing newly allocated
     `Name` and hashed-name entries into the candidate `Vec`.
     
     The bug is reachable by any caller of `DnssecDnsHandle` — including the
     resolver, recursor, and client — when built with the `dnssec-ring` or
     `dnssec-aws-lc-rs` feature and configured to perform DNSSEC validation. It is
     triggered while validating a NoData or NXDomain response whose authority
     section contains an SOA record from a zone other than an ancestor of the
     QNAME, on a code path that requires NSEC3 closest-encloser proof. In practice
     this can be reached through an insecure CNAME chain that crosses zone
     boundaries into a DNSSEC-signed zone returning NoData, but the minimum
     condition is just a mismatched SOA owner on a response requiring NSEC3
     validation.
     
     A `debug_assert_ne!(name, Name::root())` guards the loop body, so debug builds
     abort with a panic on the first iteration past the root. Release builds
     compile the assertion out and run the loop unbounded, allocating until the
     process exhausts available memory (OOM). A reachable upstream attacker who
     can return such a response can therefore crash a debug-built validator or
     exhaust memory on a release-built one.
     
     The affected code was migrated from `hickory-proto` to `hickory-net` as part of
     the 0.26.0 release. The `hickory-proto` 0.26.x release no longer offers
     `DnssecDnsHandle` and so we recommend all affected users update to `hickory-net`
     0.26.1 when the implementation of that type is required.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-3v94-mw7p-v465
   ├ Solution: No safe upgrade is available!
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             └── libdd-http-client v37.0.0
                 └── libdd-agent-client v37.0.0

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:83:1
   │
83 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0119
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0119
   ├ During message encoding, `hickory-proto`'s `BinEncoder` stores pointers to
     labels that are candidates for name compression in a `Vec<(usize, Vec<u8>)>`.
     The name compression logic then searches for matches with a linear scan.
     
     A malicious message with many records can both introduce many candidate labels,
     and invoke this linear scan many times. This can amplify CPU exhaustion in DoS
     attacks.
     
     This is similar to
     [CVE-2024-8508](https://www.nlnetlabs.nl/downloads/unbound/CVE-2024-8508.txt).
     
     We recommend all affected users update to `hickory-proto` 0.26.1 for the fix.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-q2qq-hmj6-3wpp
   ├ Solution: Upgrade to >=0.26.1 (try `cargo update -p hickory-proto`)
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             └── libdd-http-client v37.0.0
                 └── libdd-agent-client v37.0.0

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:152:1
    │
152 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      └── (dev) libdd-common v5.1.0
          └── libdd-agent-client v37.0.0

advisories FAILED, bans ok, sources ok

📦 `libdd-capabilities-impl` - 1 error(s)

Show output

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:69:1
   │
69 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2026-0097
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
   ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
     
     - The `log` and `thread_rng` features are enabled
     - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
     - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
     - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
     - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
     
     `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
   ├ Announcement: https://github.com/rust-random/rand/pull/1763
   ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
   ├ rand v0.8.5
     └── (dev) libdd-common v5.1.0
         └── libdd-capabilities-impl v3.0.0

advisories FAILED, bans ok, sources ok

📦 `libdd-capabilities` - ✅ No issues

📦 `libdd-common` - 3 error(s)

Show output

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:64:1
   │
64 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0118
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0118
   ├ The NSEC3 closest-encloser proof validation in `hickory-proto`'s
     `DnssecDnsHandle` walks from the QNAME up to the SOA owner name, building a
     list of candidate encloser names. The iterator used assumes the
     QNAME is a descendant of the SOA owner, terminating only when the current
     candidate equals the SOA name. When the SOA in a response's authority section
     is not an ancestor of the QNAME, the loop stalls at the DNS root and never
     terminates, repeatedly calling `Name::base_name()` and pushing newly allocated
     `Name` and hashed-name entries into the candidate `Vec`.
     
     The bug is reachable by any caller of `DnssecDnsHandle` — including the
     resolver, recursor, and client — when built with the `dnssec-ring` or
     `dnssec-aws-lc-rs` feature and configured to perform DNSSEC validation. It is
     triggered while validating a NoData or NXDomain response whose authority
     section contains an SOA record from a zone other than an ancestor of the
     QNAME, on a code path that requires NSEC3 closest-encloser proof. In practice
     this can be reached through an insecure CNAME chain that crosses zone
     boundaries into a DNSSEC-signed zone returning NoData, but the minimum
     condition is just a mismatched SOA owner on a response requiring NSEC3
     validation.
     
     A `debug_assert_ne!(name, Name::root())` guards the loop body, so debug builds
     abort with a panic on the first iteration past the root. Release builds
     compile the assertion out and run the loop unbounded, allocating until the
     process exhausts available memory (OOM). A reachable upstream attacker who
     can return such a response can therefore crash a debug-built validator or
     exhaust memory on a release-built one.
     
     The affected code was migrated from `hickory-proto` to `hickory-net` as part of
     the 0.26.0 release. The `hickory-proto` 0.26.x release no longer offers
     `DnssecDnsHandle` and so we recommend all affected users update to `hickory-net`
     0.26.1 when the implementation of that type is required.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-3v94-mw7p-v465
   ├ Solution: No safe upgrade is available!
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             └── libdd-common v5.1.0

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:64:1
   │
64 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0119
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0119
   ├ During message encoding, `hickory-proto`'s `BinEncoder` stores pointers to
     labels that are candidates for name compression in a `Vec<(usize, Vec<u8>)>`.
     The name compression logic then searches for matches with a linear scan.
     
     A malicious message with many records can both introduce many candidate labels,
     and invoke this linear scan many times. This can amplify CPU exhaustion in DoS
     attacks.
     
     This is similar to
     [CVE-2024-8508](https://www.nlnetlabs.nl/downloads/unbound/CVE-2024-8508.txt).
     
     We recommend all affected users update to `hickory-proto` 0.26.1 for the fix.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-q2qq-hmj6-3wpp
   ├ Solution: Upgrade to >=0.26.1 (try `cargo update -p hickory-proto`)
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             └── libdd-common v5.1.0

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:127:1
    │
127 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      └── libdd-common v5.1.0

advisories FAILED, bans ok, sources ok

📦 `libdd-crashtracker` - 1 error(s)

Show output

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:204:1
    │
204 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── libdd-common v5.1.0
      │   ├── libdd-capabilities-impl v3.0.0
      │   │   └── libdd-shared-runtime v2.0.0
      │   │       └── libdd-telemetry v6.0.0
      │   │           └── libdd-crashtracker v1.0.0
      │   ├── (build) libdd-crashtracker v1.0.0 (*)
      │   ├── libdd-shared-runtime v2.0.0 (*)
      │   └── libdd-telemetry v6.0.0 (*)
      ├── libdd-crashtracker v1.0.0 (*)
      └── (dev) libdd-ddsketch v1.1.0
          └── libdd-telemetry v6.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 `libdd-data-pipeline-ffi` - 2 error(s)

Show output

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:226:1
    │
226 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── libdd-common v5.1.0
      │   ├── libdd-capabilities-impl v3.0.0
      │   │   ├── libdd-data-pipeline v7.0.0
      │   │   │   └── libdd-data-pipeline-ffi v37.0.0
      │   │   ├── libdd-data-pipeline-ffi v37.0.0 (*)
      │   │   ├── libdd-shared-runtime v2.0.0
      │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
      │   │   │   ├── libdd-data-pipeline-ffi v37.0.0 (*)
      │   │   │   ├── libdd-telemetry v6.0.0
      │   │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
      │   │   │   │   └── libdd-trace-stats v6.0.0
      │   │   │   │       └── libdd-data-pipeline v7.0.0 (*)
      │   │   │   └── libdd-trace-stats v6.0.0 (*)
      │   │   ├── libdd-trace-stats v6.0.0 (*)
      │   │   └── libdd-trace-utils v9.0.0
      │   │       ├── libdd-data-pipeline v7.0.0 (*)
      │   │       ├── (dev) libdd-data-pipeline-ffi v37.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v5.0.0
      │   │       │   └── libdd-trace-stats v6.0.0 (*)
      │   │       ├── libdd-trace-stats v6.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v9.0.0 (*)
      │   ├── libdd-common-ffi v37.0.0
      │   │   └── libdd-data-pipeline-ffi v37.0.0 (*)
      │   ├── libdd-data-pipeline v7.0.0 (*)
      │   ├── libdd-dogstatsd-client v4.0.0
      │   │   ├── libdd-data-pipeline v7.0.0 (*)
      │   │   └── libdd-trace-stats v6.0.0 (*)
      │   ├── libdd-shared-runtime v2.0.0 (*)
      │   ├── libdd-telemetry v6.0.0 (*)
      │   ├── libdd-trace-obfuscation v5.0.0 (*)
      │   ├── libdd-trace-stats v6.0.0 (*)
      │   └── libdd-trace-utils v9.0.0 (*)
      ├── (dev) libdd-data-pipeline v7.0.0 (*)
      ├── (dev) libdd-ddsketch v1.1.0
      │   ├── libdd-data-pipeline v7.0.0 (*)
      │   ├── libdd-telemetry v6.0.0 (*)
      │   └── libdd-trace-stats v6.0.0 (*)
      ├── (dev) libdd-trace-normalization v2.1.0
      │   ├── libdd-data-pipeline v7.0.0 (*)
      │   └── libdd-trace-utils v9.0.0 (*)
      ├── (dev) libdd-trace-stats v6.0.0 (*)
      ├── libdd-trace-utils v9.0.0 (*)
      └── proptest v1.5.0
          └── (dev) libdd-tinybytes v1.1.1
              ├── libdd-data-pipeline v7.0.0 (*)
              ├── libdd-data-pipeline-ffi v37.0.0 (*)
              ├── (dev) libdd-tinybytes v1.1.1 (*)
              └── libdd-trace-utils v9.0.0 (*)

error[vulnerability]: Denial of Service via Stack Exhaustion
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:296:1
    │
296 │ time 0.3.41 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0009
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0009
    ├ ## Impact
      
      When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of
      service attack via stack exhaustion is possible. The attack relies on formally deprecated and
      rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary,
      non-malicious input will never encounter this scenario.
      
      ## Patches
      
      A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned
      rather than exhausting the stack.
      
      ## Workarounds
      
      Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of
      the stack consumed would be at most a factor of the length of the input.
    ├ Announcement: https://github.com/time-rs/time/blob/main/CHANGELOG.md#0347-2026-02-05
    ├ Solution: Upgrade to >=0.3.47 (try `cargo update -p time`)
    ├ time v0.3.41
      └── tracing-appender v0.2.3
          └── libdd-log v1.0.0
              └── (dev) libdd-data-pipeline v7.0.0
                  └── libdd-data-pipeline-ffi v37.0.0

advisories FAILED, bans ok, sources ok

📦 `libdd-data-pipeline` - 2 error(s)

Show output

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:218:1
    │
218 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── libdd-common v5.1.0
      │   ├── libdd-capabilities-impl v3.0.0
      │   │   ├── libdd-data-pipeline v7.0.0
      │   │   ├── libdd-shared-runtime v2.0.0
      │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
      │   │   │   ├── libdd-telemetry v6.0.0
      │   │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
      │   │   │   │   └── libdd-trace-stats v6.0.0
      │   │   │   │       └── libdd-data-pipeline v7.0.0 (*)
      │   │   │   └── libdd-trace-stats v6.0.0 (*)
      │   │   ├── libdd-trace-stats v6.0.0 (*)
      │   │   └── libdd-trace-utils v9.0.0
      │   │       ├── libdd-data-pipeline v7.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v5.0.0
      │   │       │   └── libdd-trace-stats v6.0.0 (*)
      │   │       ├── libdd-trace-stats v6.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v9.0.0 (*)
      │   ├── libdd-data-pipeline v7.0.0 (*)
      │   ├── libdd-dogstatsd-client v4.0.0
      │   │   ├── libdd-data-pipeline v7.0.0 (*)
      │   │   └── libdd-trace-stats v6.0.0 (*)
      │   ├── libdd-shared-runtime v2.0.0 (*)
      │   ├── libdd-telemetry v6.0.0 (*)
      │   ├── libdd-trace-obfuscation v5.0.0 (*)
      │   ├── libdd-trace-stats v6.0.0 (*)
      │   └── libdd-trace-utils v9.0.0 (*)
      ├── (dev) libdd-data-pipeline v7.0.0 (*)
      ├── (dev) libdd-ddsketch v1.1.0
      │   ├── libdd-data-pipeline v7.0.0 (*)
      │   ├── libdd-telemetry v6.0.0 (*)
      │   └── libdd-trace-stats v6.0.0 (*)
      ├── (dev) libdd-trace-normalization v2.1.0
      │   ├── libdd-data-pipeline v7.0.0 (*)
      │   └── libdd-trace-utils v9.0.0 (*)
      ├── (dev) libdd-trace-stats v6.0.0 (*)
      ├── libdd-trace-utils v9.0.0 (*)
      └── proptest v1.5.0
          └── (dev) libdd-tinybytes v1.1.1
              ├── libdd-data-pipeline v7.0.0 (*)
              ├── (dev) libdd-tinybytes v1.1.1 (*)
              └── libdd-trace-utils v9.0.0 (*)

error[vulnerability]: Denial of Service via Stack Exhaustion
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:287:1
    │
287 │ time 0.3.41 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0009
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0009
    ├ ## Impact
      
      When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of
      service attack via stack exhaustion is possible. The attack relies on formally deprecated and
      rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary,
      non-malicious input will never encounter this scenario.
      
      ## Patches
      
      A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned
      rather than exhausting the stack.
      
      ## Workarounds
      
      Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of
      the stack consumed would be at most a factor of the length of the input.
    ├ Announcement: https://github.com/time-rs/time/blob/main/CHANGELOG.md#0347-2026-02-05
    ├ Solution: Upgrade to >=0.3.47 (try `cargo update -p time`)
    ├ time v0.3.41
      └── tracing-appender v0.2.3
          └── libdd-log v1.0.0
              └── (dev) libdd-data-pipeline v7.0.0

advisories FAILED, bans ok, sources ok

📦 `libdd-ddsketch` - 1 error(s)

Show output

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:45:1
   │
45 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2026-0097
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
   ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
     
     - The `log` and `thread_rng` features are enabled
     - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
     - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
     - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
     - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
     
     `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
   ├ Announcement: https://github.com/rust-random/rand/pull/1763
   ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
   ├ rand v0.8.5
     └── (dev) libdd-ddsketch v1.1.0

advisories FAILED, bans ok, sources ok

📦 `libdd-dogstatsd-client` - 1 error(s)

Show output

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:71:1
   │
71 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2026-0097
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
   ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
     
     - The `log` and `thread_rng` features are enabled
     - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
     - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
     - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
     - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
     
     `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
   ├ Announcement: https://github.com/rust-random/rand/pull/1763
   ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
   ├ rand v0.8.5
     └── (dev) libdd-common v5.1.0
         └── libdd-dogstatsd-client v4.0.0

advisories FAILED, bans ok, sources ok

📦 `libdd-http-client` - 2 error(s)

Show output

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:72:1
   │
72 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0118
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0118
   ├ The NSEC3 closest-encloser proof validation in `hickory-proto`'s
     `DnssecDnsHandle` walks from the QNAME up to the SOA owner name, building a
     list of candidate encloser names. The iterator used assumes the
     QNAME is a descendant of the SOA owner, terminating only when the current
     candidate equals the SOA name. When the SOA in a response's authority section
     is not an ancestor of the QNAME, the loop stalls at the DNS root and never
     terminates, repeatedly calling `Name::base_name()` and pushing newly allocated
     `Name` and hashed-name entries into the candidate `Vec`.
     
     The bug is reachable by any caller of `DnssecDnsHandle` — including the
     resolver, recursor, and client — when built with the `dnssec-ring` or
     `dnssec-aws-lc-rs` feature and configured to perform DNSSEC validation. It is
     triggered while validating a NoData or NXDomain response whose authority
     section contains an SOA record from a zone other than an ancestor of the
     QNAME, on a code path that requires NSEC3 closest-encloser proof. In practice
     this can be reached through an insecure CNAME chain that crosses zone
     boundaries into a DNSSEC-signed zone returning NoData, but the minimum
     condition is just a mismatched SOA owner on a response requiring NSEC3
     validation.
     
     A `debug_assert_ne!(name, Name::root())` guards the loop body, so debug builds
     abort with a panic on the first iteration past the root. Release builds
     compile the assertion out and run the loop unbounded, allocating until the
     process exhausts available memory (OOM). A reachable upstream attacker who
     can return such a response can therefore crash a debug-built validator or
     exhaust memory on a release-built one.
     
     The affected code was migrated from `hickory-proto` to `hickory-net` as part of
     the 0.26.0 release. The `hickory-proto` 0.26.x release no longer offers
     `DnssecDnsHandle` and so we recommend all affected users update to `hickory-net`
     0.26.1 when the implementation of that type is required.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-3v94-mw7p-v465
   ├ Solution: No safe upgrade is available!
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             └── libdd-http-client v37.0.0

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:72:1
   │
72 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0119
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0119
   ├ During message encoding, `hickory-proto`'s `BinEncoder` stores pointers to
     labels that are candidates for name compression in a `Vec<(usize, Vec<u8>)>`.
     The name compression logic then searches for matches with a linear scan.
     
     A malicious message with many records can both introduce many candidate labels,
     and invoke this linear scan many times. This can amplify CPU exhaustion in DoS
     attacks.
     
     This is similar to
     [CVE-2024-8508](https://www.nlnetlabs.nl/downloads/unbound/CVE-2024-8508.txt).
     
     We recommend all affected users update to `hickory-proto` 0.26.1 for the fix.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-q2qq-hmj6-3wpp
   ├ Solution: Upgrade to >=0.26.1 (try `cargo update -p hickory-proto`)
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             └── libdd-http-client v37.0.0

advisories FAILED, bans ok, sources ok

📦 `libdd-library-config` - 1 error(s)

Show output

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:47:1
   │
47 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2026-0097
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
   ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
     
     - The `log` and `thread_rng` features are enabled
     - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
     - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
     - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
     - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
     
     `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
   ├ Announcement: https://github.com/rust-random/rand/pull/1763
   ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
   ├ rand v0.8.5
     └── libdd-library-config v3.0.0

advisories FAILED, bans ok, sources ok

📦 `libdd-profiling` - 3 error(s)

Show output

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:79:1
   │
79 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0118
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0118
   ├ The NSEC3 closest-encloser proof validation in `hickory-proto`'s
     `DnssecDnsHandle` walks from the QNAME up to the SOA owner name, building a
     list of candidate encloser names. The iterator used assumes the
     QNAME is a descendant of the SOA owner, terminating only when the current
     candidate equals the SOA name. When the SOA in a response's authority section
     is not an ancestor of the QNAME, the loop stalls at the DNS root and never
     terminates, repeatedly calling `Name::base_name()` and pushing newly allocated
     `Name` and hashed-name entries into the candidate `Vec`.
     
     The bug is reachable by any caller of `DnssecDnsHandle` — including the
     resolver, recursor, and client — when built with the `dnssec-ring` or
     `dnssec-aws-lc-rs` feature and configured to perform DNSSEC validation. It is
     triggered while validating a NoData or NXDomain response whose authority
     section contains an SOA record from a zone other than an ancestor of the
     QNAME, on a code path that requires NSEC3 closest-encloser proof. In practice
     this can be reached through an insecure CNAME chain that crosses zone
     boundaries into a DNSSEC-signed zone returning NoData, but the minimum
     condition is just a mismatched SOA owner on a response requiring NSEC3
     validation.
     
     A `debug_assert_ne!(name, Name::root())` guards the loop body, so debug builds
     abort with a panic on the first iteration past the root. Release builds
     compile the assertion out and run the loop unbounded, allocating until the
     process exhausts available memory (OOM). A reachable upstream attacker who
     can return such a response can therefore crash a debug-built validator or
     exhaust memory on a release-built one.
     
     The affected code was migrated from `hickory-proto` to `hickory-net` as part of
     the 0.26.0 release. The `hickory-proto` 0.26.x release no longer offers
     `DnssecDnsHandle` and so we recommend all affected users update to `hickory-net`
     0.26.1 when the implementation of that type is required.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-3v94-mw7p-v465
   ├ Solution: No safe upgrade is available!
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             ├── libdd-common v5.1.0
             │   └── libdd-profiling v1.0.0
             │       └── (dev) libdd-profiling v1.0.0 (*)
             └── libdd-profiling v1.0.0 (*)

error[vulnerability]: CPU exhaustion during message encoding due to O(n²) name compression
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:79:1
   │
79 │ hickory-proto 0.25.2 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0119
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0119
   ├ During message encoding, `hickory-proto`'s `BinEncoder` stores pointers to
     labels that are candidates for name compression in a `Vec<(usize, Vec<u8>)>`.
     The name compression logic then searches for matches with a linear scan.
     
     A malicious message with many records can both introduce many candidate labels,
     and invoke this linear scan many times. This can amplify CPU exhaustion in DoS
     attacks.
     
     This is similar to
     [CVE-2024-8508](https://www.nlnetlabs.nl/downloads/unbound/CVE-2024-8508.txt).
     
     We recommend all affected users update to `hickory-proto` 0.26.1 for the fix.
   ├ Announcement: https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-q2qq-hmj6-3wpp
   ├ Solution: Upgrade to >=0.26.1 (try `cargo update -p hickory-proto`)
   ├ hickory-proto v0.25.2
     └── hickory-resolver v0.25.2
         └── reqwest v0.13.2
             ├── libdd-common v5.1.0
             │   └── libdd-profiling v1.0.0
             │       └── (dev) libdd-profiling v1.0.0 (*)
             └── libdd-profiling v1.0.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:157:1
    │
157 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── libdd-common v5.1.0
      │   └── libdd-profiling v1.0.0
      │       └── (dev) libdd-profiling v1.0.0 (*)
      ├── libdd-profiling v1.0.0 (*)
      └── proptest v1.5.0
          └── (dev) libdd-profiling v1.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 `libdd-remote-config` - 2 error(s)

Show output

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:92:1
   │
92 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2026-0097
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
   ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
     
     - The `log` and `thread_rng` features are enabled
     - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
     - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
     - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
     - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
     
     `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
   ├ Announcement: https://github.com/rust-random/rand/pull/1763
   ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
   ├ rand v0.8.5
     └── (dev) libdd-common v5.1.0
         └── libdd-remote-config v1.0.0
             └── (dev) libdd-remote-config v1.0.0 (*)

error[vulnerability]: Denial of Service via Stack Exhaustion
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:136:1
    │
136 │ time 0.3.41 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0009
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0009
    ├ ## Impact
      
      When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of
      service attack via stack exhaustion is possible. The attack relies on formally deprecated and
      rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary,
      non-malicious input will never encounter this scenario.
      
      ## Patches
      
      A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned
      rather than exhausting the stack.
      
      ## Workarounds
      
      Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of
      the stack consumed would be at most a factor of the length of the input.
    ├ Announcement: https://github.com/time-rs/time/blob/main/CHANGELOG.md#0347-2026-02-05
    ├ Solution: Upgrade to >=0.3.47 (try `cargo update -p time`)
    ├ time v0.3.41
      └── libdd-remote-config v1.0.0
          └── (dev) libdd-remote-config v1.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 `libdd-sampling` - 1 error(s)

Show output

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:98:1
   │
98 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2026-0097
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
   ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
     
     - The `log` and `thread_rng` features are enabled
     - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
     - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
     - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
     - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
     
     `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
   ├ Announcement: https://github.com/rust-random/rand/pull/1763
   ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
   ├ rand v0.8.5
     └── (dev) libdd-common v5.1.0
         └── libdd-sampling v5.0.0

advisories FAILED, bans ok, sou...*[Comment body truncated]*

github-actions · 2026-07-06T15:40:25Z

📚 Documentation Check Results

⚠️ 13931 documentation warning(s) found

📦 `datadog-ffe` - 341 warning(s)

📦 `datadog-sidecar` - 2789 warning(s)

📦 `libdd-agent-client` - 168 warning(s)

📦 `libdd-capabilities-impl` - 184 warning(s)

📦 `libdd-capabilities` - 12 warning(s)

📦 `libdd-common` - 169 warning(s)

📦 `libdd-crashtracker` - 1084 warning(s)

📦 `libdd-data-pipeline-ffi` - 1315 warning(s)

📦 `libdd-data-pipeline` - 1204 warning(s)

📦 `libdd-ddsketch` - 8 warning(s)

📦 `libdd-dogstatsd-client` - 169 warning(s)

📦 `libdd-http-client` - ✅ No warnings

📦 `libdd-library-config` - 265 warning(s)

📦 `libdd-profiling` - 652 warning(s)

📦 `libdd-remote-config` - 633 warning(s)

📦 `libdd-sampling` - 180 warning(s)

📦 `libdd-shared-runtime-ffi` - 195 warning(s)

📦 `libdd-shared-runtime` - 188 warning(s)

📦 `libdd-telemetry` - 509 warning(s)

📦 `libdd-trace-normalization` - 244 warning(s)

📦 `libdd-trace-obfuscation` - 818 warning(s)

📦 `libdd-trace-protobuf` - 227 warning(s)

📦 `libdd-trace-stats` - 864 warning(s)

📦 `libdd-trace-utils` - 731 warning(s)

📦 `libdd-tracer-flare` - 982 warning(s)

Updated: 2026-07-06 15:41:12 UTC | Commit: 926c636 | missing-docs job results

datadog-prod-us1-5 · 2026-07-06T15:59:56Z

Tests

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 74.45% (+0.02%)

_{This comment will be updated automatically if new data arrives.

🔗 Commit SHA: 3de9664 | Docs | Datadog PR Page | Give us feedback!}

## What The release-proposal major-bump audit now runs against the **proposal branch HEAD** (the released ref plus this run's version bumps) instead of the pre-bump release ref, so a crate whose direct `libdd-*` dependency is bumped to a new major **within the same proposal** is correctly escalated to a major bump. ## Why In run [28800859299](https://github.com/DataDog/libdatadog/actions/runs/28800859299/job/85403702020) (PR #2199), `libdd-trace-protobuf` was bumped `3.0.2 → 4.0.0` and step 1 rewrote `libdd-trace-normalization`'s dependency requirement to `4.0.0` on the proposal branch — but `libdd-trace-normalization` only got a **minor** bump. The audit worktree was checked out at `release_head_sha` (the released ref *before* step-1 bumps), where `libdd-trace-normalization` still required protobuf `^3` — same as its prev_tag — so no major diff was detected. Already-merged majors (e.g. `libdd-common ^4 → ^5`) worked because that change was already present at the released ref; only **in-proposal** majors were missed. ## How Check the audit worktree out at `git rev-parse HEAD` (proposal branch tip) rather than `release_head_sha`. | Reference | In-proposal dep majors | Already-merged majors | Main-only changes (hotfix risk) | |---|---|---|---| | `github.sha` | ❌ | ✅ | ❌ spurious | | `release_head_sha` (pre-bump) | ❌ ← this bug | ✅ | ✅ excluded | | **proposal HEAD** | ✅ | ✅ | ✅ excluded | Proposal HEAD includes cargo-release's dependency-requirement rewrites from the previous step (so in-proposal majors propagate) while still being built from the released ref (so main-only changes absent from a hotfix/older-ref release don't trigger spurious bumps — preserving the guarantee from the earlier review of #2195). Pending no-commit crates now also propagate in-proposal dependency majors, not just already-merged ones. ## Testing YAML validated. Behavior verified by tracing the failing run's logs against the new reference; the full workflow requires the CI runner + org tokens and was not run locally. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

github-actions Bot and others added 30 commits July 6, 2026 15:34

chore: Release

22a64e0

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore: Release

6447989

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore: Release

bc34c25

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore: Release

ced174a

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore: Release

83c44cd

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore: Release

01a6702

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore: Release

d14cad6

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore: Release

cafb9eb

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore: Release

b42bcbc

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore: Release

fc1f5ec

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore: Release

c1f970e

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore: Release

da71d44

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore: Release

7553b9a

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update version for libdd-capabilities-impl with major…

82f1036

… bumps Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update version for libdd-trace-obfuscation with major…

326380d

… bumps Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update version for libdd-dogstatsd-client with major …

3835fe1

…bumps Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update version for libdd-sampling with major bumps

0bfdc2c

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update CHANGELOG.md for libdd-capabilities

5a29eb7

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update CHANGELOG.md for libdd-common

3cb8f60

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update CHANGELOG.md for libdd-ddsketch

1529471

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update CHANGELOG.md for libdd-trace-protobuf

0b9b606

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update CHANGELOG.md for libdd-capabilities-impl

5b597b1

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update CHANGELOG.md for libdd-library-config

bf88538

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update CHANGELOG.md for libdd-trace-normalization

50aa275

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update CHANGELOG.md for libdd-shared-runtime

89d0bf7

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update CHANGELOG.md for libdd-trace-utils

bd27950

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update CHANGELOG.md for libdd-telemetry

30dd794

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update CHANGELOG.md for libdd-trace-obfuscation

ad0f458

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update CHANGELOG.md for libdd-trace-stats

b24294f

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update CHANGELOG.md for libdd-data-pipeline

28cdca8

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

github-actions Bot and others added 2 commits July 6, 2026 15:35

chore(release): update CHANGELOG.md for libdd-dogstatsd-client

155fed0

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

chore(release): update CHANGELOG.md for libdd-sampling

3de9664

Co-authored-by: iunanua <18325288+iunanua@users.noreply.github.com>

dd-octo-sts Bot added skip-changelog-check skip-metadata-check release-proposal This is a release proposal PR skip-pr-title-semver-check labels Jul 6, 2026

github-actions Bot added telemetry mini-agent sidecar common data-pipeline crashtracker sampling labels Jul 6, 2026

iunanua closed this Jul 6, 2026

iunanua mentioned this pull request Jul 6, 2026

fix(release): detect in-proposal dependency major bumps #2200

Merged

iunanua deleted the release-proposal/libdd-capabilities-impl-7-more/20260706-150829 branch July 7, 2026 07:33

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

chore(release): proposal for libdd-capabilities-impl, libdd-common, libdd-data-pipeline, libdd-li...#2199

chore(release): proposal for libdd-capabilities-impl, libdd-common, libdd-data-pipeline, libdd-li...#2199
dd-octo-sts[bot] wants to merge 32 commits into
release/libdd-capabilities-impl-7-more/20260706-150829from
release-proposal/libdd-capabilities-impl-7-more/20260706-150829

dd-octo-sts Bot commented Jul 6, 2026

Uh oh!

github-actions Bot commented Jul 6, 2026

Uh oh!

github-actions Bot commented Jul 6, 2026 •

edited

Loading

Uh oh!

datadog-prod-us1-5 Bot commented Jul 6, 2026 •

edited by datadog-datadog-prod-us1 Bot

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

dd-octo-sts Bot commented Jul 6, 2026

Release proposal for libdd-capabilities-impl, libdd-common, libdd-data-pipeline, libdd-library-config, libdd-sampling, libdd-telemetry, libdd-tinybytes, libdd-trace-utils and their dependencies

libdd-capabilities

Commits

libdd-common

Commits

libdd-ddsketch

Commits

libdd-trace-protobuf

Commits

libdd-capabilities-impl

⚠️ major bump forced due to:

Commits

libdd-library-config

Commits

libdd-trace-normalization

Commits

libdd-shared-runtime

⚠️ major bump forced due to:

Commits

libdd-trace-utils

⚠️ major bump forced due to:

Commits

libdd-telemetry

⚠️ major bump forced due to:

Commits

libdd-trace-obfuscation

⚠️ major bump forced due to:

Commits

libdd-trace-stats

⚠️ major bump forced due to:

Commits

libdd-data-pipeline

⚠️ major bump forced due to:

Commits

libdd-dogstatsd-client

⚠️ major bump forced due to:

libdd-sampling

⚠️ major bump forced due to:

Uh oh!

github-actions Bot commented Jul 6, 2026

🔒 Cargo Deny Results

📦 datadog-ffe - 2 error(s)

📦 datadog-sidecar - 3 error(s)

📦 libdd-agent-client - 3 error(s)

📦 libdd-capabilities-impl - 1 error(s)

📦 libdd-capabilities - ✅ No issues

📦 libdd-common - 3 error(s)

📦 libdd-crashtracker - 1 error(s)

📦 libdd-data-pipeline-ffi - 2 error(s)

📦 libdd-data-pipeline - 2 error(s)

📦 libdd-ddsketch - 1 error(s)

📦 libdd-dogstatsd-client - 1 error(s)

📦 libdd-http-client - 2 error(s)

📦 libdd-library-config - 1 error(s)

📦 libdd-profiling - 3 error(s)

📦 libdd-remote-config - 2 error(s)

📦 libdd-sampling - 1 error(s)

Uh oh!

github-actions Bot commented Jul 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📚 Documentation Check Results

📦 datadog-ffe - 341 warning(s)

📦 datadog-sidecar - 2789 warning(s)

📦 libdd-agent-client - 168 warning(s)

📦 libdd-capabilities-impl - 184 warning(s)

📦 libdd-capabilities - 12 warning(s)

📦 libdd-common - 169 warning(s)

📦 libdd-crashtracker - 1084 warning(s)

📦 libdd-data-pipeline-ffi - 1315 warning(s)

📦 libdd-data-pipeline - 1204 warning(s)

📦 libdd-ddsketch - 8 warning(s)

📦 libdd-dogstatsd-client - 169 warning(s)

📦 libdd-http-client - ✅ No warnings

📦 libdd-library-config - 265 warning(s)

📦 libdd-profiling - 652 warning(s)

📦 libdd-remote-config - 633 warning(s)

📦 libdd-sampling - 180 warning(s)

📦 `datadog-ffe` - 2 error(s)

📦 `datadog-sidecar` - 3 error(s)

📦 `libdd-agent-client` - 3 error(s)

📦 `libdd-capabilities-impl` - 1 error(s)

📦 `libdd-capabilities` - ✅ No issues

📦 `libdd-common` - 3 error(s)

📦 `libdd-crashtracker` - 1 error(s)

📦 `libdd-data-pipeline-ffi` - 2 error(s)

📦 `libdd-data-pipeline` - 2 error(s)

📦 `libdd-ddsketch` - 1 error(s)

📦 `libdd-dogstatsd-client` - 1 error(s)

📦 `libdd-http-client` - 2 error(s)

📦 `libdd-library-config` - 1 error(s)

📦 `libdd-profiling` - 3 error(s)

📦 `libdd-remote-config` - 2 error(s)

📦 `libdd-sampling` - 1 error(s)

github-actions Bot commented Jul 6, 2026 •

edited

Loading

📦 `datadog-ffe` - 341 warning(s)

📦 `datadog-sidecar` - 2789 warning(s)

📦 `libdd-agent-client` - 168 warning(s)

📦 `libdd-capabilities-impl` - 184 warning(s)

📦 `libdd-capabilities` - 12 warning(s)

📦 `libdd-common` - 169 warning(s)

📦 `libdd-crashtracker` - 1084 warning(s)

📦 `libdd-data-pipeline-ffi` - 1315 warning(s)

📦 `libdd-data-pipeline` - 1204 warning(s)

📦 `libdd-ddsketch` - 8 warning(s)

📦 `libdd-dogstatsd-client` - 169 warning(s)

📦 `libdd-http-client` - ✅ No warnings

📦 `libdd-library-config` - 265 warning(s)

📦 `libdd-profiling` - 652 warning(s)

📦 `libdd-remote-config` - 633 warning(s)

📦 `libdd-sampling` - 180 warning(s)

📦 `libdd-shared-runtime-ffi` - 195 warning(s)

📦 `libdd-shared-runtime` - 188 warning(s)

📦 `libdd-telemetry` - 509 warning(s)

📦 `libdd-trace-normalization` - 244 warning(s)

📦 `libdd-trace-obfuscation` - 818 warning(s)

📦 `libdd-trace-protobuf` - 227 warning(s)

📦 `libdd-trace-stats` - 864 warning(s)

📦 `libdd-trace-utils` - 731 warning(s)

📦 `libdd-tracer-flare` - 982 warning(s)

datadog-prod-us1-5 Bot commented Jul 6, 2026 •

edited by datadog-datadog-prod-us1 Bot

Loading