yds12 / guarakapa Goto Github PK

Output of kapa ls is just a debug print. Make it more user friendly (sorted too).

A command like:

$ kapa check <filename>

Should display the version of the program used to generate the data file <filename>. The version is already contained in the first 3 bytes of the file. Must first check if the file contains the signature (4 "magic" bytes after the version number), if not, version is less than 0.8.6 (when this versioning was introduced).

We are using anyhow to deal with errors. That is nice for the executable program, but to extract the main functionality in a library we need to have our own error types. Maybe use thiserror.

A dependency of x11-clipboard, namely xcb, has security vulnerabilities detected by cargo audit. See if any of those can be replaced.

API:

kapa merge PATH

where PATH is the path of another guarakapa data file. The user is then prompted to input both passwords (the main one and the password of the other file), and, if there are conflicting entries (same name but different data), choose what to do (choose one of them or keep both and rename one).

Currently, if one wants to change their master password, they would have to manually backup all the data.

We need a simple command that allows one to change their password (which will, inevitably, require the user to type the old password).

I recommend to use a command line parser.
Something like clap or structopt
if you agree, let me do that :))

Command echo a | kapa ls (for example) causes a panic. Fix this.

In some Linux distros, copying the password to the clipboard does not work even after installing openssl, libxcb-shape and libxcb-xfixes. We need to find out exactly what are the relevant libraries that need to be present (beyond X itself).

Currently the path to the data file is fixed at $HOME/.config/guarakapa/gk.dat.

This path should be configurable via an environment variable. If it is provided, we use it, if not, use the current default.

At the moment, if the user wants to change a record, they have to remove and add it again. That is annoying, an edit command would be very useful.

After secrets (such as passwords) are used, they can be deleted from memory to increase safety (as deallocating does not guarantee memory deletion). We can use zeroize.

Add a command or use one of the existing commands to display the path where the program data file is.

Add a command to reset the data file. It should warn the user, and perhaps make a backup of the existing file.

We can use std::io::Read and std::io::Write instead of reading directly from files. This is a step towards making the core functionality of the program more reusable so that it can be extracted into a crate later.

Create a test that creates a new file, adds a new record, retrieve it, paste it somewhere and check that the pasting worked.

The file manager module (fman) should be an abstraction for the manipulation of the main data file: entries and cryptographic material necessary to recover them (salt, pw hash, IV, etc.). It should be as generic as possible as a "cryptographic container".
The version signature used specifically by the executable is not general enough to be in this module, and should be moved somewhere else. The decoding and encoding also should be somewhere else, as they do not concern the encrypting and decrypting, but only a binary serialization of the data.