You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
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:
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.
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.
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:
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.
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-cert0.2 -> 0.3, which pullsder0.8 /spki0.8 /const-oid0.10into the lock — but
crates/perry-ext-node-forge/Cargo.tomlstill declaresder = "0.7",spki = "0.7",const-oid = "0.9". The crate therefore compiles against der 0.7 types whilex509-cert 0.3 expects der 0.8, which is why
der::flagsetreads as "configured out" andAsExtensionappears to vanish. Bumping those three declarations in lockstep clears both ofthose errors. (
x509-certis also pinned a second time incrates/perry-stdlib/Cargo.toml:417and must move together.)
What I ported successfully
AsExtensionwas decomposed intoCriticality+ToExtension(refactor(x509-cert): decompose AsExtension into Criticality + AsExtension RustCrypto/formats#2109).Our
impl AsExtension for ExtensionWithCriticalbecomesimpl Criticality, withfn critical(...)renamed tofn criticality(...).RelativeDistinguishedName's tuple constructor is now crate-private; use the publicTryFrom<Vec<AttributeTypeAndValue>>.RdnSequence's tuple constructor is likewise private; build viaRdnSequence::default()plus the public
push().What genuinely blocks it
These are API redesigns, not renames, and they land in the certificate-building path:
Profilebecame a trait. The enum is gone, replaced by concrete profiles(
builder::profile::cabf::Root,devid::DevId, …). Our code deliberately usesProfile::Manual { issuer }because — per the comment incrypto.rs— it "injects noextensions of its own, so the cert carries precisely what sfw requested". There is no
drop-in equivalent; preserving that behaviour needs a custom
Profileimplementation.Validityis nowValidity<P: Profile>with private fields. The only publicconstructors are
from_now(duration)andinfinity(). Our code sets exactnot_before/not_afterfrom the caller's spec, which neither constructor expresses.NameandCertificateInnerfield access is now private (name.0,cert.tbs_certificate), andCertificateBuilder::newwent from 6 arguments to 4.Recommendation
Close this PR and treat the upgrade as its own tracked piece of work. The reasons:
cargo auditflags no advisory againstx509-cert0.2.5 — this is a routine versionbump, 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.)
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.