Skip to content

chore(release): merge release branch to main (proposal for libdd-data-pipeline (#1781))#1783

Merged
iunanua merged 1 commit intomainfrom
release/libdd-data-pipeline/20260323-165323
Mar 24, 2026
Merged

chore(release): merge release branch to main (proposal for libdd-data-pipeline (#1781))#1783
iunanua merged 1 commit intomainfrom
release/libdd-data-pipeline/20260323-165323

Conversation

@dd-octo-sts
Copy link
Copy Markdown
Contributor

@dd-octo-sts dd-octo-sts bot commented Mar 24, 2026

This PR merges the release branch to main

@dd-octo-sts @iunanua
chore(release): proposal for libdd-data-pipeline (#1781)
dfc4f08 
# Release proposal for libdd-data-pipeline and its dependencies

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

## libdd-common
**Next version:** `3.0.1`

**Semver bump:** `patch`
**Tag:** `libdd-common-v3.0.1`

### Commits

- chore(build): update reqwest and quinn-proto dependency for dependabot
alert (#1774)
- chore(build): ekump/APMSP-2718 update aws-lc dependencies (#1751)
## libdd-trace-protobuf
**Next version:** `3.0.0`

**Semver bump:** `major`
**Tag:** `libdd-trace-protobuf-v3.0.0`

### Commits

- fix(trace-stats): rename wrongly cased stats fields (#1780)
- feat(rc)!: add process_tags to remote config Target (#1586)
## libdd-telemetry
**Next version:** `3.1.0`

**Semver bump:** `minor`
**Tag:** `libdd-telemetry-v3.1.0`

### Commits

- refactor(sidecar)!: Refactor tarpc away (#1742)
## libdd-trace-utils
**Next version:** `3.0.0`

**Semver bump:** `major`
**Tag:** `libdd-trace-utils-v3.0.0`

### Commits

- fix(trace-stats): rename wrongly cased stats fields (#1780)
- refactor(trace-utils)!: change header name type to accept dynamic
values (#1722)
## libdd-data-pipeline
**Next version:** `3.0.0`

**Semver bump:** `major`
**Tag:** `libdd-data-pipeline-v3.0.0`

### Commits

- feat(agents)!: retrieve container tags hash from /info endpoint
(#1700)
- refactor(trace-utils)!: change header name type to accept dynamic
values (#1722)

---------

Co-authored-by: dd-octo-sts[bot] <200755185+dd-octo-sts[bot]@users.noreply.github.com>
@github-actions
Copy link
Copy Markdown

github-actions bot commented Mar 24, 2026 •
edited
Loading

📚 Documentation Check Results

⚠️ 5188 documentation warning(s) found

📦 libdd-common - 166 warning(s)

📦 libdd-crashtracker - 1049 warning(s)

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

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

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

📦 libdd-profiling - 647 warning(s)

📦 libdd-telemetry - 476 warning(s)

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

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

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

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

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

Updated: 2026-03-24 08:50:59 UTC | Commit: 7f14f86 | missing-docs job results

@github-actions
Copy link
Copy Markdown

github-actions bot commented Mar 24, 2026 •
edited
Loading

🔒 Cargo Deny Results

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

📦 libdd-common - 3 error(s)

Show output 
error[vulnerability]: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN
  ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:6:1
  │
6 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
  │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
  │
  ├ ID: RUSTSEC-2026-0044
  ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0044
  ├ A logic error in CN (Common Name) validation allows certificates with
    wildcard or raw UTF-8 Unicode CN values to bypass name constraints
    enforcement. The `cn2dnsid` function does not recognize these CN patterns
    as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
    validation. However, `X509_check_host` accepts these CN values when no
    dNSName SAN is present, allowing certificates to bypass name constraints
    while still being used for hostname verification.
    
    Customers of AWS services do not need to take action. Applications using
    `aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.
    
    ## Workarounds
    
    Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
    fallback are not affected. Applications that only encounter certificates
    with dNSName SANs (standard for public WebPKI) are also not affected.
    
    Otherwise, there is no workaround and applications using `aws-lc-sys` should
    upgrade to the most recent releases of `aws-lc-sys`.
  ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
  ├ aws-lc-sys v0.38.0
    └── aws-lc-rs v1.16.1
        ├── rustls v0.23.37
        │   ├── hyper-rustls v0.27.7
        │   │   ├── libdd-common v3.0.1
        │   │   └── reqwest v0.13.2
        │   │       └── libdd-common v3.0.1 (*)
        │   ├── libdd-common v3.0.1 (*)
        │   ├── reqwest v0.13.2 (*)
        │   ├── rustls-platform-verifier v0.6.2
        │   │   └── reqwest v0.13.2 (*)
        │   └── tokio-rustls v0.26.0
        │       ├── hyper-rustls v0.27.7 (*)
        │       ├── libdd-common v3.0.1 (*)
        │       └── reqwest v0.13.2 (*)
        └── rustls-webpki v0.103.9
            ├── rustls v0.23.37 (*)
            └── rustls-platform-verifier v0.6.2 (*)

error[vulnerability]: CRL Distribution Point Scope Check Logic Error in AWS-LC
  ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:6:1
  │
6 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
  │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
  │
  ├ ID: RUSTSEC-2026-0048
  ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0048
  ├ A logic error in CRL distribution point matching in AWS-LC allows a revoked
    certificate to bypass revocation checks during certificate validation, when
    the application enables CRL checking and uses partitioned CRLs with Issuing
    Distribution Point (IDP) extensions.
    
    Customers of AWS services do not need to take action. `aws-lc-sys` contains
    code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
    recent release of `aws-lc-sys`.
    
    ## Workarounds
    
    Applications can workaround this issue if they do not enable CRL checking
    (`X509_V_FLAG_CRL_CHECK`). Applications using complete (non-partitioned)
    CRLs without IDP extensions are also not affected.
    
    Otherwise, there is no workaround and applications using `aws-lc-sys` should
    upgrade to the most recent releases of `aws-lc-sys`.
  ├ Announcement: https://aws.amazon.com/security/security-bulletins/2026-010-AWS
  ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
  ├ aws-lc-sys v0.38.0
    └── aws-lc-rs v1.16.1
        ├── rustls v0.23.37
        │   ├── hyper-rustls v0.27.7
        │   │   ├── libdd-common v3.0.1
        │   │   └── reqwest v0.13.2
        │   │       └── libdd-common v3.0.1 (*)
        │   ├── libdd-common v3.0.1 (*)
        │   ├── reqwest v0.13.2 (*)
        │   ├── rustls-platform-verifier v0.6.2
        │   │   └── reqwest v0.13.2 (*)
        │   └── tokio-rustls v0.26.0
        │       ├── hyper-rustls v0.27.7 (*)
        │       ├── libdd-common v3.0.1 (*)
        │       └── reqwest v0.13.2 (*)
        └── rustls-webpki v0.103.9
            ├── rustls v0.23.37 (*)
            └── rustls-platform-verifier v0.6.2 (*)

error[vulnerability]: CRLs not considered authoritative by Distribution Point due to faulty matching logic
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:130:1
    │
130 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0049
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
    ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
      
      The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
      
      This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
      
      More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
      
      This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      ├── rustls v0.23.37
      │   ├── hyper-rustls v0.27.7
      │   │   ├── libdd-common v3.0.1
      │   │   └── reqwest v0.13.2
      │   │       └── libdd-common v3.0.1 (*)
      │   ├── libdd-common v3.0.1 (*)
      │   ├── reqwest v0.13.2 (*)
      │   ├── rustls-platform-verifier v0.6.2
      │   │   └── reqwest v0.13.2 (*)
      │   └── tokio-rustls v0.26.0
      │       ├── hyper-rustls v0.27.7 (*)
      │       ├── libdd-common v3.0.1 (*)
      │       └── reqwest v0.13.2 (*)
      └── rustls-platform-verifier v0.6.2 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-crashtracker - 4 error(s)

Show output 
error[vulnerability]: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:11:1
   │
11 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0044
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0044
   ├ A logic error in CN (Common Name) validation allows certificates with
     wildcard or raw UTF-8 Unicode CN values to bypass name constraints
     enforcement. The `cn2dnsid` function does not recognize these CN patterns
     as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
     validation. However, `X509_check_host` accepts these CN values when no
     dNSName SAN is present, allowing certificates to bypass name constraints
     while still being used for hostname verification.
     
     Customers of AWS services do not need to take action. Applications using
     `aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
     fallback are not affected. Applications that only encounter certificates
     with dNSName SANs (standard for public WebPKI) are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   └── libdd-common v3.0.1
         │   │       ├── (build) libdd-crashtracker v1.0.0
         │   │       └── libdd-telemetry v3.1.0
         │   │           └── libdd-crashtracker v1.0.0 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.1 (*)
         └── rustls-webpki v0.103.9
             └── rustls v0.23.37 (*)

error[vulnerability]: CRL Distribution Point Scope Check Logic Error in AWS-LC
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:11:1
   │
11 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0048
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0048
   ├ A logic error in CRL distribution point matching in AWS-LC allows a revoked
     certificate to bypass revocation checks during certificate validation, when
     the application enables CRL checking and uses partitioned CRLs with Issuing
     Distribution Point (IDP) extensions.
     
     Customers of AWS services do not need to take action. `aws-lc-sys` contains
     code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
     recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications can workaround this issue if they do not enable CRL checking
     (`X509_V_FLAG_CRL_CHECK`). Applications using complete (non-partitioned)
     CRLs without IDP extensions are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Announcement: https://aws.amazon.com/security/security-bulletins/2026-010-AWS
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   └── libdd-common v3.0.1
         │   │       ├── (build) libdd-crashtracker v1.0.0
         │   │       └── libdd-telemetry v3.1.0
         │   │           └── libdd-crashtracker v1.0.0 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.1 (*)
         └── rustls-webpki v0.103.9
             └── rustls v0.23.37 (*)

error[unmaintained]: paste - no longer maintained
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:131:1
    │
131 │ 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
      └── libdd-libunwind-sys v0.1.0
          └── libdd-crashtracker v1.0.0

error[vulnerability]: CRLs not considered authoritative by Distribution Point due to faulty matching logic
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:162:1
    │
162 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0049
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
    ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
      
      The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
      
      This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
      
      More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
      
      This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      └── rustls v0.23.37
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v3.0.1
          │       ├── (build) libdd-crashtracker v1.0.0
          │       └── libdd-telemetry v3.1.0
          │           └── libdd-crashtracker v1.0.0 (*)
          ├── libdd-common v3.0.1 (*)
          └── tokio-rustls v0.26.0
              ├── hyper-rustls v0.27.7 (*)
              └── libdd-common v3.0.1 (*)

advisories FAILED, bans ok, sources ok

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

Show output 
error[vulnerability]: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:32:1
   │
32 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0044
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0044
   ├ A logic error in CN (Common Name) validation allows certificates with
     wildcard or raw UTF-8 Unicode CN values to bypass name constraints
     enforcement. The `cn2dnsid` function does not recognize these CN patterns
     as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
     validation. However, `X509_check_host` accepts these CN values when no
     dNSName SAN is present, allowing certificates to bypass name constraints
     while still being used for hostname verification.
     
     Customers of AWS services do not need to take action. Applications using
     `aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
     fallback are not affected. Applications that only encounter certificates
     with dNSName SANs (standard for public WebPKI) are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   └── libdd-common v3.0.1
         │   │       ├── libdd-data-pipeline v3.0.0
         │   │       ├── libdd-dogstatsd-client v1.0.2
         │   │       │   └── libdd-data-pipeline v3.0.0 (*)
         │   │       ├── libdd-telemetry v3.1.0
         │   │       │   └── libdd-data-pipeline v3.0.0 (*)
         │   │       └── libdd-trace-utils v3.0.0
         │   │           ├── libdd-data-pipeline v3.0.0 (*)
         │   │           ├── libdd-trace-stats v1.0.4
         │   │           │   └── libdd-data-pipeline v3.0.0 (*)
         │   │           └── (dev) libdd-trace-utils v3.0.0 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.1 (*)
         └── rustls-webpki v0.103.9
             └── rustls v0.23.37 (*)

error[vulnerability]: CRL Distribution Point Scope Check Logic Error in AWS-LC
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:32:1
   │
32 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0048
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0048
   ├ A logic error in CRL distribution point matching in AWS-LC allows a revoked
     certificate to bypass revocation checks during certificate validation, when
     the application enables CRL checking and uses partitioned CRLs with Issuing
     Distribution Point (IDP) extensions.
     
     Customers of AWS services do not need to take action. `aws-lc-sys` contains
     code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
     recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications can workaround this issue if they do not enable CRL checking
     (`X509_V_FLAG_CRL_CHECK`). Applications using complete (non-partitioned)
     CRLs without IDP extensions are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Announcement: https://aws.amazon.com/security/security-bulletins/2026-010-AWS
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   └── libdd-common v3.0.1
         │   │       ├── libdd-data-pipeline v3.0.0
         │   │       ├── libdd-dogstatsd-client v1.0.2
         │   │       │   └── libdd-data-pipeline v3.0.0 (*)
         │   │       ├── libdd-telemetry v3.1.0
         │   │       │   └── libdd-data-pipeline v3.0.0 (*)
         │   │       └── libdd-trace-utils v3.0.0
         │   │           ├── libdd-data-pipeline v3.0.0 (*)
         │   │           ├── libdd-trace-stats v1.0.4
         │   │           │   └── libdd-data-pipeline v3.0.0 (*)
         │   │           └── (dev) libdd-trace-utils v3.0.0 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.1 (*)
         └── rustls-webpki v0.103.9
             └── rustls v0.23.37 (*)

error[vulnerability]: CRLs not considered authoritative by Distribution Point due to faulty matching logic
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:241:1
    │
241 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0049
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
    ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
      
      The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
      
      This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
      
      More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
      
      This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      └── rustls v0.23.37
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v3.0.1
          │       ├── libdd-data-pipeline v3.0.0
          │       ├── libdd-dogstatsd-client v1.0.2
          │       │   └── libdd-data-pipeline v3.0.0 (*)
          │       ├── libdd-telemetry v3.1.0
          │       │   └── libdd-data-pipeline v3.0.0 (*)
          │       └── libdd-trace-utils v3.0.0
          │           ├── libdd-data-pipeline v3.0.0 (*)
          │           ├── libdd-trace-stats v1.0.4
          │           │   └── libdd-data-pipeline v3.0.0 (*)
          │           └── (dev) libdd-trace-utils v3.0.0 (*)
          ├── libdd-common v3.0.1 (*)
          └── tokio-rustls v0.26.0
              ├── hyper-rustls v0.27.7 (*)
              └── libdd-common v3.0.1 (*)

error[vulnerability]: Denial of Service via Stack Exhaustion
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:282:1
    │
282 │ 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 v3.0.0

advisories FAILED, bans ok, sources ok

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

Show output 
error[vulnerability]: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN
  ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:5:1
  │
5 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
  │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
  │
  ├ ID: RUSTSEC-2026-0044
  ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0044
  ├ A logic error in CN (Common Name) validation allows certificates with
    wildcard or raw UTF-8 Unicode CN values to bypass name constraints
    enforcement. The `cn2dnsid` function does not recognize these CN patterns
    as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
    validation. However, `X509_check_host` accepts these CN values when no
    dNSName SAN is present, allowing certificates to bypass name constraints
    while still being used for hostname verification.
    
    Customers of AWS services do not need to take action. Applications using
    `aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.
    
    ## Workarounds
    
    Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
    fallback are not affected. Applications that only encounter certificates
    with dNSName SANs (standard for public WebPKI) are also not affected.
    
    Otherwise, there is no workaround and applications using `aws-lc-sys` should
    upgrade to the most recent releases of `aws-lc-sys`.
  ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
  ├ aws-lc-sys v0.38.0
    └── aws-lc-rs v1.16.1
        ├── rustls v0.23.37
        │   ├── hyper-rustls v0.27.7
        │   │   └── libdd-common v3.0.1
        │   │       └── libdd-dogstatsd-client v1.0.2
        │   ├── libdd-common v3.0.1 (*)
        │   └── tokio-rustls v0.26.0
        │       ├── hyper-rustls v0.27.7 (*)
        │       └── libdd-common v3.0.1 (*)
        └── rustls-webpki v0.103.9
            └── rustls v0.23.37 (*)

error[vulnerability]: CRL Distribution Point Scope Check Logic Error in AWS-LC
  ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:5:1
  │
5 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
  │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
  │
  ├ ID: RUSTSEC-2026-0048
  ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0048
  ├ A logic error in CRL distribution point matching in AWS-LC allows a revoked
    certificate to bypass revocation checks during certificate validation, when
    the application enables CRL checking and uses partitioned CRLs with Issuing
    Distribution Point (IDP) extensions.
    
    Customers of AWS services do not need to take action. `aws-lc-sys` contains
    code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
    recent release of `aws-lc-sys`.
    
    ## Workarounds
    
    Applications can workaround this issue if they do not enable CRL checking
    (`X509_V_FLAG_CRL_CHECK`). Applications using complete (non-partitioned)
    CRLs without IDP extensions are also not affected.
    
    Otherwise, there is no workaround and applications using `aws-lc-sys` should
    upgrade to the most recent releases of `aws-lc-sys`.
  ├ Announcement: https://aws.amazon.com/security/security-bulletins/2026-010-AWS
  ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
  ├ aws-lc-sys v0.38.0
    └── aws-lc-rs v1.16.1
        ├── rustls v0.23.37
        │   ├── hyper-rustls v0.27.7
        │   │   └── libdd-common v3.0.1
        │   │       └── libdd-dogstatsd-client v1.0.2
        │   ├── libdd-common v3.0.1 (*)
        │   └── tokio-rustls v0.26.0
        │       ├── hyper-rustls v0.27.7 (*)
        │       └── libdd-common v3.0.1 (*)
        └── rustls-webpki v0.103.9
            └── rustls v0.23.37 (*)

error[vulnerability]: CRLs not considered authoritative by Distribution Point due to faulty matching logic
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:84:1
   │
84 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0049
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
   ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
     
     The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
     
     This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
     
     More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
     
     This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
   ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
   ├ rustls-webpki v0.103.9
     └── rustls v0.23.37
         ├── hyper-rustls v0.27.7
         │   └── libdd-common v3.0.1
         │       └── libdd-dogstatsd-client v1.0.2
         ├── libdd-common v3.0.1 (*)
         └── tokio-rustls v0.26.0
             ├── hyper-rustls v0.27.7 (*)
             └── libdd-common v3.0.1 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-library-config - ✅ No issues

📦 libdd-profiling - 3 error(s)

Show output 
error[vulnerability]: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:13:1
   │
13 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0044
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0044
   ├ A logic error in CN (Common Name) validation allows certificates with
     wildcard or raw UTF-8 Unicode CN values to bypass name constraints
     enforcement. The `cn2dnsid` function does not recognize these CN patterns
     as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
     validation. However, `X509_check_host` accepts these CN values when no
     dNSName SAN is present, allowing certificates to bypass name constraints
     while still being used for hostname verification.
     
     Customers of AWS services do not need to take action. Applications using
     `aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
     fallback are not affected. Applications that only encounter certificates
     with dNSName SANs (standard for public WebPKI) are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   ├── libdd-common v3.0.1
         │   │   │   └── libdd-profiling v1.0.0
         │   │   │       └── (dev) libdd-profiling v1.0.0 (*)
         │   │   └── reqwest v0.13.2
         │   │       ├── libdd-common v3.0.1 (*)
         │   │       └── libdd-profiling v1.0.0 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   ├── libdd-profiling v1.0.0 (*)
         │   ├── reqwest v0.13.2 (*)
         │   ├── rustls-platform-verifier v0.6.2
         │   │   ├── libdd-profiling v1.0.0 (*)
         │   │   └── reqwest v0.13.2 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       ├── libdd-common v3.0.1 (*)
         │       └── reqwest v0.13.2 (*)
         └── rustls-webpki v0.103.9
             ├── rustls v0.23.37 (*)
             └── rustls-platform-verifier v0.6.2 (*)

error[vulnerability]: CRL Distribution Point Scope Check Logic Error in AWS-LC
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:13:1
   │
13 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0048
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0048
   ├ A logic error in CRL distribution point matching in AWS-LC allows a revoked
     certificate to bypass revocation checks during certificate validation, when
     the application enables CRL checking and uses partitioned CRLs with Issuing
     Distribution Point (IDP) extensions.
     
     Customers of AWS services do not need to take action. `aws-lc-sys` contains
     code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
     recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications can workaround this issue if they do not enable CRL checking
     (`X509_V_FLAG_CRL_CHECK`). Applications using complete (non-partitioned)
     CRLs without IDP extensions are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Announcement: https://aws.amazon.com/security/security-bulletins/2026-010-AWS
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   ├── libdd-common v3.0.1
         │   │   │   └── libdd-profiling v1.0.0
         │   │   │       └── (dev) libdd-profiling v1.0.0 (*)
         │   │   └── reqwest v0.13.2
         │   │       ├── libdd-common v3.0.1 (*)
         │   │       └── libdd-profiling v1.0.0 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   ├── libdd-profiling v1.0.0 (*)
         │   ├── reqwest v0.13.2 (*)
         │   ├── rustls-platform-verifier v0.6.2
         │   │   ├── libdd-profiling v1.0.0 (*)
         │   │   └── reqwest v0.13.2 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       ├── libdd-common v3.0.1 (*)
         │       └── reqwest v0.13.2 (*)
         └── rustls-webpki v0.103.9
             ├── rustls v0.23.37 (*)
             └── rustls-platform-verifier v0.6.2 (*)

error[vulnerability]: CRLs not considered authoritative by Distribution Point due to faulty matching logic
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:193:1
    │
193 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0049
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
    ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
      
      The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
      
      This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
      
      More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
      
      This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      ├── rustls v0.23.37
      │   ├── hyper-rustls v0.27.7
      │   │   ├── libdd-common v3.0.1
      │   │   │   └── libdd-profiling v1.0.0
      │   │   │       └── (dev) libdd-profiling v1.0.0 (*)
      │   │   └── reqwest v0.13.2
      │   │       ├── libdd-common v3.0.1 (*)
      │   │       └── libdd-profiling v1.0.0 (*)
      │   ├── libdd-common v3.0.1 (*)
      │   ├── libdd-profiling v1.0.0 (*)
      │   ├── reqwest v0.13.2 (*)
      │   ├── rustls-platform-verifier v0.6.2
      │   │   ├── libdd-profiling v1.0.0 (*)
      │   │   └── reqwest v0.13.2 (*)
      │   └── tokio-rustls v0.26.0
      │       ├── hyper-rustls v0.27.7 (*)
      │       ├── libdd-common v3.0.1 (*)
      │       └── reqwest v0.13.2 (*)
      └── rustls-platform-verifier v0.6.2 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-telemetry - 3 error(s)

Show output 
error[vulnerability]: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN
  ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:6:1
  │
6 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
  │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
  │
  ├ ID: RUSTSEC-2026-0044
  ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0044
  ├ A logic error in CN (Common Name) validation allows certificates with
    wildcard or raw UTF-8 Unicode CN values to bypass name constraints
    enforcement. The `cn2dnsid` function does not recognize these CN patterns
    as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
    validation. However, `X509_check_host` accepts these CN values when no
    dNSName SAN is present, allowing certificates to bypass name constraints
    while still being used for hostname verification.
    
    Customers of AWS services do not need to take action. Applications using
    `aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.
    
    ## Workarounds
    
    Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
    fallback are not affected. Applications that only encounter certificates
    with dNSName SANs (standard for public WebPKI) are also not affected.
    
    Otherwise, there is no workaround and applications using `aws-lc-sys` should
    upgrade to the most recent releases of `aws-lc-sys`.
  ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
  ├ aws-lc-sys v0.38.0
    └── aws-lc-rs v1.16.1
        ├── rustls v0.23.37
        │   ├── hyper-rustls v0.27.7
        │   │   └── libdd-common v3.0.1
        │   │       └── libdd-telemetry v3.1.0
        │   ├── libdd-common v3.0.1 (*)
        │   └── tokio-rustls v0.26.0
        │       ├── hyper-rustls v0.27.7 (*)
        │       └── libdd-common v3.0.1 (*)
        └── rustls-webpki v0.103.9
            └── rustls v0.23.37 (*)

error[vulnerability]: CRL Distribution Point Scope Check Logic Error in AWS-LC
  ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:6:1
  │
6 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
  │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
  │
  ├ ID: RUSTSEC-2026-0048
  ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0048
  ├ A logic error in CRL distribution point matching in AWS-LC allows a revoked
    certificate to bypass revocation checks during certificate validation, when
    the application enables CRL checking and uses partitioned CRLs with Issuing
    Distribution Point (IDP) extensions.
    
    Customers of AWS services do not need to take action. `aws-lc-sys` contains
    code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
    recent release of `aws-lc-sys`.
    
    ## Workarounds
    
    Applications can workaround this issue if they do not enable CRL checking
    (`X509_V_FLAG_CRL_CHECK`). Applications using complete (non-partitioned)
    CRLs without IDP extensions are also not affected.
    
    Otherwise, there is no workaround and applications using `aws-lc-sys` should
    upgrade to the most recent releases of `aws-lc-sys`.
  ├ Announcement: https://aws.amazon.com/security/security-bulletins/2026-010-AWS
  ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
  ├ aws-lc-sys v0.38.0
    └── aws-lc-rs v1.16.1
        ├── rustls v0.23.37
        │   ├── hyper-rustls v0.27.7
        │   │   └── libdd-common v3.0.1
        │   │       └── libdd-telemetry v3.1.0
        │   ├── libdd-common v3.0.1 (*)
        │   └── tokio-rustls v0.26.0
        │       ├── hyper-rustls v0.27.7 (*)
        │       └── libdd-common v3.0.1 (*)
        └── rustls-webpki v0.103.9
            └── rustls v0.23.37 (*)

error[vulnerability]: CRLs not considered authoritative by Distribution Point due to faulty matching logic
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:93:1
   │
93 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0049
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
   ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
     
     The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
     
     This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
     
     More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
     
     This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
   ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
   ├ rustls-webpki v0.103.9
     └── rustls v0.23.37
         ├── hyper-rustls v0.27.7
         │   └── libdd-common v3.0.1
         │       └── libdd-telemetry v3.1.0
         ├── libdd-common v3.0.1 (*)
         └── tokio-rustls v0.26.0
             ├── hyper-rustls v0.27.7 (*)
             └── libdd-common v3.0.1 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-trace-normalization - ✅ No issues

📦 libdd-trace-obfuscation - 3 error(s)

Show output 
error[vulnerability]: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:24:1
   │
24 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0044
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0044
   ├ A logic error in CN (Common Name) validation allows certificates with
     wildcard or raw UTF-8 Unicode CN values to bypass name constraints
     enforcement. The `cn2dnsid` function does not recognize these CN patterns
     as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
     validation. However, `X509_check_host` accepts these CN values when no
     dNSName SAN is present, allowing certificates to bypass name constraints
     while still being used for hostname verification.
     
     Customers of AWS services do not need to take action. Applications using
     `aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
     fallback are not affected. Applications that only encounter certificates
     with dNSName SANs (standard for public WebPKI) are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   └── libdd-common v3.0.1
         │   │       ├── libdd-trace-obfuscation v1.0.1
         │   │       └── libdd-trace-utils v3.0.0
         │   │           ├── (dev) libdd-trace-obfuscation v1.0.1 (*)
         │   │           └── (dev) libdd-trace-utils v3.0.0 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.1 (*)
         └── rustls-webpki v0.103.9
             └── rustls v0.23.37 (*)

error[vulnerability]: CRL Distribution Point Scope Check Logic Error in AWS-LC
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:24:1
   │
24 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0048
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0048
   ├ A logic error in CRL distribution point matching in AWS-LC allows a revoked
     certificate to bypass revocation checks during certificate validation, when
     the application enables CRL checking and uses partitioned CRLs with Issuing
     Distribution Point (IDP) extensions.
     
     Customers of AWS services do not need to take action. `aws-lc-sys` contains
     code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
     recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications can workaround this issue if they do not enable CRL checking
     (`X509_V_FLAG_CRL_CHECK`). Applications using complete (non-partitioned)
     CRLs without IDP extensions are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Announcement: https://aws.amazon.com/security/security-bulletins/2026-010-AWS
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   └── libdd-common v3.0.1
         │   │       ├── libdd-trace-obfuscation v1.0.1
         │   │       └── libdd-trace-utils v3.0.0
         │   │           ├── (dev) libdd-trace-obfuscation v1.0.1 (*)
         │   │           └── (dev) libdd-trace-utils v3.0.0 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.1 (*)
         └── rustls-webpki v0.103.9
             └── rustls v0.23.37 (*)

error[vulnerability]: CRLs not considered authoritative by Distribution Point due to faulty matching logic
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:218:1
    │
218 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0049
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
    ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
      
      The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
      
      This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
      
      More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
      
      This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      └── rustls v0.23.37
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v3.0.1
          │       ├── libdd-trace-obfuscation v1.0.1
          │       └── libdd-trace-utils v3.0.0
          │           ├── (dev) libdd-trace-obfuscation v1.0.1 (*)
          │           └── (dev) libdd-trace-utils v3.0.0 (*)
          ├── libdd-common v3.0.1 (*)
          └── tokio-rustls v0.26.0
              ├── hyper-rustls v0.27.7 (*)
              └── libdd-common v3.0.1 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-trace-protobuf - ✅ No issues

📦 libdd-trace-stats - 3 error(s)

Show output 
error[vulnerability]: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:25:1
   │
25 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0044
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0044
   ├ A logic error in CN (Common Name) validation allows certificates with
     wildcard or raw UTF-8 Unicode CN values to bypass name constraints
     enforcement. The `cn2dnsid` function does not recognize these CN patterns
     as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
     validation. However, `X509_check_host` accepts these CN values when no
     dNSName SAN is present, allowing certificates to bypass name constraints
     while still being used for hostname verification.
     
     Customers of AWS services do not need to take action. Applications using
     `aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
     fallback are not affected. Applications that only encounter certificates
     with dNSName SANs (standard for public WebPKI) are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   └── libdd-common v3.0.1
         │   │       └── libdd-trace-utils v3.0.0
         │   │           ├── libdd-trace-stats v1.0.4
         │   │           └── (dev) libdd-trace-utils v3.0.0 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.1 (*)
         └── rustls-webpki v0.103.9
             └── rustls v0.23.37 (*)

error[vulnerability]: CRL Distribution Point Scope Check Logic Error in AWS-LC
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:25:1
   │
25 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0048
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0048
   ├ A logic error in CRL distribution point matching in AWS-LC allows a revoked
     certificate to bypass revocation checks during certificate validation, when
     the application enables CRL checking and uses partitioned CRLs with Issuing
     Distribution Point (IDP) extensions.
     
     Customers of AWS services do not need to take action. `aws-lc-sys` contains
     code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
     recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications can workaround this issue if they do not enable CRL checking
     (`X509_V_FLAG_CRL_CHECK`). Applications using complete (non-partitioned)
     CRLs without IDP extensions are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Announcement: https://aws.amazon.com/security/security-bulletins/2026-010-AWS
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   └── libdd-common v3.0.1
         │   │       └── libdd-trace-utils v3.0.0
         │   │           ├── libdd-trace-stats v1.0.4
         │   │           └── (dev) libdd-trace-utils v3.0.0 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.1 (*)
         └── rustls-webpki v0.103.9
             └── rustls v0.23.37 (*)

error[vulnerability]: CRLs not considered authoritative by Distribution Point due to faulty matching logic
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:216:1
    │
216 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0049
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
    ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
      
      The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
      
      This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
      
      More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
      
      This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      └── rustls v0.23.37
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v3.0.1
          │       └── libdd-trace-utils v3.0.0
          │           ├── libdd-trace-stats v1.0.4
          │           └── (dev) libdd-trace-utils v3.0.0 (*)
          ├── libdd-common v3.0.1 (*)
          └── tokio-rustls v0.26.0
              ├── hyper-rustls v0.27.7 (*)
              └── libdd-common v3.0.1 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-trace-utils - 3 error(s)

Show output 
error[vulnerability]: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:24:1
   │
24 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0044
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0044
   ├ A logic error in CN (Common Name) validation allows certificates with
     wildcard or raw UTF-8 Unicode CN values to bypass name constraints
     enforcement. The `cn2dnsid` function does not recognize these CN patterns
     as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
     validation. However, `X509_check_host` accepts these CN values when no
     dNSName SAN is present, allowing certificates to bypass name constraints
     while still being used for hostname verification.
     
     Customers of AWS services do not need to take action. Applications using
     `aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
     fallback are not affected. Applications that only encounter certificates
     with dNSName SANs (standard for public WebPKI) are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   └── libdd-common v3.0.1
         │   │       └── libdd-trace-utils v3.0.0
         │   │           └── (dev) libdd-trace-utils v3.0.0 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.1 (*)
         └── rustls-webpki v0.103.9
             └── rustls v0.23.37 (*)

error[vulnerability]: CRL Distribution Point Scope Check Logic Error in AWS-LC
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:24:1
   │
24 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0048
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0048
   ├ A logic error in CRL distribution point matching in AWS-LC allows a revoked
     certificate to bypass revocation checks during certificate validation, when
     the application enables CRL checking and uses partitioned CRLs with Issuing
     Distribution Point (IDP) extensions.
     
     Customers of AWS services do not need to take action. `aws-lc-sys` contains
     code from AWS-LC. Applications using `aws-lc-sys` should upgrade to the most
     recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications can workaround this issue if they do not enable CRL checking
     (`X509_V_FLAG_CRL_CHECK`). Applications using complete (non-partitioned)
     CRLs without IDP extensions are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Announcement: https://aws.amazon.com/security/security-bulletins/2026-010-AWS
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   └── libdd-common v3.0.1
         │   │       └── libdd-trace-utils v3.0.0
         │   │           └── (dev) libdd-trace-utils v3.0.0 (*)
         │   ├── libdd-common v3.0.1 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.1 (*)
         └── rustls-webpki v0.103.9
             └── rustls v0.23.37 (*)

error[vulnerability]: CRLs not considered authoritative by Distribution Point due to faulty matching logic
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:211:1
    │
211 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0049
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
    ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
      
      The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
      
      This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
      
      More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
      
      This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      └── rustls v0.23.37
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v3.0.1
          │       └── libdd-trace-utils v3.0.0
          │           └── (dev) libdd-trace-utils v3.0.0 (*)
          ├── libdd-common v3.0.1 (*)
          └── tokio-rustls v0.26.0
              ├── hyper-rustls v0.27.7 (*)
              └── libdd-common v3.0.1 (*)

advisories FAILED, bans ok, sources ok

Updated: 2026-03-24 08:52:46 UTC | Commit: 7f14f86 | dependency-check job results

@pr-commenter
Copy link
Copy Markdown

pr-commenter bot commented Mar 24, 2026 •
edited
Loading

Benchmarks

Comparison

Benchmark execution time: 2026-03-24 08:55:58

Comparing candidate commit dfc4f08 in PR branch release/libdd-data-pipeline/20260323-165323 with baseline commit 5ff99ff in branch main.

Found 1 performance improvements and 18 performance regressions! Performance is the same for 42 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:benching serializing traces from their internal representation to msgpack

  • 🟩 execution_time [-609.332µs; -597.504µs] or [-4.137%; -4.057%]

scenario:credit_card/is_card_number/ 3782-8224-6310-005

  • 🟥 execution_time [+5.035µs; +5.250µs] or [+6.654%; +6.938%]
  • 🟥 throughput [-860380.537op/s; -823634.666op/s] or [-6.510%; -6.232%]

scenario:credit_card/is_card_number/ 378282246310005

  • 🟥 execution_time [+5.012µs; +5.104µs] or [+7.306%; +7.441%]
  • 🟥 throughput [-1009407.524op/s; -992226.139op/s] or [-6.924%; -6.807%]

scenario:credit_card/is_card_number/378282246310005

  • 🟥 execution_time [+5.845µs; +5.929µs] or [+9.020%; +9.150%]
  • 🟥 throughput [-1293645.447op/s; -1276340.033op/s] or [-8.383%; -8.271%]

scenario:credit_card/is_card_number/37828224631000521389798

  • 🟥 execution_time [+7.392µs; +7.423µs] or [+16.164%; +16.232%]
  • 🟥 throughput [-3055659.286op/s; -3040951.907op/s] or [-13.974%; -13.907%]

scenario:credit_card/is_card_number_no_luhn/ 378282246310005

  • 🟥 execution_time [+4.051µs; +4.095µs] or [+7.461%; +7.541%]
  • 🟥 throughput [-1292123.474op/s; -1278165.486op/s] or [-7.016%; -6.940%]

scenario:credit_card/is_card_number_no_luhn/378282246310005

  • 🟥 execution_time [+4.980µs; +5.054µs] or [+9.862%; +10.008%]
  • 🟥 throughput [-1803259.888op/s; -1776134.380op/s] or [-9.106%; -8.969%]

scenario:credit_card/is_card_number_no_luhn/37828224631000521389798

  • 🟥 execution_time [+7.392µs; +7.433µs] or [+16.167%; +16.258%]
  • 🟥 throughput [-3061127.491op/s; -3041437.357op/s] or [-13.996%; -13.906%]

scenario:profile_add_sample_frames_x1000

  • 🟥 execution_time [+198.228µs; +199.773µs] or [+4.759%; +4.796%]

scenario:profile_add_sample_timestamped_x1000

  • 🟥 execution_time [+208.327µs; +211.233µs] or [+5.022%; +5.092%]

scenario:receiver_entry_point/report/2598

  • 🟥 execution_time [+198.155µs; +206.765µs] or [+5.801%; +6.053%]

scenario:sql/obfuscate_sql_string

  • 🟥 execution_time [+4.286µs; +4.347µs] or [+5.069%; +5.141%]

Candidate

Candidate benchmark details

Group 1

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
concentrator/add_spans_to_concentrator execution_time 13.038ms 13.077ms ± 0.015ms 13.076ms ± 0.009ms 13.086ms 13.101ms 13.115ms 13.118ms 0.32% 0.168 0.054 0.11% 0.001ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
concentrator/add_spans_to_concentrator execution_time [13.075ms; 13.079ms] or [-0.015%; +0.015%] None None None

Group 2

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
credit_card/is_card_number/ execution_time 3.891µs 3.913µs ± 0.003µs 3.913µs ± 0.001µs 3.914µs 3.917µs 3.919µs 3.922µs 0.23% -2.405 18.121 0.08% 0.000µs 1 200
credit_card/is_card_number/ throughput 254985027.112op/s 255560135.213op/s ± 198731.534op/s 255570775.482op/s ± 86389.461op/s 255653054.407op/s 255765592.875op/s 255860800.847op/s 257003392.726op/s 0.56% 2.438 18.366 0.08% 14052.442op/s 1 200
credit_card/is_card_number/ 3782-8224-6310-005 execution_time 80.233µs 80.815µs ± 0.261µs 80.788µs ± 0.178µs 80.972µs 81.275µs 81.531µs 81.545µs 0.94% 0.476 0.016 0.32% 0.018µs 1 200
credit_card/is_card_number/ 3782-8224-6310-005 throughput 12263227.003op/s 12374030.004op/s ± 39938.830op/s 12378103.136op/s ± 27207.430op/s 12404748.855op/s 12432432.115op/s 12443966.278op/s 12463644.354op/s 0.69% -0.458 -0.009 0.32% 2824.102op/s 1 200
credit_card/is_card_number/ 378282246310005 execution_time 73.137µs 73.657µs ± 0.323µs 73.621µs ± 0.228µs 73.848µs 74.302µs 74.595µs 74.905µs 1.74% 0.981 1.050 0.44% 0.023µs 1 200
credit_card/is_card_number/ 378282246310005 throughput 13350256.747op/s 13576655.446op/s ± 59293.500op/s 13583025.972op/s ± 41939.165op/s 13625247.296op/s 13649697.593op/s 13663373.049op/s 13672943.788op/s 0.66% -0.954 0.962 0.44% 4192.684op/s 1 200
credit_card/is_card_number/37828224631 execution_time 3.898µs 3.914µs ± 0.003µs 3.914µs ± 0.002µs 3.916µs 3.918µs 3.920µs 3.920µs 0.16% -0.760 2.860 0.07% 0.000µs 1 200
credit_card/is_card_number/37828224631 throughput 255093941.464op/s 255503963.812op/s ± 189620.261op/s 255490610.729op/s ± 127102.232op/s 255627232.097op/s 255786069.902op/s 255903194.431op/s 256515570.796op/s 0.40% 0.770 2.909 0.07% 13408.177op/s 1 200
credit_card/is_card_number/378282246310005 execution_time 70.088µs 70.690µs ± 0.280µs 70.662µs ± 0.184µs 70.867µs 71.232µs 71.425µs 71.676µs 1.43% 0.601 0.286 0.40% 0.020µs 1 200
credit_card/is_card_number/378282246310005 throughput 13951713.904op/s 14146393.655op/s ± 55894.810op/s 14151818.718op/s ± 36775.276op/s 14186324.739op/s 14225994.235op/s 14257246.937op/s 14267879.436op/s 0.82% -0.579 0.246 0.39% 3952.360op/s 1 200
credit_card/is_card_number/37828224631000521389798 execution_time 53.061µs 53.140µs ± 0.034µs 53.135µs ± 0.021µs 53.157µs 53.198µs 53.240µs 53.275µs 0.26% 0.901 1.288 0.06% 0.002µs 1 200
credit_card/is_card_number/37828224631000521389798 throughput 18770591.786op/s 18818342.624op/s ± 12141.243op/s 18820095.521op/s ± 7465.293op/s 18826892.353op/s 18834159.452op/s 18837736.310op/s 18846092.637op/s 0.14% -0.897 1.274 0.06% 858.516op/s 1 200
credit_card/is_card_number/x371413321323331 execution_time 6.430µs 6.439µs ± 0.005µs 6.438µs ± 0.003µs 6.441µs 6.447µs 6.453µs 6.457µs 0.29% 0.979 1.684 0.07% 0.000µs 1 200
credit_card/is_card_number/x371413321323331 throughput 154874124.909op/s 155306925.080op/s ± 109510.757op/s 155322385.406op/s ± 61874.169op/s 155377470.278op/s 155454333.622op/s 155495414.812op/s 155520139.308op/s 0.13% -0.973 1.665 0.07% 7743.580op/s 1 200
credit_card/is_card_number_no_luhn/ execution_time 3.893µs 3.912µs ± 0.003µs 3.912µs ± 0.002µs 3.914µs 3.917µs 3.918µs 3.924µs 0.31% -1.045 11.721 0.07% 0.000µs 1 200
credit_card/is_card_number_no_luhn/ throughput 254811663.675op/s 255594587.385op/s ± 182415.704op/s 255596536.667op/s ± 109837.185op/s 255705906.994op/s 255818305.112op/s 255886573.260op/s 256868235.539op/s 0.50% 1.072 11.886 0.07% 12898.738op/s 1 200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 execution_time 64.970µs 65.173µs ± 0.155µs 65.134µs ± 0.075µs 65.229µs 65.441µs 65.717µs 66.205µs 1.64% 2.464 10.674 0.24% 0.011µs 1 200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 throughput 15104565.276op/s 15343944.724op/s ± 36175.549op/s 15352998.333op/s ± 17620.847op/s 15365340.402op/s 15381165.310op/s 15390454.102op/s 15391808.480op/s 0.25% -2.418 10.287 0.24% 2557.998op/s 1 200
credit_card/is_card_number_no_luhn/ 378282246310005 execution_time 58.205µs 58.370µs ± 0.100µs 58.354µs ± 0.060µs 58.423µs 58.566µs 58.688µs 58.779µs 0.73% 1.082 1.533 0.17% 0.007µs 1 200
credit_card/is_card_number_no_luhn/ 378282246310005 throughput 17012961.206op/s 17132157.253op/s ± 29297.992op/s 17136690.212op/s ± 17685.691op/s 17151934.279op/s 17169838.775op/s 17177181.678op/s 17180647.718op/s 0.26% -1.070 1.491 0.17% 2071.681op/s 1 200
credit_card/is_card_number_no_luhn/37828224631 execution_time 3.893µs 3.913µs ± 0.003µs 3.913µs ± 0.002µs 3.915µs 3.918µs 3.921µs 3.923µs 0.27% -1.010 11.244 0.08% 0.000µs 1 200
credit_card/is_card_number_no_luhn/37828224631 throughput 254880116.599op/s 255549596.696op/s ± 193659.359op/s 255559353.308op/s ± 106295.580op/s 255672022.814op/s 255761153.824op/s 255796584.074op/s 256902805.507op/s 0.53% 1.038 11.433 0.08% 13693.785op/s 1 200
credit_card/is_card_number_no_luhn/378282246310005 execution_time 55.146µs 55.517µs ± 0.169µs 55.502µs ± 0.107µs 55.622µs 55.816µs 55.973µs 56.111µs 1.10% 0.384 0.274 0.30% 0.012µs 1 200
credit_card/is_card_number_no_luhn/378282246310005 throughput 17821835.017op/s 18012675.041op/s ± 54745.813op/s 18017215.423op/s ± 34714.663op/s 18045859.285op/s 18097013.269op/s 18119037.034op/s 18133741.453op/s 0.65% -0.364 0.244 0.30% 3871.114op/s 1 200
credit_card/is_card_number_no_luhn/37828224631000521389798 execution_time 53.066µs 53.136µs ± 0.033µs 53.132µs ± 0.021µs 53.155µs 53.187µs 53.224µs 53.276µs 0.27% 0.739 1.434 0.06% 0.002µs 1 200
credit_card/is_card_number_no_luhn/37828224631000521389798 throughput 18770081.007op/s 18819678.562op/s ± 11525.924op/s 18820875.159op/s ± 7355.409op/s 18827804.314op/s 18836412.323op/s 18841353.575op/s 18844298.139op/s 0.12% -0.734 1.417 0.06% 815.006op/s 1 200
credit_card/is_card_number_no_luhn/x371413321323331 execution_time 6.430µs 6.440µs ± 0.005µs 6.440µs ± 0.004µs 6.444µs 6.450µs 6.454µs 6.461µs 0.33% 0.613 0.393 0.08% 0.000µs 1 200
credit_card/is_card_number_no_luhn/x371413321323331 throughput 154763882.435op/s 155270944.773op/s ± 131716.736op/s 155268721.118op/s ± 92901.903op/s 155374661.410op/s 155452227.372op/s 155482090.986op/s 155521820.773op/s 0.16% -0.608 0.379 0.08% 9313.780op/s 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
credit_card/is_card_number/ execution_time [3.913µs; 3.913µs] or [-0.011%; +0.011%] None None None
credit_card/is_card_number/ throughput [255532592.934op/s; 255587677.492op/s] or [-0.011%; +0.011%] None None None
credit_card/is_card_number/ 3782-8224-6310-005 execution_time [80.779µs; 80.851µs] or [-0.045%; +0.045%] None None None
credit_card/is_card_number/ 3782-8224-6310-005 throughput [12368494.866op/s; 12379565.141op/s] or [-0.045%; +0.045%] None None None
credit_card/is_card_number/ 378282246310005 execution_time [73.612µs; 73.702µs] or [-0.061%; +0.061%] None None None
credit_card/is_card_number/ 378282246310005 throughput [13568437.937op/s; 13584872.954op/s] or [-0.061%; +0.061%] None None None
credit_card/is_card_number/37828224631 execution_time [3.913µs; 3.914µs] or [-0.010%; +0.010%] None None None
credit_card/is_card_number/37828224631 throughput [255477684.268op/s; 255530243.357op/s] or [-0.010%; +0.010%] None None None
credit_card/is_card_number/378282246310005 execution_time [70.652µs; 70.729µs] or [-0.055%; +0.055%] None None None
credit_card/is_card_number/378282246310005 throughput [14138647.171op/s; 14154140.138op/s] or [-0.055%; +0.055%] None None None
credit_card/is_card_number/37828224631000521389798 execution_time [53.135µs; 53.144µs] or [-0.009%; +0.009%] None None None
credit_card/is_card_number/37828224631000521389798 throughput [18816659.964op/s; 18820025.283op/s] or [-0.009%; +0.009%] None None None
credit_card/is_card_number/x371413321323331 execution_time [6.438µs; 6.439µs] or [-0.010%; +0.010%] None None None
credit_card/is_card_number/x371413321323331 throughput [155291747.943op/s; 155322102.218op/s] or [-0.010%; +0.010%] None None None
credit_card/is_card_number_no_luhn/ execution_time [3.912µs; 3.913µs] or [-0.010%; +0.010%] None None None
credit_card/is_card_number_no_luhn/ throughput [255569306.323op/s; 255619868.447op/s] or [-0.010%; +0.010%] None None None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 execution_time [65.151µs; 65.194µs] or [-0.033%; +0.033%] None None None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 throughput [15338931.141op/s; 15348958.307op/s] or [-0.033%; +0.033%] None None None
credit_card/is_card_number_no_luhn/ 378282246310005 execution_time [58.356µs; 58.384µs] or [-0.024%; +0.024%] None None None
credit_card/is_card_number_no_luhn/ 378282246310005 throughput [17128096.833op/s; 17136217.673op/s] or [-0.024%; +0.024%] None None None
credit_card/is_card_number_no_luhn/37828224631 execution_time [3.913µs; 3.914µs] or [-0.010%; +0.010%] None None None
credit_card/is_card_number_no_luhn/37828224631 throughput [255522757.371op/s; 255576436.021op/s] or [-0.011%; +0.011%] None None None
credit_card/is_card_number_no_luhn/378282246310005 execution_time [55.494µs; 55.540µs] or [-0.042%; +0.042%] None None None
credit_card/is_card_number_no_luhn/378282246310005 throughput [18005087.797op/s; 18020262.284op/s] or [-0.042%; +0.042%] None None None
credit_card/is_card_number_no_luhn/37828224631000521389798 execution_time [53.131µs; 53.140µs] or [-0.008%; +0.008%] None None None
credit_card/is_card_number_no_luhn/37828224631000521389798 throughput [18818081.179op/s; 18821275.944op/s] or [-0.008%; +0.008%] None None None
credit_card/is_card_number_no_luhn/x371413321323331 execution_time [6.440µs; 6.441µs] or [-0.012%; +0.012%] None None None
credit_card/is_card_number_no_luhn/x371413321323331 throughput [155252690.100op/s; 155289199.446op/s] or [-0.012%; +0.012%] None None None

Group 3

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
profile_add_sample2_frames_x1000 execution_time 736.784µs 737.871µs ± 1.114µs 737.665µs ± 0.300µs 737.993µs 738.802µs 744.524µs 745.515µs 1.06% 4.840 26.956 0.15% 0.079µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
profile_add_sample2_frames_x1000 execution_time [737.717µs; 738.026µs] or [-0.021%; +0.021%] None None None

Group 4

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
write only interface execution_time 5.381µs 5.507µs ± 0.028µs 5.503µs ± 0.015µs 5.519µs 5.563µs 5.579µs 5.582µs 1.45% 0.175 1.994 0.50% 0.002µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
write only interface execution_time [5.503µs; 5.511µs] or [-0.070%; +0.070%] None None None

Group 5

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
normalization/normalize_trace/test_trace execution_time 243.265ns 254.622ns ± 12.076ns 250.105ns ± 3.827ns 256.339ns 285.084ns 288.244ns 290.950ns 16.33% 1.599 1.436 4.73% 0.854ns 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
normalization/normalize_trace/test_trace execution_time [252.948ns; 256.295ns] or [-0.657%; +0.657%] None None None

Group 6

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
sdk_test_data/rules-based execution_time 144.678µs 146.568µs ± 1.651µs 146.270µs ± 0.469µs 146.846µs 148.198µs 152.662µs 162.013µs 10.76% 5.679 44.266 1.12% 0.117µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
sdk_test_data/rules-based execution_time [146.339µs; 146.797µs] or [-0.156%; +0.156%] None None None

Group 7

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
benching string interning on wordpress profile execution_time 161.421µs 162.372µs ± 0.379µs 162.334µs ± 0.144µs 162.473µs 162.850µs 163.511µs 165.745µs 2.10% 3.959 30.839 0.23% 0.027µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
benching string interning on wordpress profile execution_time [162.319µs; 162.425µs] or [-0.032%; +0.032%] None None None

Group 8

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
tags/replace_trace_tags execution_time 2.341µs 2.384µs ± 0.018µs 2.381µs ± 0.007µs 2.389µs 2.438µs 2.446µs 2.448µs 2.83% 1.770 4.185 0.77% 0.001µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
tags/replace_trace_tags execution_time [2.382µs; 2.387µs] or [-0.107%; +0.107%] None None None

Group 9

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
redis/obfuscate_redis_string execution_time 32.825µs 33.483µs ± 1.237µs 32.913µs ± 0.032µs 32.974µs 36.184µs 36.226µs 36.255µs 10.15% 1.706 0.920 3.69% 0.087µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
redis/obfuscate_redis_string execution_time [33.311µs; 33.654µs] or [-0.512%; +0.512%] None None None

Group 10

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
benching deserializing traces from msgpack to their internal representation execution_time 50.108ms 50.505ms ± 0.801ms 50.387ms ± 0.049ms 50.427ms 50.593ms 55.643ms 57.569ms 14.26% 7.254 54.371 1.58% 0.057ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
benching deserializing traces from msgpack to their internal representation execution_time [50.394ms; 50.616ms] or [-0.220%; +0.220%] None None None

Group 11

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
profile_add_sample_timestamped_x1000 execution_time 4.352ms 4.358ms ± 0.008ms 4.358ms ± 0.002ms 4.360ms 4.363ms 4.370ms 4.465ms 2.46% 11.162 142.051 0.19% 0.001ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
profile_add_sample_timestamped_x1000 execution_time [4.357ms; 4.360ms] or [-0.026%; +0.026%] None None None

Group 12

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
ip_address/quantize_peer_ip_address_benchmark execution_time 4.983µs 5.064µs ± 0.045µs 5.071µs ± 0.037µs 5.094µs 5.135µs 5.140µs 5.145µs 1.46% -0.058 -1.173 0.90% 0.003µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
ip_address/quantize_peer_ip_address_benchmark execution_time [5.057µs; 5.070µs] or [-0.124%; +0.124%] None None None

Group 13

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
single_flag_killswitch/rules-based execution_time 190.332ns 192.287ns ± 1.734ns 192.072ns ± 1.231ns 193.177ns 196.106ns 197.544ns 197.979ns 3.08% 1.147 1.036 0.90% 0.123ns 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
single_flag_killswitch/rules-based execution_time [192.047ns; 192.527ns] or [-0.125%; +0.125%] None None None

Group 14

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
benching serializing traces from their internal representation to msgpack execution_time 14.068ms 14.125ms ± 0.028ms 14.122ms ± 0.012ms 14.134ms 14.158ms 14.237ms 14.305ms 1.30% 2.661 12.183 0.20% 0.002ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
benching serializing traces from their internal representation to msgpack execution_time [14.121ms; 14.129ms] or [-0.027%; +0.027%] None None None

Group 15

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000... execution_time 495.493µs 496.430µs ± 0.968µs 496.188µs ± 0.270µs 496.521µs 498.768µs 500.401µs 501.033µs 0.98% 2.893 8.643 0.19% 0.068µs 1 200
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000... throughput 1995877.183op/s 2014390.166op/s ± 3904.039op/s 2015363.903op/s ± 1096.066op/s 2016316.650op/s 2017572.169op/s 2018074.453op/s 2018191.530op/s 0.14% -2.880 8.569 0.19% 276.057op/s 1 200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて execution_time 370.439µs 371.417µs ± 0.348µs 371.430µs ± 0.218µs 371.628µs 371.990µs 372.174µs 372.256µs 0.22% -0.045 0.015 0.09% 0.025µs 1 200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて throughput 2686325.587op/s 2692392.476op/s ± 2521.875op/s 2692295.604op/s ± 1577.190op/s 2694017.820op/s 2696527.924op/s 2698253.612op/s 2699497.248op/s 0.27% 0.051 0.017 0.09% 178.323op/s 1 200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters execution_time 167.900µs 168.241µs ± 0.145µs 168.217µs ± 0.092µs 168.336µs 168.483µs 168.668µs 168.728µs 0.30% 0.775 0.772 0.09% 0.010µs 1 200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters throughput 5926703.493op/s 5943876.150op/s ± 5130.277op/s 5944715.117op/s ± 3249.324op/s 5947190.744op/s 5950871.528op/s 5952827.580op/s 5955934.396op/s 0.19% -0.770 0.760 0.09% 362.765op/s 1 200
normalization/normalize_service/normalize_service/[empty string] execution_time 36.788µs 37.022µs ± 0.095µs 37.048µs ± 0.069µs 37.096µs 37.146µs 37.167µs 37.194µs 0.40% -0.468 -0.939 0.26% 0.007µs 1 200
normalization/normalize_service/normalize_service/[empty string] throughput 26885745.242op/s 27011155.020op/s ± 69332.489op/s 26992165.361op/s ± 50130.659op/s 27070363.076op/s 27133004.265op/s 27147942.402op/s 27182692.926op/s 0.71% 0.475 -0.933 0.26% 4902.547op/s 1 200
normalization/normalize_service/normalize_service/test_ASCII execution_time 46.219µs 46.343µs ± 0.115µs 46.327µs ± 0.034µs 46.365µs 46.455µs 46.523µs 47.721µs 3.01% 8.749 101.559 0.25% 0.008µs 1 200
normalization/normalize_service/normalize_service/test_ASCII throughput 20955186.995op/s 21578206.032op/s ± 52384.640op/s 21585704.419op/s ± 15989.155op/s 21600360.241op/s 21619732.455op/s 21630075.972op/s 21635952.532op/s 0.23% -8.549 98.326 0.24% 3704.153op/s 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000... execution_time [496.296µs; 496.564µs] or [-0.027%; +0.027%] None None None
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000... throughput [2013849.104op/s; 2014931.228op/s] or [-0.027%; +0.027%] None None None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて execution_time [371.369µs; 371.465µs] or [-0.013%; +0.013%] None None None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて throughput [2692042.968op/s; 2692741.983op/s] or [-0.013%; +0.013%] None None None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters execution_time [168.220µs; 168.261µs] or [-0.012%; +0.012%] None None None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters throughput [5943165.143op/s; 5944587.157op/s] or [-0.012%; +0.012%] None None None
normalization/normalize_service/normalize_service/[empty string] execution_time [37.009µs; 37.035µs] or [-0.036%; +0.036%] None None None
normalization/normalize_service/normalize_service/[empty string] throughput [27001546.204op/s; 27020763.836op/s] or [-0.036%; +0.036%] None None None
normalization/normalize_service/normalize_service/test_ASCII execution_time [46.327µs; 46.359µs] or [-0.034%; +0.034%] None None None
normalization/normalize_service/normalize_service/test_ASCII throughput [21570946.025op/s; 21585466.039op/s] or [-0.034%; +0.034%] None None None

Group 16

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
sql/obfuscate_sql_string execution_time 88.487µs 88.867µs ± 0.169µs 88.876µs ± 0.088µs 88.956µs 89.031µs 89.103µs 90.501µs 1.83% 4.245 41.457 0.19% 0.012µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
sql/obfuscate_sql_string execution_time [88.843µs; 88.890µs] or [-0.026%; +0.026%] None None None

Group 17

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
two way interface execution_time 13.856µs 13.947µs ± 0.051µs 13.943µs ± 0.036µs 13.978µs 14.023µs 14.107µs 14.216µs 1.96% 1.202 3.465 0.37% 0.004µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
two way interface execution_time [13.940µs; 13.955µs] or [-0.051%; +0.051%] None None None

Group 18

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
receiver_entry_point/report/2598 execution_time 3.585ms 3.619ms ± 0.026ms 3.613ms ± 0.011ms 3.625ms 3.663ms 3.689ms 3.819ms 5.68% 3.035 18.199 0.70% 0.002ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
receiver_entry_point/report/2598 execution_time [3.615ms; 3.622ms] or [-0.098%; +0.098%] None None None

Group 19

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
profile_add_sample_frames_x1000 execution_time 4.357ms 4.364ms ± 0.004ms 4.363ms ± 0.001ms 4.365ms 4.374ms 4.377ms 4.379ms 0.36% 1.726 3.583 0.09% 0.000ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
profile_add_sample_frames_x1000 execution_time [4.364ms; 4.365ms] or [-0.012%; +0.012%] None None None

Group 20

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz dfc4f08 1774341409 release/libdd-data-pipeline/20260323-165323
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo... execution_time 185.676µs 186.067µs ± 0.223µs 186.029µs ± 0.131µs 186.175µs 186.491µs 186.706µs 186.812µs 0.42% 0.871 0.543 0.12% 0.016µs 1 200
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo... throughput 5352983.780op/s 5374408.379op/s ± 6422.348op/s 5375497.662op/s ± 3798.891op/s 5379055.303op/s 5382740.105op/s 5385028.066op/s 5385723.497op/s 0.19% -0.865 0.529 0.12% 454.129op/s 1 200
normalization/normalize_name/normalize_name/bad-name execution_time 17.809µs 17.872µs ± 0.035µs 17.870µs ± 0.016µs 17.887µs 17.916µs 17.963µs 18.169µs 1.67% 3.342 25.164 0.19% 0.002µs 1 200
normalization/normalize_name/normalize_name/bad-name throughput 55039133.286op/s 55953124.859op/s ± 108484.185op/s 55960156.370op/s ± 51486.787op/s 56009376.645op/s 56098758.895op/s 56123494.932op/s 56151993.537op/s 0.34% -3.250 24.169 0.19% 7670.990op/s 1 200
normalization/normalize_name/normalize_name/good execution_time 10.544µs 10.600µs ± 0.025µs 10.600µs ± 0.016µs 10.616µs 10.638µs 10.666µs 10.671µs 0.67% 0.033 0.149 0.23% 0.002µs 1 200
normalization/normalize_name/normalize_name/good throughput 93712599.909op/s 94336675.111op/s ± 218510.131op/s 94337414.807op/s ± 141034.066op/s 94477280.108op/s 94745508.318op/s 94834379.322op/s 94837509.321op/s 0.53% -0.019 0.140 0.23% 15451.000op/s 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo... execution_time [186.036µs; 186.098µs] or [-0.017%; +0.017%] None None None
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo... throughput [5373518.303op/s; 5375298.454op/s] or [-0.017%; +0.017%] None None None
normalization/normalize_name/normalize_name/bad-name execution_time [17.867µs; 17.877µs] or [-0.027%; +0.027%] None None None
normalization/normalize_name/normalize_name/bad-name throughput [55938089.994op/s; 55968159.723op/s] or [-0.027%; +0.027%] None None None
normalization/normalize_name/normalize_name/good execution_time [10.597µs; 10.604µs] or [-0.032%; +0.032%] None None None
normalization/normalize_name/normalize_name/good throughput [94306391.709op/s; 94366958.514op/s] or [-0.032%; +0.032%] None None None

Baseline

Omitted due to size.

@codecov-commenter
Copy link
Copy Markdown

codecov-commenter commented Mar 24, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.46%. Comparing base (5ff99ff) to head (dfc4f08).

Additional details and impacted files 
@@            Coverage Diff             @@
##             main    #1783      +/-   ##
==========================================
+ Coverage   70.34%   70.46%   +0.12%     
==========================================
  Files         410      410              
  Lines       62138    62138              
==========================================
+ Hits        43710    43788      +78     
+ Misses      18428    18350      -78
Components Coverage Δ
libdd-crashtracker 64.94% <ø> (+0.12%) ⬆️
libdd-crashtracker-ffi 34.98% <ø> (+0.89%) ⬆️
libdd-alloc 98.77% <ø> (ø)
libdd-data-pipeline 87.61% <ø> (-0.36%) ⬇️
libdd-data-pipeline-ffi 73.45% <ø> (-1.98%) ⬇️
libdd-common 79.78% <ø> (ø)
libdd-common-ffi 73.87% <ø> (ø)
libdd-telemetry 62.48% <ø> (ø)
libdd-telemetry-ffi 16.75% <ø> (ø)
libdd-dogstatsd-client 82.64% <ø> (ø)
datadog-ipc 72.56% <ø> (+2.24%) ⬆️
libdd-profiling 81.61% <ø> (ø)
libdd-profiling-ffi 64.94% <ø> (ø)
datadog-sidecar 31.63% <ø> (+0.96%) ⬆️
datdog-sidecar-ffi 13.34% <ø> (+4.49%) ⬆️
spawn-worker 54.69% <ø> (ø)
libdd-tinybytes 93.16% <ø> (ø)
libdd-trace-normalization 81.71% <ø> (ø)
libdd-trace-obfuscation 92.26% <ø> (ø)
libdd-trace-protobuf 68.25% <ø> (ø)
libdd-trace-utils 88.95% <ø> (ø)
datadog-tracer-flare 86.88% <ø> (ø)
libdd-log 74.69% <ø> (ø)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@datadog-official
Copy link
Copy Markdown

datadog-official bot commented Mar 24, 2026

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 70.47% (+0.13%)

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: dfc4f08 | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback!

@iunanua iunanua marked this pull request as ready for review March 24, 2026 09:17
@iunanua iunanua requested review from a team as code owners March 24, 2026 09:17
@iunanua iunanua requested review from zacharycmontoya and removed request for a team March 24, 2026 09:17
@iunanua iunanua merged commit d1eb663 into main Mar 24, 2026
314 checks passed
@iunanua iunanua deleted the release/libdd-data-pipeline/20260323-165323 branch March 24, 2026 09:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@iunanua iunanua iunanua approved these changes

@zacharycmontoya zacharycmontoya Awaiting requested review from zacharycmontoya zacharycmontoya was automatically assigned from DataDog/apm-sdk-capabilities

Assignees

No one assigned

Labels

common crashtracker data-pipeline mini-agent skip-changelog-check skip-metadata-check telemetry

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@codecov-commenter @iunanua