Skip to content

chore: move all remaining external deps to workspace-level dependencies - #2476

Open
yannham wants to merge 3 commits into
mainfrom
yannham/all-workspace-deps
Open

chore: move all remaining external deps to workspace-level dependencies#2476
yannham wants to merge 3 commits into
mainfrom
yannham/all-workspace-deps

Conversation

@yannham

@yannham yannham commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

Follow-up of #2350. Migrate all of the remaining external dependencies to the workspace level. duplicate was used with incompatible major versions. Mostly the macro syntax changed. Files are updated to use the latest version's syntax.

Motivation

As for the other workspace-level deps: use a single source of truth and version, for each dependency, in the whole workspace. Force leaf crates to opt-in features they need instead of blindly enabling default features.

…evel

Move all external (non-inter-workspace) dependencies declared directly in
member crates to [workspace.dependencies], with default features disabled
per the workspace convention. Leaf crates reference them via workspace = true
and opt into the features they use.
@yannham
yannham requested review from a team as code owners September 7, 2026 15:56
@yannham
yannham requested review from greghuels, typotter and vpellan and removed request for a team September 7, 2026 15:56
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Sep 7, 2026

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review Completed 2026-09-07T16:03:11.758886Z 737075e PR opened
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@github-actions

github-actions Bot commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

🔒 Cargo Deny Results

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

📦 bin_tests - 7 error(s)

Show output
error[unsound]: `Bitmap::try_from(&[u8])` can create invalid values
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:30:1
   │
30 │ bitmaps 3.2.1 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2025-0167
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0167
   ├ The `TryFrom<&[u8]>` implementation for `Bitmap<SIZE>` copies the input bytes
     into an uninitialized backing store and calls `assume_init()` without
     validating that the bytes form a valid value of the backing store type. For
     `SIZE = 1` the backing store is a `bool`, so any input byte other than `0x00`
     or `0x01` produces an invalid value, which is immediate undefined behavior.
     
     The `AsMut<[u8]>` implementation has the same problem, as it allows safe code
     to write invalid bit patterns into the backing store through the returned slice.
     
     No fixed version is available, as the crate is unmaintained; its GitHub
     repository was archived by the owner on 2026-05-03.
   ├ Announcement: https://github.com/bodil/bitmaps/issues/35
   ├ Solution: No safe upgrade is available!
   ├ bitmaps v3.2.1
     └── libdd-profiling v1.0.0
         ├── bin_tests v0.1.0
         └── (dev) libdd-profiling v1.0.0 (*)

error[unmaintained]: bitmaps is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:30:1
   │
30 │ bitmaps 3.2.1 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
   │
   ├ ID: RUSTSEC-2026-0247
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0247
   ├ The bitmaps crate is unmaintained; all versions are affected. The GitHub
     repository was archived by the owner on 2026-05-03.
     
     Recommended alternatives:
     
     * [fixedbitset](https://crates.io/crates/fixedbitset)
     * [bitvec](https://crates.io/crates/bitvec)
   ├ Announcement: https://github.com/bodil/bitmaps
   ├ Solution: No safe upgrade is available!
   ├ bitmaps v3.2.1
     └── libdd-profiling v1.0.0
         ├── bin_tests v0.1.0
         └── (dev) libdd-profiling v1.0.0 (*)

error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:72:1
   │
72 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     ├── crossbeam-deque v0.8.5
     │   └── rayon-core v1.12.1
     │       └── rayon v1.10.0
     │           └── criterion v0.5.1
     │               ├── (dev) libdd-crashtracker v2.0.1
     │               │   └── bin_tests v0.1.0
     │               ├── (dev) libdd-ddsketch v1.1.1
     │               │   └── libdd-telemetry v7.0.0
     │               │       └── libdd-crashtracker v2.0.1 (*)
     │               └── (dev) libdd-profiling v1.0.0
     │                   ├── bin_tests v0.1.0 (*)
     │                   └── (dev) libdd-profiling v1.0.0 (*)
     └── moka v0.12.13
         └── hickory-resolver v0.25.2
             └── reqwest v0.13.2
                 ├── libdd-common v5.2.0
                 │   ├── bin_tests v0.1.0 (*)
                 │   ├── libdd-capabilities-impl v4.0.0
                 │   │   ├── libdd-crashtracker v2.0.1 (*)
                 │   │   ├── libdd-shared-runtime v3.0.0
                 │   │   │   └── libdd-telemetry v7.0.0 (*)
                 │   │   └── (dev) libdd-telemetry v7.0.0 (*)
                 │   ├── (build) libdd-crashtracker v2.0.1 (*)
                 │   ├── libdd-profiling v1.0.0 (*)
                 │   ├── libdd-shared-runtime v3.0.0 (*)
                 │   └── libdd-telemetry v7.0.0 (*)
                 └── libdd-profiling v1.0.0 (*)

error[vulnerability]: h2 unbounded empty DATA frames
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:113:1
    │
113 │ h2 0.4.6 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0258
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0258
    ├ The h2 crate, used internally by hyper, had a flaw that would accept and queue empty DATA frames without limit.
      If streams were not actively drained, this could lead to unbounded memory usage, or a panic if the length overflows.
      
      Low severity.
      
      Patched in v0.4.16.
    ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-q83h-524g-xf6h
    ├ Solution: Upgrade to >=0.4.16 (try `cargo update -p h2`)
    ├ h2 v0.4.6
      └── hyper v1.6.0
          ├── httpmock v0.8.0-alpha.1
          │   └── (dev) libdd-telemetry v7.0.0
          │       └── libdd-crashtracker v2.0.1
          │           └── bin_tests v0.1.0
          ├── hyper-rustls v0.27.7
          │   ├── libdd-common v5.2.0
          │   │   ├── bin_tests v0.1.0 (*)
          │   │   ├── libdd-capabilities-impl v4.0.0
          │   │   │   ├── libdd-crashtracker v2.0.1 (*)
          │   │   │   ├── libdd-shared-runtime v3.0.0
          │   │   │   │   └── libdd-telemetry v7.0.0 (*)
          │   │   │   └── (dev) libdd-telemetry v7.0.0 (*)
          │   │   ├── (build) libdd-crashtracker v2.0.1 (*)
          │   │   ├── libdd-profiling v1.0.0
          │   │   │   ├── bin_tests v0.1.0 (*)
          │   │   │   └── (dev) libdd-profiling v1.0.0 (*)
          │   │   ├── libdd-shared-runtime v3.0.0 (*)
          │   │   └── libdd-telemetry v7.0.0 (*)
          │   └── reqwest v0.13.2
          │       ├── libdd-common v5.2.0 (*)
          │       └── libdd-profiling v1.0.0 (*)
          ├── hyper-util v0.1.17
          │   ├── httpmock v0.8.0-alpha.1 (*)
          │   ├── hyper-rustls v0.27.7 (*)
          │   ├── libdd-common v5.2.0 (*)
          │   └── reqwest v0.13.2 (*)
          ├── libdd-common v5.2.0 (*)
          └── reqwest v0.13.2 (*)

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:123:1
    │
123 │ 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.2.0
              │   ├── bin_tests v0.1.0
              │   ├── libdd-capabilities-impl v4.0.0
              │   │   ├── libdd-crashtracker v2.0.1
              │   │   │   └── bin_tests v0.1.0 (*)
              │   │   ├── libdd-shared-runtime v3.0.0
              │   │   │   └── libdd-telemetry v7.0.0
              │   │   │       └── libdd-crashtracker v2.0.1 (*)
              │   │   └── (dev) libdd-telemetry v7.0.0 (*)
              │   ├── (build) libdd-crashtracker v2.0.1 (*)
              │   ├── libdd-profiling v1.0.0
              │   │   ├── bin_tests v0.1.0 (*)
              │   │   └── (dev) libdd-profiling v1.0.0 (*)
              │   ├── libdd-shared-runtime v3.0.0 (*)
              │   └── libdd-telemetry v7.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:123:1
    │
123 │ 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.2.0
              │   ├── bin_tests v0.1.0
              │   ├── libdd-capabilities-impl v4.0.0
              │   │   ├── libdd-crashtracker v2.0.1
              │   │   │   └── bin_tests v0.1.0 (*)
              │   │   ├── libdd-shared-runtime v3.0.0
              │   │   │   └── libdd-telemetry v7.0.0
              │   │   │       └── libdd-crashtracker v2.0.1 (*)
              │   │   └── (dev) libdd-telemetry v7.0.0 (*)
              │   ├── (build) libdd-crashtracker v2.0.1 (*)
              │   ├── libdd-profiling v1.0.0
              │   │   ├── bin_tests v0.1.0 (*)
              │   │   └── (dev) libdd-profiling v1.0.0 (*)
              │   ├── libdd-shared-runtime v3.0.0 (*)
              │   └── libdd-telemetry v7.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:240:1
    │
240 │ 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](https://github.com/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.2.0
      │   ├── bin_tests v0.1.0
      │   ├── libdd-capabilities-impl v4.0.0
      │   │   ├── libdd-crashtracker v2.0.1
      │   │   │   └── bin_tests v0.1.0 (*)
      │   │   ├── libdd-shared-runtime v3.0.0
      │   │   │   └── libdd-telemetry v7.0.0
      │   │   │       └── libdd-crashtracker v2.0.1 (*)
      │   │   └── (dev) libdd-telemetry v7.0.0 (*)
      │   ├── (build) libdd-crashtracker v2.0.1 (*)
      │   ├── libdd-profiling v1.0.0
      │   │   ├── bin_tests v0.1.0 (*)
      │   │   └── (dev) libdd-profiling v1.0.0 (*)
      │   ├── libdd-shared-runtime v3.0.0 (*)
      │   └── libdd-telemetry v7.0.0 (*)
      ├── libdd-crashtracker v2.0.1 (*)
      ├── (dev) libdd-ddsketch v1.1.1
      │   └── libdd-telemetry v7.0.0 (*)
      ├── (dev) libdd-profiling v1.0.0 (*)
      └── proptest v1.5.0
          ├── (dev) libdd-common v5.2.0 (*)
          └── (dev) libdd-profiling v1.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 builder - 3 error(s)

Show output
error[vulnerability]: Quadratic run time when checking a start tag for duplicate attribute names
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:79:1
   │
79 │ quick-xml 0.37.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0194
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0194
   ├ `BytesStart::attributes()` returns an `Attributes` iterator which, by default
     (`with_checks(true)`), rejects a start tag that repeats an attribute name. For
     each attribute yielded, the iterator compared the new name against every name
     seen so far in the same tag using a linear scan, so a start tag with `N`
     distinct attribute names cost `O(N²)` byte comparisons. There was no bound on
     `N` other than the size of the buffered start tag.
     
     ## Impact
     
     Any code that parses untrusted XML and iterates a start tag's attributes with
     the default duplicate check enabled can be made to spend CPU time quadratic in
     the number of attributes on a single tag. Because the check is pure computation
     with no `.await`/I/O, an I/O-based timeout on the consumer (for example a read
     or request timeout) cannot interrupt it while it runs.
     
     Measured cost of a single start tag, release build:
     
     | Attributes on one tag | Time |
     |---|---|
     | 80,000  | ~6 s   |
     | 800,000 | ~10 min |
     
     The cost grows with the square of the attribute count, so a start tag of a few
     tens of megabytes can stall a parsing thread for hours. No memory is exhausted
     and the parser does not crash; the effect is CPU exhaustion on the thread doing
     the parsing: a single crafted start tag can pin a CPU core for minutes to hours,
     denying service to that worker. A deployment that places a wall-clock bound on
     parsing, or confines it to a non-critical thread, may consider the availability
     impact lower.
     
     ## Affected code paths
     
     * `BytesStart::attributes()` / `Attributes` iterated with checks enabled (the
       default), and `BytesStart::try_get_attribute`.
     * `NsReader`, which resolves namespaces by iterating a tag's attributes and so
       reaches the same check internally.
     
     Consumers that iterate attributes with `.attributes().with_checks(false)` and do
     not use `NsReader` are not affected.
     
     This was reported as reachable by a remote, unauthenticated attacker in a
     real-world RPKI relying party (NLnet Labs Routinator) via a crafted RRDP
     `snapshot.xml`.
     
     ## Remediation
     
     Upgrade to `quick-xml >= 0.41.0`, where the duplicate check keeps the linear
     scan for start tags with a small number of attributes and switches to an `O(1)`
     hash pre-filter above a threshold, making the whole tag `O(N)`. The reported
     `AttrError::Duplicated` positions are unchanged.
     
     If upgrading is not possible and duplicate-name detection is not required,
     disable it with `.attributes().with_checks(false)` (this does not help
     `NsReader` consumers, which have no equivalent opt-out before 0.41.0).
   ├ Announcement: https://github.com/tafia/quick-xml/issues/969
   ├ Solution: Upgrade to >=0.41.0 (try `cargo update -p quick-xml`)
   ├ quick-xml v0.37.5
     └── tools v43.0.0
         └── builder v43.0.0

error[vulnerability]: Unbounded namespace-declaration allocation in `NsReader` enables memory-exhaustion denial of service
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:79:1
   │
79 │ quick-xml 0.37.5 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0195
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0195
   ├ `NsReader` resolves namespaces by calling `NamespaceResolver::push` for every
     `Start`/`Empty` event *before* the event is returned to the caller. `push`
     iterated all `xmlns` / `xmlns:*` attributes on the start tag and, for each one,
     appended the prefix bytes to an internal buffer and pushed a `NamespaceBinding`
     (32 bytes on 64-bit) to an internal `Vec`, with no upper bound on the number of
     declarations.
     
     ## Impact
     
     A start tag with `N` namespace declarations drove roughly `3×` the tag's byte
     size in `NamespaceResolver` heap, allocated *inside* `quick-xml` before the
     `NsReader` consumer ever received the event and could inspect or reject it. A
     consumer that bounds its *input* size therefore still cannot bound this
     allocation: an `M`-byte start tag yields on the order of `3 × M` bytes of
     resolver heap the caller never sees.
     
     On untrusted XML this lets a remote, unauthenticated attacker force large heap
     allocations with a single start tag. With several `NsReader`s running
     concurrently on independent inputs (a common server pattern), the allocations
     stack and can exhaust process memory, causing the operating system to kill the
     process (OOM). This was confirmed against a real-world RPKI relying party (NLnet
     Labs Routinator), where concurrent RRDP validation workers parsing a crafted
     `snapshot.xml` exceeded the memory limit and the process was OOM-killed.
     
     ## Affected code paths
     
     Consumers using `NsReader` (which always calls `NamespaceResolver::push` before
     yielding `Start`/`Empty`), or calling `NamespaceResolver::push` directly. A plain
     `Reader` that does not perform namespace resolution is not affected.
     
     ## Remediation
     
     Upgrade to `quick-xml >= 0.41.0`. `NamespaceResolver::push` now rejects a start
     tag that declares more than `DEFAULT_MAX_DECLARATIONS_PER_ELEMENT` (256)
     namespace bindings, returning the new `NamespaceError::TooManyDeclarations`
     instead of allocating without limit. The limit is configurable via
     `NamespaceResolver::set_max_declarations_per_element` (use `usize::MAX` to
     restore the previous unbounded behavior), and `NsReader::resolver_mut()` is
     provided to reach it.
     
     There is no clean workaround for `NsReader` consumers before 0.41.0, as the
     allocation happens inside the reader with no configuration knob to cap it.
   ├ Announcement: https://github.com/tafia/quick-xml/issues/970
   ├ Solution: Upgrade to >=0.41.0 (try `cargo update -p quick-xml`)
   ├ quick-xml v0.37.5
     └── tools v43.0.0
         └── builder v43.0.0

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:82:1
   │
82 │ 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](https://github.com/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.2.0
     │   ├── builder v43.0.0
     │   └── tools v43.0.0
     │       └── builder v43.0.0 (*)
     └── proptest v1.5.0
         └── (dev) libdd-common v5.2.0 (*)

advisories FAILED, bans ok, sources ok

📦 datadog-profiling-replayer - 6 error(s)

Show output
error[unsound]: `Bitmap::try_from(&[u8])` can create invalid values
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:18:1
   │
18 │ bitmaps 3.2.1 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
   │
   ├ ID: RUSTSEC-2025-0167
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0167
   ├ The `TryFrom<&[u8]>` implementation for `Bitmap<SIZE>` copies the input bytes
     into an uninitialized backing store and calls `assume_init()` without
     validating that the bytes form a valid value of the backing store type. For
     `SIZE = 1` the backing store is a `bool`, so any input byte other than `0x00`
     or `0x01` produces an invalid value, which is immediate undefined behavior.
     
     The `AsMut<[u8]>` implementation has the same problem, as it allows safe code
     to write invalid bit patterns into the backing store through the returned slice.
     
     No fixed version is available, as the crate is unmaintained; its GitHub
     repository was archived by the owner on 2026-05-03.
   ├ Announcement: https://github.com/bodil/bitmaps/issues/35
   ├ Solution: No safe upgrade is available!
   ├ bitmaps v3.2.1
     └── libdd-profiling v1.0.0
         ├── datadog-profiling-replayer v43.0.0
         └── (dev) libdd-profiling v1.0.0 (*)

error[unmaintained]: bitmaps is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:18:1
   │
18 │ bitmaps 3.2.1 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
   │
   ├ ID: RUSTSEC-2026-0247
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0247
   ├ The bitmaps crate is unmaintained; all versions are affected. The GitHub
     repository was archived by the owner on 2026-05-03.
     
     Recommended alternatives:
     
     * [fixedbitset](https://crates.io/crates/fixedbitset)
     * [bitvec](https://crates.io/crates/bitvec)
   ├ Announcement: https://github.com/bodil/bitmaps
   ├ Solution: No safe upgrade is available!
   ├ bitmaps v3.2.1
     └── libdd-profiling v1.0.0
         ├── datadog-profiling-replayer v43.0.0
         └── (dev) libdd-profiling v1.0.0 (*)

error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:54:1
   │
54 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     ├── crossbeam-deque v0.8.5
     │   └── rayon-core v1.12.1
     │       └── rayon v1.10.0
     │           └── criterion v0.5.1
     │               └── (dev) libdd-profiling v1.0.0
     │                   ├── datadog-profiling-replayer v43.0.0
     │                   └── (dev) libdd-profiling v1.0.0 (*)
     └── moka v0.12.13
         └── hickory-resolver v0.25.2
             └── reqwest v0.13.2
                 ├── libdd-common v5.2.0
                 │   └── libdd-profiling v1.0.0 (*)
                 └── libdd-profiling v1.0.0 (*)

error[vulnerability]: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:86:1
   │
86 │ 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.2.0
             │   └── libdd-profiling v1.0.0
             │       ├── datadog-profiling-replayer v43.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:86:1
   │
86 │ 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.2.0
             │   └── libdd-profiling v1.0.0
             │       ├── datadog-profiling-replayer v43.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:166:1
    │
166 │ 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](https://github.com/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.2.0
      │   └── libdd-profiling v1.0.0
      │       ├── datadog-profiling-replayer v43.0.0
      │       └── (dev) libdd-profiling v1.0.0 (*)
      ├── (dev) libdd-profiling v1.0.0 (*)
      └── proptest v1.5.0
          ├── (dev) libdd-common v5.2.0 (*)
          └── (dev) libdd-profiling v1.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 datadog-sidecar-ffi - 7 error(s)

Show output
error[unmaintained]: Bincode is unmaintained
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:36:1
   │
36 │ 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-sidecar v0.0.1
     │   └── datadog-sidecar-ffi v0.0.1
     ├── (dev) libdd-ffe v1.0.0
     │   └── datadog-sidecar v0.0.1 (*)
     └── libdd-ipc v1.0.0
         ├── datadog-sidecar v0.0.1 (*)
         └── datadog-sidecar-ffi v0.0.1 (*)

error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:91:1
   │
91 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     ├── libdd-common v5.2.0
                     │   ├── datadog-sidecar v0.0.1
                     │   │   └── datadog-sidecar-ffi v0.0.1
                     │   ├── datadog-sidecar-ffi v0.0.1 (*)
                     │   ├── libdd-capabilities-impl v4.0.0
                     │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   ├── libdd-crashtracker v2.0.1
                     │   │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
                     │   │   │   └── libdd-crashtracker-ffi v43.0.0
                     │   │   │       ├── datadog-sidecar v0.0.1 (*)
                     │   │   │       └── datadog-sidecar-ffi v0.0.1 (*)
                     │   │   ├── libdd-data-pipeline v9.0.0
                     │   │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   │   └── libdd-live-debugger v0.1.0
                     │   │   │       ├── datadog-sidecar v0.0.1 (*)
                     │   │   │       └── datadog-sidecar-ffi v0.0.1 (*)
                     │   │   ├── (dev) libdd-ffe v1.0.0
                     │   │   │   └── datadog-sidecar v0.0.1 (*)
                     │   │   ├── libdd-live-debugger v0.1.0 (*)
                     │   │   ├── libdd-remote-config v4.0.0
                     │   │   │   ├── (dev) datadog-sidecar v0.0.1 (*)
                     │   │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
                     │   │   │   ├── libdd-ffe v1.0.0 (*)
                     │   │   │   ├── libdd-live-debugger v0.1.0 (*)
                     │   │   │   └── (dev) libdd-remote-config v4.0.0 (*)
                     │   │   ├── libdd-shared-runtime v3.0.0
                     │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   │   │   ├── libdd-dogstatsd-client v5.0.0
                     │   │   │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
                     │   │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v8.0.0
                     │   │   │   │       ├── datadog-sidecar v0.0.1 (*)
                     │   │   │   │       ├── libdd-data-pipeline v9.0.0 (*)
                     │   │   │   │       └── libdd-ipc v1.0.0
                     │   │   │   │           ├── datadog-sidecar v0.0.1 (*)
                     │   │   │   │           └── datadog-sidecar-ffi v0.0.1 (*)
                     │   │   │   ├── libdd-telemetry v7.0.0
                     │   │   │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
                     │   │   │   │   ├── libdd-crashtracker v2.0.1 (*)
                     │   │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   │   │   │   ├── libdd-telemetry-ffi v43.0.0
                     │   │   │   │   │   └── datadog-sidecar-ffi v0.0.1 (*)
                     │   │   │   │   └── libdd-trace-stats v8.0.0 (*)
                     │   │   │   └── libdd-trace-stats v8.0.0 (*)
                     │   │   ├── (dev) libdd-telemetry v7.0.0 (*)
                     │   │   ├── libdd-telemetry-ffi v43.0.0 (*)
                     │   │   ├── libdd-trace-stats v8.0.0 (*)
                     │   │   └── libdd-trace-utils v11.0.0
                     │   │       ├── (dev) datadog-sidecar v0.0.1 (*)
                     │   │       ├── (dev) datadog-sidecar-ffi v0.0.1 (*)
                     │   │       ├── libdd-data-pipeline v9.0.0 (*)
                     │   │       ├── libdd-data-pipeline-core v0.1.0
                     │   │       │   └── libdd-data-pipeline v9.0.0 (*)
                     │   │       ├── libdd-trace-obfuscation v7.0.0
                     │   │       │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   │       │   ├── libdd-data-pipeline-core v0.1.0 (*)
                     │   │       │   └── libdd-trace-stats v8.0.0 (*)
                     │   │       ├── libdd-trace-stats v8.0.0 (*)
                     │   │       └── (dev) libdd-trace-utils v11.0.0 (*)
                     │   ├── libdd-common-ffi v43.0.0
                     │   │   ├── datadog-sidecar v0.0.1 (*)
                     │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
                     │   │   ├── libdd-crashtracker-ffi v43.0.0 (*)
                     │   │   └── libdd-telemetry-ffi v43.0.0 (*)
                     │   ├── (build) libdd-crashtracker v2.0.1 (*)
                     │   ├── libdd-crashtracker-ffi v43.0.0 (*)
                     │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   ├── libdd-data-pipeline-core v0.1.0 (*)
                     │   ├── libdd-dogstatsd-client v5.0.0 (*)
                     │   ├── libdd-ffe v1.0.0 (*)
                     │   ├── libdd-ipc v1.0.0 (*)
                     │   ├── libdd-live-debugger v0.1.0 (*)
                     │   ├── libdd-remote-config v4.0.0 (*)
                     │   ├── libdd-shared-runtime v3.0.0 (*)
                     │   ├── libdd-telemetry v7.0.0 (*)
                     │   ├── libdd-telemetry-ffi v43.0.0 (*)
                     │   ├── libdd-trace-obfuscation v7.0.0 (*)
                     │   ├── libdd-trace-stats v8.0.0 (*)
                     │   └── libdd-trace-utils v11.0.0 (*)
                     ├── (dev) libdd-crashtracker v2.0.1 (*)
                     ├── (dev) libdd-data-pipeline v9.0.0 (*)
                     ├── (dev) libdd-ddsketch v1.1.1
                     │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   ├── libdd-ipc v1.0.0 (*)
                     │   ├── libdd-telemetry v7.0.0 (*)
                     │   └── libdd-trace-stats v8.0.0 (*)
                     ├── (dev) libdd-ipc v1.0.0 (*)
                     ├── (dev) libdd-trace-normalization v4.0.0
                     │   ├── libdd-data-pipeline v9.0.0 (*)
                     │   └── libdd-trace-utils v11.0.0 (*)
                     ├── (dev) libdd-trace-obfuscation v7.0.0 (*)
                     ├── (dev) libdd-trace-stats v8.0.0 (*)
                     └── (dev) libdd-trace-utils v11.0.0 (*)

error[vulnerability]: h2 unbounded empty DATA frames
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:151:1
    │
151 │ h2 0.4.6 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0258
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0258
    ├ The h2 crate, used internally by hyper, had a flaw that would accept and queue empty DATA frames without limit.
      If streams were not actively drained, this could lead to unbounded memory usage, or a panic if the length overflows.
      
      Low severity.
      
      Patched in v0.4.16.
    ├ Announcement: https://github.com/hyperium/hyper/security/advisories/GHSA-q83h-524g-xf6h
    ├ Solution: Upgrade to >=0.4.16 (try `cargo update -p h2`)
    ├ h2 v0.4.6
      ├── hyper v1.6.0
      │   ├── httpmock v0.8.0-alpha.1
      │   │   ├── (dev) datadog-sidecar v0.0.1
      │   │   │   └── datadog-sidecar-ffi v0.0.1
      │   │   ├── (dev) libdd-data-pipeline v9.0.0
      │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   └── libdd-live-debugger v0.1.0
      │   │   │       ├── datadog-sidecar v0.0.1 (*)
      │   │   │       └── datadog-sidecar-ffi v0.0.1 (*)
      │   │   ├── (dev) libdd-ffe v1.0.0
      │   │   │   └── datadog-sidecar v0.0.1 (*)
      │   │   ├── (dev) libdd-telemetry v7.0.0
      │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
      │   │   │   ├── libdd-crashtracker v2.0.1
      │   │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
      │   │   │   │   └── libdd-crashtracker-ffi v43.0.0
      │   │   │   │       ├── datadog-sidecar v0.0.1 (*)
      │   │   │   │       └── datadog-sidecar-ffi v0.0.1 (*)
      │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │   │   ├── libdd-telemetry-ffi v43.0.0
      │   │   │   │   └── datadog-sidecar-ffi v0.0.1 (*)
      │   │   │   └── libdd-trace-stats v8.0.0
      │   │   │       ├── datadog-sidecar v0.0.1 (*)
      │   │   │       ├── libdd-data-pipeline v9.0.0 (*)
      │   │   │       └── libdd-ipc v1.0.0
      │   │   │           ├── datadog-sidecar v0.0.1 (*)
      │   │   │           └── datadog-sidecar-ffi v0.0.1 (*)
      │   │   ├── (dev) libdd-trace-stats v8.0.0 (*)
      │   │   └── libdd-trace-utils v11.0.0
      │   │       ├── (dev) datadog-sidecar v0.0.1 (*)
      │   │       ├── (dev) datadog-sidecar-ffi v0.0.1 (*)
      │   │       ├── libdd-data-pipeline v9.0.0 (*)
      │   │       ├── libdd-data-pipeline-core v0.1.0
      │   │       │   └── libdd-data-pipeline v9.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v7.0.0
      │   │       │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │       │   ├── libdd-data-pipeline-core v0.1.0 (*)
      │   │       │   └── libdd-trace-stats v8.0.0 (*)
      │   │       ├── libdd-trace-stats v8.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v11.0.0 (*)
      │   ├── hyper-rustls v0.27.7
      │   │   └── libdd-common v5.2.0
      │   │       ├── datadog-sidecar v0.0.1 (*)
      │   │       ├── datadog-sidecar-ffi v0.0.1 (*)
      │   │       ├── libdd-capabilities-impl v4.0.0
      │   │       │   ├── datadog-sidecar v0.0.1 (*)
      │   │       │   ├── libdd-crashtracker v2.0.1 (*)
      │   │       │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │       │   ├── (dev) libdd-ffe v1.0.0 (*)
      │   │       │   ├── libdd-live-debugger v0.1.0 (*)
      │   │       │   ├── libdd-remote-config v4.0.0
      │   │       │   │   ├── (dev) datadog-sidecar v0.0.1 (*)
      │   │       │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
      │   │       │   │   ├── libdd-ffe v1.0.0 (*)
      │   │       │   │   ├── libdd-live-debugger v0.1.0 (*)
      │   │       │   │   └── (dev) libdd-remote-config v4.0.0 (*)
      │   │       │   ├── libdd-shared-runtime v3.0.0
      │   │       │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │       │   │   ├── libdd-dogstatsd-client v5.0.0
      │   │       │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │       │   │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
      │   │       │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │       │   │   │   └── libdd-trace-stats v8.0.0 (*)
      │   │       │   │   ├── libdd-telemetry v7.0.0 (*)
      │   │       │   │   └── libdd-trace-stats v8.0.0 (*)
      │   │       │   ├── (dev) libdd-telemetry v7.0.0 (*)
      │   │       │   ├── libdd-telemetry-ffi v43.0.0 (*)
      │   │       │   ├── libdd-trace-stats v8.0.0 (*)
      │   │       │   └── libdd-trace-utils v11.0.0 (*)
      │   │       ├── libdd-common-ffi v43.0.0
      │   │       │   ├── datadog-sidecar v0.0.1 (*)
      │   │       │   ├── datadog-sidecar-ffi v0.0.1 (*)
      │   │       │   ├── libdd-crashtracker-ffi v43.0.0 (*)
      │   │       │   └── libdd-telemetry-ffi v43.0.0 (*)
      │   │       ├── (build) libdd-crashtracker v2.0.1 (*)
      │   │       ├── libdd-crashtracker-ffi v43.0.0 (*)
      │   │       ├── libdd-data-pipeline v9.0.0 (*)
      │   │       ├── libdd-data-pipeline-core v0.1.0 (*)
      │   │       ├── libdd-dogstatsd-client v5.0.0 (*)
      │   │       ├── libdd-ffe v1.0.0 (*)
      │   │       ├── libdd-ipc v1.0.0 (*)
      │   │       ├── libdd-live-debugger v0.1.0 (*)
      │   │       ├── libdd-remote-config v4.0.0 (*)
      │   │       ├── libdd-shared-runtime v3.0.0 (*)
      │   │       ├── libdd-telemetry v7.0.0 (*)
      │   │       ├── libdd-telemetry-ffi v43.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v7.0.0 (*)
      │   │       ├── libdd-trace-stats v8.0.0 (*)
      │   │       └── libdd-trace-utils v11.0.0 (*)
      │   ├── hyper-util v0.1.17
      │   │   ├── httpmock v0.8.0-alpha.1 (*)
      │   │   ├── hyper-rustls v0.27.7 (*)
      │   │   ├── libdd-common v5.2.0 (*)
      │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │   └── libdd-remote-config v4.0.0 (*)
      │   ├── libdd-common v5.2.0 (*)
      │   ├── libdd-common-ffi v43.0.0 (*)
      │   ├── libdd-data-pipeline v9.0.0 (*)
      │   ├── libdd-remote-config v4.0.0 (*)
      │   └── libdd-trace-utils v11.0.0 (*)
      └── (dev) libdd-data-pipeline v9.0.0 (*)

error[unsound]: Potential use-after-free due to lack of panic safety in `LruCache::pop()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:232:1
    │
232 │ lru 0.16.4 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0253
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0253
    ├ `LruCache::pop()` in `lru` was not panic-safe. If the `Drop` implementation of a stored key panics during `pop()`, `self.detach()` is never called, leaving dangling pointers in the internal doubly-linked list.
      
      A subsequent cache operation that triggers eviction can then dereference these dangling pointers:
      - The node is freed from the map, but remains linked in the LRU list due to the skipped `detach()` call
      - When a new insertion causes eviction, the LRU traversal encounters the dangling pointer
      - This results in a write to already-freed memory during the eviction process
      
      ## Impact
      
      - **CWE-416 (Use-After-Free):** memory corruption when subsequent cache operations access freed node pointers in the linked list
      - **CWE-415 (Double Free):** potential heap corruption when the same memory is freed multiple times
      
      Both types of undefined behavior can be invoked in safe Rust, but only if unwinding panics are enabled and `std::panic::catch_unwind` is used with key types that have potentially-panicking `Drop` implementations.
      
      ## Fix
      
      Fixed in `lru` 0.18.2 by detaching the node from the linked list before freeing it and dropping the key ([lru-rs#238](https://github.com/jeromefroe/lru-rs/pull/238)).
    ├ Announcement: https://github.com/jeromefroe/lru-rs/pull/238
    ├ Solution: Upgrade to >=0.18.2 (try `cargo update -p lru`)
    ├ lru v0.16.4
      └── libdd-ffe v1.0.0
          └── datadog-sidecar v0.0.1
              └── datadog-sidecar-ffi v0.0.1

error[unmaintained]: paste - no longer maintained
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:274:1
    │
274 │ paste 1.0.15 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
    │
    ├ ID: RUSTSEC-2024-0436
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0436
    ├ The creator of the crate `paste` has stated in the [`README.md`](https://github.com/dtolnay/paste/blob/master/README.md) 
      that this project is not longer maintained as well as archived the repository
      
      ## Possible Alternative(s)
      
      - [`pastey`]: a fork of paste and is aimed to be a drop-in replacement with additional features for paste crate
      - [`with_builtin_macros`]: crate providing a [superset of `paste`'s functionality including general `macro_rules!` eager expansions](https://docs.rs/with_builtin_macros/0.1.0/with_builtin_macros/macro.with_eager_expansions.html)  and `concat!`/`concat_idents!` macros
      
      [`pastey`]: https://crates.io/crates/pastey
      [`with_builtin_macros`]: https://crates.io/crates/with_builtin_macros
    ├ Announcement: https://github.com/dtolnay/paste
    ├ Solution: No safe upgrade is available!
    ├ paste v1.0.15
      ├── datadog-sidecar-ffi v0.0.1
      ├── libdd-libunwind-sys v1.0.3
      │   └── libdd-crashtracker v2.0.1
      │       ├── datadog-sidecar v0.0.1
      │       │   └── datadog-sidecar-ffi v0.0.1 (*)
      │       ├── datadog-sidecar-ffi v0.0.1 (*)
      │       └── libdd-crashtracker-ffi v43.0.0
      │           ├── datadog-sidecar v0.0.1 (*)
      │           └── datadog-sidecar-ffi v0.0.1 (*)
      ├── libdd-telemetry-ffi v43.0.0
      │   └── datadog-sidecar-ffi v0.0.1 (*)
      └── rmp v0.8.14
          ├── libdd-trace-utils v11.0.0
          │   ├── (dev) datadog-sidecar v0.0.1 (*)
          │   ├── (dev) datadog-sidecar-ffi v0.0.1 (*)
          │   ├── libdd-data-pipeline v9.0.0
          │   │   ├── datadog-sidecar v0.0.1 (*)
          │   │   └── libdd-live-debugger v0.1.0
          │   │       ├── datadog-sidecar v0.0.1 (*)
          │   │       └── datadog-sidecar-ffi v0.0.1 (*)
          │   ├── libdd-data-pipeline-core v0.1.0
          │   │   └── libdd-data-pipeline v9.0.0 (*)
          │   ├── libdd-trace-obfuscation v7.0.0
          │   │   ├── libdd-data-pipeline v9.0.0 (*)
          │   │   ├── libdd-data-pipeline-core v0.1.0 (*)
          │   │   └── libdd-trace-stats v8.0.0
          │   │       ├── datadog-sidecar v0.0.1 (*)
          │   │       ├── libdd-data-pipeline v9.0.0 (*)
          │   │       └── libdd-ipc v1.0.0
          │   │           ├── datadog-sidecar v0.0.1 (*)
          │   │           └── datadog-sidecar-ffi v0.0.1 (*)
          │   ├── libdd-trace-stats v8.0.0 (*)
          │   └── (dev) libdd-trace-utils v11.0.0 (*)
          ├── rmp-serde v1.3.0
          │   ├── datadog-sidecar v0.0.1 (*)
          │   ├── datadog-sidecar-ffi v0.0.1 (*)
          │   ├── libdd-data-pipeline v9.0.0 (*)
          │   ├── (dev) libdd-tinybytes v1.1.2
          │   │   ├── datadog-sidecar v0.0.1 (*)
          │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
          │   │   ├── libdd-data-pipeline v9.0.0 (*)
          │   │   ├── (dev) libdd-data-pipeline-core v0.1.0 (*)
          │   │   ├── libdd-ipc v1.0.0 (*)
          │   │   ├── (dev) libdd-tinybytes v1.1.2 (*)
          │   │   ├── (dev) libdd-trace-obfuscation v7.0.0 (*)
          │   │   └── libdd-trace-utils v11.0.0 (*)
          │   ├── libdd-trace-stats v8.0.0 (*)
          │   └── libdd-trace-utils v11.0.0 (*)
          └── rmpv v1.3.0
              └── libdd-trace-utils v11.0.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:306:1
    │
306 │ 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](https://github.com/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
      │   └── datadog-sidecar-ffi v0.0.1
      ├── libdd-common v5.2.0
      │   ├── datadog-sidecar v0.0.1 (*)
      │   ├── datadog-sidecar-ffi v0.0.1 (*)
      │   ├── libdd-capabilities-impl v4.0.0
      │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   ├── libdd-crashtracker v2.0.1
      │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
      │   │   │   └── libdd-crashtracker-ffi v43.0.0
      │   │   │       ├── datadog-sidecar v0.0.1 (*)
      │   │   │       └── datadog-sidecar-ffi v0.0.1 (*)
      │   │   ├── libdd-data-pipeline v9.0.0
      │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   └── libdd-live-debugger v0.1.0
      │   │   │       ├── datadog-sidecar v0.0.1 (*)
      │   │   │       └── datadog-sidecar-ffi v0.0.1 (*)
      │   │   ├── (dev) libdd-ffe v1.0.0
      │   │   │   └── datadog-sidecar v0.0.1 (*)
      │   │   ├── libdd-live-debugger v0.1.0 (*)
      │   │   ├── libdd-remote-config v4.0.0
      │   │   │   ├── (dev) datadog-sidecar v0.0.1 (*)
      │   │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
      │   │   │   ├── libdd-ffe v1.0.0 (*)
      │   │   │   ├── libdd-live-debugger v0.1.0 (*)
      │   │   │   └── (dev) libdd-remote-config v4.0.0 (*)
      │   │   ├── libdd-shared-runtime v3.0.0
      │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │   │   ├── libdd-dogstatsd-client v5.0.0
      │   │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
      │   │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │   │   │   └── libdd-trace-stats v8.0.0
      │   │   │   │       ├── datadog-sidecar v0.0.1 (*)
      │   │   │   │       ├── libdd-data-pipeline v9.0.0 (*)
      │   │   │   │       └── libdd-ipc v1.0.0
      │   │   │   │           ├── datadog-sidecar v0.0.1 (*)
      │   │   │   │           └── datadog-sidecar-ffi v0.0.1 (*)
      │   │   │   ├── libdd-telemetry v7.0.0
      │   │   │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
      │   │   │   │   ├── libdd-crashtracker v2.0.1 (*)
      │   │   │   │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │   │   │   ├── libdd-telemetry-ffi v43.0.0
      │   │   │   │   │   └── datadog-sidecar-ffi v0.0.1 (*)
      │   │   │   │   └── libdd-trace-stats v8.0.0 (*)
      │   │   │   └── libdd-trace-stats v8.0.0 (*)
      │   │   ├── (dev) libdd-telemetry v7.0.0 (*)
      │   │   ├── libdd-telemetry-ffi v43.0.0 (*)
      │   │   ├── libdd-trace-stats v8.0.0 (*)
      │   │   └── libdd-trace-utils v11.0.0
      │   │       ├── (dev) datadog-sidecar v0.0.1 (*)
      │   │       ├── (dev) datadog-sidecar-ffi v0.0.1 (*)
      │   │       ├── libdd-data-pipeline v9.0.0 (*)
      │   │       ├── libdd-data-pipeline-core v0.1.0
      │   │       │   └── libdd-data-pipeline v9.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v7.0.0
      │   │       │   ├── libdd-data-pipeline v9.0.0 (*)
      │   │       │   ├── libdd-data-pipeline-core v0.1.0 (*)
      │   │       │   └── libdd-trace-stats v8.0.0 (*)
      │   │       ├── libdd-trace-stats v8.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v11.0.0 (*)
      │   ├── libdd-common-ffi v43.0.0
      │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   ├── datadog-sidecar-ffi v0.0.1 (*)
      │   │   ├── libdd-crashtracker-ffi v43.0.0 (*)
      │   │   └── libdd-telemetry-ffi v43.0.0 (*)
      │   ├── (build) libdd-crashtracker v2.0.1 (*)
      │   ├── libdd-crashtracker-ffi v43.0.0 (*)
      │   ├── libdd-data-pipeline v9.0.0 (*)
      │   ├── libdd-data-pipeline-core v0.1.0 (*)
      │   ├── libdd-dogstatsd-client v5.0.0 (*)
      │   ├── libdd-ffe v1.0.0 (*)
      │   ├── libdd-ipc v1.0.0 (*)
      │   ├── libdd-live-debugger v0.1.0 (*)
      │   ├── libdd-remote-config v4.0.0 (*)
      │   ├── libdd-shared-runtime v3.0.0 (*)
      │   ├── libdd-telemetry v7.0.0 (*)
      │   ├── libdd-telemetry-ffi v43.0.0 (*)
      │   ├── libdd-trace-obfuscation v7.0.0 (*)
      │   ├── libdd-trace-stats v8.0.0 (*)
      │   └── libdd-trace-utils v11.0.0 (*)
      ├── libdd-crashtracker v2.0.1 (*)
      ├── (dev) libdd-data-pipeline v9.0.0 (*)
      ├── (dev) libdd-ddsketch v1.1.1
      │   ├── libdd-data-pipeline v9.0.0 (*)
      │   ├── libdd-ipc v1.0.0 (*)
      │   ├── libdd-telemetry v7.0.0 (*)
      │   └── libdd-trace-stats v8.0.0 (*)
      ├── (dev) libdd-trace-normalization v4.0.0
      │   ├── libdd-data-pipeline v9.0.0 (*)
      │   └── libdd-trace-utils v11.0.0 (*)
      ├── (dev) libdd-trace-stats v8.0.0 (*)
      ├── libdd-trace-utils v11.0.0 (*)
      └── proptest v1.5.0
          ├── (dev) libdd-common v5.2.0 (*)
          └── (dev) libdd-tinybytes v1.1.2
              ├── datadog-sidecar v0.0.1 (*)
              ├── datadog-sidecar-ffi v0.0.1 (*)
              ├── libdd-data-pipeline v9.0.0 (*)
              ├── (dev) libdd-data-pipeline-core v0.1.0 (*)
              ├── libdd-ipc v1.0.0 (*)
              ├── (dev) libdd-tinybytes v1.1.2 (*)
              ├── (dev) libdd-trace-obfuscation v7.0.0 (*)
              └── libdd-trace-utils v11.0.0 (*)

error[vulnerability]: Denial of Service via Stack Exhaustion
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:401:1
    │
401 │ 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 v4.0.0
      │   ├── (dev) datadog-sidecar v0.0.1
      │   │   └── datadog-sidecar-ffi v0.0.1
      │   ├── datadog-sidecar-ffi v0.0.1 (*)
      │   ├── libdd-ffe v1.0.0
      │   │   └── datadog-sidecar v0.0.1 (*)
      │   ├── libdd-live-debugger v0.1.0
      │   │   ├── datadog-sidecar v0.0.1 (*)
      │   │   └── datadog-sidecar-ffi v0.0.1 (*)
      │   └── (dev) libdd-remote-config v4.0.0 (*)
      └── tracing-appender v0.2.3
          └── libdd-log v1.0.0
              └── (dev) libdd-data-pipeline v9.0.0
                  ├── datadog-sidecar v0.0.1 (*)
         ...*[Comment body truncated]*

@datadog-official datadog-official Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Datadog Autotest: PASS

More details

Source inspection finds no reportable defect in the dependency changes, feature selections, or macro syntax updates.

Was this helpful? React 👍 or 👎

Open Bits AI session

🤖 Datadog Autotest · Commit 737075e · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest

@github-actions

github-actions Bot commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

📚 Documentation Check Results

⚠️ 30097 documentation warning(s) found

📦 bin_tests - 1704 warning(s)

📦 builder - 207 warning(s)

📦 datadog-profiling-replayer - 660 warning(s)

📦 datadog-sidecar-ffi - 3216 warning(s)

📦 datadog-sidecar-macros - 2 warning(s)

📦 datadog-sidecar - 2927 warning(s)

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

📦 libdd-alloc - 3 warning(s)

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

📦 libdd-capabilities - 35 warning(s)

📦 libdd-common-ffi - 278 warning(s)

📦 libdd-common - 169 warning(s)

📦 libdd-crashtracker-ffi - 1283 warning(s)

📦 libdd-crashtracker - 1112 warning(s)

📦 libdd-data-pipeline-core - 805 warning(s)

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

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

📦 libdd-ddsketch - 8 warning(s)

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

📦 libdd-ffe-ffi - 548 warning(s)

📦 libdd-ffe-test-suite - ✅ No warnings

📦 libdd-ffe - 387 warning(s)

📦 libdd-http-client - ✅ No warnings

📦 libdd-ipc-macros - 1 warning(s)

📦 libdd-ipc - 1019 warning(s)

📦 libdd-library-config-ffi - 578 warning(s)

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

📦 libdd-live-debugger-ffi - 1951 warning(s)

📦 libdd-live-debugger - 1658 warning(s)

📦 libdd-log - 4 warning(s)

📦 libdd-otel-thread-ctx - 1 warning(s)

📦 libdd-profiling-ffi - 770 warning(s)

📦 libdd-profiling-heap-gotter-ffi - 333 warning(s)

📦 libdd-profiling-heap-gotter - 55 warning(s)

📦 libdd-profiling-heap-sampler - 49 warning(s)

📦 libdd-profiling-protobuf - 11 warning(s)

📦 libdd-profiling - 649 warning(s)

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

📦 libdd-sampling - 136 warning(s)

📦 libdd-shared-runtime - 213 warning(s)

📦 libdd-telemetry-ffi - 734 warning(s)

📦 libdd-telemetry - 570 warning(s)

📦 libdd-tinybytes - 7 warning(s)

📦 libdd-trace-normalization - 1 warning(s)

📦 libdd-trace-obfuscation - 853 warning(s)

📦 libdd-trace-protobuf - 1 warning(s)

📦 libdd-trace-stats - 914 warning(s)

📦 libdd-trace-utils - 765 warning(s)

📦 libdd-tracer-flare - 1025 warning(s)

📦 spawn_worker - 74 warning(s)

📦 test_spawn_from_lib - 78 warning(s)

📦 libdd-wasm-tests - ✅ No warnings

📦 tools - 129 warning(s)

📦 cc_utils - 24 warning(s)

📦 sidecar_mockgen - 2 warning(s)


Updated: 2026-09-09 09:51:43 UTC | Commit: 060562f | missing-docs job results

@datadog-official

datadog-official Bot commented Sep 7, 2026

Copy link
Copy Markdown

Pipelines  Tests

⚠️ Warnings

Your PR has failed checks. Please review the issues below and take necessary action before merging.

🚦 3 Pipeline jobs failed

Verify trace-protobuf | Verify trace-protobuf .proto files are in sync with datadog-agent — 🔧 Needs a code fix, caused by this PR

View more details · View in GitHub Actions

Serialization/deserialization errors due to missing implementations for HashMap types in libdd-trace-protobuf.

semver-check | semver-check — 🔧 Needs a code fix, caused by this PR

View more details · View in GitHub Actions

Compilation error in libdd-trace-protobuf due to missing serde traits for HashMap types.

Required checks pass | allchecks

View more details · View in GitHub Actions

Some checks have failed or timed out.

📋 Copy fix prompt
CI on my pull request is failing. Help me find and fix the root cause of each failing job below — they were flagged as caused by changes in this PR, so focus on the diff. For each job, explain the failure and propose a fix.

Before you start, set up the Datadog software-delivery tooling so you can
query the CI data yourself:

1. Check whether you already have the Datadog software-delivery MCP tools
   (e.g. a `search_datadog_ci_pipeline_events` tool) and the `unblock-pr` skill.
2. If either is missing, STOP and ask me for permission before installing
   anything. Do not install or run anything until I have said yes.
3. Only with my explicit approval, set up the Datadog software-delivery MCP
   server and skills by following:
     https://docs.datadoghq.com/getting_started/software_delivery_mcp_tools/
   then restart so the skill is picked up.
4. If I decline, skip all of the above and work from the context below alone.

Then run /unblock-pr — it will pull the CI data itself. The job context below is what we already know.

If /unblock-pr is not available — because I declined the setup above, or it did not install — work from the context below instead.

Datadog has already classified this failure as caused by changes in this PR.
Take that as given and work the fix:

1. Locate the change. Diff this branch against its base and find the change
   that produces this error. Explain the mechanism, don't just name a file:
     git fetch origin && git diff $(git merge-base origin/main HEAD)...HEAD
2. Reproduce it locally. Run the failing job's command or test before
   proposing anything.
3. Propose the smallest fix that addresses the root cause — not a workaround,
   not a broadened assertion, not a disabled or skipped test.
4. Re-run the same command to confirm, and say exactly what you ran.
5. If the failure turns out to be intermittent rather than deterministic, say
   so plainly instead of "fixing" it — that is a flaky test, and patching it
   hides the problem.

If the right move is to re-run the job rather than change code, use the job
link in the context below. For GitHub Actions: `gh run rerun <run-id> --failed`,
where the run ID is the number after `/runs/` in that URL (not the trailing
number, which is the job ID).

Branch: yannham/all-workspace-deps

Verify trace-protobuf | Verify trace-protobuf .proto files are in sync with datadog-agent
Commit: 060562f9423b2b2117e64c8741635718a4121641
Error (code / build):
Serialization/deserialization errors due to missing implementations for HashMap types in libdd-trace-protobuf.
CI job: https://github.com/DataDog/libdatadog/actions/runs/34336520985/job/102417073229

semver-check | semver-check
Commit: 060562f9423b2b2117e64c8741635718a4121641
Error (code / build):
Compilation error in libdd-trace-protobuf due to missing serde traits for HashMap types.
CI job: https://github.com/DataDog/libdatadog/actions/runs/34336520896/job/102417231316

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
Patch Coverage: 50.00%
Overall Coverage: 77.55% (+0.30%)

Useful? React with 👍 / 👎

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: c56110d | Docs | View more details | Give us feedback!

@dd-octo-sts

dd-octo-sts Bot commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

Artifact Size Benchmark Report

aarch64-alpine-linux-musl
Artifact Baseline Commit Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a 91.32 MB 91.36 MB +.04% (+42.50 KB) 🔍
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so 8.45 MB 8.45 MB 0% (0 B) 👌
aarch64-unknown-linux-gnu
Artifact Baseline Commit Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a 102.61 MB 102.72 MB +.10% (+113.92 KB) 🔍
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so 11.38 MB 11.38 MB +.02% (+2.61 KB) 🔍
libdatadog-x64-windows
Artifact Baseline Commit Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll 27.32 MB 27.37 MB +.16% (+45.00 KB) 🔍
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib 96.08 KB 96.08 KB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb 185.41 MB 185.39 MB -0% (-16.00 KB) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib 803.94 MB 801.30 MB --.32% (-2.63 MB) 💪
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll 9.00 MB 9.01 MB +.04% (+4.50 KB) 🔍
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib 96.08 KB 96.08 KB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb 26.20 MB 26.20 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib 52.21 MB 52.21 MB +.01% (+8.51 KB) 🔍
libdatadog-x86-windows
Artifact Baseline Commit Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll 23.82 MB 23.87 MB +.19% (+47.50 KB) 🔍
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib 97.58 KB 97.58 KB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb 190.44 MB 190.50 MB +.03% (+64.00 KB) 🔍
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib 786.99 MB 785.23 MB --.22% (-1.75 MB) 💪
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll 6.96 MB 6.95 MB --.04% (-3.50 KB) 💪
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib 97.58 KB 97.58 KB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb 28.18 MB 28.16 MB --.05% (-16.00 KB) 💪
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib 49.70 MB 49.68 MB --.04% (-20.67 KB) 💪
x86_64-alpine-linux-musl
Artifact Baseline Commit Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a 81.48 MB 81.48 MB +0% (+4.10 KB) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so 9.41 MB 9.41 MB --.04% (-4.00 KB) 💪
x86_64-unknown-linux-gnu
Artifact Baseline Commit Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a 97.21 MB 97.23 MB +.02% (+21.83 KB) 🔍
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so 11.46 MB 11.46 MB +0% (+568 B) 👌

@pr-commenter

pr-commenter Bot commented Sep 7, 2026

Copy link
Copy Markdown

Benchmarks

Comparison

Benchmark execution time: 2026-09-09 10:25:57

Comparing candidate commit c56110d in PR branch yannham/all-workspace-deps with baseline commit 50bcdb7 in branch main.

📊 Benchmarking dashboard

Found 10 performance improvements and 7 performance regressions! Performance is the same for 136 metrics, 0 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

  • 🟩 = significantly better candidate vs. baseline
  • 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:flagevaluation_evp/coalescer/scale/2500flags_500users_20fields

  • 🟥 execution_time [+222.228µs; +231.194µs] or [+4.121%; +4.288%]

scenario:flagevaluation_evp/coalescer/typical/100flags_50users_10fields

  • 🟥 execution_time [+13.567µs; +30.168µs] or [+7.386%; +16.423%]
  • 🟥 throughput [-53641.334op/s; -45735.128op/s] or [-9.853%; -8.401%]

scenario:normalization/normalize_service/normalize_service/[empty string]

  • 🟥 execution_time [+1.781µs; +1.816µs] or [+4.993%; +5.091%]
  • 🟥 throughput [-1358894.245op/s; -1332251.772op/s] or [-4.848%; -4.753%]

scenario:vec_map/as_deduped_map/already_deduped/16

  • 🟥 execution_time [+5.477ns; +5.642ns] or [+21.533%; +22.185%]

scenario:vec_map/as_deduped_map/already_deduped/8

  • 🟩 execution_time [-1.815ns; -1.797ns] or [-11.559%; -11.449%]

scenario:vec_map/contains_key/128

  • 🟩 execution_time [-650.252ns; -637.294ns] or [-4.141%; -4.058%]
  • 🟩 throughput [+344958.592op/s; +352105.237op/s] or [+4.232%; +4.320%]

scenario:vec_map/contains_key/16

  • 🟩 execution_time [-30.767ns; -30.405ns] or [-11.735%; -11.597%]
  • 🟩 throughput [+8010177.569op/s; +8111531.074op/s] or [+13.126%; +13.292%]

scenario:vec_map/contains_key/64

  • 🟩 execution_time [-181.267ns; -177.170ns] or [-4.322%; -4.224%]
  • 🟩 throughput [+673386.511op/s; +689041.179op/s] or [+4.413%; +4.515%]

scenario:vec_map/contains_key/8

  • 🟩 execution_time [-8.265ns; -7.983ns] or [-10.456%; -10.099%]
  • 🟩 throughput [+11396289.765op/s; +11772038.799op/s] or [+11.258%; +11.630%]

scenario:vec_map/get_miss/16

  • 🟥 execution_time [+0.931ns; +0.996ns] or [+9.962%; +10.657%]

scenario:vec_map/get_miss/8

  • 🟩 execution_time [-1.345ns; -1.316ns] or [-17.893%; -17.500%]

Benchmark execution time: 2026-09-09 10:28:47

Comparing candidate commit c56110d in PR branch yannham/all-workspace-deps with baseline commit 50bcdb7 in branch main.

📊 Benchmarking dashboard

Found 9 performance improvements and 20 performance regressions! Performance is the same for 140 metrics, 10 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

  • 🟩 = significantly better candidate vs. baseline
  • 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:credit_card/is_card_number/ 378282246310005

  • 🟥 execution_time [+4.864µs; +4.965µs] or [+7.115%; +7.263%]
  • 🟥 throughput [-990181.577op/s; -971283.131op/s] or [-6.769%; -6.640%]

scenario:credit_card/is_card_number/378282246310005

  • 🟥 execution_time [+4.778µs; +4.895µs] or [+7.366%; +7.546%]
  • 🟥 throughput [-1081178.321op/s; -1057161.862op/s] or [-7.014%; -6.858%]

scenario:credit_card/is_card_number/37828224631000521389798

  • 🟥 execution_time [+6.649µs; +6.680µs] or [+14.523%; +14.590%]
  • 🟥 throughput [-2781968.839op/s; -2768593.280op/s] or [-12.737%; -12.676%]

scenario:credit_card/is_card_number/x371413321323331

  • 🟩 execution_time [-728.279ns; -725.962ns] or [-11.291%; -11.255%]
  • 🟩 throughput [+19664372.372op/s; +19728630.909op/s] or [+12.684%; +12.726%]

scenario:credit_card/is_card_number_no_luhn/ 378282246310005

  • 🟥 execution_time [+4.016µs; +4.066µs] or [+7.433%; +7.525%]
  • 🟥 throughput [-1295486.583op/s; -1280175.908op/s] or [-6.999%; -6.917%]

scenario:credit_card/is_card_number_no_luhn/378282246310005

  • 🟥 execution_time [+4.321µs; +4.380µs] or [+8.557%; +8.674%]
  • 🟥 throughput [-1580739.989op/s; -1560421.197op/s] or [-7.983%; -7.880%]

scenario:credit_card/is_card_number_no_luhn/37828224631000521389798

  • 🟥 execution_time [+6.625µs; +6.663µs] or [+14.468%; +14.550%]
  • 🟥 throughput [-2775635.367op/s; -2758463.217op/s] or [-12.710%; -12.632%]

scenario:credit_card/is_card_number_no_luhn/x371413321323331

  • 🟩 execution_time [-729.068ns; -726.495ns] or [-11.300%; -11.260%]
  • 🟩 throughput [+19670479.873op/s; +19740972.344op/s] or [+12.691%; +12.737%]

scenario:ddsketch_encode/encode_to_vec/clustered_near_zero

  • 🟥 execution_time [+45.198ns; +50.629ns] or [+6.482%; +7.261%]

scenario:ddsketch_encode/encode_to_vec/large_values

  • 🟥 execution_time [+72.243ns; +76.680ns] or [+8.602%; +9.130%]

scenario:ddsketch_encode/encode_to_vec/mixed

  • 🟥 execution_time [+80.164ns; +87.385ns] or [+6.517%; +7.104%]

scenario:glob_matcher/ascii_case_insensitive_match/wall_time

  • 🟥 execution_time [+1.222ns; +1.249ns] or [+4.464%; +4.562%]

scenario:glob_matcher/ascii_exact_match/wall_time

  • 🟥 execution_time [+1.257ns; +1.280ns] or [+4.596%; +4.681%]

scenario:glob_matcher/ascii_exact_miss/wall_time

  • 🟥 execution_time [+1.076ns; +1.121ns] or [+8.682%; +9.044%]

scenario:no_profiler/short_circuit/4096

  • 🟥 execution_time [+7.922ns; +8.078ns] or [+8.069%; +8.228%]

scenario:profiler_attached/fast_path_system/4096

  • 🟩 execution_time [-4.396ns; -4.246ns] or [-4.180%; -4.037%]

scenario:sql/obfuscate_sql_string

  • 🟥 execution_time [+18.918µs; +19.144µs] or [+6.770%; +6.851%]

scenario:trace_buffer/2_senders/no_delay

  • 🟩 execution_time [-95.032µs; -77.651µs] or [-5.521%; -4.512%]
  • 🟩 throughput [+49730.218op/s; +60950.292op/s] or [+4.752%; +5.824%]

scenario:trace_buffer/4_senders/no_delay

  • 🟩 execution_time [-166.470µs; -154.178µs] or [-4.436%; -4.109%]
  • 🟩 throughput [+41185.683op/s; +44481.897op/s] or [+4.293%; +4.636%]

Unstable benchmarks

These benchmarks have a confidence interval too wide to call a change; treat them as noise rather than signal.

scenario:datadog_sample_span/parent_not_sampled_short_circuit/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+293.356%; -492.577%]

scenario:datadog_sample_span/parent_sampled_short_circuit/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+293.357%; -492.576%]

scenario:glob_matcher/ascii_case_insensitive_match/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+293.366%; -492.567%]

scenario:glob_matcher/ascii_exact_match/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+293.351%; -492.582%]

scenario:glob_matcher/ascii_exact_miss/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+293.393%; -492.541%]

scenario:glob_matcher/ascii_wildcard_backtrack_match/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+293.404%; -492.530%]

scenario:glob_matcher/ascii_wildcard_heavy_backtrack/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+293.400%; -492.534%]

scenario:glob_matcher/ascii_wildcard_question_match/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+293.405%; -492.529%]

scenario:glob_matcher/ascii_wildcard_star_match/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+293.405%; -492.529%]

scenario:glob_matcher/star_short_circuit/allocated_bytes

  • unstable execution_time [-0.000ns; +0.000ns] or [+293.366%; -492.566%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

@typotter typotter left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

lgtm for FFE

Comment thread libdd-trace-obfuscation/src/http.rs
Comment thread libdd-trace-protobuf/Cargo.toml Outdated
Comment on lines +18 to +19
# `std` is required: it gates the alloc-backed `ByteBuf`/`Vec<u8>` serde impls used by
# `#[serde(with = "serde_bytes")]` in the generated code.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'm not sure this is needed, I don't think the crate is supposed to no-std anyway

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Sorry, what do yo think is not needed? The comment? The default-features?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The comment is mentioning std which is a bit confusing (not clear it's talking about the feature). I guess it's fine to explain why we add the default feature it just seems weird that it's the only dependency explaining it.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Ah, got it. I think it's because elsewhere I've avoided std features on many crates, preferring alloc, in the spirit of the lint we have (make it easier to move crates to no-std in the future). Though the comment is dubious because serde-bytes does have an alloc feature. I'll either remove it if I can get by with alloc, or reword it to make things clearer 👍

Comment thread libdd-trace-stats/src/span_concentrator/aggregation.rs
@yannham
yannham requested a review from a team as a code owner September 9, 2026 09:45

@datadog-official datadog-official Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Datadog Autotest: PASS

More details

The workspace dependency move keeps each leaf crate's feature choice. The required duplicate, priority-queue, and elf API changes match the new dependency versions.

Was this helpful? React 👍 or 👎

Open Bits AI session

🤖 Datadog Autotest · Commit c56110d · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants