Tony Arcieri
Tony Arcieri
#1299 backs out the usages of `ObjectIdentifierRef` in the database until such a time as the concerns in this issue have been addressed
Going to close this. We now have derived `PartialEq`/`Eq` back and use owned `ObjectIdentifier` for the database, so using OIDs in patterns works once again.
We're in the middle of transitioning over to a new release cycle, and `x509-cert` has not yet been upgraded to use the new prerelease version of `const-oid`
I did an initial pass on this in #291. However as I noted on that PR: > Unfortunately all serialization/deserialization is currently performed in terms of the `Read` and `Write`...
I think we can close this as having initial `no_std` support in place
Are you specifically trying to avoid heap allocations? If not, then you can use `Vec` instead.
Right now the `ArrayVec` type isn't part of the public API. That's intentional as it enables changing the backing storage without making breaking changes to the API. I would prefer...
It might be possible. It would require some investigation, and is likely to require breaking changes, which I'd prefer not to make for awhile as I just cut a `der`...
We've had streaming decoding come up in a few other scenarios, particularly CRLs. Random access to data which doesn't fit in memory is a different matter though. I'd suggest only...
The problem is the current backend selection for `x25519-dalek` is feature-based, and features are additive, so if anything else activates either feature they can collide, and the errors as you...