What does qubes-pass bring to the table that a vault pass does not?

I am trying to understand the advantage of using qubes-pass over a normal pass setup on an isolated vault qube.

Correct me if I am wrong, but, when copying/pasting clipboard is as easy as ctrl+shift+c/v, what is the advantage of qubes-pass? What ease of use does it bring to the table that copying/pasting passwords from a vault qube to other qubes does not have?

1 Like

plus this issue?

1 Like

Indeed. Seeing that made me a bit more cautious about qubes-pass tool and learn more about it.

Paging @Rudd-O for comment.

Okay folks.

clip() {
	if [[ -n $WAYLAND_DISPLAY ]]; then
		local copy_cmd=( wl-copy )
		local paste_cmd=( wl-paste -n )
		if [[ $X_SELECTION == primary ]]; then
			copy_cmd+=( --primary )
			paste_cmd+=( --primary )
		local display_name="$WAYLAND_DISPLAY"
	elif [[ -n $DISPLAY ]]; then
		local copy_cmd=( xclip -selection "$X_SELECTION" )
		local paste_cmd=( xclip -o -selection "$X_SELECTION" )
		local display_name="$DISPLAY"
		die "Error: No X11 or Wayland display detected"
	local sleep_argv0="password store sleep on display $display_name"

	# This base64 business is because bash cannot store binary data in a shell
	# variable. Specifically, it cannot store nulls nor (non-trivally) store
	# trailing new lines.
	pkill -f "^$sleep_argv0" 2>/dev/null && sleep 0.5
	local before="$("${paste_cmd[@]}" 2>/dev/null | $BASE64)"
	echo -n "$1" | "${copy_cmd[@]}" || die "Error: Could not copy data to the clipboard"
		( exec -a "$sleep_argv0" bash <<<"trap 'kill %1' TERM; sleep '$CLIP_TIME' & wait" )
		local now="$("${paste_cmd[@]}" | $BASE64)"
		[[ $now != $(echo -n "$1" | $BASE64) ]] && before="$now"

		# It might be nice to programatically check to see if klipper exists,
		# as well as checking for other common clipboard managers. But for now,
		# this works fine -- if qdbus isn't there or if klipper isn't running,
		# this essentially becomes a no-op.
		# Clipboard managers frequently write their history out in plaintext,
		# so we axe it here:
		qdbus org.kde.klipper /klipper org.kde.klipper.klipper.clearClipboardHistory &>/dev/null

		echo "$before" | $BASE64 -d | "${copy_cmd[@]}"
	) >/dev/null 2>&1 & disown
	echo "Copied $2 to clipboard. Will clear in $CLIP_TIME seconds."

This is code in qubes-pass to pass the password (haha) to xclip. This is part of the code that is under indictment for putting the passwords in the command line.

Guess where this code comes from?

That’s right, it comes from pass. pass does the exact same thing we do, partly because we want to preserve compatibility with how pass does things.

If you want to be “cautious about qubes-pass” you should be cautious about pass too.

That said, the bug report contained valuable info, which led to a few fixes. I will also investigate whether we could improve on how pass does this without posting the password to the process list.

EDIT: I have released a new version of qubes-pass just now, which addresses the concern by using a private FIFO pipe instead of passing any arguments on the command line.

EDIT 2: a new version was released which instead of using FIFOs (which can be fragile) it simply base64 encodes the code that bash is supposed to run for us (that’s the pesky pass code), and then decodes it on bash’s side — we send it via stdin instead.

The principal advantage of using qubes-pass is that you can script activities (e.g. a browser tool, or some automation), which is not something you can do with C+S+V / C+S+C.


OK. That’s fair. That’s what I wanted to know.

1 Like

Just added mlockall() support to the qvm-pass command, which means your retrieved or stored secrets are never at risk of being swapped to the disk of the client VM. This is sadly not something that can be done for the plain pass command or the qvm-pass -c / qvm-pass -q commands, because they’re all implemented in bash and bash does not support mlockall (mlockall is released upon execve()).

EDIT: frankly never understood why pass would be implemented in bash precisely because of this security issue, as well as the broader problem of bash being absolute garbage at handling binary data.