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

dd-octo-sts · 2026-03-23T17:04:35Z

Release proposal for libdd-data-pipeline and its dependencies

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

libdd-common

Next version: 3.0.1

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

Commits

chore(build): update reqwest and quinn-proto dependency for dependabot alert (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-trace-protobuf

Next version: 3.0.0

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

Commits

fix(trace-stats): rename wrongly cased stats fields (fix(trace-stats): rename wrongly cased stats fields #1780)
feat(rc)!: add process_tags to remote config Target (feat(rc)!: add process_tags to remote config Target #1586)

libdd-telemetry

Next version: 3.1.0

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

Commits

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

libdd-trace-utils

Next version: 3.0.0

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

Commits

fix(trace-stats): rename wrongly cased stats fields (fix(trace-stats): rename wrongly cased stats fields #1780)
refactor(trace-utils)!: change header name type to accept dynamic values (refactor(trace-utils)!: change header name type to accept dynamic values #1722)

libdd-data-pipeline

Next version: 3.0.0

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

Commits

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

github-actions · 2026-03-23T17:07:15Z

📚 Documentation Check Results

⚠️ 5188 documentation warning(s) found

📦 `libdd-common` - 166 warning(s)

📦 `libdd-crashtracker` - 1049 warning(s)

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

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

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

📦 `libdd-profiling` - 647 warning(s)

📦 `libdd-telemetry` - 476 warning(s)

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

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

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

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

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

Updated: 2026-03-23 17:07:32 UTC | Commit: 6db6e30 | missing-docs job results

github-actions · 2026-03-23T17:09:03Z

🔒 Cargo Deny Results

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

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

Show output

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

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

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

advisories FAILED, bans ok, sources ok

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

Show output

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

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

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

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

advisories FAILED, bans ok, sources ok

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

Show output

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

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

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

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

advisories FAILED, bans ok, sources ok

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

Show output

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

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

Show output

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

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

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

advisories FAILED, bans ok, sources ok

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

Show output

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

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

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

advisories FAILED, bans ok, sources ok

📦 `libdd-trace-normalization` - ✅ No issues

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

Show output

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

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

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

advisories FAILED, bans ok, sources ok

📦 `libdd-trace-protobuf` - ✅ No issues

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

Show output

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

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

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

advisories FAILED, bans ok, sources ok

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

Show output

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

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

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

advisories FAILED, bans ok, sources ok

Updated: 2026-03-23 17:09:15 UTC | Commit: 6db6e30 | dependency-check job results

github-actions · 2026-03-23T17:09:04Z

🔒 Cargo Deny Results

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

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

Show output

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

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

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

advisories FAILED, bans ok, sources ok

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

Show output

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

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

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

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

advisories FAILED, bans ok, sources ok

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

Show output

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

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

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

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

advisories FAILED, bans ok, sources ok

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

Show output

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

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

Show output

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

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

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

advisories FAILED, bans ok, sources ok

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

Show output

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

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

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

advisories FAILED, bans ok, sources ok

📦 `libdd-trace-normalization` - ✅ No issues

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

Show output

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

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

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

advisories FAILED, bans ok, sources ok

📦 `libdd-trace-protobuf` - ✅ No issues

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

Show output

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

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

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

advisories FAILED, bans ok, sources ok

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

Show output

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

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

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

advisories FAILED, bans ok, sources ok

Updated: 2026-03-23 17:09:03 UTC | Commit: 6db6e30 | dependency-check job results

pr-commenter · 2026-03-23T17:21:04Z

Benchmarks

Comparison

Benchmark execution time: 2026-03-23 17:20:31

Comparing candidate commit 60ffef3 in PR branch release-proposal/libdd-data-pipeline/20260323-165323 with baseline commit 5ff99ff in branch release/libdd-data-pipeline/20260323-165323.

Found 2 performance improvements and 10 performance regressions! Performance is the same for 49 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:credit_card/is_card_number/ 3782-8224-6310-005

🟥 execution_time [+4.505µs; +4.703µs] or [+5.963%; +6.226%]
🟥 throughput [-778624.742op/s; -744234.262op/s] or [-5.881%; -5.622%]

scenario:normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo...

🟥 execution_time [+19.260µs; +19.370µs] or [+10.363%; +10.423%]
🟥 throughput [-507974.397op/s; -505182.647op/s] or [-9.440%; -9.389%]

scenario:normalization/normalize_name/normalize_name/good

🟥 execution_time [+580.472ns; +592.750ns] or [+5.640%; +5.759%]
🟥 throughput [-5293830.174op/s; -5184125.387op/s] or [-5.449%; -5.336%]

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

🟥 execution_time [+36.915µs; +37.097µs] or [+7.442%; +7.479%]
🟥 throughput [-140299.304op/s; -139620.852op/s] or [-6.959%; -6.926%]

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

🟥 execution_time [+21.335µs; +21.402µs] or [+12.691%; +12.731%]
🟥 throughput [-671922.543op/s; -669811.996op/s] or [-11.295%; -11.260%]

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

🟩 execution_time [-1.831µs; -1.809µs] or [-4.758%; -4.699%]
🟩 throughput [+1281523.714op/s; +1297665.317op/s] or [+4.932%; +4.994%]

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	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
benching string interning on wordpress profile	execution_time	159.507µs	160.340µs ± 0.565µs	160.214µs ± 0.114µs	160.388µs	160.951µs	161.499µs	166.902µs	4.17%	8.213	89.731	0.35%	0.040µs	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
benching string interning on wordpress profile	execution_time	[160.262µs; 160.419µs] or [-0.049%; +0.049%]	None	None	None

Group 2

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
single_flag_killswitch/rules-based	execution_time	199.862ns	202.193ns ± 1.990ns	201.962ns ± 1.516ns	203.173ns	205.881ns	207.764ns	210.558ns	4.26%	1.197	1.625	0.98%	0.141ns	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	[201.917ns; 202.469ns] or [-0.136%; +0.136%]	None	None	None

Group 3

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
profile_add_sample_frames_x1000	execution_time	4.151ms	4.155ms ± 0.004ms	4.155ms ± 0.001ms	4.156ms	4.160ms	4.165ms	4.191ms	0.88%	5.416	48.985	0.09%	0.000ms	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
profile_add_sample_frames_x1000	execution_time	[4.155ms; 4.156ms] or [-0.012%; +0.012%]	None	None	None

Group 4

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
normalization/normalize_trace/test_trace	execution_time	242.492ns	253.245ns ± 13.204ns	248.080ns ± 3.958ns	255.636ns	284.804ns	295.229ns	300.985ns	21.33%	1.817	2.427	5.20%	0.934ns	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	[251.415ns; 255.075ns] or [-0.723%; +0.723%]	None	None	None

Group 5

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
benching serializing traces from their internal representation to msgpack	execution_time	14.955ms	15.005ms ± 0.034ms	14.999ms ± 0.014ms	15.015ms	15.043ms	15.147ms	15.250ms	1.68%	3.380	16.859	0.23%	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	[15.000ms; 15.010ms] or [-0.032%; +0.032%]	None	None	None

Group 6

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
profile_add_sample2_frames_x1000	execution_time	747.329µs	748.438µs ± 0.506µs	748.379µs ± 0.321µs	748.718µs	749.329µs	749.583µs	750.359µs	0.26%	0.672	0.508	0.07%	0.036µ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	[748.368µs; 748.509µs] or [-0.009%; +0.009%]	None	None	None

Group 7

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
two way interface	execution_time	14.182µs	14.364µs ± 0.076µs	14.361µs ± 0.058µs	14.421µs	14.474µs	14.561µs	14.634µs	1.90%	0.203	0.236	0.53%	0.005µs	1	200

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

Group 8

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
redis/obfuscate_redis_string	execution_time	35.096µs	35.629µs ± 0.818µs	35.257µs ± 0.060µs	35.360µs	37.362µs	37.388µs	38.726µs	9.84%	1.729	1.309	2.29%	0.058µ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.516µs; 35.743µs] or [-0.318%; +0.318%]	None	None	None

Group 9

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
credit_card/is_card_number/	execution_time	3.896µs	3.915µs ± 0.003µs	3.914µs ± 0.002µs	3.917µs	3.920µs	3.921µs	3.927µs	0.34%	-0.374	5.579	0.08%	0.000µs	1	200
credit_card/is_card_number/	throughput	254621251.138op/s	255440223.874op/s ± 210916.344op/s	255480736.755op/s ± 126913.749op/s	255581811.738op/s	255694958.462op/s	255759388.440op/s	256685218.327op/s	0.47%	0.392	5.665	0.08%	14914.038op/s	1	200
credit_card/is_card_number/ 3782-8224-6310-005	execution_time	78.364µs	80.147µs ± 0.201µs	80.144µs ± 0.047µs	80.204µs	80.314µs	80.413µs	81.482µs	1.67%	-2.675	40.679	0.25%	0.014µs	1	200
credit_card/is_card_number/ 3782-8224-6310-005	throughput	12272684.118op/s	12477169.140op/s ± 31525.033op/s	12477496.836op/s ± 7323.560op/s	12483416.720op/s	12493140.712op/s	12578675.045op/s	12760906.951op/s	2.27%	2.941	41.773	0.25%	2229.156op/s	1	200
credit_card/is_card_number/ 378282246310005	execution_time	67.832µs	67.983µs ± 0.100µs	67.967µs ± 0.053µs	68.028µs	68.131µs	68.272µs	68.686µs	1.06%	2.601	13.911	0.15%	0.007µs	1	200
credit_card/is_card_number/ 378282246310005	throughput	14558971.610op/s	14709603.457op/s ± 21543.014op/s	14713076.248op/s ± 11401.719op/s	14721850.547op/s	14737762.865op/s	14740677.179op/s	14742203.982op/s	0.20%	-2.561	13.575	0.15%	1523.321op/s	1	200
credit_card/is_card_number/37828224631	execution_time	3.897µs	3.914µs ± 0.003µs	3.914µs ± 0.001µs	3.916µs	3.918µs	3.921µs	3.929µs	0.38%	-0.391	13.048	0.07%	0.000µs	1	200
credit_card/is_card_number/37828224631	throughput	254533206.522op/s	255471633.388op/s ± 172344.390op/s	255488822.368op/s ± 87113.712op/s	255564977.398op/s	255662364.777op/s	255769989.309op/s	256632957.518op/s	0.45%	0.421	13.147	0.07%	12186.589op/s	1	200
credit_card/is_card_number/378282246310005	execution_time	64.603µs	64.751µs ± 0.078µs	64.748µs ± 0.052µs	64.798µs	64.876µs	64.994µs	65.076µs	0.51%	0.796	1.317	0.12%	0.006µs	1	200
credit_card/is_card_number/378282246310005	throughput	15366760.962op/s	15443709.285op/s ± 18609.724op/s	15444486.338op/s ± 12422.891op/s	15457034.853op/s	15470090.668op/s	15476711.079op/s	15479229.969op/s	0.22%	-0.786	1.285	0.12%	1315.906op/s	1	200
credit_card/is_card_number/37828224631000521389798	execution_time	45.490µs	45.733µs ± 0.084µs	45.733µs ± 0.060µs	45.795µs	45.861µs	45.897µs	45.937µs	0.45%	-0.175	-0.282	0.18%	0.006µs	1	200
credit_card/is_card_number/37828224631000521389798	throughput	21768989.865op/s	21865994.450op/s ± 40203.735op/s	21866227.612op/s ± 28763.146op/s	21893155.680op/s	21934545.044op/s	21959301.192op/s	21982906.333op/s	0.53%	0.184	-0.276	0.18%	2842.833op/s	1	200
credit_card/is_card_number/x371413321323331	execution_time	6.577µs	6.630µs ± 0.013µs	6.634µs ± 0.004µs	6.638µs	6.642µs	6.643µs	6.648µs	0.21%	-1.793	3.371	0.19%	0.001µs	1	200
credit_card/is_card_number/x371413321323331	throughput	150419948.957op/s	150837273.556op/s ± 289034.511op/s	150730701.560op/s ± 97038.780op/s	151016867.911op/s	151424760.640op/s	151802256.870op/s	152045265.933op/s	0.87%	1.806	3.431	0.19%	20437.826op/s	1	200
credit_card/is_card_number_no_luhn/	execution_time	3.894µs	3.916µs ± 0.004µs	3.915µs ± 0.002µs	3.917µs	3.921µs	3.926µs	3.945µs	0.76%	2.240	18.753	0.11%	0.000µs	1	200
credit_card/is_card_number_no_luhn/	throughput	253498603.178op/s	255394263.525op/s ± 273622.263op/s	255433191.458op/s ± 111597.414op/s	255524095.923op/s	255672146.614op/s	255763102.848op/s	256779248.538op/s	0.53%	-2.190	18.538	0.11%	19348.016op/s	1	200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	execution_time	64.986µs	65.759µs ± 0.223µs	65.839µs ± 0.031µs	65.867µs	65.897µs	65.916µs	65.919µs	0.12%	-2.428	4.710	0.34%	0.016µs	1	200
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	throughput	15170161.809op/s	15207237.346op/s ± 52032.180op/s	15188553.906op/s ± 7117.766op/s	15198360.857op/s	15368622.227op/s	15381159.637op/s	15387920.361op/s	1.31%	2.436	4.751	0.34%	3679.231op/s	1	200
credit_card/is_card_number_no_luhn/ 378282246310005	execution_time	53.362µs	53.423µs ± 0.032µs	53.417µs ± 0.021µs	53.443µs	53.482µs	53.500µs	53.512µs	0.18%	0.493	-0.227	0.06%	0.002µs	1	200
credit_card/is_card_number_no_luhn/ 378282246310005	throughput	18687365.641op/s	18718682.131op/s ± 11058.811op/s	18720664.631op/s ± 7235.761op/s	18726824.465op/s	18734879.806op/s	18738797.476op/s	18739804.002op/s	0.10%	-0.490	-0.230	0.06%	781.976op/s	1	200
credit_card/is_card_number_no_luhn/37828224631	execution_time	3.897µs	3.914µs ± 0.003µs	3.914µs ± 0.001µs	3.916µs	3.918µs	3.920µs	3.927µs	0.32%	-0.538	9.383	0.07%	0.000µs	1	200
credit_card/is_card_number_no_luhn/37828224631	throughput	254655460.630op/s	255471259.848op/s ± 174936.082op/s	255481822.469op/s ± 94036.134op/s	255573176.990op/s	255689178.041op/s	255762004.803op/s	256594813.089op/s	0.44%	0.561	9.477	0.07%	12369.849op/s	1	200
credit_card/is_card_number_no_luhn/378282246310005	execution_time	50.139µs	50.196µs ± 0.030µs	50.190µs ± 0.017µs	50.214µs	50.252µs	50.271µs	50.313µs	0.24%	0.804	0.558	0.06%	0.002µs	1	200
credit_card/is_card_number_no_luhn/378282246310005	throughput	19875732.942op/s	19921746.053op/s ± 11928.610op/s	19924225.183op/s ± 6813.423op/s	19929845.449op/s	19937333.174op/s	19943801.777op/s	19944454.694op/s	0.10%	-0.800	0.549	0.06%	843.480op/s	1	200
credit_card/is_card_number_no_luhn/37828224631000521389798	execution_time	45.440µs	45.725µs ± 0.088µs	45.721µs ± 0.056µs	45.793µs	45.862µs	45.894µs	45.968µs	0.54%	-0.101	0.029	0.19%	0.006µs	1	200
credit_card/is_card_number_no_luhn/37828224631000521389798	throughput	21754265.997op/s	21869770.612op/s ± 41943.702op/s	21871666.351op/s ± 26917.326op/s	21896177.475op/s	21939683.898op/s	21963013.470op/s	22006814.475op/s	0.62%	0.113	0.038	0.19%	2965.868op/s	1	200
credit_card/is_card_number_no_luhn/x371413321323331	execution_time	6.601µs	6.633µs ± 0.009µs	6.635µs ± 0.003µs	6.638µs	6.643µs	6.645µs	6.646µs	0.17%	-1.774	3.246	0.13%	0.001µs	1	200
credit_card/is_card_number_no_luhn/x371413321323331	throughput	150460050.562op/s	150755545.501op/s ± 193765.331op/s	150716977.572op/s ± 61079.936op/s	150773561.861op/s	151207604.291op/s	151430637.947op/s	151487632.662op/s	0.51%	1.782	3.276	0.13%	13701.278op/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.914µs; 3.915µs] or [-0.011%; +0.011%]	None	None	None
credit_card/is_card_number/	throughput	[255410992.897op/s; 255469454.851op/s] or [-0.011%; +0.011%]	None	None	None
credit_card/is_card_number/ 3782-8224-6310-005	execution_time	[80.119µs; 80.175µs] or [-0.035%; +0.035%]	None	None	None
credit_card/is_card_number/ 3782-8224-6310-005	throughput	[12472800.074op/s; 12481538.206op/s] or [-0.035%; +0.035%]	None	None	None
credit_card/is_card_number/ 378282246310005	execution_time	[67.969µs; 67.997µs] or [-0.020%; +0.020%]	None	None	None
credit_card/is_card_number/ 378282246310005	throughput	[14706617.802op/s; 14712589.111op/s] or [-0.020%; +0.020%]	None	None	None
credit_card/is_card_number/37828224631	execution_time	[3.914µs; 3.915µs] or [-0.009%; +0.009%]	None	None	None
credit_card/is_card_number/37828224631	throughput	[255447748.113op/s; 255495518.663op/s] or [-0.009%; +0.009%]	None	None	None
credit_card/is_card_number/378282246310005	execution_time	[64.741µs; 64.762µs] or [-0.017%; +0.017%]	None	None	None
credit_card/is_card_number/378282246310005	throughput	[15441130.156op/s; 15446288.413op/s] or [-0.017%; +0.017%]	None	None	None
credit_card/is_card_number/37828224631000521389798	execution_time	[45.722µs; 45.745µs] or [-0.025%; +0.025%]	None	None	None
credit_card/is_card_number/37828224631000521389798	throughput	[21860422.599op/s; 21871566.301op/s] or [-0.025%; +0.025%]	None	None	None
credit_card/is_card_number/x371413321323331	execution_time	[6.628µs; 6.631µs] or [-0.026%; +0.026%]	None	None	None
credit_card/is_card_number/x371413321323331	throughput	[150797216.153op/s; 150877330.959op/s] or [-0.027%; +0.027%]	None	None	None
credit_card/is_card_number_no_luhn/	execution_time	[3.915µs; 3.916µs] or [-0.015%; +0.015%]	None	None	None
credit_card/is_card_number_no_luhn/	throughput	[255356342.111op/s; 255432184.939op/s] or [-0.015%; +0.015%]	None	None	None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	execution_time	[65.728µs; 65.790µs] or [-0.047%; +0.047%]	None	None	None
credit_card/is_card_number_no_luhn/ 3782-8224-6310-005	throughput	[15200026.187op/s; 15214448.506op/s] or [-0.047%; +0.047%]	None	None	None
credit_card/is_card_number_no_luhn/ 378282246310005	execution_time	[53.418µs; 53.427µs] or [-0.008%; +0.008%]	None	None	None
credit_card/is_card_number_no_luhn/ 378282246310005	throughput	[18717149.486op/s; 18720214.776op/s] or [-0.008%; +0.008%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631	execution_time	[3.914µs; 3.915µs] or [-0.009%; +0.009%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631	throughput	[255447015.389op/s; 255495504.306op/s] or [-0.009%; +0.009%]	None	None	None
credit_card/is_card_number_no_luhn/378282246310005	execution_time	[50.192µs; 50.201µs] or [-0.008%; +0.008%]	None	None	None
credit_card/is_card_number_no_luhn/378282246310005	throughput	[19920092.862op/s; 19923399.244op/s] or [-0.008%; +0.008%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631000521389798	execution_time	[45.713µs; 45.738µs] or [-0.027%; +0.027%]	None	None	None
credit_card/is_card_number_no_luhn/37828224631000521389798	throughput	[21863957.619op/s; 21875583.606op/s] or [-0.027%; +0.027%]	None	None	None
credit_card/is_card_number_no_luhn/x371413321323331	execution_time	[6.632µs; 6.634µs] or [-0.018%; +0.018%]	None	None	None
credit_card/is_card_number_no_luhn/x371413321323331	throughput	[150728691.490op/s; 150782399.513op/s] or [-0.018%; +0.018%]	None	None	None

Group 10

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
sdk_test_data/rules-based	execution_time	144.716µs	146.581µs ± 1.835µs	146.364µs ± 0.474µs	146.805µs	148.478µs	153.868µs	165.251µs	12.90%	6.449	56.456	1.25%	0.130µ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.327µs; 146.836µs] or [-0.174%; +0.174%]	None	None	None

Group 11

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
benching deserializing traces from msgpack to their internal representation	execution_time	50.475ms	50.860ms ± 1.057ms	50.694ms ± 0.068ms	50.776ms	51.081ms	57.221ms	60.788ms	19.91%	7.887	63.851	2.07%	0.075ms	1	200

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

Group 12

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
profile_add_sample_timestamped_x1000	execution_time	4.166ms	4.171ms ± 0.009ms	4.170ms ± 0.002ms	4.172ms	4.174ms	4.182ms	4.294ms	2.97%	12.187	160.121	0.22%	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.170ms; 4.172ms] or [-0.030%; +0.030%]	None	None	None

Group 13

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
tags/replace_trace_tags	execution_time	2.319µs	2.384µs ± 0.019µs	2.385µs ± 0.010µs	2.398µs	2.404µs	2.409µs	2.411µs	1.10%	-1.682	3.216	0.78%	0.001µs	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
tags/replace_trace_tags	execution_time	[2.382µs; 2.387µs] or [-0.108%; +0.108%]	None	None	None

Group 14

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
receiver_entry_point/report/2598	execution_time	3.417ms	3.452ms ± 0.026ms	3.446ms ± 0.008ms	3.455ms	3.503ms	3.561ms	3.600ms	4.49%	2.797	10.064	0.76%	0.002ms	1	200

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

Group 15

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
concentrator/add_spans_to_concentrator	execution_time	12.905ms	12.933ms ± 0.016ms	12.930ms ± 0.009ms	12.940ms	12.959ms	12.980ms	13.000ms	0.54%	1.141	2.273	0.12%	0.001ms	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
concentrator/add_spans_to_concentrator	execution_time	[12.931ms; 12.935ms] or [-0.017%; +0.017%]	None	None	None

Group 16

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
write only interface	execution_time	5.505µs	5.601µs ± 0.059µs	5.592µs ± 0.051µs	5.660µs	5.695µs	5.702µs	5.724µs	2.35%	0.224	-1.318	1.05%	0.004µ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.593µs; 5.609µs] or [-0.146%; +0.146%]	None	None	None

Group 17

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
ip_address/quantize_peer_ip_address_benchmark	execution_time	4.997µs	5.097µs ± 0.044µs	5.115µs ± 0.025µs	5.126µs	5.153µs	5.156µs	5.159µs	0.87%	-0.586	-0.914	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.091µs; 5.103µ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	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
sql/obfuscate_sql_string	execution_time	84.381µs	84.605µs ± 0.176µs	84.571µs ± 0.039µs	84.620µs	84.794µs	84.999µs	86.600µs	2.40%	7.853	83.000	0.21%	0.012µs	1	200

scenario	metric	95% CI mean	Shapiro-Wilk pvalue	Ljung-Box pvalue (lag=1)	Dip test pvalue
sql/obfuscate_sql_string	execution_time	[84.580µs; 84.629µs] or [-0.029%; +0.029%]	None	None	None

Group 19

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000...	execution_time	532.150µs	533.038µs ± 0.503µs	532.913µs ± 0.223µs	533.220µs	533.916µs	534.393µs	536.831µs	0.74%	2.774	15.602	0.09%	0.036µs	1	200
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000...	throughput	1862785.265op/s	1876038.940op/s ± 1764.563op/s	1876477.243op/s ± 784.305op/s	1877051.162op/s	1877992.267op/s	1878450.062op/s	1879168.784op/s	0.14%	-2.747	15.326	0.09%	124.773op/s	1	200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	execution_time	379.750µs	380.359µs ± 0.248µs	380.338µs ± 0.153µs	380.495µs	380.778µs	381.036µs	381.401µs	0.28%	0.735	1.611	0.07%	0.018µs	1	200
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	throughput	2621912.370op/s	2629096.343op/s ± 1714.253op/s	2629239.255op/s ± 1054.696op/s	2630130.721op/s	2631649.406op/s	2632253.484op/s	2633311.691op/s	0.15%	-0.729	1.595	0.07%	121.216op/s	1	200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	execution_time	189.076µs	189.476µs ± 0.186µs	189.469µs ± 0.121µs	189.589µs	189.771µs	189.931µs	190.289µs	0.43%	0.587	1.323	0.10%	0.013µs	1	200
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	throughput	5255162.389op/s	5277725.555op/s ± 5185.573op/s	5277910.403op/s ± 3368.465op/s	5281412.624op/s	5285168.841op/s	5287939.987op/s	5288889.305op/s	0.21%	-0.579	1.296	0.10%	366.675op/s	1	200
normalization/normalize_service/normalize_service/[empty string]	execution_time	36.516µs	36.668µs ± 0.066µs	36.661µs ± 0.040µs	36.703µs	36.775µs	36.809µs	37.062µs	1.09%	1.168	5.350	0.18%	0.005µs	1	200
normalization/normalize_service/normalize_service/[empty string]	throughput	26982165.573op/s	27272096.036op/s ± 49018.852op/s	27276752.471op/s ± 29817.232op/s	27304531.208op/s	27342753.988op/s	27367702.595op/s	27385412.746op/s	0.40%	-1.136	5.152	0.18%	3466.156op/s	1	200
normalization/normalize_service/normalize_service/test_ASCII	execution_time	44.976µs	45.098µs ± 0.038µs	45.097µs ± 0.023µs	45.123µs	45.163µs	45.172µs	45.194µs	0.21%	-0.040	-0.068	0.08%	0.003µs	1	200
normalization/normalize_service/normalize_service/test_ASCII	throughput	22127040.039op/s	22174058.517op/s ± 18557.272op/s	22174493.080op/s ± 11425.670op/s	22185397.509op/s	22204057.031op/s	22215128.541op/s	22234202.599op/s	0.27%	0.044	-0.064	0.08%	1312.197op/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	[532.969µs; 533.108µs] or [-0.013%; +0.013%]	None	None	None
normalization/normalize_service/normalize_service/A0000000000000000000000000000000000000000000000000...	throughput	[1875794.388op/s; 1876283.491op/s] or [-0.013%; +0.013%]	None	None	None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	execution_time	[380.325µs; 380.393µs] or [-0.009%; +0.009%]	None	None	None
normalization/normalize_service/normalize_service/Data🐨dog🐶 繋がっ⛰てて	throughput	[2628858.764op/s; 2629333.922op/s] or [-0.009%; +0.009%]	None	None	None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	execution_time	[189.450µs; 189.502µs] or [-0.014%; +0.014%]	None	None	None
normalization/normalize_service/normalize_service/Test Conversion 0f Weird !@#$%^&**() Characters	throughput	[5277006.884op/s; 5278444.225op/s] or [-0.014%; +0.014%]	None	None	None
normalization/normalize_service/normalize_service/[empty string]	execution_time	[36.658µs; 36.677µs] or [-0.025%; +0.025%]	None	None	None
normalization/normalize_service/normalize_service/[empty string]	throughput	[27265302.495op/s; 27278889.578op/s] or [-0.025%; +0.025%]	None	None	None
normalization/normalize_service/normalize_service/test_ASCII	execution_time	[45.093µs; 45.103µs] or [-0.012%; +0.012%]	None	None	None
normalization/normalize_service/normalize_service/test_ASCII	throughput	[22171486.658op/s; 22176630.377op/s] or [-0.012%; +0.012%]	None	None	None

Group 20

cpu_model	git_commit_sha	git_commit_date	git_branch
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz	`60ffef3`	1774285441	release-proposal/libdd-data-pipeline/20260323-165323

scenario	metric	min	mean ± sd	median ± mad	p75	p95	p99	max	peak_to_median_ratio	skewness	kurtosis	cv	sem	runs	sample_size
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo...	execution_time	204.660µs	205.160µs ± 0.332µs	205.111µs ± 0.199µs	205.320µs	205.693µs	206.159µs	206.704µs	0.78%	1.471	3.812	0.16%	0.023µs	1	200
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo...	throughput	4837838.909op/s	4874259.945op/s ± 7872.804op/s	4875400.252op/s ± 4722.350op/s	4880011.240op/s	4884016.617op/s	4885769.753op/s	4886159.741op/s	0.22%	-1.453	3.724	0.16%	556.691op/s	1	200
normalization/normalize_name/normalize_name/bad-name	execution_time	18.425µs	18.533µs ± 0.048µs	18.530µs ± 0.024µs	18.550µs	18.620µs	18.687µs	18.698µs	0.91%	0.810	1.390	0.26%	0.003µs	1	200
normalization/normalize_name/normalize_name/bad-name	throughput	53482148.950op/s	53957901.692op/s ± 139745.217op/s	53967620.360op/s ± 68632.629op/s	54043300.882op/s	54165234.129op/s	54229761.971op/s	54272992.215op/s	0.57%	-0.789	1.347	0.26%	9881.479op/s	1	200
normalization/normalize_name/normalize_name/good	execution_time	10.794µs	10.879µs ± 0.032µs	10.879µs ± 0.021µs	10.899µs	10.937µs	10.951µs	10.985µs	0.97%	0.247	0.104	0.29%	0.002µs	1	200
normalization/normalize_name/normalize_name/good	throughput	91033548.332op/s	91920466.764op/s ± 268983.348op/s	91919034.321op/s ± 179130.293op/s	92104124.087op/s	92332405.753op/s	92502104.925op/s	92641267.160op/s	0.79%	-0.229	0.091	0.29%	19019.995op/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	[205.114µs; 205.206µs] or [-0.022%; +0.022%]	None	None	None
normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo...	throughput	[4873168.850op/s; 4875351.040op/s] or [-0.022%; +0.022%]	None	None	None
normalization/normalize_name/normalize_name/bad-name	execution_time	[18.526µs; 18.540µs] or [-0.036%; +0.036%]	None	None	None
normalization/normalize_name/normalize_name/bad-name	throughput	[53938534.349op/s; 53977269.035op/s] or [-0.036%; +0.036%]	None	None	None
normalization/normalize_name/normalize_name/good	execution_time	[10.875µs; 10.883µs] or [-0.041%; +0.041%]	None	None	None
normalization/normalize_name/normalize_name/good	throughput	[91883188.259op/s; 91957745.269op/s] or [-0.041%; +0.041%]	None	None	None

Baseline

Omitted due to size.

codecov-commenter · 2026-03-23T17:25:02Z

Codecov Report

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

Additional details and impacted files

@@                               Coverage Diff                               @@
##           release/libdd-data-pipeline/20260323-165323    #1781      +/-   ##
===============================================================================
- Coverage                                        70.34%   70.30%   -0.04%     
===============================================================================
  Files                                              410      410              
  Lines                                            62138    62138              
===============================================================================
- Hits                                             43710    43686      -24     
- Misses                                           18428    18452      +24

Components	Coverage Δ
libdd-crashtracker	`64.93% <ø> (+0.10%)`	⬆️
libdd-crashtracker-ffi	`34.98% <ø> (+0.89%)`	⬆️
libdd-alloc	`98.77% <ø> (ø)`
libdd-data-pipeline	`87.63% <ø> (-0.34%)`	⬇️
libdd-data-pipeline-ffi	`73.57% <ø> (-1.87%)`	⬇️
libdd-common	`79.78% <ø> (ø)`
libdd-common-ffi	`73.87% <ø> (ø)`
libdd-telemetry	`62.48% <ø> (ø)`
libdd-telemetry-ffi	`16.75% <ø> (ø)`
libdd-dogstatsd-client	`82.64% <ø> (ø)`
datadog-ipc	`70.31% <ø> (ø)`
libdd-profiling	`81.61% <ø> (ø)`
libdd-profiling-ffi	`64.94% <ø> (ø)`
datadog-sidecar	`30.48% <ø> (-0.20%)`	⬇️
datdog-sidecar-ffi	`7.94% <ø> (-0.90%)`	⬇️
spawn-worker	`54.69% <ø> (ø)`
libdd-tinybytes	`93.16% <ø> (ø)`
libdd-trace-normalization	`81.71% <ø> (ø)`
libdd-trace-obfuscation	`92.26% <ø> (ø)`
libdd-trace-protobuf	`68.25% <ø> (ø)`
libdd-trace-utils	`88.95% <ø> (ø)`
datadog-tracer-flare	`86.88% <ø> (ø)`
libdd-log	`74.69% <ø> (ø)`

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

datadog-official · 2026-03-23T17:25:03Z

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

_{This comment will be updated automatically if new data arrives.

🔗 Commit SHA: 60ffef3 | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback!}

dd-octo-sts · 2026-03-23T17:32:17Z

Artifact Size Benchmark Report

aarch64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a	101.43 MB	101.43 MB	-0% (-2.22 KB) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so	8.70 MB	8.70 MB	0% (0 B) 👌

aarch64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a	118.20 MB	118.20 MB	-0% (-3.56 KB) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so	11.29 MB	11.29 MB	-0% (-136 B) 👌

libdatadog-x64-windows

Artifact	Baseline	Commit	Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll	27.24 MB	27.26 MB	+.05% (+15.50 KB) 🔍
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib	80.34 KB	80.34 KB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb	186.41 MB	186.51 MB	+.05% (+96.00 KB) 🔍
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib	922.07 MB	921.92 MB	--.01% (-156.07 KB) 💪
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll	8.99 MB	8.99 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib	80.34 KB	80.34 KB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb	26.83 MB	26.83 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib	61.00 MB	61.00 MB	+0% (+138 B) 👌

libdatadog-x86-windows

Artifact	Baseline	Commit	Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll	23.07 MB	23.07 MB	-0% (-2.00 KB) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib	81.59 KB	81.59 KB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb	190.57 MB	190.73 MB	+.08% (+160.00 KB) 🔍
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib	905.12 MB	905.43 MB	+.03% (+318.48 KB) 🔍
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll	6.86 MB	6.86 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib	81.59 KB	81.59 KB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb	28.94 MB	28.94 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib	57.38 MB	57.38 MB	+0% (+522 B) 👌

x86_64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a	88.28 MB	88.29 MB	+0% (+4.46 KB) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so	10.28 MB	10.28 MB	0% (0 B) 👌

x86_64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a	110.95 MB	110.95 MB	-0% (-1.67 KB) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so	12.02 MB	12.02 MB	+0% (+232 B) 👌

# Release proposal for libdd-data-pipeline and its dependencies This PR contains version bumps based on public API changes and commits since last release. ## libdd-common **Next version:** `3.0.1` **Semver bump:** `patch` **Tag:** `libdd-common-v3.0.1` ### Commits - chore(build): update reqwest and quinn-proto dependency for dependabot alert (#1774) - chore(build): ekump/APMSP-2718 update aws-lc dependencies (#1751) ## libdd-trace-protobuf **Next version:** `3.0.0` **Semver bump:** `major` **Tag:** `libdd-trace-protobuf-v3.0.0` ### Commits - fix(trace-stats): rename wrongly cased stats fields (#1780) - feat(rc)!: add process_tags to remote config Target (#1586) ## libdd-telemetry **Next version:** `3.1.0` **Semver bump:** `minor` **Tag:** `libdd-telemetry-v3.1.0` ### Commits - refactor(sidecar)!: Refactor tarpc away (#1742) ## libdd-trace-utils **Next version:** `3.0.0` **Semver bump:** `major` **Tag:** `libdd-trace-utils-v3.0.0` ### Commits - fix(trace-stats): rename wrongly cased stats fields (#1780) - refactor(trace-utils)!: change header name type to accept dynamic values (#1722) ## libdd-data-pipeline **Next version:** `3.0.0` **Semver bump:** `major` **Tag:** `libdd-data-pipeline-v3.0.0` ### Commits - feat(agents)!: retrieve container tags hash from /info endpoint (#1700) - refactor(trace-utils)!: change header name type to accept dynamic values (#1722) --------- Co-authored-by: dd-octo-sts[bot] <200755185+dd-octo-sts[bot]@users.noreply.github.com>

…-pipeline (#1781)) (#1783) This PR merges the release branch to main Co-authored-by: dd-octo-sts[bot] <200755185+dd-octo-sts[bot]@users.noreply.github.com>

# Release proposal for libdd-data-pipeline and its dependencies ## libdd-common **Next version:** `3.0.2` ## libdd-trace-protobuf **Next version:** `3.0.1` ## libdd-trace-stats **Next version:** `2.0.0` ## libdd-trace-obfuscation **Next version:** `2.0.0` ## libdd-trace-normalization **Next version:** `2.0.0` ## libdd-trace-utils **Next version:** `3.0.1` ## libdd-data-pipeline **Next version:** `3.0.1` ## libdd-telemetry **Next version:** `4.0.0` ### Notes It fixes #1781 ### Tests It has been tested by packaging the crates involved in the PR, patching crates.io libdd-* dependencies on dd-trace-rs and compiling dd-trace-rs. The dependency tree obtained is as follows ``` > cargo tree -p datadog-opentelemetry -d -e normal | grep "libdd-" └── libdd-telemetry v3.0.0 └── libdd-data-pipeline v2.0.1 └── libdd-data-pipeline v2.0.1 (*) ├── libdd-ddsketch v1.0.1 │ ├── libdd-data-pipeline v2.0.1 (*) │ ├── libdd-telemetry v3.0.0 (*) │ └── libdd-trace-stats v1.0.3 │ └── libdd-data-pipeline v2.0.1 (*) ├── libdd-trace-protobuf v2.0.0 │ ├── libdd-data-pipeline v2.0.1 (*) │ ├── libdd-trace-normalization v1.0.2 │ │ └── libdd-trace-utils v2.0.2 │ │ ├── libdd-data-pipeline v2.0.1 (*) │ │ └── libdd-trace-stats v1.0.3 (*) │ ├── libdd-trace-stats v1.0.3 (*) │ └── libdd-trace-utils v2.0.2 (*) └── libdd-trace-utils v2.0.2 (*) ├── libdd-telemetry v3.0.0 (*) └── libdd-trace-stats v1.0.3 (*) │ └── libdd-trace-utils v2.0.2 (*) │ └── libdd-trace-utils v2.0.2 (*) ├── libdd-data-pipeline v2.0.1 (*) └── libdd-telemetry v3.0.0 (*) └── libdd-common v2.0.1 ├── libdd-data-pipeline v2.0.1 (*) ├── libdd-dogstatsd-client v1.0.1 │ └── libdd-data-pipeline v2.0.1 (*) ├── libdd-telemetry v3.0.0 (*) └── libdd-trace-utils v2.0.2 (*) ``` and there are no duplicated dependencies with different versions, and none of the crates in this proposal are part in the tree. --------- Co-authored-by: iunanua <[email protected]>

dd-octo-sts bot added 5 commits March 23, 2026 16:56

chore: Release

de47c3c

chore: Release

65dabf9

chore: Release

f71041d

chore: Release

d3bd6fe

chore: Release

60ffef3

dd-octo-sts bot requested a review from a team as a code owner March 23, 2026 17:04

dd-octo-sts bot added skip-changelog-check skip-metadata-check labels Mar 23, 2026

dd-octo-sts bot requested a review from a team as a code owner March 23, 2026 17:04

dd-octo-sts bot added the release-proposal This is a release proposal PR label Mar 23, 2026

dd-octo-sts bot requested review from a team as code owners March 23, 2026 17:04

dd-octo-sts bot requested review from mabdinur and removed request for a team March 23, 2026 17:04

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

iunanua approved these changes Mar 23, 2026

View reviewed changes

paullegranddc merged commit f467132 into release/libdd-data-pipeline/20260323-165323 Mar 23, 2026
80 checks passed

iunanua deleted the release-proposal/libdd-data-pipeline/20260323-165323 branch March 24, 2026 09:32

iunanua mentioned this pull request Mar 25, 2026

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

Merged

Conversation

dd-octo-sts bot commented Mar 23, 2026

Release proposal for libdd-data-pipeline and its dependencies

libdd-common

Commits

libdd-trace-protobuf

Commits

libdd-telemetry

Commits

libdd-trace-utils

Commits

libdd-data-pipeline

Commits

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-library-config - 150 warning(s)

📦 libdd-profiling - 647 warning(s)

📦 libdd-telemetry - 476 warning(s)

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

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

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

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

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

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-library-config - ✅ No issues

📦 libdd-profiling - 3 error(s)

📦 libdd-telemetry - 3 error(s)

📦 libdd-trace-normalization - ✅ No issues

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

📦 libdd-trace-protobuf - ✅ No issues

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

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

Uh oh!

github-actions bot commented Mar 23, 2026

🔒 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-library-config - ✅ No issues

📦 libdd-profiling - 3 error(s)

📦 libdd-telemetry - 3 error(s)

📦 libdd-trace-normalization - ✅ No issues

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

📦 libdd-trace-protobuf - ✅ No issues

📦 libdd-trace-stats - 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:credit_card/is_card_number/ 3782-8224-6310-005

scenario:normalization/normalize_name/normalize_name/Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Long-.Too-Lo...

scenario:normalization/normalize_name/normalize_name/good

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

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

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

Candidate

Group 1

Group 2

Group 3

Group 4

Group 5

Group 6

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-library-config` - 150 warning(s)

📦 `libdd-profiling` - 647 warning(s)

📦 `libdd-telemetry` - 476 warning(s)

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

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

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

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

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

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-library-config` - ✅ No issues

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

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

📦 `libdd-trace-normalization` - ✅ No issues

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

📦 `libdd-trace-protobuf` - ✅ No issues

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

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

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

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

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

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

📦 `libdd-library-config` - ✅ No issues

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

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

📦 `libdd-trace-normalization` - ✅ No issues

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

📦 `libdd-trace-protobuf` - ✅ No issues

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

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

pr-commenter bot commented Mar 23, 2026 •

edited

Loading

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

edited

Loading