Hi @conradkdotcom

error: the listed checksum of `/builddir/rooster-2.7.1/vendor/backtrace-sys/src/libbacktrace/config.sub` has changed:
expected: 3b739084e4b409aacf8531f87b57efa602eccdd17b5cddbc4ae1313a2c866f34
actual:   82745ce935695e7984a053c155a64b9ad16ece3a07d931cc90ab3fb28b7221af

What's wrong ? Regards.

I like to have a long master password, however without GUI I have to retype it for every operation, which is really bothersome. Is there a solution to this?

It would be awesome to have a way to see if we have any weak/hacked passwords in our Rooster file.

What do you think ? Please post your thoughts here before working on this issue because we have to agree on the solution before we start coding.

My thoughts:

• https://crates.io/crates/zxcvbn is a nice crate, but it has a lot of dependencies (ie 3rd party code) and so it's difficult to audit, I don't want us to install crates that have so many dependencies because we lose track of what's inside, which could lead us to install viruses by mistake at some point (we've seen this happen recently with the https://kite.com fiasco and the NPM ecosystem)
• I think having a way to quickly see which passwords are weak would be a good way to go, for instance rooster weak could show a list of weak passwords
• I'd like to see if we can find a way to integrate with https://haveibeenpwned.com: this is not easy because it is a online service, and sending any password to it is a no-go. There is an archive of hacked passwords that we could use offline but it is 5Gb so that's a no-go as well. I'm not sure what we can do here. Maybe we could create a command that would fetch the 5Gb file only if the user agrees and then check if any of our passwords have been hacked ? I'd do that for my passwords.

At some point, Rooster will include an "Analytics" module so that we can use data to make Rooster better. Let's see what this whole "Analytics" thing is about.

Given the nature of Rooster, including some kind of tracking system inside of it could seem crazy. I get that. Matter of fact, when I am not sure what data is collected about me and/or don't understand what's being done with that data, I usually try to opt-out.

And, just so you know, when Rooster gets analytics, there will be a way to opt-out.

However, as with a lot of software projects, knowing what users do with the software helps in making it better. Here are some thing that I think Rooster could benefit from knowing:

• The Rooster commands you use (rooster list, rooster get, etc): this information could be used to removed unused commands or improve heavily used ones,
• Your locale: this could be used to translate Rooster documentation for heavily used languages,
• Your operating system: this could be used to focus testing efforts on those systems for every new release, so as to not lose users,
• Your version of Rooster: this could be used to drop support for older, unused versions, and focus development resources on what matters most.

These things will help make Rooster better for every user, including you. So yeah, at some point, Rooster will track how you use it. If you don't want to be tracked, you will be able opt-out.

Any feedback is welcome.

Hello again!

Currently when I rooster get github, for example, and mistype my master password, the output looks like this:

I could not upgrade the Rooster file. This could be because:
- you explicitly told Rooster not to open the file,
- your version of Rooster is outdated,
- your Rooster file is corrupted,
- your master password is wrong.
Try upgrading to the latest version of Rooster.

IMO rooster should know which scenario has occurred, and print just the most accurate thing.

I hate issues for discussing stuff, but there we go:

I was trying to build the same thing you've done with rooster, with two big differences

• using libsodium via sodiumoxide

The library is ultra fast and provides encryption which is going to last. (It's taken from djb's nacl after all), and the main consequence for this one would be having a better key derivation scheme - we definitely don't want to have SHA256 for keys :)

• using sqlite3 as storage instead of a single flat file

my reasoning for this one is having a file format which is well documented, stable and with all the bonus points of being almost drop-in compatible with android - which means less hassle for doing the mobile app.

Thoughts? I'd be more than happy to discuss more on this, since I don't want to duplicate effort :)

Can't seem to get rooster to install on ubuntu. This can be reproduced exactly in a docker container:

root@dockerhost:/# docker run -it ubuntu bash

root@6a956b281c:/# apt-get update
 [ ... ]
root@6a956b281c:/# apt-get install curl gcc make file sudo
 [ ... ]

root@6a956b281c:/# curl -sSf https://static.rust-lang.org/rustup.sh | sh
rustup: gpg available. signatures will be verified
rustup: downloading manifest for 'stable'
rustup: downloading toolchain for 'stable'
######################################################################## 100.0%
gpg: assuming signed data in `/root/.rustup/dl/481cfcf7d473f81de22d/rust-1.12.1-x86_64-unknown-linux-gnu.tar.gz'
gpg: Signature made Thu Oct 20 20:32:08 2016 UTC using RSA key ID 7B3B09DC
gpg: Good signature from "Rust Language (Tag and Release Signing Key) <[email protected]>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 108F 6620 5EAE B0AA A8DD  5E1C 85AB 96E6 FA1B E5FE
     Subkey fingerprint: C134 66B7 E169 A085 1886  3216 5CB4 A934 7B3B 09DC
rustup: installing toolchain for 'stable'
rustup: extracting installer
install: creating uninstall script at /usr/local/lib/rustlib/uninstall.sh
install: installing component 'rustc'
install: installing component 'rust-std-x86_64-unknown-linux-gnu'
install: installing component 'rust-docs'
install: installing component 'cargo'

    Rust is ready to roll.

root@6a956b281c:/# cargo install rooster
 Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading rooster v2.3.0
 Downloading rpassword v0.2.3
 Downloading rustc-serialize v0.3.19
 Downloading clipboard v0.1.2
 Downloading byteorder v0.5.3
 Downloading rand v0.3.14
 Downloading libc v0.2.17
 Downloading getopts v0.2.14
 Downloading rust-crypto v0.2.36
 Downloading unix-daemonize v0.1.2
 Downloading time v0.1.35
 Downloading winapi v0.2.8
 Downloading kernel32-sys v0.2.2
 Downloading winapi-build v0.1.1
 Downloading gcc v0.3.38
 Downloading termios v0.2.2
 Downloading x11 v2.11.0
 Downloading pkg-config v0.3.8
   Compiling byteorder v0.5.3
   Compiling winapi v0.2.8
   Compiling winapi-build v0.1.1
   Compiling rustc-serialize v0.3.19
   Compiling gcc v0.3.38
   Compiling pkg-config v0.3.8
   Compiling kernel32-sys v0.2.2
   Compiling libc v0.2.17
   Compiling termios v0.2.2
   Compiling unix-daemonize v0.1.2
   Compiling x11 v2.11.0
   Compiling rand v0.3.14
   Compiling time v0.1.35
   Compiling rust-crypto v0.2.36
Build failed, waiting for other jobs to finish...
error: failed to compile `rooster v2.3.0`, intermediate artifacts can be found at `/tmp/cargo-install.Q8oAJxea4HXk`

Caused by:
  failed to run custom build command for `x11 v2.11.0`
process didn't exit successfully: `/tmp/cargo-install.Q8oAJxea4HXk/release/build/x11-0ca340fb7c96474d/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "Failed to run `\"pkg-config\" \"--libs\" \"--cflags\" \"x11\"`: No such file or directory (os error 2)"', ../src/libcore/result.rs:788
note: Run with `RUST_BACKTRACE=1` for a backtrace.

There is a possible use case for Rooster to store private keys, such as SSH or GPG keys, cryptocurrency account keys. But there is currently no convenient UI to do so. One can copy-paste file contents into rooster add input, but that wouldn't work with multiple lines.

I propose adding a way for users to add passwords from a file path and to get passwords into a file path. This change wouldn't require to create any new entities in the interface or invent new commands. There are at least two ways to do so:

1. Add an optional command-line flag -p <path> or -f <file> which can be used by different commands as a signal, that they have to interact with a specified file, rather than with stdin or clipboard. Suggested usage:

   • rooster add prod-ssh master -f ./id_rsa
   • rooster get prod-ssh -f ./id_rsa.

   This method has a flaw: -f flag is used sometimes as an input, sometimes as an output, therefore it might not always be clear what is does (as in rooster change someapp -f ./pwd for example).

2. Add an optional positional argument [path] to the commands that accept it. Suggested usage:

   • rooster add prod-ssh master ./id_rsa
   • rooster get prod-ssh ./id_rsa.

   Every command will have to have an explanation of this argument's function in the help text.

Same flag or argument could be added to change, generate and regenerate commands as well to ensure that commands act similarly.

Good day! Here is my humble contribution into the project :) Below I describe some of the design decisions I made, which you might want to correct.

1. 784fd56: Created a function for fuzzy searching named list::search_and_choose_password, which basically combines PasswordStore::search_passwords and list::choose_password_in_list. This function is used throughout all the subcommands.

2. 784fd56: Changed the behaviour of list::request_password_index_from_stdin (which led to change in behaviour of list::choose_password_in_list): made it return 0-based index of selected password instead of 1-based. I thought it would more intuitive and independent of the UI representation of the passwords list :)

3. 9075715: Sometimes, when search results only contain one password, rooster asks user to "select password from 1 to 1". This commit makes rooster select the only result quietly without prompting the user.

4. 4ed9b42: Move help text about fuzzy searching into rooster's usage text.

5. 6b2efa3: Moved the function you recently created: commands::get::confirm_password_retrieved into the clip module since this code was also repeated in change and regenerate commands. My choice of module might not be the best, but it's the closest one by meaning I could think of :)

Resolves #27.

• change paste_keys() to return a &'static str instead of a String

Not sure how reliable cli_clipboard is but it seems to be working as intended. The problem might be that rooster will require wayland protocols to be installed in order to compile now (on Linux)

Open to feedback

All the dependencies are stores in the vendor directory.

Except xcb. Until the author releases the latest patch (which makes sources generation deterministic to satisfy cargo's checksum test) and until both x11-clipboard and clipboard crates update their dependency version, xcb sources should live in the patch/rust-xcb directory, which is just a clone of v0.7.7 with a patch applied. But when xcb is updated, this directory and the [replace] section in Cargo.toml may be removed.

A copy of xcb is still present in vendor/xcb because cargo for some reason wants to see it there but doesn't use it.

You might probably want to leave a note for contributors to run cargo-vendor after updating dependencies :)

Resolves #36