x509-cert: move to all owned types?

[tarcieri]

The x509-cert crate currently has a hard dependency on alloc, but several types still have a lifetime which borrows from the input, which precludes one-pass decoding from PEM (where Base64 is decoded directly into owned types) and makes writing things like certificate builders harder.

We could potentially move entirely to types which own their backing data, eliminating lifetimes from all types. We could still potentially have a corresponding set of borrowed e.g. Ref types (see https://github.com/RustCrypto/formats/issues/689), but using owned types would make usage more convenient at the cost of losing zero-copy decoding from DER bytes.

[baloo]

I don't really see a way to make a better certificate builder API without this. The current version of the API kind of work, but it's pretty inconvenient to use.

[carl-wallace]

I'd prefer to see owned and no copy be peers rather than owned replacing no copy (even if owned is why got the shorter crate name). The draft changes would generate a pile of work to catch up and each could be useful to have.

[tarcieri]

@carl-wallace as I mentioned, we can still have *Ref types which would be useful for #689

[baloo]

So do we want just duplicate all the types to add a Foo along with FooRef ? For example the Name<'a>, the tree of types there is pretty heavy.

I'm okay with that, just want to make sure, for example the impl of AnyRef is pretty heavy, and duplicating that is a lot of code. https://github.com/RustCrypto/formats/blob/c7c1fa73277007b83a92aa77c31d427a05cdf62b/der/src/asn1/any.rs#L35-L162

Or do I just throw a macro in there an factorize out both bodies?

[tarcieri]

@baloo for now I’d say make everything owned, and circle back in *Ref types later as part of #689, which needs additional design work anyway

[carl-wallace]

Could we have proc macros emit a second set of structures such that one set behaves the old way and one set uses owned? On Nov 26, 2022, at 11:19 AM, Tony Arcieri @.***> wrote: @baloo for now I’d say make everything owned, and circle back in *Ref types later as part of #689, which needs additional design work anyway

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[tarcieri]

Could we have proc macros emit a second set of structures

Really if we want to have unified borrowed/owned types I would suggest evaluating yoke for this purpose (see #734)

It would allow us to define zero-copy types and owned wrappers which borrow from them.

However, if we'd like to have truly heapless support as per #689, I think they are really going to need to be different data structures entirely. It may be necessary to loop in e.g. heapless::Pool to provide backing storage for certain types of objects.

[tarcieri]

This has been completed, as far as I'm aware