gonzalo-bulnes/dice

🎲 Lookup dice-generated passphrases from EFF's long wordlist.

dice's Issues

Security considerations (a.k.a maybe a note in the README wouldn't hurt)

Dice is about passwords (passphrases).

What kind of security implications does that have?
What should we take into consideration when writing it?
What should we consider when using it?

I started thinking more seriously about this when considering what problem would be addressed by making sure that:

[Users] can take the list that ships with the application and verify it is the same as the one provided by EFF themselves. (source)

And after some relfection I think that dice does not deserve the security scrutiny that one could think of at first, or rather, that probably:

Nobody should use dice unless they understand its code.

If you find that a bit disapoining, so do I! But before getting to why I think that, I believe the implications are that:

• making the code as easy to review as possible should be a priority
• there is likely value in also keeping the code simple, so that proficiency with Rust is not critical to review it (goal: making the code accessible to a larger user base)
• ensuring that once someone has reviewed the code, they can be reasonably sure about what's in the binary (that is less obvious than it might seem) would also help making distribution easier (compiling from the sources is never that straightforward)

The program input and output need some testing

The main function needs some refactoring (for example: #4).
But refactoring requires being able to run some tests to ensure that the code behaviour hasn't changed.

I like to use dependency injection, and replacing STDIN, STDOUT by variables to test the output of my command line programs (example code, test).

I'm not sure how to achieve that in Rust yet, and would appreciate any suggestion!

Remove code duplication in usage instructions

The program welcome message and instructions make extensive use of the println! macro, because they run across multiple lines, and long lines are difficult to read in the code as well.

A raw string litteral could be used instead, that would:

• keep the message readable in the code
• keep the message formatting unchanged in the program output
• require only one println! : )

Note: I'd like to add some tests around this to make the refactoring easier, but I'll be more than happy to accept a contribution based on manual testing if I haven't added them when you pick it up!

The data of EFF's long wordlist should live in a different file

Edit: If you are looking to make your first (or second, or third!) open-source contribution, welcome! You can read the original comments in chronological order for context, or jump to the issue re-definition below! 🙂

---

As it is currently, that long piece of data (7776 numbers -dice throws- and 7776 words) is bloating the dice/wordlist/mod.rs file.

Github does a pretty good job, only skipping syntactic coloration for those lines, but otherwise editing the file isn't pleasant. Also, the data is unlikely to change while the logic certainly will.

I made an attempt to move the throws and words definitions to a different file, but Rust didn't like the variable assignments outside a function. I then tried encapsulating them in two functions, but got a bit lots with the ownership details as that implied extra borrowing...

I certainly need to understand better the ownership model, but I'm also sure there must be a pattern for this use case. Do you know of one? Please let me know! 🙂