-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: "Recommended" badges #10
Comments
Sounds good! But I fear our choices could be controversial. For example, should we use the green badge for argon2 (assuming we had it in this organization), even though some argue that it's worse than Also I think the danger sign on such small fonts is not distinguishable enough (and it's with 4K display). so it's probably better to remove it. |
For password hashes, I'd say:
I think hashing out the specific recommendations will need a per-repo issue at least with some discussion. If specific recommendations wind up being too controversial, we can always change them! |
Yeah, the exclamation looks good. |
I opened up tracking issues on some of our repos to begin initial discussion. I've linked them from the toplevel description. |
Edit: this is in-progress. See the following tracking issues:
We have a few open issues about algorithm guidance, such as RustCrypto/password-hashes#48
While we have some precedent for this, such as the "Security" rubric here:
https://github.com/rustcrypto/hashes#supported-algorithms
...we don't have a consistent way of communicating this information across all repos/crates, which I think would be helpful.
I'd like to propose adding a "recommended" badge to each crate which uses the following rubric and links back to documentation (similar to HAZMAT.md) about what the badge means.
Recommended: Yes
Preferred modern algorithms we suggest people embrace in new projects.
Recommended: Neutral
Algorithms which are still considered secure, but are obscure, uncommonly used, and/or poorly-analyzed.
Recommended: No!
Algorithms which are known to be cryptographically broken and should only be used because legacy interop requires it.
The text was updated successfully, but these errors were encountered: