To reproduce:

cd freepass/cli
cargo build --release
strip target/release/freepass 
mv target/release/freepass /usr/local/bin
RUST_BACKTRACE=1 freepass interact

Expected output: interactive repl displayed Actual output:

thread 'main' panicked at 'Option file not found', src/main.rs:139:16                       
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: __libc_start_main
  11: <unknown>

Notes: help subcommand works though, so that's helpful.

Doing a cargo update before cargo build leads to the following error:

Compiling freepass-core v0.0.0 (file:///some/path/freepass/core)
error[E0053]: method `lookup` has an incompatible type for trait
   --> some/path/freepass/core/src/attachments.rs:121:6
    |
121 |      fn lookup(&mut self, _req: &Request, parent: u64, name: &Path, reply: ReplyEntry) {
    |      ^ expected struct `std::ffi::OsStr`, found struct `std::path::Path`
    |
    = note: expected type `fn(&mut attachments::Attachments, &fuse::Request<'_>, u64, &std::ffi::OsStr, fuse::ReplyEntry)`
    = note:    found type `fn(&mut attachments::Attachments, &fuse::Request<'_>, u64, &std::path::Path, fuse::ReplyEntry)`

error[E0053]: method `mknod` has an incompatible type for trait
   --> /some/path/freepass/core/src/attachments.rs:226:6
    |
226 |      fn mknod(&mut self, _req: &Request, parent: u64, name: &Path, mode: u32, _rdev: u32, reply: ReplyEntry) {
    |      ^ expected struct `std::ffi::OsStr`, found struct `std::path::Path`
    |
    = note: expected type `fn(&mut attachments::Attachments, &fuse::Request<'_>, u64, &std::ffi::OsStr, u32, u32, fuse::ReplyEntry)`
    = note:    found type `fn(&mut attachments::Attachments, &fuse::Request<'_>, u64, &std::path::Path, u32, u32, fuse::ReplyEntry)`

error[E0053]: method `mkdir` has an incompatible type for trait
   --> /some/path/freepass/core/src/attachments.rs:235:6
    |
235 |      fn mkdir(&mut self, _req: &Request, parent: u64, name: &Path, mode: u32, reply: ReplyEntry) {
    |      ^ expected struct `std::ffi::OsStr`, found struct `std::path::Path`
    |
    = note: expected type `fn(&mut attachments::Attachments, &fuse::Request<'_>, u64, &std::ffi::OsStr, u32, fuse::ReplyEntry)`
    = note:    found type `fn(&mut attachments::Attachments, &fuse::Request<'_>, u64, &std::path::Path, u32, fuse::ReplyEntry)`

error[E0053]: method `create` has an incompatible type for trait
   --> /some/path/freepass/core/src/attachments.rs:243:6
    |
243 |      fn create(&mut self, _req: &Request, parent: u64, name: &Path, mode: u32, flags: u32, reply: ReplyCreate) {
    |      ^ expected struct `std::ffi::OsStr`, found struct `std::path::Path`
    |
    = note: expected type `fn(&mut attachments::Attachments, &fuse::Request<'_>, u64, &std::ffi::OsStr, u32, u32, fuse::ReplyCreate)`
    = note:    found type `fn(&mut attachments::Attachments, &fuse::Request<'_>, u64, &std::path::Path, u32, u32, fuse::ReplyCreate)`

error: aborting due to 4 previous errors

error: Could not compile `freepass-core`.

To learn more, run the command again with --verbose.

Steps to reproduce

git clone https://github.com/myfreeweb/freepass.git
cd freepass
git submodule update --init libsodium rusterpassword
cd "cli"
cargo update
cargo build --release

For making distro packages, it would be great if you could provide some kind of version incrementing. Having '0.0.0' for every published version doesn't reflect any differences in the builds. If you follow semver, the 0.x.y releases are fine for an unstable product.

Not all legislations allow releasing code to the public domain, nor recognize the UNLICENSE as valid. To solve this, you should consider dual licensing your project. This would allow the user to choose which license to use. Maybe a possible alternative is the MIT license (see https://github.com/BurntSushi/fst, which is dual-licensed under MIT and the UNLICENSE).

See this stack exchange question for details about the problems with UNLICENSE.

From the most recent libsodium CHANGELOG:

• The aes128ctr primitive was removed. It was slow, non-standard, not authenticated, and didn't seem to be used by any opensource project.

Updating my system broke freepass so I've had to build an older copy of libsodium to deal with this for the time being.

The spec on the master password website mistakenly declared '0' as the default counter value. As per this issue it is confirmed that none of the algorithms implemented in the official applications use 0. While It's annoying to have to change passwords, I think it is better to update to the actual behaviour of master password applications. Fixes issue #5 if merged.

 cargo build --release
warning: An explicit [[bin]] section is specified in Cargo.toml which currently
disables Cargo from automatically inferring other binary targets.
This inference behavior will change in the Rust 2018 edition and the following
files will be included as a binary target:
*freepass/cli/src/main.rs

This is likely to break cargo build or cargo test as these files may not be
ready to be compiled as a binary target today. You can future-proof yourself
and disable this warning by adding `autobins = false` to your [package]
section. You may also move the files to a location where Cargo would not
automatically infer them to be a target, such as in subfolders.

For more information on this warning you can consult
https://github.com/rust-lang/cargo/issues/5330
warning: path `/freepass/cli/src/main.rs` was erroneously implicitly accepted for binary `freepass`,
please set bin.path in Cargo.toml

Not a problem when compiling, but thought it would help to note this behavior.

I tried to generate a password which I am using from freepass in the master password app. The README says that freepass generates the same passwords, but while I get the same output on both the android master password app and the web based master password app, the output from freepass is different for the same settings. Trying here for example.

Update: Seems master password uses a counter of '1' for the first password, wheras freepass does not. In the web app, you can clear the counter field to be empty to get the same output as freepass. In the mobile apps, the counter cannot be unset in this way and so cannot generate the first password that freepass does. Not sure if this is something that should be fixed. Making freepass start at '1' will annoy anyone already using it, on the other hand, if you're already using master password, you now have to increment the counter for every password you add to freepass.

i checked the released tab but you only have "serde-migration". i wanted to use it but i need to compile it? it would be much nicer to just have it built.

Right now I can print the public key from freepass, or add the private key to ssh-agent. Are there any plans to allow printing the private key as well? I want to be able to export the keys for use but right now I have to do it in a round about way. Is this an option you are considering adding?