chore(release): proposal for libdd-telemetry by dd-octo-sts[bot] · Pull Request #1779 · DataDog/libdatadog

dd-octo-sts · 2026-03-23T15:34:23Z

Release proposal for libdd-telemetry 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 (chore(build): update reqwest and quinn-proto dependency for dependabot alert #1774)
chore(build): ekump/APMSP-2718 update aws-lc dependencies (chore(build): ekump/APMSP-2718 update aws-lc dependencies #1751)

libdd-telemetry

Next version: 3.1.0
Semver bump: minor
Tag: libdd-telemetry-v3.1.0

Commits

refactor(sidecar)!: Refactor tarpc away (refactor(sidecar)!: Refactor tarpc away #1742)

Cargo publish dry-run failures

These crates did not pass cargo publish --dry-run --all-features --locked (dependencies are resolved as on crates.io, not via workspace path dependencies).

`libdd-telemetry`

    Updating crates.io index
warning: crate libdd-telemetry@3.0.0 already exists on crates.io index
   Packaging libdd-telemetry v3.0.0 (/home/runner/work/libdatadog/libdatadog/libdd-telemetry)
    Updating crates.io index
error: failed to prepare local package for uploading

Caused by:
  failed to select a version for the requirement `libdd-common = "^3.0.1"`
  candidate versions found which didn't match: 3.0.0, 2.0.1, 2.0.0, ...
  location searched: crates.io index
  required by package `libdd-telemetry v3.0.0 (/home/runner/work/libdatadog/libdatadog/libdd-telemetry)`

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

github-actions · 2026-03-23T15:36:51Z

📚 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 15:37:09 UTC | Commit: abb85b7 | missing-docs job results

github-actions · 2026-03-23T15:38:38Z

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

advisories FAILED, bans ok, sources ok

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

Show output

error[vulnerability]: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:11:1
   │
11 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0044
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0044
   ├ A logic error in CN (Common Name) validation allows certificates with
     wildcard or raw UTF-8 Unicode CN values to bypass name constraints
     enforcement. The `cn2dnsid` function does not recognize these CN patterns
     as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
     validation. However, `X509_check_host` accepts these CN values when no
     dNSName SAN is present, allowing certificates to bypass name constraints
     while still being used for hostname verification.
     
     Customers of AWS services do not need to take action. Applications using
     `aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.
     
     ## Workarounds
     
     Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
     fallback are not affected. Applications that only encounter certificates
     with dNSName SANs (standard for public WebPKI) are also not affected.
     
     Otherwise, there is no workaround and applications using `aws-lc-sys` should
     upgrade to the most recent releases of `aws-lc-sys`.
   ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
   ├ aws-lc-sys v0.38.0
     └── aws-lc-rs v1.16.1
         ├── rustls v0.23.37
         │   ├── hyper-rustls v0.27.7
         │   │   └── libdd-common v3.0.1
         │   │       ├── (build) libdd-crashtracker v1.0.0
         │   │       └── libdd-telemetry v3.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 authoritative by Distribution Point due to faulty matching logic
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:162:1
    │
162 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0049
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
    ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
      
      The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
      
      This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
      
      More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
      
      This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      └── rustls v0.23.37
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v3.0.1
          │       ├── (build) libdd-crashtracker v1.0.0
          │       └── libdd-telemetry v3.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 authoritative by Distribution Point due to faulty matching logic
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:241:1
    │
241 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0049
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
    ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
      
      The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
      
      This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
      
      More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
      
      This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      └── rustls v0.23.37
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v3.0.1
          │       ├── libdd-data-pipeline 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 authoritative by Distribution Point due to faulty matching logic
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:84:1
   │
84 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0049
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
   ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
     
     The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
     
     This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
     
     More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
     
     This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
   ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
   ├ rustls-webpki v0.103.9
     └── rustls v0.23.37
         ├── hyper-rustls v0.27.7
         │   └── libdd-common v3.0.1
         │       └── libdd-dogstatsd-client v1.0.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 authoritative by Distribution Point due to faulty matching logic
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:193:1
    │
193 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0049
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
    ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
      
      The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
      
      This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
      
      More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
      
      This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      ├── rustls v0.23.37
      │   ├── hyper-rustls v0.27.7
      │   │   ├── libdd-common v3.0.1
      │   │   │   └── libdd-profiling v1.0.0
      │   │   │       └── (dev) libdd-profiling v1.0.0 (*)
      │   │   └── reqwest v0.13.2
      │   │       ├── libdd-common v3.0.1 (*)
      │   │       └── libdd-profiling v1.0.0 (*)
      │   ├── libdd-common v3.0.1 (*)
      │   ├── libdd-profiling v1.0.0 (*)
      │   ├── reqwest v0.13.2 (*)
      │   ├── rustls-platform-verifier v0.6.2
      │   │   ├── libdd-profiling v1.0.0 (*)
      │   │   └── reqwest v0.13.2 (*)
      │   └── tokio-rustls v0.26.0
      │       ├── hyper-rustls v0.27.7 (*)
      │       ├── libdd-common v3.0.1 (*)
      │       └── reqwest v0.13.2 (*)
      └── rustls-platform-verifier v0.6.2 (*)

advisories FAILED, bans ok, sources ok

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

Show output

error[vulnerability]: AWS-LC X.509 Name Constraints Bypass via Wildcard/Unicode CN
  ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:6:1
  │
6 │ aws-lc-sys 0.38.0 registry+https://github.com/rust-lang/crates.io-index
  │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
  │
  ├ ID: RUSTSEC-2026-0044
  ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0044
  ├ A logic error in CN (Common Name) validation allows certificates with
    wildcard or raw UTF-8 Unicode CN values to bypass name constraints
    enforcement. The `cn2dnsid` function does not recognize these CN patterns
    as valid DNS identifiers, causing `NAME_CONSTRAINTS_check_CN` to skip
    validation. However, `X509_check_host` accepts these CN values when no
    dNSName SAN is present, allowing certificates to bypass name constraints
    while still being used for hostname verification.
    
    Customers of AWS services do not need to take action. Applications using
    `aws-lc-sys` should upgrade to the most recent release of `aws-lc-sys`.
    
    ## Workarounds
    
    Applications that set `X509_CHECK_FLAG_NEVER_CHECK_SUBJECT` to disable CN
    fallback are not affected. Applications that only encounter certificates
    with dNSName SANs (standard for public WebPKI) are also not affected.
    
    Otherwise, there is no workaround and applications using `aws-lc-sys` should
    upgrade to the most recent releases of `aws-lc-sys`.
  ├ Solution: Upgrade to >=0.39.0 (try `cargo update -p aws-lc-sys`)
  ├ aws-lc-sys v0.38.0
    └── aws-lc-rs v1.16.1
        ├── rustls v0.23.37
        │   ├── hyper-rustls v0.27.7
        │   │   └── libdd-common v3.0.1
        │   │       └── libdd-telemetry v3.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 authoritative by Distribution Point due to faulty matching logic
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:93:1
   │
93 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0049
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
   ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
     
     The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
     
     This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
     
     More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
     
     This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
   ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
   ├ rustls-webpki v0.103.9
     └── rustls v0.23.37
         ├── hyper-rustls v0.27.7
         │   └── libdd-common v3.0.1
         │       └── libdd-telemetry v3.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 authoritative by Distribution Point due to faulty matching logic
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:218:1
    │
218 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0049
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
    ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
      
      The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
      
      This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
      
      More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
      
      This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      └── rustls v0.23.37
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v3.0.1
          │       ├── libdd-trace-obfuscation v1.0.1
          │       └── libdd-trace-utils 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 authoritative by Distribution Point due to faulty matching logic
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:211:1
    │
211 │ rustls-webpki 0.103.9 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0049
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0049
    ├ If a certificate had more than one `distributionPoint`, then only the first `distributionPoint` would be considered against each CRL's `IssuingDistributionPoint` `distributionPoint`, and then the certificate's subsequent `distributionPoint`s would be ignored.
      
      The impact was that correctly provided CRLs would not be consulted to check revocation. With `UnknownStatusPolicy::Deny` (the default) this would lead to incorrect but safe `Error::UnknownRevocationStatus`. With `UnknownStatusPolicy::Allow` this would lead to inappropriate acceptance of revoked certificates.
      
      This vulnerability is thought to be of limited impact. This is because both the certificate and CRL are signed -- an attacker would need to compromise a trusted issuing authority to trigger this bug.  An attacker with such capabilities could likely bypass revocation checking through other more impactful means (such as publishing a valid, empty CRL.)
      
      More likely, this bug would be latent in normal use, and an attacker could leverage faulty revocation checking to continue using a revoked credential.
      
      This vulnerability is identified as [GHSA-pwjx-qhcg-rvj4](https://github.com/rustls/webpki/security/advisories/GHSA-pwjx-qhcg-rvj4). Thank you to @1seal for the report.
    ├ Solution: Upgrade to >=0.103.10 (try `cargo update -p rustls-webpki`)
    ├ rustls-webpki v0.103.9
      └── rustls v0.23.37
          ├── hyper-rustls v0.27.7
          │   └── libdd-common v3.0.1
          │       └── libdd-trace-utils 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 15:38:54 UTC | Commit: abb85b7 | dependency-check job results

pr-commenter · 2026-03-23T15:50:28Z

Benchmarks

Comparison

Benchmark execution time: 2026-03-23 15:49:50

Comparing candidate commit bc98bbb in PR branch release-proposal/libdd-telemetry/20260323-152704 with baseline commit 561f772 in branch release/libdd-telemetry/20260323-152704.

Found 6 performance improvements and 14 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 [-625.380µs; -613.154µs] or [-4.244%; -4.161%]

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

🟥 execution_time [+3.390µs; +3.601µs] or [+4.459%; +4.736%]
🟥 throughput [-596762.708op/s; -561064.353op/s] or [-4.537%; -4.265%]

scenario:credit_card/is_card_number/ 378282246310005

🟥 execution_time [+4.293µs; +4.404µs] or [+6.255%; +6.417%]
🟥 throughput [-878543.366op/s; -857337.743op/s] or [-6.030%; -5.884%]

scenario:credit_card/is_card_number/378282246310005

🟥 execution_time [+4.881µs; +4.966µs] or [+7.522%; +7.653%]
🟥 throughput [-1095310.909op/s; -1077754.659op/s] or [-7.108%; -6.994%]

scenario:credit_card/is_card_number/37828224631000521389798

🟥 execution_time [+6.452µs; +6.484µs] or [+14.100%; +14.170%]
🟥 throughput [-2713165.190op/s; -2699556.388op/s] or [-12.416%; -12.353%]

scenario:credit_card/is_card_number/x371413321323331

🟩 execution_time [-396.610ns; -392.946ns] or [-6.162%; -6.105%]
🟩 throughput [+10104285.707op/s; +10203193.195op/s] or [+6.503%; +6.567%]

scenario:credit_card/is_card_number_no_luhn/ 378282246310005

🟥 execution_time [+3.971µs; +4.021µs] or [+7.317%; +7.408%]
🟥 throughput [-1271511.726op/s; -1255682.937op/s] or [-6.901%; -6.815%]

scenario:credit_card/is_card_number_no_luhn/378282246310005

🟥 execution_time [+4.235µs; +4.318µs] or [+8.384%; +8.549%]
🟥 throughput [-1560030.794op/s; -1530226.612op/s] or [-7.880%; -7.730%]

scenario:credit_card/is_card_number_no_luhn/37828224631000521389798

🟥 execution_time [+6.482µs; +6.517µs] or [+14.175%; +14.252%]
🟥 throughput [-2729660.694op/s; -2713204.532op/s] or [-12.483%; -12.407%]

scenario:credit_card/is_card_number_no_luhn/x371413321323331

🟩 execution_time [-400.504ns; -397.507ns] or [-6.221%; -6.175%]
🟩 throughput [+10224374.905op/s; +10305291.703op/s] or [+6.582%; +6.634%]

scenario:tags/replace_trace_tags

🟩 execution_time [-108.140ns; -100.184ns] or [-4.395%; -4.071%]

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	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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.276µs	2.357µs ± 0.022µs	2.355µs ± 0.007µs	2.367µs	2.397µs	2.404µs	2.412µs	2.42%	-0.986	3.382	0.92%	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.353µs; 2.360µs] or [-0.128%; +0.128%]	None	None	None

Group 2

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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.480µs	496.393µs ± 0.881µs	496.300µs ± 0.326µs	496.639µs	496.981µs	500.182µs	506.011µs	1.96%	7.299	72.165	0.18%	0.062µs	1	200
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000...	throughput	1976242.925op/s	2014538.191op/s ± 3531.823op/s	2014911.464op/s ± 1323.074op/s	2016120.056op/s	2017479.453op/s	2017933.315op/s	2018244.255op/s	0.17%	-7.189	70.473	0.17%	249.738op/s	1	200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	execution_time	370.557µs	371.353µs ± 0.320µs	371.313µs ± 0.208µs	371.555µs	371.880µs	372.168µs	372.362µs	0.28%	0.250	0.036	0.09%	0.023µs	1	200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	throughput	2685558.363op/s	2692856.192op/s ± 2316.822op/s	2693143.941op/s ± 1511.933op/s	2694280.859op/s	2696572.168op/s	2697644.171op/s	2698636.989op/s	0.20%	-0.245	0.032	0.09%	163.824op/s	1	200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	execution_time	168.206µs	168.642µs ± 0.156µs	168.658µs ± 0.090µs	168.736µs	168.880µs	169.021µs	169.165µs	0.30%	-0.011	0.504	0.09%	0.011µs	1	200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	throughput	5911401.292op/s	5929713.484op/s ± 5502.390op/s	5929174.766op/s ± 3170.551op/s	5932723.877op/s	5939755.272op/s	5942587.012op/s	5945085.385op/s	0.27%	0.018	0.500	0.09%	389.078op/s	1	200
normalization/normalize_service/normalize_service/[empty string]	execution_time	38.310µs	38.407µs ± 0.043µs	38.408µs ± 0.029µs	38.433µs	38.474µs	38.512µs	38.569µs	0.42%	0.269	0.356	0.11%	0.003µs	1	200
normalization/normalize_service/normalize_service/[empty string]	throughput	25927449.062op/s	26037141.397op/s ± 29144.959op/s	26036422.132op/s ± 19475.623op/s	26058001.981op/s	26087461.326op/s	26096982.329op/s	26102800.060op/s	0.25%	-0.261	0.342	0.11%	2060.860op/s	1	200
normalization/normalize_service/normalize_service/test_ASCII	execution_time	46.194µs	46.297µs ± 0.056µs	46.283µs ± 0.029µs	46.322µs	46.410µs	46.506µs	46.570µs	0.62%	1.760	4.760	0.12%	0.004µs	1	200
normalization/normalize_service/normalize_service/test_ASCII	throughput	21473056.279op/s	21599799.322op/s ± 26036.151op/s	21606094.870op/s ± 13645.908op/s	21615607.446op/s	21628187.892op/s	21639200.980op/s	21647883.442op/s	0.19%	-1.747	4.694	0.12%	1841.034op/s	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000...	execution_time	[496.271µs; 496.515µs] or [-0.025%; +0.025%]	None	None	None
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000...	throughput	[2014048.715op/s; 2015027.668op/s] or [-0.024%; +0.024%]	None	None	None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	execution_time	[371.309µs; 371.397µs] or [-0.012%; +0.012%]	None	None	None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	throughput	[2692535.103op/s; 2693177.282op/s] or [-0.012%; +0.012%]	None	None	None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	execution_time	[168.621µs; 168.664µs] or [-0.013%; +0.013%]	None	None	None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	throughput	[5928950.906op/s; 5930476.062op/s] or [-0.013%; +0.013%]	None	None	None
normalization/normalize_service/normalize_service/[empty string]	execution_time	[38.401µs; 38.413µs] or [-0.016%; +0.016%]	None	None	None
normalization/normalize_service/normalize_service/[empty string]	throughput	[26033102.186op/s; 26041180.608op/s] or [-0.016%; +0.016%]	None	None	None
normalization/normalize_service/normalize_service/test_ASCII	execution_time	[46.289µs; 46.305µs] or [-0.017%; +0.017%]	None	None	None
normalization/normalize_service/normalize_service/test_ASCII	throughput	[21596190.962op/s; 21603407.682op/s] or [-0.017%; +0.017%]	None	None	None

Group 3

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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.311µs	5.385µs ± 0.034µs	5.382µs ± 0.025µs	5.411µs	5.430µs	5.446µs	5.479µs	1.79%	-0.204	-0.443	0.62%	0.002µs	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
write only interface	execution_time	[5.380µs; 5.389µs] or [-0.087%; +0.087%]	None	None	None

Group 4

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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.239ns	192.408ns ± 1.791ns	192.209ns ± 1.534ns	193.426ns	195.856ns	197.042ns	198.190ns	3.11%	0.767	-0.047	0.93%	0.127ns	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.159ns; 192.656ns] or [-0.129%; +0.129%]	None	None	None

Group 5

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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.895µs	3.913µs ± 0.003µs	3.913µs ± 0.002µs	3.915µs	3.919µs	3.921µs	3.921µs	0.21%	-0.580	5.780	0.08%	0.000µs	1	200
credit_card/is_card_number/	throughput	255023901.008op/s	255533237.819op/s ± 200650.403op/s	255562981.702op/s ± 113081.930op/s	255654096.412op/s	255773340.170op/s	255876987.376op/s	256754599.760op/s	0.47%	0.598	5.885	0.08%	14188.126op/s	1	200
credit_card/is_card_number/ 3782-8224-6310-005	execution_time	78.771µs	79.521µs ± 0.361µs	79.434µs ± 0.199µs	79.707µs	80.145µs	80.610µs	80.937µs	1.89%	0.975	1.244	0.45%	0.026µs	1	200
credit_card/is_card_number/ 3782-8224-6310-005	throughput	12355332.297op/s	12575513.921op/s ± 56879.683op/s	12589002.259op/s ± 31644.493op/s	12614098.807op/s	12648791.639op/s	12680468.214op/s	12695003.055op/s	0.84%	-0.944	1.154	0.45%	4022.001op/s	1	200
credit_card/is_card_number/ 378282246310005	execution_time	72.360µs	72.980µs ± 0.369µs	72.914µs ± 0.203µs	73.135µs	73.707µs	74.069µs	74.380µs	2.01%	1.112	1.309	0.50%	0.026µs	1	200
credit_card/is_card_number/ 378282246310005	throughput	13444487.515op/s	13702783.452op/s ± 68824.313op/s	13714835.351op/s ± 38195.650op/s	13750258.925op/s	13788476.392op/s	13809322.191op/s	13819785.757op/s	0.77%	-1.081	1.212	0.50%	4866.614op/s	1	200
credit_card/is_card_number/37828224631	execution_time	3.894µs	3.914µs ± 0.003µs	3.914µs ± 0.002µs	3.915µs	3.918µs	3.921µs	3.927µs	0.35%	-0.564	8.720	0.08%	0.000µs	1	200
credit_card/is_card_number/37828224631	throughput	254640867.178op/s	255513787.802op/s ± 198729.290op/s	255522358.212op/s ± 120935.851op/s	255643332.832op/s	255741034.647op/s	255875234.384op/s	256786990.719op/s	0.49%	0.588	8.834	0.08%	14052.283op/s	1	200
credit_card/is_card_number/378282246310005	execution_time	69.109µs	69.817µs ± 0.291µs	69.800µs ± 0.171µs	69.953µs	70.361µs	70.661µs	71.182µs	1.98%	1.081	2.568	0.42%	0.021µs	1	200
credit_card/is_card_number/378282246310005	throughput	14048568.046op/s	14323492.721op/s ± 59491.399op/s	14326605.518op/s ± 35179.211op/s	14363494.843op/s	14403656.664op/s	14422322.831op/s	14469886.659op/s	1.00%	-1.039	2.408	0.41%	4206.677op/s	1	200
credit_card/is_card_number/37828224631000521389798	execution_time	52.135µs	52.229µs ± 0.077µs	52.218µs ± 0.024µs	52.244µs	52.295µs	52.336µs	52.983µs	1.47%	6.975	60.948	0.15%	0.005µs	1	200
credit_card/is_card_number/37828224631000521389798	throughput	18873972.880op/s	19146366.416op/s ± 27821.075op/s	19150616.306op/s ± 8892.639op/s	19158866.393op/s	19165611.720op/s	19174160.538op/s	19180901.576op/s	0.16%	-6.912	60.142	0.14%	1967.247op/s	1	200
credit_card/is_card_number/x371413321323331	execution_time	6.028µs	6.041µs ± 0.013µs	6.039µs ± 0.004µs	6.042µs	6.071µs	6.111µs	6.115µs	1.27%	3.577	14.885	0.21%	0.001µs	1	200
credit_card/is_card_number/x371413321323331	throughput	163525676.790op/s	165527137.429op/s ± 346629.414op/s	165595545.481op/s ± 98245.327op/s	165693434.528op/s	165788682.563op/s	165881379.283op/s	165893548.634op/s	0.18%	-3.552	14.675	0.21%	24510.401op/s	1	200
credit_card/is_card_number_no_luhn/	execution_time	3.892µs	3.914µs ± 0.003µs	3.914µs ± 0.002µs	3.916µs	3.918µs	3.919µs	3.921µs	0.19%	-1.973	14.036	0.08%	0.000µs	1	200
credit_card/is_card_number_no_luhn/	throughput	255040517.617op/s	255510140.457op/s ± 193281.109op/s	255516969.767op/s ± 124843.431op/s	255635181.792op/s	255757808.972op/s	255832184.860op/s	256962001.392op/s	0.57%	2.001	14.287	0.08%	13667.038op/s	1	200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	execution_time	64.024µs	64.412µs ± 0.167µs	64.400µs ± 0.125µs	64.524µs	64.728µs	64.812µs	64.818µs	0.65%	0.349	-0.534	0.26%	0.012µs	1	200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	throughput	15427842.251op/s	15525204.816op/s ± 40298.956op/s	15528026.046op/s ± 30211.754op/s	15558288.617op/s	15581169.145op/s	15599173.341op/s	15619048.992op/s	0.59%	-0.339	-0.542	0.26%	2849.567op/s	1	200
credit_card/is_card_number_no_luhn/ 378282246310005	execution_time	58.128µs	58.270µs ± 0.121µs	58.227µs ± 0.048µs	58.312µs	58.517µs	58.727µs	58.739µs	0.88%	1.789	3.396	0.21%	0.009µs	1	200
credit_card/is_card_number_no_luhn/ 378282246310005	throughput	17024558.520op/s	17161467.586op/s ± 35573.964op/s	17174023.431op/s ± 14255.023op/s	17185329.314op/s	17196237.721op/s	17201503.704op/s	17203535.327op/s	0.17%	-1.776	3.331	0.21%	2515.459op/s	1	200
credit_card/is_card_number_no_luhn/37828224631	execution_time	3.894µs	3.913µs ± 0.003µs	3.913µs ± 0.002µs	3.915µs	3.917µs	3.919µs	3.921µs	0.20%	-1.407	11.139	0.07%	0.000µs	1	200
credit_card/is_card_number_no_luhn/37828224631	throughput	255050620.962op/s	255549705.015op/s ± 179410.842op/s	255561078.049op/s ± 111933.532op/s	255664273.999op/s	255750537.343op/s	255874716.563op/s	256819739.672op/s	0.49%	1.431	11.323	0.07%	12686.262op/s	1	200
credit_card/is_card_number_no_luhn/378282246310005	execution_time	54.556µs	54.792µs ± 0.231µs	54.696µs ± 0.085µs	54.893µs	55.210µs	55.649µs	55.951µs	2.29%	1.927	4.729	0.42%	0.016µs	1	200
credit_card/is_card_number_no_luhn/378282246310005	throughput	17872814.707op/s	18251238.995op/s ± 76175.237op/s	18282805.037op/s ± 28459.137op/s	18305225.685op/s	18317606.069op/s	18326847.330op/s	18329762.035op/s	0.26%	-1.889	4.506	0.42%	5386.403op/s	1	200
credit_card/is_card_number_no_luhn/37828224631000521389798	execution_time	52.158µs	52.230µs ± 0.040µs	52.225µs ± 0.025µs	52.255µs	52.286µs	52.332µs	52.471µs	0.47%	1.513	6.176	0.08%	0.003µs	1	200
credit_card/is_card_number_no_luhn/37828224631000521389798	throughput	19058006.417op/s	19146142.254op/s ± 14530.893op/s	19147813.591op/s ± 9224.210op/s	19156034.984op/s	19166698.915op/s	19168517.054op/s	19172659.787op/s	0.13%	-1.500	6.084	0.08%	1027.489op/s	1	200
credit_card/is_card_number_no_luhn/x371413321323331	execution_time	6.029µs	6.038µs ± 0.010µs	6.035µs ± 0.003µs	6.040µs	6.068µs	6.076µs	6.106µs	1.17%	3.286	12.948	0.17%	0.001µs	1	200
credit_card/is_card_number_no_luhn/x371413321323331	throughput	163763555.489op/s	165604771.573op/s ± 280799.069op/s	165687325.505op/s ± 80099.595op/s	165743459.263op/s	165805369.017op/s	165859151.607op/s	165873209.764op/s	0.11%	-3.265	12.756	0.17%	19855.493op/s	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
credit_card/is_card_number/	execution_time	[3.913µs; 3.914µs] or [-0.011%; +0.011%]	None	None	None
credit_card/is_card_number/	throughput	[255505429.603op/s; 255561046.035op/s] or [-0.011%; +0.011%]	None	None	None
credit_card/is_card_number/ 3782-8224-6310-005	execution_time	[79.471µs; 79.571µs] or [-0.063%; +0.063%]	None	None	None
credit_card/is_card_number/ 3782-8224-6310-005	throughput	[12567630.944op/s; 12583396.898op/s] or [-0.063%; +0.063%]	None	None	None
credit_card/is_card_number/ 378282246310005	execution_time	[72.929µs; 73.031µs] or [-0.070%; +0.070%]	None	None	None
credit_card/is_card_number/ 378282246310005	throughput	[13693245.064op/s; 13712321.839op/s] or [-0.070%; +0.070%]	None	None	None
credit_card/is_card_number/37828224631	execution_time	[3.913µs; 3.914µs] or [-0.011%; +0.011%]	None	None	None
credit_card/is_card_number/37828224631	throughput	[255486245.834op/s; 255541329.770op/s] or [-0.011%; +0.011%]	None	None	None
credit_card/is_card_number/378282246310005	execution_time	[69.776µs; 69.857µs] or [-0.058%; +0.058%]	None	None	None
credit_card/is_card_number/378282246310005	throughput	[14315247.785op/s; 14331737.657op/s] or [-0.058%; +0.058%]	None	None	None
credit_card/is_card_number/37828224631000521389798	execution_time	[52.219µs; 52.240µs] or [-0.020%; +0.020%]	None	None	None
credit_card/is_card_number/37828224631000521389798	throughput	[19142510.683op/s; 19150222.150op/s] or [-0.020%; +0.020%]	None	None	None
credit_card/is_card_number/x371413321323331	execution_time	[6.040µs; 6.043µs] or [-0.029%; +0.029%]	None	None	None
credit_card/is_card_number/x371413321323331	throughput	[165479097.926op/s; 165575176.932op/s] or [-0.029%; +0.029%]	None	None	None
credit_card/is_card_number_no_luhn/	execution_time	[3.913µs; 3.914µs] or [-0.010%; +0.010%]	None	None	None
credit_card/is_card_number_no_luhn/	throughput	[255483353.555op/s; 255536927.360op/s] or [-0.010%; +0.010%]	None	None	None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	execution_time	[64.389µs; 64.435µs] or [-0.036%; +0.036%]	None	None	None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	throughput	[15519619.768op/s; 15530789.864op/s] or [-0.036%; +0.036%]	None	None	None
credit_card/is_card_number_no_luhn/ 378282246310005	execution_time	[58.254µs; 58.287µs] or [-0.029%; +0.029%]	None	None	None
credit_card/is_card_number_no_luhn/ 378282246310005	throughput	[17156537.377op/s; 17166397.796op/s] or [-0.029%; +0.029%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631	execution_time	[3.913µs; 3.914µs] or [-0.010%; +0.010%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631	throughput	[255524840.398op/s; 255574569.632op/s] or [-0.010%; +0.010%]	None	None	None
credit_card/is_card_number_no_luhn/378282246310005	execution_time	[54.760µs; 54.824µs] or [-0.058%; +0.058%]	None	None	None
credit_card/is_card_number_no_luhn/378282246310005	throughput	[18240681.840op/s; 18261796.151op/s] or [-0.058%; +0.058%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631000521389798	execution_time	[52.224µs; 52.235µs] or [-0.011%; +0.011%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631000521389798	throughput	[19144128.412op/s; 19148156.096op/s] or [-0.011%; +0.011%]	None	None	None
credit_card/is_card_number_no_luhn/x371413321323331	execution_time	[6.037µs; 6.040µs] or [-0.024%; +0.024%]	None	None	None
credit_card/is_card_number_no_luhn/x371413321323331	throughput	[165565855.523op/s; 165643687.624op/s] or [-0.023%; +0.023%]	None	None	None

Group 6

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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.493µs	13.775µs ± 0.108µs	13.771µs ± 0.061µs	13.829µs	13.975µs	14.086µs	14.128µs	2.59%	0.564	0.803	0.78%	0.008µs	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
two way interface	execution_time	[13.760µs; 13.790µs] or [-0.109%; +0.109%]	None	None	None

Group 7

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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	34.934µs	35.332µs ± 0.695µs	35.019µs ± 0.044µs	35.127µs	36.703µs	36.756µs	39.627µs	13.16%	2.351	6.826	1.96%	0.049µ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.236µs; 35.428µs] or [-0.273%; +0.273%]	None	None	None

Group 8

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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.883µs	85.156µs ± 0.233µs	85.134µs ± 0.047µs	85.186µs	85.261µs	85.391µs	88.225µs	3.63%	11.596	150.311	0.27%	0.016µ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	[85.123µs; 85.188µs] or [-0.038%; +0.038%]	None	None	None

Group 9

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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.392ms	3.427ms ± 0.024ms	3.419ms ± 0.011ms	3.435ms	3.476ms	3.502ms	3.520ms	2.94%	1.316	1.328	0.70%	0.002ms	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
receiver_entry_point/report/2598	execution_time	[3.424ms; 3.430ms] or [-0.097%; +0.097%]	None	None	None

Group 10

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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	735.484µs	736.626µs ± 0.522µs	736.608µs ± 0.334µs	736.938µs	737.437µs	738.131µs	738.687µs	0.28%	0.531	1.251	0.07%	0.037µ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	[736.553µs; 736.698µs] or [-0.010%; +0.010%]	None	None	None

Group 11

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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.278ms	4.282ms ± 0.002ms	4.282ms ± 0.001ms	4.284ms	4.286ms	4.288ms	4.298ms	0.38%	1.663	7.235	0.06%	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.282ms; 4.283ms] or [-0.008%; +0.008%]	None	None	None

Group 12

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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.959µs	5.022µs ± 0.044µs	5.007µs ± 0.031µs	5.064µs	5.105µs	5.109µs	5.114µs	2.14%	0.618	-0.869	0.87%	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.016µs; 5.028µs] or [-0.121%; +0.121%]	None	None	None

Group 13

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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.169µs	161.055µs ± 0.287µs	161.024µs ± 0.120µs	161.142µs	161.502µs	162.089µs	162.736µs	1.06%	1.805	8.159	0.18%	0.020µ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	[161.015µs; 161.095µs] or [-0.025%; +0.025%]	None	None	None

Group 14

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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.837ms	50.044ms ± 0.464ms	49.959ms ± 0.032ms	49.997ms	50.210ms	52.421ms	54.420ms	8.93%	6.761	50.126	0.92%	0.033ms	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.980ms; 50.108ms] or [-0.129%; +0.129%]	None	None	None

Group 15

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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.320µs	146.376µs ± 1.717µs	146.045µs ± 0.591µs	146.726µs	149.012µs	153.022µs	161.790µs	10.78%	4.965	35.835	1.17%	0.121µ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.138µs; 146.614µs] or [-0.163%; +0.163%]	None	None	None

Group 16

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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.011ms	13.040ms ± 0.014ms	13.039ms ± 0.009ms	13.049ms	13.063ms	13.072ms	13.113ms	0.57%	0.870	2.543	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.039ms; 13.042ms] or [-0.015%; +0.015%]	None	None	None

Group 17

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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.336µs	185.851µs ± 0.272µs	185.830µs ± 0.225µs	186.063µs	186.324µs	186.414µs	186.453µs	0.34%	0.292	-0.844	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	5363277.585op/s	5380680.193op/s ± 7873.029op/s	5381272.218op/s ± 6501.890op/s	5387279.576op/s	5391702.212op/s	5392568.970op/s	5395602.907op/s	0.27%	-0.287	-0.848	0.15%	556.707op/s	1	200
normalization/normalize_name/normalize_name/bad-name	execution_time	17.886µs	17.971µs ± 0.042µs	17.966µs ± 0.023µs	17.990µs	18.036µs	18.126µs	18.208µs	1.35%	1.483	5.377	0.23%	0.003µs	1	200
normalization/normalize_name/normalize_name/bad-name	throughput	54920153.481op/s	55646349.132op/s ± 130209.695op/s	55661798.920op/s ± 72623.835op/s	55731276.900op/s	55822738.643op/s	55865060.196op/s	55908126.505op/s	0.44%	-1.447	5.170	0.23%	9207.216op/s	1	200
normalization/normalize_name/normalize_name/good	execution_time	10.133µs	10.247µs ± 0.098µs	10.247µs ± 0.032µs	10.270µs	10.312µs	10.338µs	11.472µs	11.96%	9.938	122.852	0.95%	0.007µs	1	200
normalization/normalize_name/normalize_name/good	throughput	87166168.433op/s	97601859.067op/s ± 852073.018op/s	97589358.139op/s ± 307645.037op/s	97979888.571op/s	98386297.087op/s	98556552.424op/s	98689596.546op/s	1.13%	-9.197	110.788	0.87%	60250.661op/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.813µs; 185.888µ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	[5379589.067op/s; 5381771.319op/s] or [-0.020%; +0.020%]	None	None	None
normalization/normalize_name/normalize_name/bad-name	execution_time	[17.965µs; 17.977µs] or [-0.033%; +0.033%]	None	None	None
normalization/normalize_name/normalize_name/bad-name	throughput	[55628303.320op/s; 55664394.943op/s] or [-0.032%; +0.032%]	None	None	None
normalization/normalize_name/normalize_name/good	execution_time	[10.233µs; 10.260µs] or [-0.132%; +0.132%]	None	None	None
normalization/normalize_name/normalize_name/good	throughput	[97483769.941op/s; 97719948.192op/s] or [-0.121%; +0.121%]	None	None	None

Group 18

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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.064ms	14.117ms ± 0.029ms	14.114ms ± 0.012ms	14.125ms	14.147ms	14.221ms	14.353ms	1.70%	4.084	26.389	0.20%	0.002ms	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
benching serializing traces from their internal representation to msgpack	execution_time	[14.113ms; 14.121ms] or [-0.028%; +0.028%]	None	None	None

Group 19

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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.299ms	4.304ms ± 0.008ms	4.303ms ± 0.001ms	4.304ms	4.306ms	4.312ms	4.415ms	2.61%	12.430	164.029	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.303ms; 4.305ms] or [-0.027%; +0.027%]	None	None	None

Group 20

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`bc98bbb`	1774279940	release-proposal/libdd-telemetry/20260323-152704

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.366ns	248.759ns ± 13.170ns	242.451ns ± 3.242ns	252.970ns	286.972ns	289.110ns	290.143ns	19.67%	1.899	2.807	5.28%	0.931ns	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.933ns; 250.584ns] or [-0.734%; +0.734%]	None	None	None

Baseline

Omitted due to size.

codecov-commenter · 2026-03-23T15:51:45Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.45%. Comparing base (561f772) to head (bc98bbb).

Additional details and impacted files

@@                             Coverage Diff                             @@
##           release/libdd-telemetry/20260323-152704    #1779      +/-   ##
===========================================================================
+ Coverage                                    70.40%   70.45%   +0.04%     
===========================================================================
  Files                                          410      410              
  Lines                                        62138    62138              
===========================================================================
+ Hits                                         43749    43778      +29     
+ Misses                                       18389    18360      -29

Components	Coverage Δ
libdd-crashtracker	`65.06% <ø> (+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	`72.56% <ø> (ø)`
libdd-profiling	`81.60% <ø> (ø)`
libdd-profiling-ffi	`64.94% <ø> (ø)`
datadog-sidecar	`31.01% <ø> (+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.

github-actions Bot and others added 2 commits March 23, 2026 15:32

chore: Release

c6d8f4c

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

chore: Release

bc98bbb

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

dd-octo-sts Bot added skip-changelog-check skip-metadata-check release-proposal This is a release proposal PR labels Mar 23, 2026

github-actions Bot added telemetry mini-agent common data-pipeline crashtracker labels Mar 23, 2026

This comment has been minimized.

Sign in to view

iunanua closed this Mar 23, 2026

iunanua deleted the release-proposal/libdd-telemetry/20260323-152704 branch March 23, 2026 15:56

Conversation

dd-octo-sts Bot commented Mar 23, 2026

Release proposal for libdd-telemetry and its dependencies

libdd-common

Commits

libdd-telemetry

Commits

Cargo publish dry-run failures

libdd-telemetry

Uh oh!

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

Uh oh!

📚 Documentation Check Results

📦 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)

Uh oh!

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

Uh oh!

🔒 Cargo Deny Results

📦 libdd-common - 3 error(s)

📦 libdd-crashtracker - 4 error(s)

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

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

📦 libdd-profiling - 3 error(s)

📦 libdd-telemetry - 3 error(s)

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

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

Uh oh!

pr-commenter Bot commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Benchmarks

Comparison

Explanation

More details about the CI and significant changes

scenario:benching serializing traces from their internal representation to msgpack

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

scenario:credit_card/is_card_number/ 378282246310005

scenario:credit_card/is_card_number/378282246310005

scenario:credit_card/is_card_number/37828224631000521389798

scenario:credit_card/is_card_number/x371413321323331

scenario:credit_card/is_card_number_no_luhn/ 378282246310005

scenario:credit_card/is_card_number_no_luhn/378282246310005

scenario:credit_card/is_card_number_no_luhn/37828224631000521389798

scenario:credit_card/is_card_number_no_luhn/x371413321323331

scenario:tags/replace_trace_tags

Candidate

Group 1

Group 2

Group 3

Group 4

Group 5

Group 6

Group 7

Group 8

Group 9

Group 10

Group 11

Group 12

Group 13

Group 14

Group 15

Group 16

Group 17

Group 18

Group 19

Group 20

Baseline

Uh oh!

This comment has been minimized.

codecov-commenter commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Reviewers

`libdd-telemetry`

github-actions Bot commented Mar 23, 2026 •

edited

Loading

📦 `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)

github-actions Bot commented Mar 23, 2026 •

edited

Loading

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

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

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

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

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

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

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

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

pr-commenter Bot commented Mar 23, 2026 •

edited

Loading

codecov-commenter commented Mar 23, 2026 •

edited

Loading