deps(deps): bump x509-cert from 0.2.5 to 0.3.0

[dependabot]

Bumps x509-cert from 0.2.5 to 0.3.0.

Commits

• c478c6b x509-cert v0.3.0 (#2375)
• 905717f der v0.8.1 (#2377)
• 2556627 der: cap maximum number of nested messages at 64 (#2379)
• b45caa8 der: have SliceReader use reader::position::Position (#2378)
• 42b4325 x509-cert: re-enable minimal-versions checks (#2374)
• 233eb65 chore(deps): bump the all-deps group across 1 directory with 8 updates (#2373)
• f9e2ab5 chore(deps): bump crate-ci/typos from 1.47.2 to 1.48.0 (#2372)
• 4bfdd7c chore(deps): bump p256 from 0.14.0-rc.15 to 0.14 (#2371)
• 235839f tls_codec: 0.4.3 prep (#2365)
• de2aa55 der: simplify SetOfVec sorting test (#2367)
• 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 this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[proggeramlug]

Validated locally on macOS: this does not compile. cargo check --workspace --all-targets
(host-compatible scope) is green on origin/main and fails with 4 errors on this branch,
all in crates/perry-ext-node-forge/src/crypto.rs. x509-cert 0.3 is a breaking release and
this PR bumps the version without adapting the call sites.

error[E0432]: unresolved import `der::flagset`
   --> crates/perry-ext-node-forge/src/crypto.rs:21:10
    | use der::flagset::FlagSet;
note: found an item that was configured out

error[E0432]: unresolved import `x509_cert::ext::AsExtension`
  --> crates/perry-ext-node-forge/src/crypto.rs:35:5
   | no `AsExtension` in `ext`

error[E0423]: cannot initialize a tuple struct which contains private fields
   --> crates/perry-ext-node-forge/src/crypto.rs:242:19
    | rdns.push(RelativeDistinguishedName(set));

error[E0423]: cannot initialize a tuple struct which contains private fields
   --> crates/perry-ext-node-forge/src/crypto.rs:244:8
    | Ok(RdnSequence(rdns))

Three distinct adaptations are needed:

1. der::flagset is now behind a feature that is off in this resolution — the der
   dependency needs its flagset feature enabled ("found an item that was configured out").
2. x509_cert::ext::AsExtension moved or was renamed.
3. RelativeDistinguishedName and RdnSequence no longer expose their tuple constructors;
   these need to go through the crate's own constructor API.

Leaving this open rather than merging. It needs a human to port crypto.rs.

[proggeramlug]

This cannot merge as-is, and it is not a mechanical port

I attempted the port rather than just reporting the breakage. Findings, so the next person
does not repeat the investigation.

The lockfile bump alone is incoherent

This PR moves x509-cert 0.2 -> 0.3, which pulls der 0.8 / spki 0.8 / const-oid 0.10
into the lock — but crates/perry-ext-node-forge/Cargo.toml still declares der = "0.7",
spki = "0.7", const-oid = "0.9". The crate therefore compiles against der 0.7 types while
x509-cert 0.3 expects der 0.8, which is why der::flagset reads as "configured out" and
AsExtension appears to vanish. Bumping those three declarations in lockstep clears both of
those errors. (x509-cert is also pinned a second time in crates/perry-stdlib/Cargo.toml:417
and must move together.)

What I ported successfully

• AsExtension was decomposed into Criticality + ToExtension (refactor(x509-cert): decompose AsExtension into Criticality + AsExtension RustCrypto/formats#2109).
  Our impl AsExtension for ExtensionWithCritical becomes impl Criticality, with
  fn critical(...) renamed to fn criticality(...).
• RelativeDistinguishedName's tuple constructor is now crate-private; use the public
  TryFrom<Vec<AttributeTypeAndValue>>.
• RdnSequence's tuple constructor is likewise private; build via RdnSequence::default()
  plus the public push().

What genuinely blocks it

These are API redesigns, not renames, and they land in the certificate-building path:

1. Profile became a trait. The enum is gone, replaced by concrete profiles
   (builder::profile::cabf::Root, devid::DevId, …). Our code deliberately uses
   Profile::Manual { issuer } because — per the comment in crypto.rs — it "injects no
   extensions of its own, so the cert carries precisely what sfw requested". There is no
   drop-in equivalent; preserving that behaviour needs a custom Profile implementation.
2. Validity is now Validity<P: Profile> with private fields. The only public
   constructors are from_now(duration) and infinity(). Our code sets exact
   not_before/not_after from the caller's spec, which neither constructor expresses.
3. Name and CertificateInner field access is now private (name.0,
   cert.tbs_certificate), and CertificateBuilder::new went from 6 arguments to 4.

Recommendation

Close this PR and treat the upgrade as its own tracked piece of work. The reasons:

• cargo audit flags no advisory against x509-cert 0.2.5 — this is a routine version
  bump, not a security fix, so there is no pressure to rush it. (Contrast deps: h2 0.4.16 for RUSTSEC-2026-0258 (unbounded empty DATA frames) #8404, the h2 bump
  for RUSTSEC-2026-0258, which I merged promptly.)
• The affected code generates the CA certificates for Socket Firewall's TLS MITM. Rewriting
  certificate-profile and validity handling there against a redesigned API deserves
  deliberate work and its own review, not a dependency-bump PR.

I have filed the port as a separate issue with these findings attached.

[proggeramlug]

Closing in favour of #8436, which carries the full port findings. Not a security bump (cargo audit flags no advisory against x509-cert 0.2.5), and the upgrade requires a custom Profile implementation plus a new Validity construction path in the TLS CA certificate builder — work that deserves its own PR and review rather than riding on a dependency bump.

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.