RustCrypto / RustCrypto/formats
cms builders: infallible methods with `Result<_>` return type
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 338
- Forks
- 188
- Avg merge
- 4d 6h
- Merged PRs (30d)
- 15
Description
I'm only working with SignedData & SignerInfo, I haven't checked the other builders, but these methods are all infallible, why do they return Result<_>?
SignedDataBuilder::add_digest_algorithmSignedDataBuilder::add_certificateSignedDataBuilder::add_crlSignerInfoBuilder::newSignerInfoBuilder::add_signed_attributeSignerInfoBuilder::add_unsigned_attribute
Would you be open to returning the unwrapped types? The current approach strikes me as unnecessary, and creates a lot of boilerplate in my specific use case where I'm using anyhow to catch errors, which relies on the std/core Error trait for ? coercion (not implemented on v0.2, though I can see it in the v0.3 prereleases).
Despite opening a few issues on this repo in a relatively short timeframe, I'd like to emphasise that my experience across several of the RustCrypto crates has been overwhelmingly positive! Everything I've wanted to do has an API/trait, has felt ergonomic, and has worked once it's compiled ❤️
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the definitions and call sites for SignedDataBuilder and SignerInfoBuilder, including the six named methods. Compare their behavior with the other CMS builders and inspect existing tests for their Result-returning APIs. Done means documenting the affected API surface and reaching agreement on whether and how infallible return types should change.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- cryptography
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100