timvisee / prs Goto Github PK

I'm just looking for a quick secure ephemeral password.

What is the meaning of passing a name, without calling --store?

Okay, in writing out this comment I looked a bit more and figured out what's going on.

Context:

• I'm migrating from gopass
• gopass seems to work "fine" for all normal operations I perform

Scenario:

• I tried prs edit for the first time and it complained because I didn't have any recipients established

So I poked around a bit more, and then realized that something somewhat unexpected can happen -- my recipients and committed without me even realizing!

So, starting from a naive repo:

• I ran prs edit, got a complaint about recipients
• ran prs recipients ls -> no results
• ran prs recipients add and then Ctrl+C'd out....
• ran prs recipients ls -> ... shows a key... wait what?
• ran git log and see that prs updated and committed my recipients for me, by:
  • deleted a maybe "wrong" duplicate of my gpg key in .public-keys
  • replaced the .gpg-id with the pubkey fingerprint instead of keygrip as I'd had in there (not sure if one is more valid than another, the manpage is vague)

(back-context - I think I'd basically added my gpg key TWICE to public-keys, once named by the keygrip, once named by the fingerprint).

So, I guess net result is probably fine. It seems that prs edit <foo> and gopass edit <foo> work fine now.

However, this was definitely a bit unexpected. Even just a log message of "recipients refreshed and committed" at the end of the process would've helped me realize that even though I Ctrl+C'd out of the selection dialog, that prs still went ahead and updated my recipients.

Thought I'd mention this - I don't know if there's a way to use this that would result in valid public keys being dropped... I don't necessarily know what else there is to do here, feel free to close as you see fit, but I thought I'd mention it, it definitely confused me.

Hello, I built prs on Linux arm64, and I'm running Wayland. When I tried to copy a password, I came across this error:

error: failed to copy secret to clipboard
caused by: failed to set clipboard
caused by: Could not find wl-copy or wl-paste binary for clipboard support

After installing wl-clipboard, the problem was solved; but I think it should be included on the README.md as a dependency on Wayland.

Hi,

I have started a new company and have been making my entries like <company>/discord.com to align with previous naming schemes. Let's say its bigco.

However, I am used to doing prs show disco or some other shortened for my usual full entry names.

Now though, this is a bit of a pain, as I wind up having to interactively select each time.

Helix has a particularly-fuzzy search that lets me type things like pkgtoonixdefault to get to pkgs/tools/package-management/nix/default.nix with minimal typing. My brain is fairly tuned to this "type some unique-ish path characters in order and get there fast".

Similarly, it would be nice to be able to do prs show bigcodisco and have it match to bigco/discord.com. What do you think?

I considered a separate password-store and a xprs command that sets PASSWORD_STORE, which to be honest, might be better for separation of concerns, but becomes a bit of a mess to think about with respect to my syncing story and usage with Android-Password-Store.

Maybe you have another idea? If not, maybe it's possible to re-use the algorithm from the interactive fuzzy finder to do matches on the CLI? If that's not too much magic?

Although the command line interface is different, it looks like prs implements the format used by pass. This is not explicitly documented in the README. Is it safe to use for people that switch back and forth, or may modifying the password store using prs lead to a situation where it's not compatible with plain pass anymore? It would be great if that could be documented.

I'm using prs-cli 0.1.2 in macOS Big Sur, and after prs copy'ing, the clipboard is cleared and the following message starts getting printed multiple times on the terminal:

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.

Let me know if you need more information!

This is super minor, but I thought I'd ask.

I typically just hit my hotkey for a terminal and tap out prs totp clip <site> but sometimes I don't, for whatever reason, and do prs totp show <site> and then am surprised to see the TOTP code with a space in it.

As I type this, the request seems more minor and more silly, but all the same, it might be nice if that space were elided in favor of being able to double click and copy the code rather than having to click and drag, or manually type out the 6-8 characters.

Thanks either way!

Hello, I've been getting this error recently, especially when syncing and now with editing. It seems to happen randomly with some commands, especially the ones that perform Git operations. A long delay occurs before the following message gets printed.

$ prs edit ...
[wait like two or three minutes or so]
mux_client_request_session: read from master failed: Broken pipe
[editor opens]

This happens on Intel macOS 11.2.2.

in pass we have (line 101)

	local gpg_id
	while read -r gpg_id; do
		gpg_id="${gpg_id%%#*}" # strip comment
		[[ -n $gpg_id ]] || continue
		GPG_RECIPIENT_ARGS+=( "-r" "$gpg_id" )
		GPG_RECIPIENTS+=( "$gpg_id" )
	done < "$current"

howeverprs consider the complete line as UserId and no whatever before the ' # ' only

To Reproduce

Steps to reproduce the behavior:

1. Add remarks to gpg_id entry in the .gpg_id file

Something like:

21347213469hdsaklfha # username <[email protected]>

2. ~/.cargo/bin/prs edit ali

3, Change something

4. save and exit

prs, will now say it can not find the ID (After inspecting with export RUST_BACKTRACE=1)

Expected behavior

prs should not care if entry has ramarks or not.

if it helps

in my implementation of pass pass simple I've used simply

Pseudocode

line.split(" ")[0]

Sorry I'm not a Rust developer and I can not just submit PR,
but I can gladly test and confirm problem solved after it will be fixed.

Hi.

Prs.exe on windows currently fails in some scenarios since I don't have FZF installed. I think it would be great if FZF were replaced with Skim, a Rust equivalent:

https://github.com/lotabout/skim

Thank you!

The rise in popularity of the arm64 (aarch64) platform, mainly due to Apple, Raspberry Pi and PINE64 adopting it and building cool stuff on it, means that now more users expect pre-built binaries available for their platform. Currently, Linux and macOS are the most common platforms with ARM64 support, I highly suggest releasing binaries for these two.

Hi !

I am always following your great project !

The problem I had with git was that I used keygrip instead of long ID in .gpg-id file, prs seems to not be able to handle them. Manually replacing keygrip with key ID allows prs to recognize recipients. Great 👍

Now I still have some issues:

1. I use multiple remote with custom name. It seems prs can't handle them:

prs sync remote
error: multiple remotes configured, cannot decide automatically

What should I do ?

2. Even if now git recognizes the recipient, it seems I mostly can't use it
   For exemple, when I want to edit a secret using prs edit [secret_path] --verbose it returns me:

error: git operation exited with non-zero status code: exit status: 128

If I have uncommited change, the previous command is able to warn me about it and stop. I have no issue to decrypt a file with gpg with prs show. Also, my ssh key are stored with gpg too so I always have to set gpg agent using export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket) before doing any git related stuff. Maybe it is not supported by prs ?

3. Bash completion not working as expected

I did prs internal completion bash this allows me to complete using tabs but it only propose me the file in the current folder. I have to cd into password-store directory to be able to complete with secrets' names.

Thanks for your time :)

Hi,

I'm trying to use https://github.com/mdellweg/pass_secret_service but between python, python-crytography, what I suspect is pypass, I am less interested in making it work than I would be hacking on a Rust solution.

Is this something you've considered?

Admin edit: tracking issue, merge request

First off - love what you're doing with this project, very nice job.

Second, please consider adding pass-tomb support/similar functionality. The ability to keep passwords in a tomb is a very nice security add. I know not all users will want to use it, but it's a brilliant extension for pass to solve the "metadata leakage" that one might have with secret names.

Update: After posting this, I did realize there's a potential work around by simply using pass-tomb direction for managing the tomb itself. And then prs will remain oblivious to the fact that it's operating on a tomb while the tomb is mounted.

Workaround

Here's a potential workaround (not tested, hypothetical)

pass tomb [email protected] #only required once to create tomb
pass open #assuming not already open from above command
prs add foo/bar
prs sync
prs ....
pass close

There's some caveats here, particularly around use by multiple recipients etc, but those are likely quite small issues as each recipient would just create their own personal tomb and then prs sync appropriately. This doesn't cover every threat model, but it may be an idea. Also, pass tomb accepts multiple gpg-id's, so it may just take some finagling to clear out any existing pass data in the .password-store directory and then run prs init as desired.

I was very excited to finally get rid of gopass but it seems prs is missing totp functionality. It would be great if it could be supported.

Ahoi,

how could autocompletion be accomplished? It would nice if prx could generate the needed output for these shells. I don't know how pass does it, but I could just type pass <tab> and get a list of entries. Would be nice to have the same feature with prs.

"pass" allows signing of the git commits. (pass.signcommits=true)

We use github's branch protection to enforce that.

It would be great if prs would support this, too!

I was reading over the source code before considering using this, and was a bit surprised to find usage of unsafe in a relatively high-level, security-sensitive application like this. Removing them would IMO be worth considering because it makes the code much easier to audit, and ongoing maintenance risk is lower (even if all use of unsafe is sound now, you need to ensure it remains sound in future changes).

unsafe is used in three places:

1. copy_timeout_x11

This uses libc::fork() and libc::kill() to create and destroy a process (running the same executable image, since there is no exec()) to clear the clipboard.

Why not use std::process to fork off a subprocess to do that? fork() without exec() can be wildly unsafe in large programs; every library in use should be audited to ensure it is safe to continue using after a fork(), and the dependency tree is too big to realistically do that on an ongoing basis:

$ cargo tree | wc -l
491

2. u8_as_utf16

This is called by parse_output for the gnupg_bin crypto backend, with the comment:

/// Command output formatting might not always be consistent. This function tries to parse both as
/// UTF-8 and UTF-16.

In what situations would the command output be UTF-16 rather than UTF-8? Could it be another charset? (Why not?) Why not use an existing crate to handle UTF-16 decoding?

The unsafe block in u8_as_utf16 assumes the &[u8] is properly aligned to be interpreted as a &[u16], which is not guaranteed. It also assumes native byte order, which (if I've understood the context that this code is used in correctly) would be problematic if a repository is shared between systems of different endianness.

3. tests, verifying zero-on-drop

This seems perfectly reasonable — I don't know of a way to do this in safe Rust, but usage of unsafe could at least be confined to tests.

Hello! I think it would be better if prs list behaved similarly to pass ls, showing passwords in a tree instead of a plain list, like this:

├── password1
├── folder
│   ├── password2
│   └── password3
└── password4

I just share some direction I find interesting for your nice project if you need some ideas to continue working on it :), feel free to ignore if you don't have time !

I don't know if you plan to work on a GUI for prs but that would be a great thing to have ! I love the idea of having a fully featured implementation that is compatible with all OSs, windows in particular but users are often using GUI on such distro.

A nice possibility that requires less work than coding a whole GUI for you is to make prs fully compatible with QtPass, already compatible on all OSs. QtPass allows the user to provide his own pass implementation in its settings but this requires commands compatibility. It works already a bit when you use prs binaries: I can read passwords' content with QtPass. However I can't generate them, I can't get the totp and I don't think I can get the recipients. But I think it could be simple to handle by adding legacy CLI to prs. For example, if prs totp [FILE] would just return the OTP if no other subcommand would be provided then it should be possible to support OTP in QtPass without any other change.

That's say it could break some CLI you already made (like prs generate maybe ?)

Another issue I have is that I don't fully get what could be diferent from the original pass . I see new commands like housekeeping and alias but I don't fully get the implication of using them. It seems also that prs recipients list does not detect the gpg ID I used with pass. More documentation on pass interaction would be great to be sure to not mess up the "imported" password store !

I just had my hands on a shared keyset of which one key's encryption subkeys have all expired.

In order to find this, I had to strace prs in order to find the gpg invocation, which (even in the form it was in, with the --quiet in place) gave me at least a hint as to which key was offending. (GPG lent no aid in finding what's wrong there, apart from its --verbose output pointing me in the general direction of subkeys; I wouldn't expect prs to peek into gpg internals here).

I did not run through a full reproduction setup, but this is what should do:

• Create a key that has an expired encryption subkey (but is generally non-expired; didn't test what happens when it is)
• Put it into a repo's .gpg-id
• Run prs edit on an existing file

The PRS version I used was the current prs-cli from crates (0.3.5), with features clipboard and alias. I can't tell the behavior with gpgme: on Debian that somehow doesn't like to work with the dev libs for lack of gpg-error-config (Debian had to patch that where they packaged the GPGME crate).

I suggest that when --verbose is given (alternatively, some other debug flag), that then GPG's stderr output be shown, either captured and labelled, or just keeping stderr intact.