Skip to content

chore(release): proposal for libdd-common#1777

Merged
iunanua merged 1 commit intorelease/libdd-common/20260323-092142from
release-proposal/libdd-common/20260323-092142
Mar 23, 2026
Merged

chore(release): proposal for libdd-common#1777
iunanua merged 1 commit intorelease/libdd-common/20260323-092142from
release-proposal/libdd-common/20260323-092142

Conversation

@dd-octo-sts
Copy link
Copy Markdown
Contributor

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

Release proposal for libdd-common and its dependencies

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

libdd-common

Next version: 3.0.1

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

Commits

@github-actions @iunanua
chore: Release
a490536 
Co-authored-by: iunanua <[email protected]>
@github-actions
Copy link
Copy Markdown

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

📚 Documentation Check Results

⚠️ 4307 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-profiling - 647 warning(s)

📦 libdd-telemetry - 476 warning(s)

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

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

Updated: 2026-03-23 09:28:24 UTC | Commit: 8db82fe | missing-docs job results

@github-actions
Copy link
Copy Markdown

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

🔒 Cargo Deny Results

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

📦 libdd-common - 3 error(s)

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

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

error[vulnerability]: CRLs not considered authorative 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 correct 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 by [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      ├── rustls v0.23.37
      │   ├── hyper-rustls v0.27.7
      │   │   ├── libdd-common v3.0.1
      │   │   └── reqwest v0.13.2
      │   │       └── libdd-common v3.0.1 (*)
      │   ├── libdd-common v3.0.1 (*)
      │   ├── reqwest v0.13.2 (*)
      │   ├── rustls-platform-verifier v0.6.2
      │   │   └── reqwest v0.13.2 (*)
      │   └── tokio-rustls v0.26.0
      │       ├── hyper-rustls v0.27.7 (*)
      │       ├── libdd-common v3.0.1 (*)
      │       └── reqwest v0.13.2 (*)
      └── rustls-platform-verifier v0.6.2 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-crashtracker - 4 error(s)

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

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

error[unmaintained]: paste - no longer maintained
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:131:1
    │
131 │ paste 1.0.15 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unmaintained advisory detected
    │
    ├ ID: RUSTSEC-2024-0436
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2024-0436
    ├ The creator of the crate `paste` has stated in the [`README.md`](https://github.com/dtolnay/paste/blob/master/README.md) 
      that this project is not longer maintained as well as archived the repository
      
      ## Possible Alternative(s)
      
      - [`pastey`]: a fork of paste and is aimed to be a drop-in replacement with additional features for paste crate
      - [`with_builtin_macros`]: crate providing a [superset of `paste`'s functionality including general `macro_rules!` eager expansions](https://docs.rs/with_builtin_macros/0.1.0/with_builtin_macros/macro.with_eager_expansions.html)  and `concat!`/`concat_idents!` macros
      
      [`pastey`]: https://crates.io/crates/pastey
      [`with_builtin_macros`]: https://crates.io/crates/with_builtin_macros
    ├ Announcement: https://github.com/dtolnay/paste
    ├ Solution: No safe upgrade is available!
    ├ paste v1.0.15
      └── libdd-libunwind-sys v0.1.0
          └── libdd-crashtracker v1.0.0

error[vulnerability]: CRLs not considered authorative 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 correct 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 by [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      └── rustls v0.23.37
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v3.0.1
          │       ├── (build) libdd-crashtracker v1.0.0
          │       └── libdd-telemetry v3.0.0
          │           └── libdd-crashtracker v1.0.0 (*)
          ├── libdd-common v3.0.1 (*)
          └── tokio-rustls v0.26.0
              ├── hyper-rustls v0.27.7 (*)
              └── libdd-common v3.0.1 (*)

advisories FAILED, bans ok, sources ok

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

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

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

error[vulnerability]: CRLs not considered authorative 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 correct 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 by [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      └── rustls v0.23.37
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v3.0.1
          │       ├── libdd-data-pipeline v2.0.1
          │       ├── libdd-dogstatsd-client v1.0.1
          │       │   └── libdd-data-pipeline v2.0.1 (*)
          │       ├── libdd-telemetry v3.0.0
          │       │   └── libdd-data-pipeline v2.0.1 (*)
          │       └── libdd-trace-utils v2.0.2
          │           ├── libdd-data-pipeline v2.0.1 (*)
          │           ├── libdd-trace-stats v1.0.3
          │           │   └── libdd-data-pipeline v2.0.1 (*)
          │           └── (dev) libdd-trace-utils v2.0.2 (*)
          ├── libdd-common v3.0.1 (*)
          └── tokio-rustls v0.26.0
              ├── hyper-rustls v0.27.7 (*)
              └── libdd-common v3.0.1 (*)

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

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

error[vulnerability]: CRLs not considered authorative 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 correct 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 by [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
   ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
   ├ rustls-webpki v0.103.9
     └── rustls v0.23.37
         ├── hyper-rustls v0.27.7
         │   └── libdd-common v3.0.1
         │       └── libdd-dogstatsd-client v1.0.1
         ├── libdd-common v3.0.1 (*)
         └── tokio-rustls v0.26.0
             ├── hyper-rustls v0.27.7 (*)
             └── libdd-common v3.0.1 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-profiling - 3 error(s)

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

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

error[vulnerability]: CRLs not considered authorative 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 correct 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 by [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      ├── rustls v0.23.37
      │   ├── hyper-rustls v0.27.7
      │   │   ├── libdd-common v3.0.1
      │   │   │   └── libdd-profiling v1.0.0
      │   │   │       └── (dev) libdd-profiling v1.0.0 (*)
      │   │   └── reqwest v0.13.2
      │   │       ├── libdd-common v3.0.1 (*)
      │   │       └── libdd-profiling v1.0.0 (*)
      │   ├── libdd-common v3.0.1 (*)
      │   ├── libdd-profiling v1.0.0 (*)
      │   ├── reqwest v0.13.2 (*)
      │   ├── rustls-platform-verifier v0.6.2
      │   │   ├── libdd-profiling v1.0.0 (*)
      │   │   └── reqwest v0.13.2 (*)
      │   └── tokio-rustls v0.26.0
      │       ├── hyper-rustls v0.27.7 (*)
      │       ├── libdd-common v3.0.1 (*)
      │       └── reqwest v0.13.2 (*)
      └── rustls-platform-verifier v0.6.2 (*)

advisories FAILED, bans ok, sources ok

📦 libdd-telemetry - 3 error(s)

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

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

error[vulnerability]: CRLs not considered authorative 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 correct 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 by [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
   ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
   ├ rustls-webpki v0.103.9
     └── rustls v0.23.37
         ├── hyper-rustls v0.27.7
         │   └── libdd-common v3.0.1
         │       └── libdd-telemetry v3.0.0
         ├── libdd-common v3.0.1 (*)
         └── tokio-rustls v0.26.0
             ├── hyper-rustls v0.27.7 (*)
             └── libdd-common v3.0.1 (*)

advisories FAILED, bans ok, sources ok

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

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

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

error[vulnerability]: CRLs not considered authorative 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 correct 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 by [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      └── rustls v0.23.37
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v3.0.1
          │       ├── libdd-trace-obfuscation v1.0.1
          │       └── libdd-trace-utils v2.0.2
          │           ├── (dev) libdd-trace-obfuscation v1.0.1 (*)
          │           └── (dev) libdd-trace-utils v2.0.2 (*)
          ├── libdd-common v3.0.1 (*)
          └── tokio-rustls v0.26.0
              ├── hyper-rustls v0.27.7 (*)
              └── libdd-common v3.0.1 (*)

advisories FAILED, bans ok, sources ok

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

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

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

error[vulnerability]: CRLs not considered authorative 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 correct 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 by [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      └── rustls v0.23.37
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v3.0.1
          │       └── libdd-trace-utils v2.0.2
          │           └── (dev) libdd-trace-utils v2.0.2 (*)
          ├── libdd-common v3.0.1 (*)
          └── tokio-rustls v0.26.0
              ├── hyper-rustls v0.27.7 (*)
              └── libdd-common v3.0.1 (*)

advisories FAILED, bans ok, sources ok

Updated: 2026-03-23 09:30:07 UTC | Commit: 8db82fe | dependency-check job results

@iunanua iunanua marked this pull request as ready for review March 23, 2026 09:35
@iunanua iunanua requested review from a team as code owners March 23, 2026 09:35
@iunanua iunanua merged commit 24c055f into release/libdd-common/20260323-092142 Mar 23, 2026
44 of 46 checks passed
@iunanua iunanua deleted the release-proposal/libdd-common/20260323-092142 branch March 23, 2026 09:35
@pr-commenter
Copy link
Copy Markdown

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

Benchmarks

Comparison

Benchmark execution time: 2026-03-23 09:41:50

Comparing candidate commit a490536 in PR branch release-proposal/libdd-common/20260323-092142 with baseline commit ed00b92 in branch release/libdd-common/20260323-092142.

Found 5 performance improvements and 15 performance regressions! Performance is the same for 41 metrics, 0 unstable metrics.

Explanation

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

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

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

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

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

More details about the CI and significant changes

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

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

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

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

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

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

scenario:benching serializing traces from their internal representation to msgpack

  • 🟩 execution_time [-626.960µs; -615.735µs] or [-4.258%; -4.181%]

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

  • 🟥 execution_time [+3.676µs; +3.893µs] or [+4.862%; +5.150%]
  • 🟥 throughput [-650269.621op/s; -612920.852op/s] or [-4.916%; -4.633%]

scenario:credit_card/is_card_number/ 378282246310005

  • 🟥 execution_time [+4.265µs; +4.373µs] or [+6.216%; +6.373%]
  • 🟥 throughput [-872751.069op/s; -852532.047op/s] or [-5.989%; -5.850%]

scenario:credit_card/is_card_number/378282246310005

  • 🟥 execution_time [+4.855µs; +4.948µs] or [+7.486%; +7.629%]
  • 🟥 throughput [-1092896.700op/s; -1073409.013op/s] or [-7.088%; -6.962%]

scenario:credit_card/is_card_number/37828224631000521389798

  • 🟥 execution_time [+6.529µs; +6.550µs] or [+14.298%; +14.345%]
  • 🟥 throughput [-2748512.914op/s; -2738737.928op/s] or [-12.550%; -12.505%]

scenario:credit_card/is_card_number/x371413321323331

  • 🟩 execution_time [-400.480ns; -396.938ns] or [-6.222%; -6.167%]
  • 🟩 throughput [+10213397.012op/s; +10308451.123op/s] or [+6.574%; +6.635%]

scenario:credit_card/is_card_number_no_luhn/ 378282246310005

  • 🟥 execution_time [+3.974µs; +4.023µs] or [+7.324%; +7.414%]
  • 🟥 throughput [-1272470.403op/s; -1257355.779op/s] or [-6.904%; -6.822%]

scenario:credit_card/is_card_number_no_luhn/378282246310005

  • 🟥 execution_time [+4.196µs; +4.266µs] or [+8.304%; +8.442%]
  • 🟥 throughput [-1541519.693op/s; -1516467.914op/s] or [-7.789%; -7.663%]

scenario:credit_card/is_card_number_no_luhn/37828224631000521389798

  • 🟥 execution_time [+6.526µs; +6.565µs] or [+14.294%; +14.380%]
  • 🟥 throughput [-2755933.825op/s; -2737388.755op/s] or [-12.582%; -12.498%]

scenario:credit_card/is_card_number_no_luhn/x371413321323331

  • 🟩 execution_time [-400.431ns; -397.660ns] or [-6.222%; -6.179%]
  • 🟩 throughput [+10234256.510op/s; +10308396.856op/s] or [+6.587%; +6.634%]

scenario:profile_add_sample_frames_x1000

  • 🟥 execution_time [+285.292µs; +286.329µs] or [+6.945%; +6.970%]

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 a490536 1774257915 release-proposal/libdd-common/20260323-092142
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.341ms 4.345ms ± 0.008ms 4.344ms ± 0.002ms 4.346ms 4.350ms 4.352ms 4.453ms 2.51% 11.915 155.269 0.19% 0.001ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
profile_add_sample_timestamped_x1000 execution_time [4.344ms; 4.346ms] or [-0.026%; +0.026%] None None None

Group 2

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a490536 1774257915 release-proposal/libdd-common/20260323-092142
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.892µs 3.911µs ± 0.003µs 3.911µs ± 0.002µs 3.913µs 3.916µs 3.918µs 3.920µs 0.22% -0.971 8.193 0.07% 0.000µs 1 200
credit_card/is_card_number/ throughput 255124922.911op/s 255661169.842op/s ± 188862.827op/s 255686256.864op/s ± 122026.783op/s 255774999.625op/s 255881335.432op/s 255956222.990op/s 256906690.726op/s 0.48% 0.991 8.334 0.07% 13354.619op/s 1 200
credit_card/is_card_number/ 3782-8224-6310-005 execution_time 78.672µs 79.383µs ± 0.303µs 79.347µs ± 0.191µs 79.536µs 79.956µs 80.210µs 80.454µs 1.39% 0.741 0.485 0.38% 0.021µs 1 200
credit_card/is_card_number/ 3782-8224-6310-005 throughput 12429519.201op/s 12597261.493op/s ± 47885.542op/s 12602832.493op/s ± 30471.423op/s 12633265.916op/s 12663872.393op/s 12681509.448op/s 12711029.572op/s 0.86% -0.719 0.441 0.38% 3386.019op/s 1 200
credit_card/is_card_number/ 378282246310005 execution_time 72.369µs 72.937µs ± 0.378µs 72.870µs ± 0.244µs 73.157µs 73.679µs 74.053µs 74.397µs 2.10% 0.987 1.049 0.52% 0.027µs 1 200
credit_card/is_card_number/ 378282246310005 throughput 13441348.138op/s 13710797.738op/s ± 70771.396op/s 13722994.995op/s ± 45939.509op/s 13765217.191op/s 13801697.880op/s 13814980.244op/s 13818060.124op/s 0.69% -0.955 0.949 0.51% 5004.293op/s 1 200
credit_card/is_card_number/37828224631 execution_time 3.895µs 3.913µs ± 0.003µs 3.913µs ± 0.002µs 3.915µs 3.918µs 3.920µs 3.923µs 0.25% -0.696 5.039 0.08% 0.000µs 1 200
credit_card/is_card_number/37828224631 throughput 254936617.792op/s 255567512.816op/s ± 203144.612op/s 255575074.910op/s ± 132583.534op/s 255700409.123op/s 255844600.810op/s 255927073.089op/s 256765963.899op/s 0.47% 0.712 5.125 0.08% 14364.493op/s 1 200
credit_card/is_card_number/378282246310005 execution_time 69.069µs 69.758µs ± 0.313µs 69.711µs ± 0.192µs 69.940µs 70.378µs 70.593µs 70.778µs 1.53% 0.649 0.270 0.45% 0.022µs 1 200
credit_card/is_card_number/378282246310005 throughput 14128598.108op/s 14335627.001op/s ± 64207.900op/s 14344886.965op/s ± 39661.872op/s 14380459.114op/s 14426208.021op/s 14449604.237op/s 14478375.792op/s 0.93% -0.624 0.226 0.45% 4540.184op/s 1 200
credit_card/is_card_number/37828224631000521389798 execution_time 52.130µs 52.199µs ± 0.033µs 52.195µs ± 0.020µs 52.216µs 52.255µs 52.301µs 52.343µs 0.28% 1.206 2.488 0.06% 0.002µs 1 200
credit_card/is_card_number/37828224631000521389798 throughput 19104728.540op/s 19157339.835op/s ± 12008.532op/s 19159101.067op/s ± 7196.102op/s 19165464.791op/s 19172329.344op/s 19175705.264op/s 19182771.953op/s 0.12% -1.200 2.466 0.06% 849.131op/s 1 200
credit_card/is_card_number/x371413321323331 execution_time 6.028µs 6.038µs ± 0.012µs 6.034µs ± 0.003µs 6.039µs 6.050µs 6.107µs 6.116µs 1.36% 4.419 23.097 0.20% 0.001µs 1 200
credit_card/is_card_number/x371413321323331 throughput 163495492.182op/s 165630889.818op/s ± 325312.715op/s 165722206.776op/s ± 81992.873op/s 165777368.305op/s 165845756.030op/s 165871523.449op/s 165893548.002op/s 0.10% -4.386 22.785 0.20% 23003.083op/s 1 200
credit_card/is_card_number_no_luhn/ execution_time 3.894µs 3.912µs ± 0.003µs 3.912µs ± 0.002µs 3.914µs 3.918µs 3.920µs 3.921µs 0.25% -0.082 4.608 0.08% 0.000µs 1 200
credit_card/is_card_number_no_luhn/ throughput 255011112.979op/s 255625927.277op/s ± 213927.063op/s 255655452.062op/s ± 129263.837op/s 255770228.110op/s 255860607.557op/s 255930886.272op/s 256829716.876op/s 0.46% 0.099 4.683 0.08% 15126.928op/s 1 200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 execution_time 63.941µs 64.357µs ± 0.184µs 64.318µs ± 0.112µs 64.492µs 64.664µs 64.796µs 65.061µs 1.15% 0.877 0.884 0.28% 0.013µs 1 200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 throughput 15370306.145op/s 15538366.275op/s ± 44272.872op/s 15547675.079op/s ± 27121.786op/s 15572018.253op/s 15591007.966op/s 15611914.166op/s 15639364.280op/s 0.59% -0.859 0.827 0.28% 3130.565op/s 1 200
credit_card/is_card_number_no_luhn/ 378282246310005 execution_time 58.089µs 58.257µs ± 0.142µs 58.207µs ± 0.067µs 58.317µs 58.575µs 58.691µs 58.908µs 1.20% 1.654 3.050 0.24% 0.010µs 1 200
credit_card/is_card_number_no_luhn/ 378282246310005 throughput 16975735.259op/s 17165462.577op/s ± 41732.814op/s 17180146.623op/s ± 19809.520op/s 17194315.130op/s 17208362.060op/s 17212781.644op/s 17214968.415op/s 0.20% -1.637 2.969 0.24% 2950.956op/s 1 200
credit_card/is_card_number_no_luhn/37828224631 execution_time 3.889µs 3.911µs ± 0.003µs 3.911µs ± 0.002µs 3.913µs 3.915µs 3.918µs 3.919µs 0.19% -2.658 18.040 0.08% 0.000µs 1 200
credit_card/is_card_number_no_luhn/37828224631 throughput 255182699.731op/s 255667011.549op/s ± 198235.492op/s 255657241.657op/s ± 103244.425op/s 255760387.340op/s 255903962.780op/s 255952595.739op/s 257147022.200op/s 0.58% 2.688 18.291 0.08% 14017.366op/s 1 200
credit_card/is_card_number_no_luhn/378282246310005 execution_time 54.480µs 54.760µs ± 0.188µs 54.687µs ± 0.089µs 54.874µs 55.092µs 55.444µs 55.495µs 1.48% 1.434 2.219 0.34% 0.013µs 1 200
credit_card/is_card_number_no_luhn/378282246310005 throughput 18019660.927op/s 18261746.048op/s ± 62306.442op/s 18285981.991op/s ± 29612.302op/s 18307469.448op/s 18323382.745op/s 18338701.837op/s 18355203.274op/s 0.38% -1.412 2.122 0.34% 4405.731op/s 1 200
credit_card/is_card_number_no_luhn/37828224631000521389798 execution_time 52.132µs 52.201µs ± 0.034µs 52.196µs ± 0.020µs 52.218µs 52.261µs 52.316µs 52.371µs 0.33% 1.310 3.738 0.07% 0.002µs 1 200
credit_card/is_card_number_no_luhn/37828224631000521389798 throughput 19094669.981op/s 19156750.638op/s ± 12493.508op/s 19158424.309op/s ± 7475.633op/s 19164973.615op/s 19172911.839op/s 19177776.792op/s 19182179.755op/s 0.12% -1.302 3.699 0.07% 883.424op/s 1 200
credit_card/is_card_number_no_luhn/x371413321323331 execution_time 6.027µs 6.037µs ± 0.009µs 6.036µs ± 0.003µs 6.039µs 6.044µs 6.066µs 6.115µs 1.31% 5.862 44.868 0.15% 0.001µs 1 200
credit_card/is_card_number_no_luhn/x371413321323331 throughput 163524712.512op/s 165651634.945op/s ± 250681.498op/s 165670858.496op/s ± 86295.773op/s 165772977.411op/s 165867370.129op/s 165904201.195op/s 165920508.356op/s 0.15% -5.805 44.228 0.15% 17725.859op/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.911µs; 3.912µs] or [-0.010%; +0.010%] None None None
credit_card/is_card_number/ throughput [255634995.271op/s; 255687344.414op/s] or [-0.010%; +0.010%] None None None
credit_card/is_card_number/ 3782-8224-6310-005 execution_time [79.342µs; 79.425µs] or [-0.053%; +0.053%] None None None
credit_card/is_card_number/ 3782-8224-6310-005 throughput [12590625.017op/s; 12603897.968op/s] or [-0.053%; +0.053%] None None None
credit_card/is_card_number/ 378282246310005 execution_time [72.885µs; 72.990µs] or [-0.072%; +0.072%] None None None
credit_card/is_card_number/ 378282246310005 throughput [13700989.504op/s; 13720605.973op/s] or [-0.072%; +0.072%] None None None
credit_card/is_card_number/37828224631 execution_time [3.912µs; 3.913µs] or [-0.011%; +0.011%] None None None
credit_card/is_card_number/37828224631 throughput [255539358.926op/s; 255595666.705op/s] or [-0.011%; +0.011%] None None None
credit_card/is_card_number/378282246310005 execution_time [69.714µs; 69.801µs] or [-0.062%; +0.062%] None None None
credit_card/is_card_number/378282246310005 throughput [14326728.403op/s; 14344525.598op/s] or [-0.062%; +0.062%] None None None
credit_card/is_card_number/37828224631000521389798 execution_time [52.195µs; 52.204µs] or [-0.009%; +0.009%] None None None
credit_card/is_card_number/37828224631000521389798 throughput [19155675.568op/s; 19159004.102op/s] or [-0.009%; +0.009%] None None None
credit_card/is_card_number/x371413321323331 execution_time [6.036µs; 6.039µs] or [-0.027%; +0.027%] None None None
credit_card/is_card_number/x371413321323331 throughput [165585804.605op/s; 165675975.032op/s] or [-0.027%; +0.027%] None None None
credit_card/is_card_number_no_luhn/ execution_time [3.912µs; 3.912µs] or [-0.012%; +0.012%] None None None
credit_card/is_card_number_no_luhn/ throughput [255596279.043op/s; 255655575.510op/s] or [-0.012%; +0.012%] None None None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 execution_time [64.332µs; 64.383µs] or [-0.040%; +0.040%] None None None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005 throughput [15532230.480op/s; 15544502.069op/s] or [-0.039%; +0.039%] None None None
credit_card/is_card_number_no_luhn/ 378282246310005 execution_time [58.237µs; 58.277µs] or [-0.034%; +0.034%] None None None
credit_card/is_card_number_no_luhn/ 378282246310005 throughput [17159678.810op/s; 17171246.344op/s] or [-0.034%; +0.034%] None None None
credit_card/is_card_number_no_luhn/37828224631 execution_time [3.911µs; 3.912µs] or [-0.011%; +0.011%] None None None
credit_card/is_card_number_no_luhn/37828224631 throughput [255639538.017op/s; 255694485.082op/s] or [-0.011%; +0.011%] None None None
credit_card/is_card_number_no_luhn/378282246310005 execution_time [54.734µs; 54.786µs] or [-0.048%; +0.048%] None None None
credit_card/is_card_number_no_luhn/378282246310005 throughput [18253110.975op/s; 18270381.122op/s] or [-0.047%; +0.047%] None None None
credit_card/is_card_number_no_luhn/37828224631000521389798 execution_time [52.196µs; 52.206µs] or [-0.009%; +0.009%] None None None
credit_card/is_card_number_no_luhn/37828224631000521389798 throughput [19155019.158op/s; 19158482.118op/s] or [-0.009%; +0.009%] None None None
credit_card/is_card_number_no_luhn/x371413321323331 execution_time [6.036µs; 6.038µs] or [-0.021%; +0.021%] None None None
credit_card/is_card_number_no_luhn/x371413321323331 throughput [165616892.900op/s; 165686376.990op/s] or [-0.021%; +0.021%] None None None

Group 3

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a490536 1774257915 release-proposal/libdd-common/20260323-092142
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.390ms 4.394ms ± 0.002ms 4.393ms ± 0.001ms 4.395ms 4.397ms 4.398ms 4.413ms 0.43% 3.003 21.679 0.05% 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.393ms; 4.394ms] or [-0.007%; +0.007%] None None None

Group 4

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a490536 1774257915 release-proposal/libdd-common/20260323-092142
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 160.380µs 160.937µs ± 0.262µs 160.895µs ± 0.128µs 161.029µs 161.399µs 161.920µs 162.264µs 0.85% 1.829 6.102 0.16% 0.019µ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 [160.901µs; 160.974µs] or [-0.023%; +0.023%] None None None

Group 5

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a490536 1774257915 release-proposal/libdd-common/20260323-092142
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.391ms 3.421ms ± 0.026ms 3.412ms ± 0.008ms 3.426ms 3.483ms 3.506ms 3.517ms 3.09% 1.749 2.452 0.76% 0.002ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
receiver_entry_point/report/2598 execution_time [3.418ms; 3.425ms] or [-0.106%; +0.106%] None None None

Group 6

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a490536 1774257915 release-proposal/libdd-common/20260323-092142
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 84.491µs 84.856µs ± 0.905µs 84.751µs ± 0.060µs 84.828µs 85.047µs 85.694µs 97.313µs 14.82% 13.179 178.441 1.06% 0.064µ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 [84.730µs; 84.981µs] or [-0.148%; +0.148%] None None None

Group 7

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a490536 1774257915 release-proposal/libdd-common/20260323-092142
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 35.098µs 35.364µs ± 0.401µs 35.206µs ± 0.046µs 35.292µs 36.014µs 36.060µs 38.987µs 10.74% 4.349 31.924 1.13% 0.028µ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 [35.309µs; 35.420µs] or [-0.157%; +0.157%] None None None

Group 8

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a490536 1774257915 release-proposal/libdd-common/20260323-092142
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.326µs 185.792µs ± 0.274µs 185.761µs ± 0.180µs 185.955µs 186.341µs 186.547µs 186.892µs 0.61% 0.899 1.054 0.15% 0.019µs 1 200
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo... throughput 5350674.513op/s 5382387.082op/s ± 7925.976op/s 5383262.012op/s ± 5219.942op/s 5388168.002op/s 5393198.993op/s 5394756.528op/s 5395894.776op/s 0.23% -0.889 1.023 0.15% 560.451op/s 1 200
normalization/normalize_name/normalize_name/bad-name execution_time 17.866µs 17.958µs ± 0.101µs 17.948µs ± 0.022µs 17.973µs 18.006µs 18.062µs 19.297µs 7.51% 11.634 151.200 0.56% 0.007µs 1 200
normalization/normalize_name/normalize_name/bad-name throughput 51822095.624op/s 55688519.421op/s ± 295142.669op/s 55715554.173op/s ± 66740.858op/s 55775110.979op/s 55870413.218op/s 55920504.020op/s 55972264.320op/s 0.46% -11.329 145.823 0.53% 20869.738op/s 1 200
normalization/normalize_name/normalize_name/good execution_time 10.136µs 10.206µs ± 0.029µs 10.208µs ± 0.019µs 10.226µs 10.250µs 10.273µs 10.284µs 0.74% -0.053 -0.137 0.29% 0.002µs 1 200
normalization/normalize_name/normalize_name/good throughput 97238062.143op/s 97978502.600op/s ± 280366.679op/s 97960783.135op/s ± 186702.108op/s 98178017.693op/s 98450699.103op/s 98624984.323op/s 98655607.042op/s 0.71% 0.068 -0.140 0.29% 19824.918op/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 [185.754µs; 185.830µs] or [-0.020%; +0.020%] None None None
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo... throughput [5381288.618op/s; 5383485.546op/s] or [-0.020%; +0.020%] None None None
normalization/normalize_name/normalize_name/bad-name execution_time [17.944µs; 17.972µs] or [-0.078%; +0.078%] None None None
normalization/normalize_name/normalize_name/bad-name throughput [55647615.486op/s; 55729423.356op/s] or [-0.073%; +0.073%] None None None
normalization/normalize_name/normalize_name/good execution_time [10.202µs; 10.210µs] or [-0.040%; +0.040%] None None None
normalization/normalize_name/normalize_name/good throughput [97939646.474op/s; 98017358.725op/s] or [-0.040%; +0.040%] None None None

Group 9

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a490536 1774257915 release-proposal/libdd-common/20260323-092142
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.966µs 5.035µs ± 0.042µs 5.039µs ± 0.042µs 5.073µs 5.089µs 5.090µs 5.093µs 1.07% -0.301 -1.453 0.84% 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.029µs; 5.041µs] or [-0.116%; +0.116%] None None None

Group 10

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a490536 1774257915 release-proposal/libdd-common/20260323-092142
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
benching serializing traces from their internal representation to msgpack execution_time 14.068ms 14.105ms ± 0.027ms 14.102ms ± 0.012ms 14.113ms 14.138ms 14.211ms 14.283ms 1.29% 3.043 14.479 0.19% 0.002ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
benching serializing traces from their internal representation to msgpack execution_time [14.101ms; 14.108ms] or [-0.026%; +0.026%] None None None

Group 11

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a490536 1774257915 release-proposal/libdd-common/20260323-092142
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 49.028ms 49.246ms ± 0.629ms 49.155ms ± 0.043ms 49.204ms 49.295ms 51.482ms 56.433ms 14.81% 8.976 90.457 1.27% 0.044ms 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 [49.159ms; 49.333ms] or [-0.177%; +0.177%] None None None

Group 12

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a490536 1774257915 release-proposal/libdd-common/20260323-092142
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.286µs 2.367µs ± 0.022µs 2.366µs ± 0.007µs 2.378µs 2.401µs 2.409µs 2.411µs 1.91% -1.355 3.618 0.91% 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.364µs; 2.370µs] or [-0.126%; +0.126%] None None None

Group 13

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a490536 1774257915 release-proposal/libdd-common/20260323-092142
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.736ns 193.158ns ± 1.944ns 192.984ns ± 1.268ns 194.112ns 196.713ns 199.458ns 202.713ns 5.04% 1.293 2.894 1.00% 0.137ns 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.889ns; 193.427ns] or [-0.139%; +0.139%] None None None

Group 14

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a490536 1774257915 release-proposal/libdd-common/20260323-092142
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
concentrator/add_spans_to_concentrator execution_time 13.018ms 13.053ms ± 0.015ms 13.052ms ± 0.008ms 13.061ms 13.074ms 13.086ms 13.130ms 0.59% 0.781 3.418 0.11% 0.001ms 1 200
scenario metric 95% CI mean Shapiro-Wilk pvalue Ljung-Box pvalue (lag=1) Dip test pvalue
concentrator/add_spans_to_concentrator execution_time [13.051ms; 13.055ms] or [-0.016%; +0.016%] None None None

Group 15

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a490536 1774257915 release-proposal/libdd-common/20260323-092142
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
two way interface execution_time 13.909µs 14.056µs ± 0.090µs 14.055µs ± 0.080µs 14.129µs 14.195µs 14.216µs 14.350µs 2.10% 0.212 -0.871 0.64% 0.006µ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.044µs; 14.069µs] or [-0.089%; +0.089%] None None None

Group 16

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a490536 1774257915 release-proposal/libdd-common/20260323-092142
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 716.462µs 717.654µs ± 0.559µs 717.602µs ± 0.337µs 717.925µs 718.600µs 719.259µs 719.436µs 0.26% 0.762 0.866 0.08% 0.040µ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 [717.577µs; 717.732µs] or [-0.011%; +0.011%] None None None

Group 17

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a490536 1774257915 release-proposal/libdd-common/20260323-092142
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.333µs 5.414µs ± 0.045µs 5.413µs ± 0.013µs 5.422µs 5.455µs 5.623µs 5.637µs 4.15% 2.757 11.339 0.82% 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.407µs; 5.420µs] or [-0.114%; +0.114%] None None None

Group 18

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a490536 1774257915 release-proposal/libdd-common/20260323-092142
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.570µs 146.577µs ± 1.673µs 146.314µs ± 0.534µs 146.889µs 148.555µs 153.940µs 161.242µs 10.20% 4.926 34.225 1.14% 0.118µ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.345µs; 146.809µs] or [-0.158%; +0.158%] None None None

Group 19

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a490536 1774257915 release-proposal/libdd-common/20260323-092142
scenario metric min mean ± sd median ± mad p75 p95 p99 max peak_to_median_ratio skewness kurtosis cv sem runs sample_size
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000... execution_time 495.243µs 496.043µs ± 0.599µs 495.986µs ± 0.228µs 496.220µs 496.674µs 496.926µs 502.867µs 1.39% 7.490 82.686 0.12% 0.042µs 1 200
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000... throughput 1988596.064op/s 2015955.569op/s ± 2410.853op/s 2016184.021op/s ± 925.359op/s 2017073.010op/s 2018076.009op/s 2018899.164op/s 2019209.412op/s 0.15% -7.388 81.127 0.12% 170.473op/s 1 200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて execution_time 373.557µs 374.320µs ± 0.344µs 374.307µs ± 0.253µs 374.573µs 374.845µs 375.205µs 375.491µs 0.32% 0.363 0.000 0.09% 0.024µs 1 200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて throughput 2663183.069op/s 2671511.584op/s ± 2451.251op/s 2671606.118op/s ± 1805.149op/s 2673358.898op/s 2675230.242op/s 2675733.386op/s 2676964.834op/s 0.20% -0.357 -0.008 0.09% 173.330op/s 1 200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters execution_time 167.769µs 168.543µs ± 0.455µs 168.398µs ± 0.330µs 168.905µs 169.320µs 169.556µs 169.754µs 0.80% 0.486 -0.928 0.27% 0.032µs 1 200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters throughput 5890893.528op/s 5933261.686op/s ± 15998.986op/s 5938305.438op/s ± 11661.019op/s 5947047.832op/s 5953868.966op/s 5955855.746op/s 5960571.788op/s 0.37% -0.479 -0.938 0.27% 1131.299op/s 1 200
normalization/normalize_service/normalize_service/[empty string] execution_time 38.263µs 38.360µs ± 0.039µs 38.358µs ± 0.023µs 38.383µs 38.422µs 38.492µs 38.522µs 0.43% 0.716 2.118 0.10% 0.003µs 1 200
normalization/normalize_service/normalize_service/[empty string] throughput 25959017.592op/s 26069058.936op/s ± 26224.337op/s 26070483.920op/s ± 15682.776op/s 26085427.813op/s 26105245.180op/s 26130459.562op/s 26134928.970op/s 0.25% -0.705 2.089 0.10% 1854.341op/s 1 200
normalization/normalize_service/normalize_service/test_ASCII execution_time 46.185µs 46.291µs ± 0.114µs 46.273µs ± 0.032µs 46.311µs 46.404µs 46.530µs 47.649µs 2.98% 8.746 100.055 0.25% 0.008µs 1 200
normalization/normalize_service/normalize_service/test_ASCII throughput 20986655.788op/s 21602618.787op/s ± 51993.679op/s 21611068.753op/s ± 14895.137op/s 21624868.307op/s 21638313.547op/s 21648596.681op/s 21651946.182op/s 0.19% -8.559 96.964 0.24% 3676.508op/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 [495.960µs; 496.126µs] or [-0.017%; +0.017%] None None None
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000... throughput [2015621.448op/s; 2016289.690op/s] or [-0.017%; +0.017%] None None None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて execution_time [374.273µs; 374.368µs] or [-0.013%; +0.013%] None None None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて throughput [2671171.864op/s; 2671851.303op/s] or [-0.013%; +0.013%] None None None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters execution_time [168.480µs; 168.606µs] or [-0.037%; +0.037%] None None None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters throughput [5931044.381op/s; 5935478.992op/s] or [-0.037%; +0.037%] None None None
normalization/normalize_service/normalize_service/[empty string] execution_time [38.354µs; 38.365µs] or [-0.014%; +0.014%] None None None
normalization/normalize_service/normalize_service/[empty string] throughput [26065424.495op/s; 26072693.377op/s] or [-0.014%; +0.014%] None None None
normalization/normalize_service/normalize_service/test_ASCII execution_time [46.275µs; 46.307µs] or [-0.034%; +0.034%] None None None
normalization/normalize_service/normalize_service/test_ASCII throughput [21595412.963op/s; 21609824.611op/s] or [-0.033%; +0.033%] None None None

Group 20

cpu_model git_commit_sha git_commit_date git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz a490536 1774257915 release-proposal/libdd-common/20260323-092142
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 237.886ns 248.648ns ± 13.678ns 243.344ns ± 3.915ns 249.262ns 282.776ns 290.209ns 293.045ns 20.42% 1.872 2.458 5.49% 0.967ns 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 [246.752ns; 250.544ns] or [-0.762%; +0.762%] None None None

Baseline

Omitted due to size.

@codecov-commenter
Copy link
Copy Markdown

codecov-commenter commented Mar 23, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.41%. Comparing base (ed00b92) to head (a490536).
⚠️ Report is 2 commits behind head on release/libdd-common/20260323-092142.

Additional details and impacted files 
@@                           Coverage Diff                            @@
##           release/libdd-common/20260323-092142    #1777      +/-   ##
========================================================================
+ Coverage                                 70.40%   70.41%   +0.01%     
========================================================================
  Files                                       410      410              
  Lines                                     62123    62123              
========================================================================
+ Hits                                      43735    43744       +9     
+ Misses                                    18388    18379       -9
Components Coverage Δ
libdd-crashtracker 65.09% <ø> (+0.26%) ⬆️
libdd-crashtracker-ffi 36.25% <ø> (+2.16%) ⬆️
libdd-alloc 98.77% <ø> (ø)
libdd-data-pipeline 88.07% <ø> (+0.10%) ⬆️
libdd-data-pipeline-ffi 76.01% <ø> (+0.58%) ⬆️
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 70.51% <ø> (-2.27%) ⬇️
libdd-profiling 81.60% <ø> (-0.02%) ⬇️
libdd-profiling-ffi 64.94% <ø> (ø)
datadog-sidecar 31.00% <ø> (+0.33%) ⬆️
datdog-sidecar-ffi 10.41% <ø> (+1.57%) ⬆️
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.

iunanua added a commit that referenced this pull request Mar 23, 2026
@dd-octo-sts @github-actions @iunanua
chore(release): proposal for libdd-common - TESTING (#1777)
25fb18e 
# Release proposal for libdd-common and its dependencies

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

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

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

### Commits

- chore(build): update reqwest and quinn-proto dependency for dependabot
alert (#1774)
- chore(build): ekump/APMSP-2718 update aws-lc dependencies (#1751)

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
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

No reviews

Assignees

No one assigned

Labels

common crashtracker data-pipeline mini-agent release-proposal This is a release proposal PR skip-changelog-check skip-metadata-check telemetry

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@codecov-commenter @iunanua