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

dd-octo-sts · 2026-04-08T14:07:55Z

Release proposal for libdd-telemetry and its dependencies

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

❗ Cut from non-default ref

This proposal was generated from 5ff99ff6c465a95a740a494f42cce258c0e80be8 instead of the default latest origin/main.

🧪 Non-default workflow options

bypass_standard_checks was enabled: the ongoing-proposal branch guard was skipped; branches use proposal prefix release-proposal-testing and release prefix release-testing. Crates whose resolved git tag is not the latest SemVer tag for that crate are still included (normally skipped).

libdd-common

Next version: 3.0.1
Semver bump: patch
Tag: libdd-common-v3.0.1

Commits

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

libdd-telemetry

Next version: 4.0.0
Semver bump: major
Tag: libdd-telemetry-v4.0.0

⚠️ major bump forced due to:

libdd-common: ^2.0.0 → ^3.0.2

Commits

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

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

github-actions · 2026-04-08T14:10:17Z

📚 Documentation Check Results

⚠️ 4307 documentation warning(s) found

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

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

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

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

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

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

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

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

Updated: 2026-04-08 14:10:32 UTC | Commit: d7fe30f | missing-docs job results

github-actions · 2026-04-08T14:12:05Z

🔒 Cargo Deny Results

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

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

Show output

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

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

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

advisories FAILED, bans ok, sources ok

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

Show output

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

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

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

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

advisories FAILED, bans ok, sources ok

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

Show output

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

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

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

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

advisories FAILED, bans ok, sources ok

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

Show output

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

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

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

advisories FAILED, bans ok, sources ok

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

Show output

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

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

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

advisories FAILED, bans ok, sources ok

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

Show output

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

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

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

advisories FAILED, bans ok, sources ok

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

Show output

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

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

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

advisories FAILED, bans ok, sources ok

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

Show output

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

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

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

advisories FAILED, bans ok, sources ok

Updated: 2026-04-08 14:12:22 UTC | Commit: d7fe30f | dependency-check job results

codecov-commenter · 2026-04-08T14:20:47Z

Codecov Report

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

Additional details and impacted files

@@                                 Coverage Diff                                 @@
##           release-testing/libdd-telemetry/20260408-140137    #1854      +/-   ##
===================================================================================
+ Coverage                                            70.34%   70.43%   +0.09%     
===================================================================================
  Files                                                  410      410              
  Lines                                                62138    62138              
===================================================================================
+ Hits                                                 43710    43768      +58     
+ Misses                                               18428    18370      -58

Components	Coverage Δ
libdd-crashtracker	`65.06% <ø> (+0.24%)`	⬆️
libdd-crashtracker-ffi	`36.13% <ø> (+2.03%)`	⬆️
libdd-alloc	`98.77% <ø> (ø)`
libdd-data-pipeline	`87.42% <ø> (-0.54%)`	⬇️
libdd-data-pipeline-ffi	`72.40% <ø> (-3.03%)`	⬇️
libdd-common	`79.78% <ø> (ø)`
libdd-common-ffi	`73.87% <ø> (ø)`
libdd-telemetry	`62.48% <ø> (ø)`
libdd-telemetry-ffi	`16.75% <ø> (ø)`
libdd-dogstatsd-client	`82.64% <ø> (ø)`
datadog-ipc	`72.56% <ø> (+2.24%)`	⬆️
libdd-profiling	`81.61% <ø> (ø)`
libdd-profiling-ffi	`64.94% <ø> (ø)`
datadog-sidecar	`31.33% <ø> (+0.65%)`	⬆️
datdog-sidecar-ffi	`11.91% <ø> (+3.07%)`	⬆️
spawn-worker	`54.69% <ø> (ø)`
libdd-tinybytes	`93.16% <ø> (ø)`
libdd-trace-normalization	`81.71% <ø> (ø)`
libdd-trace-obfuscation	`92.26% <ø> (ø)`
libdd-trace-protobuf	`68.25% <ø> (ø)`
libdd-trace-utils	`88.95% <ø> (ø)`
datadog-tracer-flare	`86.88% <ø> (ø)`
libdd-log	`74.69% <ø> (ø)`

🚀 New features to boost your workflow:

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

github-actions Bot and others added 5 commits April 8, 2026 14:06

chore: Release

453763d

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

chore: Release

8ef7a85

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

chore(release): update version for libdd-telemetry with major bumps

049e795

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

chore(release): update CHANGELOG.md for libdd-common

76b8f78

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

chore(release): update CHANGELOG.md for libdd-telemetry

c93e1e5

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

dd-octo-sts Bot added skip-changelog-check skip-metadata-check release-proposal This is a release proposal PR skip-pr-title-semver-check labels Apr 8, 2026

github-actions Bot added telemetry mini-agent common data-pipeline crashtracker labels Apr 8, 2026

iunanua closed this Apr 8, 2026

iunanua deleted the release-proposal-testing/libdd-telemetry/20260408-140137 branch April 13, 2026 14:47

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chore(release): proposal for libdd-telemetry#1854

chore(release): proposal for libdd-telemetry#1854
dd-octo-sts[bot] wants to merge 5 commits intorelease-testing/libdd-telemetry/20260408-140137from
release-proposal-testing/libdd-telemetry/20260408-140137

dd-octo-sts Bot commented Apr 8, 2026

Uh oh!

github-actions Bot commented Apr 8, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Apr 8, 2026 •

edited

Loading

Uh oh!

codecov-commenter commented Apr 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

dd-octo-sts Bot commented Apr 8, 2026

Release proposal for libdd-telemetry and its dependencies

❗ Cut from non-default ref

🧪 Non-default workflow options

libdd-common

Commits

libdd-telemetry

⚠️ major bump forced due to:

Commits

Uh oh!

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

Uh oh!

📚 Documentation Check Results

📦 libdd-common - 166 warning(s)

📦 libdd-crashtracker - 1049 warning(s)

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

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

📦 libdd-profiling - 647 warning(s)

📦 libdd-telemetry - 476 warning(s)

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

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

Uh oh!

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

Uh oh!

🔒 Cargo Deny Results

📦 libdd-common - 3 error(s)

📦 libdd-crashtracker - 4 error(s)

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

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

📦 libdd-profiling - 3 error(s)

📦 libdd-telemetry - 3 error(s)

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

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

Uh oh!

codecov-commenter commented Apr 8, 2026

Codecov Report

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

github-actions Bot commented Apr 8, 2026 •

edited

Loading

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

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

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

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

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

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

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

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

github-actions Bot commented Apr 8, 2026 •

edited

Loading

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

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

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

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

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

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

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

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