Add From implementation to Certificate when cert_nossl

[BRA1L0R]

The Certificate implementation under cert_nossl.rs (the one used when the cert_nossl feature is enabled) is missing a From implementation between the Certificate wrapper and the inner x509_cert::Certificate

I also bumped the minor version as this does not break current APIs.

On a side note, the currently implemented From<&Certificate> (and the other way around) in the openssl implementation are wrong. Cloning should not be done implicitly inside From implementation.

I addede a cert method returning a reference to the inner type to support cloning explicitly the x509_cert certificate type instead of cloning it implicitly via .into()

[DGonzalezVillal]

Hey I do appreciate the version bump, but we prefer having bumps when we are ready to cut release in a separate PR. It makes it easier for us to keep track everything that has been added into the repo between releases.

[DGonzalezVillal]

The code itself looks good although. Please make sure you add your sign to the commits and also please raise an issue regarding the &Certificate From implementation.

[BRA1L0R]

Got it, i'll create a new pr with signed commits and no version bump and the other implementation you mentioned. Thanks.

…

On Fri, Dec 19, 2025, 6:44 PM DGonzalezVillal ***@***.***> wrote: *DGonzalezVillal* left a comment (virtee/sev#356) <#356 (comment)> The code itself looks good although. Please make sure you add your sign to the commits and also please raise an issue regarding the &Certificate From implementation. — Reply to this email directly, view it on GitHub <#356 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZBE35B3B3OE7P5IY5VRL4CQ2OBAVCNFSM6AAAAACMBOPTC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMNZVHE3DKMJQHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[DGonzalezVillal]

@BRA1L0R were you able to put the requested changes in?

[BRA1L0R]

@DGonzalezVillal i was able to sign the commits in place in this pr. Do you want me to create a separate issue for the From implementation for Certificate references?

[DGonzalezVillal]

@BRA1L0R I still see the sign-off issue, are you sure you are using -s when committing?
Also please add the new issue for the From implementation.

[BRA1L0R]

@DGonzalezVillal I am, the workflow error is not very descriptive of what the problem might be.

[DGonzalezVillal]

@tylerfanelli PTAL

[BRA1L0R]

@DGonzalezVillal i think that aligning the bahaviour between the openssl and no openssl is more important. Subsequent versions may correct this idiomatic correctness problem independently of this fix

[BRA1L0R]

@DGonzalezVillal I applied the requested changes. Sorry for the misunderstanding

[DGonzalezVillal]

@tylerfanelli it should be good to go now! Thanks for the PR @BRA1L0R

[tylerfanelli]

We are exposing types from other crates. This introduces a dependency issue. Not sure if we want to do that.

[DGonzalezVillal]

We are exposing types from other crates. This introduces a dependency issue. Not sure if we want to do that.

I looked deeper into this, and the concern stems from the crate’s design rather than from these From impls specifically.

Certificate is defined as:

#[derive(Clone, Debug, Eq, PartialEq)]
pub struct Certificate(x509_cert::Certificate);

under crypto_nossl, and as:

#[derive(Clone, Debug, Eq, PartialEq)]
pub struct Certificate(X509);

under openssl.

In both cases, enabling either feature already couples the public Certificate type to an external backend type. While this is feature-gated and therefore not exposed by the base library, the underlying dependency exposure is inherent to the current design.

Given that, the added From impls do not introduce a new class of dependency issue; they are consistent with an API that already opts into a backend-specific certificate representation when the corresponding feature is enabled.