majjoha / passphrase

Strong Diceware passphrase generator.

Moof!

passphrase's Issues

Sync Usage section in README.md with actual --help output

To prevent --help output and README.md from drifting apart, why not create a CI script that complains when the ## Usage section does not match the output of running the executable? The script could be made such that it either complains or patches the README.md so that updating this section is semi-automatic. (One might consider a CI script that auto-commits to a PR when --help output changes, but I'm not sure I like automated checks causing commits for risk of automation cascades.)

Print package version in --help section

When running passphrase --help, it would be neat if the program would mention what version is mentioned in package.yaml. Printing the version number of the program is useful for debugging purposes when filing bug reports, and keeping the version number being printed in one canonical place prevents the printed version from drifting from the actual package version.

This is possible using Data.Version. You can see an example here / here.

The trick is extracting version from the module Paths_passphrase that is dynamically generated by the Stack tool.

Answering "How do I install this thing?"

When stack install moves the passphrase binary to ~/.local/bin (or wherever), it would be neat if the program could access the default wordlist, or any alternate wordlists shipped with the program. Right now the default wordlist only works when sitting in the project directory. This task consists of investigating if stack install is sufficient for installing anything but the executable, such as word lists, or if program distribution should be handled in a way that places word lists somewhere like /usr/local/share.

Add option for configuring the length of the passphrase

At the moment, passphrase is hardcoded to generate only six-word passphrases, but in some cases, you might want to generate a shorter or longer passphrase. It would be great if the application could handle this so we could configure the length of our passphrase this way:

% stack exec -- passphrase -n 10

Running the command above should generate a passphrase of 10 words rather than six. It needs to handle situations where the provided input is not a (positive) number and then fall back to six as its default value.

Print ASCII art of rolled dice

It would be cool if there were an option to show illustrations of the dice rolled.

For inspiration, the ASCII art archive on dice contains some ideas, although my initial idea was something more readable, like:

.-------. .-------. .-------.
| o   o | | o     | | o   o |
|   o   | |   o   | | o   o | ...
| o   o | |     o | | o   o |
`-------' `-------' `-------'

Worth considering, Unicode has symbols for dice as well: ⚀⚁⚂⚃⚄⚅

The option could be --draw to enable drawings of dice next to the generated passphrase.

Idea: Calculate 1d(6^5) instead of 5d6

Rather than roll (N * 5)d6, why not just roll Nd(6^5)? That is, for each Diceware word, pick a random line in the wordfile. This is not a true simulation of Diceware, but for correctly dimensioned wordlists, one could explain any 1d(6^5) die roll as a 5d6 die roll by drawing the dice e.g. as in #8.

The advantage is that fewer random numbers are generated and that this method works for wordlists that are not well-formed. I.e., you can still draw words uniformly even when you are unable to express the word's position in the wordlist as a 5d6 roll.

Allow custom wordlists to be used

Apart from the wordlist already in the repository, EFF also lists additional wordlists here and here. There is, currently, no functionality for handling custom wordlists, but it would be a useful feature to add.

For instance, in the following manner:

% stack exec -- passphrase short-wordlist.txt

By default, it should use the wordlist already shipped with the app, but if a path to a file is provided, it should read this file instead and, of course, fail gracefully in case the file does not exist or follow the expected format.

Use cache in CI

Currently CI downloads GHC and compiles dependencies every time:

https://github.com/majjoha/passphrase/runs/1893990197?check_suite_focus=true#step:4:7

Total running time: 6m6s. Let's get this number down!

The GitHub Actions uses: cache@v2 could be configured to cache the ~/.stack and .stack-work/ paths.

As the cache key, one should want to mention the operating system, the GHC version, and some file that changes when dependencies change. This could be stack.yaml.lock, since the presence of this file pins the dependencies being used. (Here is a cabal example.)

One caveat, stack build (and consequently stack test) rebuilds based on file timestamps that may not be preserved in CI in spite of the file content being the same. This does not affect caching of downloading dependencies, but it does affect some recompilation. See this hack to potentially get around that.

Support >d10 Diceware wordlists

The many alternative Diceware wordlists referenced in #1 don't have a common format. In particular,

The current default wordlist format is

11111<TAB>abacus
11112<TAB>abdomen
...

which, as long as we stick to decimal eyes, will only go up to Nd10. So the 3d20 Star Trek Diceware wordlist cannot trivially be converted to the default format. One reason is that the plaintext header is in the way. We may want a wordlist format to support a copyright notice, e.g. in a # ... comment. And we may want a format that can still be used manually, the way Diceware was originally intended.

And the other reason is that for eyes >9, "119" becomes ambiguous: Is it 1-1-9, 1-19, 11-9, or 119?

How about parsing the wordlist file so that both \d+\s+\S+ and \d+(-\d+)*\s+\S+ work?

So: If a dash occurs on a non-comment line, use the >d10 syntax. Otherwise assume single-digit eyes.

We could even just skip lines that don't match this and regard them as comments.

But I like the idea of # ... comments, too.