Bump the cargo group across 2 directories with 2 updates

[dependabot]

Bumps the cargo group with 2 updates in the /benchv2 directory: quinn-proto and rustls-webpki.
Bumps the cargo group with 2 updates in the / directory: quinn-proto and rustls-webpki.

Updates quinn-proto from 0.11.13 to 0.11.14

Release notes

Sourced from quinn-proto's releases.

quinn-proto 0.11.14

@​jxs reported a denial of service issue in quinn-proto 5 days ago:

• GHSA-6xvm-j4wr-6v98

We coordinated with them to release this version to patch the issue. Unfortunately the maintainers missed these issues during code review and we did not have enough fuzzing coverage -- we regret the oversight and have added an additional fuzzing target.

Organizations that want to participate in coordinated disclosure can contact us privately to discuss terms.

What's Changed

• Fix over-permissive proto dependency edge by @​Ralith in quinn-rs/quinn#2385
• 0.11.x: avoid unwrapping VarInt decoding during parameter parsing by @​djc in quinn-rs/quinn#2559

Commits

• 2c315aa proto: bump version to 0.11.14
• 8ad47f4 Use newer rustls-pki-types PEM parser API
• c81c028 ci: fix workflow syntax
• 0050172 ci: pin wasm-bindgen-cli version
• 8a6f82c Take semver-compatible dependency updates
• e52db4a Apply suggestions from clippy 1.91
• 6df7275 chore: Fix unnecessary_unwrap clippy
• c8eefa0 proto: avoid unwrapping varint decoding during parameters parsing
• 9723a97 fuzz: add fuzzing target for parsing transport parameters
• eaf0ef3 Fix over-permissive proto dependency edge (#2385)
• Additional commits viewable in compare view

Updates rustls-webpki from 0.103.9 to 0.103.12

Release notes

Sourced from rustls-webpki's releases.

0.103.12

This release fixes two bugs in name constraint enforcement:

• GHSA-965h-392x-2mh5: name constraints for URI names were ignored and therefore accepted. URI name constraints are now rejected unconditionally. Note this library does not provide an API for asserting URI names, and URI name constraints are otherwise not implemented.
• GHSA-xgp8-3hg3-c2mh: permitted subtree name constraints for DNS names were accepted for certificates asserting a wildcard name. This was incorrect because, given a name constraint of accept.example.com, *.example.com could feasibly allow a name of reject.example.com which is outside the constraint. This is very similar to CVE-2025-61727.

Since name constraints are restrictions on otherwise properly-issued certificates, these bugs are reachable only after signature verification and require misissuance to exploit.

What's Changed

• Prepare 0.103.12 by @​djc in rustls/webpki#470

Full Changelog: rustls/webpki@v/0.103.11...v/0.103.12

0.103.11

In response to #464, we've slightly relaxed requirements for anchor_from_trust_cert() to ignore unknown extensions even if they're marked as critical. This only affects parsing a TrustAnchor from DER, for which most extensions are ignored anyway.

What's Changed

• Backport parsing trust anchors with unknown critical extensions to 0.103 by @​djc in rustls/webpki#466

0.103.10

Correct selection of candidate CRLs by Distribution Point and Issuing Distribution Point. 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 distributionPoints 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 by GHSA-pwjx-qhcg-rvj4. Thank you to @​1seal for the report.

What's Changed

• Freshen up rel-0.103 by @​ctz in rustls/webpki#455
• Prepare 0.103.10 by @​ctz in rustls/webpki#458

Full Changelog: rustls/webpki@v/0.103.9...v/0.103.10

Commits

• 27131d4 Bump version to 0.103.12
• 6ecb876 Clean up stuttery enum variant names
• 318b3e6 Ignore wildcard labels when matching name constraints
• 1219622 Rewrite constraint matching to avoid permissive catch-all branch
• 57bc62c Bump version to 0.103.11
• d0fa01e Allow parsing trust anchors with unknown criticial extensions
• 348ce01 Prepare 0.103.10
• dbde592 crl: fix authoritative_for() support for multiple URIs
• 9c4838e avoid std::prelude imports
• 009ef66 fix rust 1.94 ambiguous panic macro warnings
• Additional commits viewable in compare view

Updates quinn-proto from 0.11.13 to 0.11.14

Release notes

Sourced from quinn-proto's releases.

quinn-proto 0.11.14

@​jxs reported a denial of service issue in quinn-proto 5 days ago:

• GHSA-6xvm-j4wr-6v98

We coordinated with them to release this version to patch the issue. Unfortunately the maintainers missed these issues during code review and we did not have enough fuzzing coverage -- we regret the oversight and have added an additional fuzzing target.

Organizations that want to participate in coordinated disclosure can contact us privately to discuss terms.

What's Changed

• Fix over-permissive proto dependency edge by @​Ralith in quinn-rs/quinn#2385
• 0.11.x: avoid unwrapping VarInt decoding during parameter parsing by @​djc in quinn-rs/quinn#2559

Commits

• 2c315aa proto: bump version to 0.11.14
• 8ad47f4 Use newer rustls-pki-types PEM parser API
• c81c028 ci: fix workflow syntax
• 0050172 ci: pin wasm-bindgen-cli version
• 8a6f82c Take semver-compatible dependency updates
• e52db4a Apply suggestions from clippy 1.91
• 6df7275 chore: Fix unnecessary_unwrap clippy
• c8eefa0 proto: avoid unwrapping varint decoding during parameters parsing
• 9723a97 fuzz: add fuzzing target for parsing transport parameters
• eaf0ef3 Fix over-permissive proto dependency edge (#2385)
• Additional commits viewable in compare view

Updates rustls-webpki from 0.103.9 to 0.103.12

Release notes

Sourced from rustls-webpki's releases.

0.103.12

This release fixes two bugs in name constraint enforcement:

• GHSA-965h-392x-2mh5: name constraints for URI names were ignored and therefore accepted. URI name constraints are now rejected unconditionally. Note this library does not provide an API for asserting URI names, and URI name constraints are otherwise not implemented.
• GHSA-xgp8-3hg3-c2mh: permitted subtree name constraints for DNS names were accepted for certificates asserting a wildcard name. This was incorrect because, given a name constraint of accept.example.com, *.example.com could feasibly allow a name of reject.example.com which is outside the constraint. This is very similar to CVE-2025-61727.

Since name constraints are restrictions on otherwise properly-issued certificates, these bugs are reachable only after signature verification and require misissuance to exploit.

What's Changed

• Prepare 0.103.12 by @​djc in rustls/webpki#470

Full Changelog: rustls/webpki@v/0.103.11...v/0.103.12

0.103.11

In response to #464, we've slightly relaxed requirements for anchor_from_trust_cert() to ignore unknown extensions even if they're marked as critical. This only affects parsing a TrustAnchor from DER, for which most extensions are ignored anyway.

What's Changed

• Backport parsing trust anchors with unknown critical extensions to 0.103 by @​djc in rustls/webpki#466

0.103.10

Correct selection of candidate CRLs by Distribution Point and Issuing Distribution Point. 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 distributionPoints 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 by GHSA-pwjx-qhcg-rvj4. Thank you to @​1seal for the report.

What's Changed

• Freshen up rel-0.103 by @​ctz in rustls/webpki#455
• Prepare 0.103.10 by @​ctz in rustls/webpki#458

Full Changelog: rustls/webpki@v/0.103.9...v/0.103.10

Commits

• 27131d4 Bump version to 0.103.12
• 6ecb876 Clean up stuttery enum variant names
• 318b3e6 Ignore wildcard labels when matching name constraints
• 1219622 Rewrite constraint matching to avoid permissive catch-all branch
• 57bc62c Bump version to 0.103.11
• d0fa01e Allow parsing trust anchors with unknown criticial extensions
• 348ce01 Prepare 0.103.10
• dbde592 crl: fix authoritative_for() support for multiple URIs
• 9c4838e avoid std::prelude imports
• 009ef66 fix rust 1.94 ambiguous panic macro warnings
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions
  You can disable automated security fix PRs for this repo from the Security Alerts page.