Skip to content

chore(release): proposal for libdd-data-pipeline#1785

Merged
hoolioh merged 10 commits intorelease/libdd-data-pipeline/20260324-152000from
release-proposal/libdd-data-pipeline/20260324-152000
Mar 26, 2026
Merged

chore(release): proposal for libdd-data-pipeline#1785
hoolioh merged 10 commits intorelease/libdd-data-pipeline/20260324-152000from
release-proposal/libdd-data-pipeline/20260324-152000

Conversation

@hoolioh
Copy link
Copy Markdown
Contributor

@hoolioh hoolioh commented Mar 24, 2026 •
edited by iunanua
Loading

Release proposal for libdd-data-pipeline and its dependencies

libdd-common

Next version: 3.0.2

libdd-trace-protobuf

Next version: 3.0.1

libdd-trace-stats

Next version: 2.0.0

libdd-trace-obfuscation

Next version: 2.0.0

libdd-trace-normalization

Next version: 2.0.0

libdd-trace-utils

Next version: 3.0.1

libdd-data-pipeline

Next version: 3.0.1

libdd-telemetry

Next version: 4.0.0

Notes

It fixes #1781

Tests

It has been tested by packaging the crates involved in the PR, patching crates.io libdd-* dependencies on dd-trace-rs and compiling dd-trace-rs.

The dependency tree obtained is as follows

> cargo tree -p datadog-opentelemetry -d -e normal | grep "libdd-"

└── libdd-telemetry v3.0.0
    └── libdd-data-pipeline v2.0.1
└── libdd-data-pipeline v2.0.1 (*)
            ├── libdd-ddsketch v1.0.1
            │   ├── libdd-data-pipeline v2.0.1 (*)
            │   ├── libdd-telemetry v3.0.0 (*)
            │   └── libdd-trace-stats v1.0.3
            │       └── libdd-data-pipeline v2.0.1 (*)
            ├── libdd-trace-protobuf v2.0.0
            │   ├── libdd-data-pipeline v2.0.1 (*)
            │   ├── libdd-trace-normalization v1.0.2
            │   │   └── libdd-trace-utils v2.0.2
            │   │       ├── libdd-data-pipeline v2.0.1 (*)
            │   │       └── libdd-trace-stats v1.0.3 (*)
            │   ├── libdd-trace-stats v1.0.3 (*)
            │   └── libdd-trace-utils v2.0.2 (*)
            └── libdd-trace-utils v2.0.2 (*)
    ├── libdd-telemetry v3.0.0 (*)
    └── libdd-trace-stats v1.0.3 (*)
    │   └── libdd-trace-utils v2.0.2 (*)
    │   └── libdd-trace-utils v2.0.2 (*)
    ├── libdd-data-pipeline v2.0.1 (*)
    └── libdd-telemetry v3.0.0 (*)
└── libdd-common v2.0.1
    ├── libdd-data-pipeline v2.0.1 (*)
    ├── libdd-dogstatsd-client v1.0.1
    │   └── libdd-data-pipeline v2.0.1 (*)
    ├── libdd-telemetry v3.0.0 (*)
    └── libdd-trace-utils v2.0.2 (*)

and there are no duplicated dependencies with different versions, and none of the crates in this proposal are part in the tree.

@iunanua iunanua changed the title Release proposal/libdd data pipeline/20260324 152000 chore(release): proposal for libdd-data-pipeline Mar 24, 2026
@iunanua iunanua changed the base branch from main to release/libdd-data-pipeline/20260324-152000 March 24, 2026 14:59
@github-actions
Copy link
Copy Markdown

github-actions bot commented Mar 25, 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-25 11:22:26 UTC | Commit: ceaad0d | missing-docs job results

@github-actions
Copy link
Copy Markdown

github-actions bot commented Mar 25, 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.2
        │   │   └── reqwest v0.13.2
        │   │       └── libdd-common v3.0.2 (*)
        │   ├── libdd-common v3.0.2 (*)
        │   ├── 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.2 (*)
        │       └── 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.2
        │   │   └── reqwest v0.13.2
        │   │       └── libdd-common v3.0.2 (*)
        │   ├── libdd-common v3.0.2 (*)
        │   ├── 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.2 (*)
        │       └── 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.2
      │   │   └── reqwest v0.13.2
      │   │       └── libdd-common v3.0.2 (*)
      │   ├── libdd-common v3.0.2 (*)
      │   ├── 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.2 (*)
      │       └── 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.2
         │   │       ├── (build) libdd-crashtracker v1.0.0
         │   │       └── libdd-telemetry v4.0.0
         │   │           └── libdd-crashtracker v1.0.0 (*)
         │   ├── libdd-common v3.0.2 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.2 (*)
         └── 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.2
         │   │       ├── (build) libdd-crashtracker v1.0.0
         │   │       └── libdd-telemetry v4.0.0
         │   │           └── libdd-crashtracker v1.0.0 (*)
         │   ├── libdd-common v3.0.2 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.2 (*)
         └── 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.2
          │       ├── (build) libdd-crashtracker v1.0.0
          │       └── libdd-telemetry v4.0.0
          │           └── libdd-crashtracker v1.0.0 (*)
          ├── libdd-common v3.0.2 (*)
          └── tokio-rustls v0.26.0
              ├── hyper-rustls v0.27.7 (*)
              └── libdd-common v3.0.2 (*)

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.2
         │   │       ├── libdd-data-pipeline v3.0.1
         │   │       ├── libdd-dogstatsd-client v2.0.0
         │   │       │   └── libdd-data-pipeline v3.0.1 (*)
         │   │       ├── libdd-telemetry v4.0.0
         │   │       │   └── libdd-data-pipeline v3.0.1 (*)
         │   │       └── libdd-trace-utils v3.0.1
         │   │           ├── libdd-data-pipeline v3.0.1 (*)
         │   │           ├── libdd-trace-stats v2.0.0
         │   │           │   └── libdd-data-pipeline v3.0.1 (*)
         │   │           └── (dev) libdd-trace-utils v3.0.1 (*)
         │   ├── libdd-common v3.0.2 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.2 (*)
         └── 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.2
         │   │       ├── libdd-data-pipeline v3.0.1
         │   │       ├── libdd-dogstatsd-client v2.0.0
         │   │       │   └── libdd-data-pipeline v3.0.1 (*)
         │   │       ├── libdd-telemetry v4.0.0
         │   │       │   └── libdd-data-pipeline v3.0.1 (*)
         │   │       └── libdd-trace-utils v3.0.1
         │   │           ├── libdd-data-pipeline v3.0.1 (*)
         │   │           ├── libdd-trace-stats v2.0.0
         │   │           │   └── libdd-data-pipeline v3.0.1 (*)
         │   │           └── (dev) libdd-trace-utils v3.0.1 (*)
         │   ├── libdd-common v3.0.2 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.2 (*)
         └── 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.2
          │       ├── libdd-data-pipeline v3.0.1
          │       ├── libdd-dogstatsd-client v2.0.0
          │       │   └── libdd-data-pipeline v3.0.1 (*)
          │       ├── libdd-telemetry v4.0.0
          │       │   └── libdd-data-pipeline v3.0.1 (*)
          │       └── libdd-trace-utils v3.0.1
          │           ├── libdd-data-pipeline v3.0.1 (*)
          │           ├── libdd-trace-stats v2.0.0
          │           │   └── libdd-data-pipeline v3.0.1 (*)
          │           └── (dev) libdd-trace-utils v3.0.1 (*)
          ├── libdd-common v3.0.2 (*)
          └── tokio-rustls v0.26.0
              ├── hyper-rustls v0.27.7 (*)
              └── libdd-common v3.0.2 (*)

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.1

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.2
        │   │       └── libdd-dogstatsd-client v2.0.0
        │   ├── libdd-common v3.0.2 (*)
        │   └── tokio-rustls v0.26.0
        │       ├── hyper-rustls v0.27.7 (*)
        │       └── libdd-common v3.0.2 (*)
        └── 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.2
        │   │       └── libdd-dogstatsd-client v2.0.0
        │   ├── libdd-common v3.0.2 (*)
        │   └── tokio-rustls v0.26.0
        │       ├── hyper-rustls v0.27.7 (*)
        │       └── libdd-common v3.0.2 (*)
        └── 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.2
         │       └── libdd-dogstatsd-client v2.0.0
         ├── libdd-common v3.0.2 (*)
         └── tokio-rustls v0.26.0
             ├── hyper-rustls v0.27.7 (*)
             └── libdd-common v3.0.2 (*)

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.2
         │   │   │   └── libdd-profiling v1.0.0
         │   │   │       └── (dev) libdd-profiling v1.0.0 (*)
         │   │   └── reqwest v0.13.2
         │   │       ├── libdd-common v3.0.2 (*)
         │   │       └── libdd-profiling v1.0.0 (*)
         │   ├── libdd-common v3.0.2 (*)
         │   ├── 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.2 (*)
         │       └── 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.2
         │   │   │   └── libdd-profiling v1.0.0
         │   │   │       └── (dev) libdd-profiling v1.0.0 (*)
         │   │   └── reqwest v0.13.2
         │   │       ├── libdd-common v3.0.2 (*)
         │   │       └── libdd-profiling v1.0.0 (*)
         │   ├── libdd-common v3.0.2 (*)
         │   ├── 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.2 (*)
         │       └── 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.2
      │   │   │   └── libdd-profiling v1.0.0
      │   │   │       └── (dev) libdd-profiling v1.0.0 (*)
      │   │   └── reqwest v0.13.2
      │   │       ├── libdd-common v3.0.2 (*)
      │   │       └── libdd-profiling v1.0.0 (*)
      │   ├── libdd-common v3.0.2 (*)
      │   ├── 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.2 (*)
      │       └── 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.2
        │   │       └── libdd-telemetry v4.0.0
        │   ├── libdd-common v3.0.2 (*)
        │   └── tokio-rustls v0.26.0
        │       ├── hyper-rustls v0.27.7 (*)
        │       └── libdd-common v3.0.2 (*)
        └── 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.2
        │   │       └── libdd-telemetry v4.0.0
        │   ├── libdd-common v3.0.2 (*)
        │   └── tokio-rustls v0.26.0
        │       ├── hyper-rustls v0.27.7 (*)
        │       └── libdd-common v3.0.2 (*)
        └── 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.2
         │       └── libdd-telemetry v4.0.0
         ├── libdd-common v3.0.2 (*)
         └── tokio-rustls v0.26.0
             ├── hyper-rustls v0.27.7 (*)
             └── libdd-common v3.0.2 (*)

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.2
         │   │       ├── libdd-trace-obfuscation v2.0.0
         │   │       └── libdd-trace-utils v3.0.1
         │   │           ├── (dev) libdd-trace-obfuscation v2.0.0 (*)
         │   │           └── (dev) libdd-trace-utils v3.0.1 (*)
         │   ├── libdd-common v3.0.2 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.2 (*)
         └── 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.2
         │   │       ├── libdd-trace-obfuscation v2.0.0
         │   │       └── libdd-trace-utils v3.0.1
         │   │           ├── (dev) libdd-trace-obfuscation v2.0.0 (*)
         │   │           └── (dev) libdd-trace-utils v3.0.1 (*)
         │   ├── libdd-common v3.0.2 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.2 (*)
         └── 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.2
          │       ├── libdd-trace-obfuscation v2.0.0
          │       └── libdd-trace-utils v3.0.1
          │           ├── (dev) libdd-trace-obfuscation v2.0.0 (*)
          │           └── (dev) libdd-trace-utils v3.0.1 (*)
          ├── libdd-common v3.0.2 (*)
          └── tokio-rustls v0.26.0
              ├── hyper-rustls v0.27.7 (*)
              └── libdd-common v3.0.2 (*)

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.2
         │   │       └── libdd-trace-utils v3.0.1
         │   │           ├── libdd-trace-stats v2.0.0
         │   │           └── (dev) libdd-trace-utils v3.0.1 (*)
         │   ├── libdd-common v3.0.2 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.2 (*)
         └── 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.2
         │   │       └── libdd-trace-utils v3.0.1
         │   │           ├── libdd-trace-stats v2.0.0
         │   │           └── (dev) libdd-trace-utils v3.0.1 (*)
         │   ├── libdd-common v3.0.2 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.2 (*)
         └── 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.2
          │       └── libdd-trace-utils v3.0.1
          │           ├── libdd-trace-stats v2.0.0
          │           └── (dev) libdd-trace-utils v3.0.1 (*)
          ├── libdd-common v3.0.2 (*)
          └── tokio-rustls v0.26.0
              ├── hyper-rustls v0.27.7 (*)
              └── libdd-common v3.0.2 (*)

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.2
         │   │       └── libdd-trace-utils v3.0.1
         │   │           └── (dev) libdd-trace-utils v3.0.1 (*)
         │   ├── libdd-common v3.0.2 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.2 (*)
         └── 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.2
         │   │       └── libdd-trace-utils v3.0.1
         │   │           └── (dev) libdd-trace-utils v3.0.1 (*)
         │   ├── libdd-common v3.0.2 (*)
         │   └── tokio-rustls v0.26.0
         │       ├── hyper-rustls v0.27.7 (*)
         │       └── libdd-common v3.0.2 (*)
         └── 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.2
          │       └── libdd-trace-utils v3.0.1
          │           └── (dev) libdd-trace-utils v3.0.1 (*)
          ├── libdd-common v3.0.2 (*)
          └── tokio-rustls v0.26.0
              ├── hyper-rustls v0.27.7 (*)
              └── libdd-common v3.0.2 (*)

advisories FAILED, bans ok, sources ok

Updated: 2026-03-25 11:23:52 UTC | Commit: ceaad0d | dependency-check job results

@codecov-commenter
Copy link
Copy Markdown

codecov-commenter commented Mar 25, 2026 •
edited
Loading

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.42%. Comparing base (d1eb663) to head (a11baaa).

Additional details and impacted files 
@@                               Coverage Diff                               @@
##           release/libdd-data-pipeline/20260324-152000    #1785      +/-   ##
===============================================================================
- Coverage                                        70.46%   70.42%   -0.05%     
===============================================================================
  Files                                              410      410              
  Lines                                            62138    62138              
===============================================================================
- Hits                                             43786    43760      -26     
- Misses                                           18352    18378      +26
Components Coverage Δ
libdd-crashtracker 64.90% <ø> (-0.04%) ⬇️
libdd-crashtracker-ffi 34.86% <ø> (-0.13%) ⬇️
libdd-alloc 98.77% <ø> (ø)
libdd-data-pipeline 87.48% <ø> (-0.13%) ⬇️
libdd-data-pipeline-ffi 72.75% <ø> (-0.70%) ⬇️
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% <ø> (ø)
libdd-profiling 81.61% <ø> (+0.01%) ⬆️
libdd-profiling-ffi 64.94% <ø> (ø)
datadog-sidecar 31.28% <ø> (-0.36%) ⬇️
datdog-sidecar-ffi 11.69% <ø> (-1.65%) ⬇️
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-prod-us1-5
Copy link
Copy Markdown

datadog-prod-us1-5 bot commented Mar 25, 2026 •
edited
Loading

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 70.42% (-0.04%)

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

@pr-commenter
Copy link
Copy Markdown

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

Benchmarks

Comparison

Benchmark execution time: 2026-03-25 11:35:43

Comparing candidate commit a11baaa in PR branch release-proposal/libdd-data-pipeline/20260324-152000 with baseline commit d1eb663 in branch release/libdd-data-pipeline/20260324-152000.

Found 2 performance improvements and 4 performance regressions! Performance is the same for 55 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:normalization/normalize_name/normalize_name/good

  • 🟩 execution_time [-681.758ns; -666.892ns] or [-6.439%; -6.298%]
  • 🟩 throughput [+6351902.300op/s; +6498392.641op/s] or [+6.726%; +6.881%]

scenario:normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000...

  • 🟥 execution_time [+38.824µs; +39.120µs] or [+7.823%; +7.883%]
  • 🟥 throughput [-147286.813op/s; -146161.244op/s] or [-7.309%; -7.253%]

scenario:normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters

  • 🟥 execution_time [+26.958µs; +27.054µs] or [+16.021%; +16.078%]
  • 🟥 throughput [-823272.773op/s; -820520.484op/s] or [-13.853%; -13.807%]

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 a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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.091ms 14.150ms ± 0.042ms 14.145ms ± 0.014ms 14.158ms 14.192ms 14.307ms 14.569ms 3.00% 5.631 48.708 0.30% 0.003ms 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.144ms; 14.156ms] or [-0.041%; +0.041%] None None None

Group 2

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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 12.909ms 12.951ms ± 0.016ms 12.948ms ± 0.010ms 12.960ms 12.976ms 13.003ms 13.020ms 0.55% 1.037 2.299 0.12% 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 [12.949ms; 12.953ms] or [-0.017%; +0.017%] None None None

Group 3

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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.420µs 2.443µs ± 0.023µs 2.436µs ± 0.009µs 2.450µs 2.510µs 2.517µs 2.521µs 3.46% 1.926 3.442 0.93% 0.002µ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.440µs; 2.446µs] or [-0.129%; +0.129%] None None None

Group 4

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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.384ms 3.405ms ± 0.013ms 3.403ms ± 0.008ms 3.413ms 3.431ms 3.446ms 3.454ms 1.51% 1.096 1.474 0.38% 0.001ms 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.404ms; 3.407ms] or [-0.053%; +0.053%] None None None

Group 5

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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.426µs 5.511µs ± 0.045µs 5.522µs ± 0.036µs 5.550µs 5.572µs 5.594µs 5.610µs 1.59% -0.082 -1.284 0.81% 0.003µ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.505µs; 5.518µs] or [-0.113%; +0.113%] None None None

Group 6

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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.574µs 186.171µs ± 0.479µs 186.035µs ± 0.190µs 186.270µs 187.189µs 187.550µs 188.484µs 1.32% 1.789 3.440 0.26% 0.034µs 1 200
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo... throughput 5305495.751op/s 5371447.430op/s ± 13750.039op/s 5375331.516op/s ± 5480.691op/s 5380302.115op/s 5385246.065op/s 5386635.348op/s 5388684.463op/s 0.25% -1.772 3.349 0.26% 972.275op/s 1 200
normalization/normalize_name/normalize_name/bad-name execution_time 17.809µs 17.993µs ± 0.087µs 17.995µs ± 0.063µs 18.055µs 18.112µs 18.181µs 18.468µs 2.63% 0.709 3.151 0.48% 0.006µs 1 200
normalization/normalize_name/normalize_name/bad-name throughput 54147123.650op/s 55578344.218op/s ± 267779.368op/s 55570005.908op/s ± 194118.425op/s 55770945.536op/s 55997973.552op/s 56094481.449op/s 56151172.168op/s 1.05% -0.644 2.799 0.48% 18934.861op/s 1 200
normalization/normalize_name/normalize_name/good execution_time 9.865µs 9.914µs ± 0.047µs 9.883µs ± 0.012µs 9.954µs 9.999µs 10.011µs 10.046µs 1.66% 0.740 -0.915 0.47% 0.003µs 1 200
normalization/normalize_name/normalize_name/good throughput 99537636.453op/s 100867219.318op/s ± 473459.674op/s 101185429.146op/s ± 118458.525op/s 101244373.279op/s 101310392.810op/s 101335814.041op/s 101370869.518op/s 0.18% -0.733 -0.935 0.47% 33478.655op/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.104µs; 186.237µs] or [-0.036%; +0.036%] None None None
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo... throughput [5369541.807op/s; 5373353.054op/s] or [-0.035%; +0.035%] None None None
normalization/normalize_name/normalize_name/bad-name execution_time [17.981µs; 18.005µs] or [-0.067%; +0.067%] None None None
normalization/normalize_name/normalize_name/bad-name throughput [55541232.573op/s; 55615455.863op/s] or [-0.067%; +0.067%] None None None
normalization/normalize_name/normalize_name/good execution_time [9.908µs; 9.921µs] or [-0.065%; +0.065%] None None None
normalization/normalize_name/normalize_name/good throughput [100801602.360op/s; 100932836.275op/s] or [-0.065%; +0.065%] None None None

Group 7

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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 14.036µs 14.220µs ± 0.170µs 14.165µs ± 0.089µs 14.366µs 14.532µs 14.621µs 14.859µs 4.90% 1.006 0.029 1.20% 0.012µs 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
two way interface execution_time [14.196µs; 14.244µs] or [-0.166%; +0.166%] None None None

Group 8

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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 727.543µs 728.444µs ± 0.449µs 728.403µs ± 0.281µs 728.684µs 729.201µs 729.781µs 730.276µs 0.26% 0.951 1.899 0.06% 0.032µ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 [728.382µs; 728.507µs] or [-0.009%; +0.009%] None None None

Group 9

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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.941µs 33.609µs ± 1.276µs 33.029µs ± 0.041µs 33.082µs 36.371µs 36.407µs 36.843µs 11.55% 1.709 0.937 3.79% 0.090µ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.432µs; 33.786µs] or [-0.526%; +0.526%] None None None

Group 10

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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.152ms 4.156ms ± 0.007ms 4.155ms ± 0.002ms 4.157ms 4.161ms 4.164ms 4.239ms 2.03% 10.489 129.118 0.16% 0.000ms 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.155ms; 4.157ms] or [-0.022%; +0.022%] None None None

Group 11

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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 534.478µs 535.237µs ± 0.702µs 535.105µs ± 0.223µs 535.379µs 536.026µs 537.035µs 542.130µs 1.31% 6.220 52.538 0.13% 0.050µs 1 200
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000... throughput 1844576.024op/s 1868334.364op/s ± 2432.026op/s 1868793.647op/s ± 777.264op/s 1869386.103op/s 1870148.474op/s 1870859.919op/s 1870982.752op/s 0.12% -6.158 51.699 0.13% 171.970op/s 1 200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて execution_time 380.029µs 380.961µs ± 0.335µs 380.941µs ± 0.220µs 381.169µs 381.521µs 381.778µs 381.896µs 0.25% 0.170 -0.120 0.09% 0.024µs 1 200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて throughput 2618511.556op/s 2624941.613op/s ± 2308.886op/s 2625075.129op/s ± 1517.508op/s 2626415.667op/s 2628380.278op/s 2629768.419op/s 2631380.841op/s 0.24% -0.165 -0.122 0.09% 163.263op/s 1 200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters execution_time 194.537µs 195.273µs ± 0.305µs 195.285µs ± 0.198µs 195.485µs 195.717µs 195.975µs 196.403µs 0.57% 0.101 0.415 0.16% 0.022µs 1 200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters throughput 5091563.734op/s 5121043.339op/s ± 7986.524op/s 5120712.372op/s ± 5182.191op/s 5125846.098op/s 5134336.295op/s 5138532.400op/s 5140416.566op/s 0.38% -0.090 0.398 0.16% 564.733op/s 1 200
normalization/normalize_service/normalize_service/[empty string] execution_time 37.856µs 38.178µs ± 0.145µs 38.175µs ± 0.103µs 38.275µs 38.433µs 38.529µs 38.568µs 1.03% 0.219 -0.195 0.38% 0.010µs 1 200
normalization/normalize_service/normalize_service/[empty string] throughput 25928074.595op/s 26193370.019op/s ± 99739.527op/s 26195170.262op/s ± 70572.777op/s 26266726.595op/s 26344011.974op/s 26408902.250op/s 26416157.632op/s 0.84% -0.199 -0.206 0.38% 7052.650op/s 1 200
normalization/normalize_service/normalize_service/test_ASCII execution_time 45.776µs 45.883µs ± 0.098µs 45.870µs ± 0.024µs 45.897µs 45.955µs 46.018µs 47.133µs 2.75% 10.454 130.061 0.21% 0.007µs 1 200
normalization/normalize_service/normalize_service/test_ASCII throughput 21216657.433op/s 21794539.009op/s ± 45591.541op/s 21800683.138op/s ± 11329.904op/s 21810396.168op/s 21823542.474op/s 21835113.560op/s 21845354.792op/s 0.20% -10.308 127.545 0.21% 3223.809op/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 [535.140µs; 535.334µs] or [-0.018%; +0.018%] None None None
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000... throughput [1867997.308op/s; 1868671.419op/s] or [-0.018%; +0.018%] None None None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて execution_time [380.915µs; 381.008µs] or [-0.012%; +0.012%] None None None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて throughput [2624621.624op/s; 2625261.603op/s] or [-0.012%; +0.012%] None None None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters execution_time [195.231µs; 195.315µs] or [-0.022%; +0.022%] None None None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters throughput [5119936.483op/s; 5122150.194op/s] or [-0.022%; +0.022%] None None None
normalization/normalize_service/normalize_service/[empty string] execution_time [38.158µs; 38.198µs] or [-0.053%; +0.053%] None None None
normalization/normalize_service/normalize_service/[empty string] throughput [26179547.080op/s; 26207192.958op/s] or [-0.053%; +0.053%] None None None
normalization/normalize_service/normalize_service/test_ASCII execution_time [45.870µs; 45.897µs] or [-0.030%; +0.030%] None None None
normalization/normalize_service/normalize_service/test_ASCII throughput [21788220.460op/s; 21800857.558op/s] or [-0.029%; +0.029%] None None None

Group 12

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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 47.655ms 48.012ms ± 1.104ms 47.856ms ± 0.062ms 47.936ms 48.192ms 50.487ms 60.135ms 25.66% 9.509 93.479 2.29% 0.078ms 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 [47.859ms; 48.165ms] or [-0.319%; +0.319%] None None None

Group 13

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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.855ns 254.627ns ± 12.112ns 249.003ns ± 3.561ns 257.108ns 282.867ns 287.178ns 290.586ns 16.70% 1.439 0.824 4.75% 0.856ns 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.305ns] or [-0.659%; +0.659%] None None None

Group 14

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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 86.472µs 86.814µs ± 0.204µs 86.793µs ± 0.109µs 86.915µs 87.061µs 87.161µs 88.566µs 2.04% 3.302 26.042 0.23% 0.014µ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 [86.786µs; 86.842µs] or [-0.033%; +0.033%] None None None

Group 15

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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.192µs 146.449µs ± 1.794µs 146.111µs ± 0.587µs 146.768µs 148.593µs 154.632µs 162.137µs 10.97% 4.791 32.878 1.22% 0.127µ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.201µs; 146.698µs] or [-0.170%; +0.170%] None None None

Group 16

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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.512µs 162.204µs ± 0.402µs 162.124µs ± 0.170µs 162.339µs 162.749µs 163.615µs 165.502µs 2.08% 4.048 25.846 0.25% 0.028µ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.149µs; 162.260µs] or [-0.034%; +0.034%] None None None

Group 17

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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.965µs 5.032µs ± 0.048µs 5.031µs ± 0.036µs 5.063µs 5.119µs 5.122µs 5.122µs 1.81% 0.421 -1.025 0.95% 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.025µs; 5.039µs] or [-0.133%; +0.133%] None None None

Group 18

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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.897µs 3.915µs ± 0.003µs 3.915µs ± 0.002µs 3.917µs 3.920µs 3.922µs 3.925µs 0.24% -0.782 7.023 0.07% 0.000µs 1 200
credit_card/is_card_number/ throughput 254796379.797op/s 255400593.517op/s ± 190093.891op/s 255414410.642op/s ± 130281.619op/s 255537634.305op/s 255630665.624op/s 255695113.016op/s 256605842.880op/s 0.47% 0.801 7.140 0.07% 13441.668op/s 1 200
credit_card/is_card_number/ 3782-8224-6310-005 execution_time 79.215µs 79.962µs ± 0.464µs 79.884µs ± 0.331µs 80.249µs 80.757µs 81.242µs 81.344µs 1.83% 0.621 -0.063 0.58% 0.033µs 1 200
credit_card/is_card_number/ 3782-8224-6310-005 throughput 12293395.344op/s 12506422.216op/s ± 72290.225op/s 12518110.342op/s ± 52024.954op/s 12562253.276op/s 12602017.710op/s 12617268.480op/s 12623841.387op/s 0.84% -0.595 -0.118 0.58% 5111.691op/s 1 200
credit_card/is_card_number/ 378282246310005 execution_time 73.102µs 73.870µs ± 0.433µs 73.805µs ± 0.257µs 74.076µs 74.688µs 75.050µs 75.470µs 2.26% 0.789 0.792 0.58% 0.031µs 1 200
credit_card/is_card_number/ 378282246310005 throughput 13250317.496op/s 13537759.726op/s ± 78922.155op/s 13549300.569op/s ± 47254.065op/s 13592374.689op/s 13652810.438op/s 13664233.370op/s 13679499.781op/s 0.96% -0.752 0.696 0.58% 5580.639op/s 1 200
credit_card/is_card_number/37828224631 execution_time 3.896µs 3.916µs ± 0.004µs 3.915µs ± 0.002µs 3.919µs 3.922µs 3.924µs 3.925µs 0.26% -0.295 3.595 0.09% 0.000µs 1 200
credit_card/is_card_number/37828224631 throughput 254749116.009op/s 255365558.408op/s ± 235665.454op/s 255409999.305op/s ± 147289.759op/s 255528351.892op/s 255633104.163op/s 255710462.949op/s 256677277.468op/s 0.50% 0.310 3.676 0.09% 16664.064op/s 1 200
credit_card/is_card_number/378282246310005 execution_time 69.824µs 70.467µs ± 0.476µs 70.371µs ± 0.327µs 70.814µs 71.307µs 71.902µs 72.152µs 2.53% 0.959 0.823 0.67% 0.034µs 1 200
credit_card/is_card_number/378282246310005 throughput 13859673.999op/s 14191727.655op/s ± 95270.829op/s 14210320.797op/s ± 65982.073op/s 14266057.535op/s 14310101.504op/s 14318698.158op/s 14321819.292op/s 0.78% -0.921 0.711 0.67% 6736.665op/s 1 200
credit_card/is_card_number/37828224631000521389798 execution_time 53.015µs 53.141µs ± 0.035µs 53.141µs ± 0.026µs 53.167µs 53.198µs 53.211µs 53.213µs 0.14% -0.109 -0.272 0.07% 0.002µs 1 200
credit_card/is_card_number/37828224631000521389798 throughput 18792370.457op/s 18817809.658op/s ± 12313.954op/s 18817994.942op/s ± 9355.999op/s 18827570.337op/s 18836730.249op/s 18841059.534op/s 18862508.877op/s 0.24% 0.112 -0.266 0.07% 870.728op/s 1 200
credit_card/is_card_number/x371413321323331 execution_time 6.430µs 6.437µs ± 0.004µs 6.436µs ± 0.003µs 6.440µs 6.444µs 6.446µs 6.446µs 0.16% 0.484 -0.823 0.06% 0.000µs 1 200
credit_card/is_card_number/x371413321323331 throughput 155138498.547op/s 155353914.831op/s ± 95620.111op/s 155384368.333op/s ± 68012.495op/s 155434522.007op/s 155474797.371op/s 155509781.975op/s 155532591.534op/s 0.10% -0.483 -0.825 0.06% 6761.363op/s 1 200
credit_card/is_card_number_no_luhn/ execution_time 3.894µs 3.915µs ± 0.003µs 3.914µs ± 0.001µs 3.916µs 3.919µs 3.920µs 3.921µs 0.18% -2.267 19.969 0.07% 0.000µs 1 200
credit_card/is_card_number_no_luhn/ throughput 255018295.941op/s 255443363.487op/s ± 170657.705op/s 255471170.079op/s ± 97197.133op/s 255543397.704op/s 255627793.452op/s 255682801.731op/s 256829348.709op/s 0.53% 2.301 20.290 0.07% 12067.322op/s 1 200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 execution_time 64.932µs 65.213µs ± 0.178µs 65.175µs ± 0.110µs 65.318µs 65.575µs 65.769µs 65.965µs 1.21% 1.371 2.202 0.27% 0.013µs 1 200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 throughput 15159478.203op/s 15334500.711op/s ± 41797.198op/s 15343249.161op/s ± 25954.045op/s 15367352.444op/s 15377878.000op/s 15384941.620op/s 15400779.279op/s 0.37% -1.352 2.119 0.27% 2955.508op/s 1 200
credit_card/is_card_number_no_luhn/ 378282246310005 execution_time 58.637µs 58.946µs ± 0.193µs 58.895µs ± 0.127µs 59.067µs 59.301µs 59.455µs 59.579µs 1.16% 0.824 0.010 0.33% 0.014µs 1 200
credit_card/is_card_number_no_luhn/ 378282246310005 throughput 16784341.355op/s 16964782.739op/s ± 55527.692op/s 16979247.260op/s ± 36654.185op/s 17008999.462op/s 17030928.507op/s 17045397.605op/s 17054088.748op/s 0.44% -0.811 -0.021 0.33% 3926.401op/s 1 200
credit_card/is_card_number_no_luhn/37828224631 execution_time 3.897µs 3.915µs ± 0.003µs 3.915µs ± 0.002µs 3.917µs 3.920µs 3.921µs 3.922µs 0.17% -0.988 5.783 0.07% 0.000µs 1 200
credit_card/is_card_number_no_luhn/37828224631 throughput 254978136.249op/s 255404491.712op/s ± 190159.237op/s 255415993.690op/s ± 132632.556op/s 255527807.815op/s 255664095.443op/s 255732832.266op/s 256583114.300op/s 0.46% 1.004 5.888 0.07% 13446.289op/s 1 200
credit_card/is_card_number_no_luhn/378282246310005 execution_time 55.424µs 55.691µs ± 0.199µs 55.623µs ± 0.125µs 55.811µs 56.031µs 56.326µs 56.410µs 1.41% 1.014 0.815 0.36% 0.014µs 1 200
credit_card/is_card_number_no_luhn/378282246310005 throughput 17727498.216op/s 17956564.613op/s ± 63818.207op/s 17978102.681op/s ± 40570.070op/s 18009106.310op/s 18028934.728op/s 18037382.367op/s 18042873.476op/s 0.36% -0.995 0.747 0.35% 4512.629op/s 1 200
credit_card/is_card_number_no_luhn/37828224631000521389798 execution_time 53.073µs 53.126µs ± 0.033µs 53.118µs ± 0.017µs 53.142µs 53.198µs 53.234µs 53.242µs 0.23% 1.218 1.569 0.06% 0.002µs 1 200
credit_card/is_card_number_no_luhn/37828224631000521389798 throughput 18782226.052op/s 18823155.962op/s ± 11846.145op/s 18825947.195op/s ± 5980.016op/s 18831115.309op/s 18837539.053op/s 18841596.139op/s 18842049.393op/s 0.09% -1.214 1.557 0.06% 837.649op/s 1 200
credit_card/is_card_number_no_luhn/x371413321323331 execution_time 6.429µs 6.437µs ± 0.004µs 6.436µs ± 0.002µs 6.438µs 6.444µs 6.449µs 6.453µs 0.26% 1.204 2.173 0.06% 0.000µs 1 200
credit_card/is_card_number_no_luhn/x371413321323331 throughput 154966527.629op/s 155362967.594op/s ± 90966.620op/s 155376701.264op/s ± 55057.226op/s 155428544.473op/s 155473868.745op/s 155495051.960op/s 155545201.446op/s 0.11% -1.199 2.154 0.06% 6432.311op/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.915µs; 3.916µs] or [-0.010%; +0.010%] None None None
credit_card/is_card_number/ throughput [255374248.332op/s; 255426938.702op/s] or [-0.010%; +0.010%] None None None
credit_card/is_card_number/ 3782-8224-6310-005 execution_time [79.897µs; 80.026µs] or [-0.080%; +0.080%] None None None
credit_card/is_card_number/ 3782-8224-6310-005 throughput [12496403.486op/s; 12516440.946op/s] or [-0.080%; +0.080%] None None None
credit_card/is_card_number/ 378282246310005 execution_time [73.810µs; 73.930µs] or [-0.081%; +0.081%] None None None
credit_card/is_card_number/ 378282246310005 throughput [13526821.874op/s; 13548697.577op/s] or [-0.081%; +0.081%] None None None
credit_card/is_card_number/37828224631 execution_time [3.915µs; 3.916µs] or [-0.013%; +0.013%] None None None
credit_card/is_card_number/37828224631 throughput [255332897.443op/s; 255398219.373op/s] or [-0.013%; +0.013%] None None None
credit_card/is_card_number/378282246310005 execution_time [70.401µs; 70.533µs] or [-0.094%; +0.094%] None None None
credit_card/is_card_number/378282246310005 throughput [14178524.035op/s; 14204931.276op/s] or [-0.093%; +0.093%] None None None
credit_card/is_card_number/37828224631000521389798 execution_time [53.136µs; 53.146µs] or [-0.009%; +0.009%] None None None
credit_card/is_card_number/37828224631000521389798 throughput [18816103.062op/s; 18819516.253op/s] or [-0.009%; +0.009%] None None None
credit_card/is_card_number/x371413321323331 execution_time [6.436µs; 6.437µs] or [-0.009%; +0.009%] None None None
credit_card/is_card_number/x371413321323331 throughput [155340662.803op/s; 155367166.859op/s] or [-0.009%; +0.009%] None None None
credit_card/is_card_number_no_luhn/ execution_time [3.914µs; 3.915µs] or [-0.009%; +0.009%] None None None
credit_card/is_card_number_no_luhn/ throughput [255419711.971op/s; 255467015.004op/s] or [-0.009%; +0.009%] None None None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 execution_time [65.188µs; 65.238µs] or [-0.038%; +0.038%] None None None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 throughput [15328708.021op/s; 15340293.400op/s] or [-0.038%; +0.038%] None None None
credit_card/is_card_number_no_luhn/ 378282246310005 execution_time [58.919µs; 58.973µs] or [-0.045%; +0.045%] None None None
credit_card/is_card_number_no_luhn/ 378282246310005 throughput [16957087.135op/s; 16972478.343op/s] or [-0.045%; +0.045%] None None None
credit_card/is_card_number_no_luhn/37828224631 execution_time [3.915µs; 3.916µs] or [-0.010%; +0.010%] None None None
credit_card/is_card_number_no_luhn/37828224631 throughput [255378137.471op/s; 255430845.953op/s] or [-0.010%; +0.010%] None None None
credit_card/is_card_number_no_luhn/378282246310005 execution_time [55.663µs; 55.718µs] or [-0.049%; +0.049%] None None None
credit_card/is_card_number_no_luhn/378282246310005 throughput [17947720.023op/s; 17965409.203op/s] or [-0.049%; +0.049%] None None None
credit_card/is_card_number_no_luhn/37828224631000521389798 execution_time [53.121µs; 53.131µs] or [-0.009%; +0.009%] None None None
credit_card/is_card_number_no_luhn/37828224631000521389798 throughput [18821514.200op/s; 18824797.724op/s] or [-0.009%; +0.009%] None None None
credit_card/is_card_number_no_luhn/x371413321323331 execution_time [6.436µs; 6.437µs] or [-0.008%; +0.008%] None None None
credit_card/is_card_number_no_luhn/x371413321323331 throughput [155350360.496op/s; 155375574.693op/s] or [-0.008%; +0.008%] None None None

Group 19

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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.011ns 192.439ns ± 2.071ns 192.029ns ± 1.475ns 193.828ns 196.444ns 198.079ns 200.707ns 4.52% 1.013 0.797 1.07% 0.146ns 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.152ns; 192.726ns] or [-0.149%; +0.149%] None None None

Group 20

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a11baaa 1774437501 release-proposal/libdd-data-pipeline/20260324-152000
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.187ms 4.194ms ± 0.003ms 4.194ms ± 0.002ms 4.197ms 4.199ms 4.200ms 4.202ms 0.19% -0.189 -0.697 0.08% 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.194ms; 4.195ms] or [-0.011%; +0.011%] None None None

Baseline

Omitted due to size.

@dd-octo-sts
Copy link
Copy Markdown
Contributor

dd-octo-sts bot commented Mar 25, 2026 •
edited
Loading

Artifact Size Benchmark Report

aarch64-alpine-linux-musl
Artifact Baseline Commit Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a 101.42 MB 101.42 MB +0% (+1.77 KB) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so 8.70 MB 8.70 MB 0% (0 B) 👌
aarch64-unknown-linux-gnu
Artifact Baseline Commit Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so 11.29 MB 11.29 MB +0% (+384 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a 118.20 MB 118.21 MB +0% (+7.47 KB) 👌
libdatadog-x64-windows
Artifact Baseline Commit Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll 27.26 MB 27.26 MB -0% (-512 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib 80.34 KB 80.34 KB 0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb 186.51 MB 186.48 MB --.01% (-32.00 KB) 💪
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib 921.90 MB 922.18 MB +.03% (+284.18 KB) 🔍
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll 8.99 MB 8.99 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib 80.34 KB 80.34 KB 0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb 26.83 MB 26.83 MB 0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib 60.99 MB 60.99 MB +0% (+852 B) 👌
libdatadog-x86-windows
Artifact Baseline Commit Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll 23.07 MB 23.07 MB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib 81.59 KB 81.59 KB 0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb 190.75 MB 190.77 MB +.01% (+24.00 KB) 🔍
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib 905.43 MB 905.49 MB +0% (+63.89 KB) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll 6.86 MB 6.86 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib 81.59 KB 81.59 KB 0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb 28.94 MB 28.94 MB 0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib 57.39 MB 57.39 MB +0% (+70 B) 👌
x86_64-alpine-linux-musl
Artifact Baseline Commit Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a 88.29 MB 88.29 MB -0% (-2.67 KB) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so 10.28 MB 10.28 MB 0% (0 B) 👌
x86_64-unknown-linux-gnu
Artifact Baseline Commit Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a 110.95 MB 110.95 MB -0% (-1.66 KB) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so 12.02 MB 12.02 MB +0% (+8 B) 👌

@iunanua iunanua marked this pull request as ready for review March 25, 2026 11:14
@iunanua iunanua requested review from a team as code owners March 25, 2026 11:14
@iunanua iunanua requested a review from a team as a code owner March 25, 2026 11:14
@iunanua iunanua requested review from BridgeAR and removed request for a team March 25, 2026 11:14
paullegranddc
paullegranddc reviewed Mar 25, 2026
View reviewed changes
@hoolioh hoolioh merged commit 1235d7d into release/libdd-data-pipeline/20260324-152000 Mar 26, 2026
62 of 69 checks passed
@hoolioh hoolioh deleted the release-proposal/libdd-data-pipeline/20260324-152000 branch March 26, 2026 08:31
iunanua added a commit that referenced this pull request Mar 30, 2026
@dd-octo-sts @hoolioh @iunanua
chore(release): merge release branch to main (proposal for libdd-data…
bfdbeae 
…-pipeline (#1785)) (#1802)

This PR merges the release branch to main

Co-authored-by: Julio Gonzalez <[email protected]>
Co-authored-by: iunanua <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@paullegranddc paullegranddc paullegranddc left review comments

@iunanua iunanua iunanua approved these changes

@BridgeAR BridgeAR Awaiting requested review from BridgeAR BridgeAR 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 skip-pr-title-semver-check telemetry

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@hoolioh @codecov-commenter @iunanua @paullegranddc