Skip to content

deps: port perry-ext-node-forge to x509-cert 0.3 / der 0.8 (Profile is now a trait, Validity generic) #8436

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions