Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq, @GrabYourPitchforks
See info in area-owners.md if you want to be subscribed.

I didn't go with the custom MemoryManager trick. For one I would probably have a difficult time figuring out how to do it correctly, and for two because it still feels a bit unnecessary to me. MemoryMarshal is an "I know what I am doing" type, and even if we did do it, it would not address the pinning possibility.

Should we doc that the returned ROM<byte> has an independent lifetime from the underlying certificate? ROM<byte> is supposed to be an abstraction, but we're returning a property whose correct usage relies on the buffer having an independent lifetime, and people will absolutely depend on this behavior. Might be worthwhile to formalize this expectation in docs.

@GrabYourPitchforks

Should we doc that the returned ROM<byte> has an independent lifetime from the underlying certificate?

What would documentation like that look like? I... think... given the API shape it's a reasonable expectation (otherwise it'd be a CopyRawDataTo(..) or something like that.

Would codifying in a test be more reasonable, or is that not strong enough? (I'm starting to think the test should exist regardless... let me add that).

Would codifying in a test be more reasonable, or is that not strong enough?

That's probably good enough honestly. Get the ROM<byte>, dispose the cert, then validate the buffer you previously got is still filled with delicious X.509 goodness.