You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 25, 2023. It is now read-only.
KBSecret's generator interface is currently pretty inflexible -- all generators take a format and length, and the current Generator class just uses SecureRandom.
Ideally, generators would be more like record types -- extensible by users, and pluggable.
A mock hierarchy:
KBSecret::Generator::Abstract
- KBSecret::Generator::Basic # the current `SecureRandom` implementation
- KBSecret::Generator::Whatever
This would necessitate a configuration change, from:
Another idea: move the generator code out of KBSecret, and allow commands like kbsecret new to call an external command that generates the password. This would allow users to leverage the existing password generator ecosystem (pwgen, diceware, etc) and would simplify the codebase.
Pros:
Keeps codebase simple
Leverages existing tools
Conceptually simple and simpler to configure (no more kbsecret generator new?)
Cons:
Relies on the presence of external utilities
Might make hinting the generator more difficult (e.g., telling it to use at least one number, one symbol, etc.)
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
KBSecret's generator interface is currently pretty inflexible -- all generators take a
format
andlength
, and the currentGenerator
class just usesSecureRandom
.Ideally, generators would be more like record types -- extensible by users, and pluggable.
A mock hierarchy:
This would necessitate a configuration change, from:
to:
But this could be checked for, for backwards compatibility.
The text was updated successfully, but these errors were encountered: