Should key usages be tracked as a `HashSet` instead?

Open
#265 2 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Refactor
Clarity
Needs clarification
Activity status
Stale
Tech stack
rust
Domain
security

Research direction

Start by reviewing the changes referenced in #264 and the CertificateParams::key_usages and extended_key_usages fields. Determine whether usage order or duplicates are meaningful, then compare the proposed HashSet and bitset representations. Done means reaching and documenting a representation decision with its API implications.

Written by the indexing model from the issue text.

Description

next-major-release

In #264 code is pretty ugly because we're keeping track of whether an EKU already exists in the Vec that we hold. Should CertificateParams::key_usages and extended_key_usages be HashSet instead?

  • Does the order matter?
  • Is there a valid use case for having the same usage twice?

(I guess it could even be more like a bitset similar to what x509-parser apparently does.)

Dominant language
Rust
Stars
516
Forks
160
PR merge metrics
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rustls/rcgen

All issues in rustls/rcgen

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.