Plaintext passwords / PIN exposed via rofi cache history file

[trinitronx]

In testing this rofi plugin, I noticed that whatever is entered into the "secure" password entry in rofi gets directly written to disk in plaintext.

This appears due to rofi's default behavior to write textbox input history to: $XDG_CACHE_HOME/rofi-entry-history.txt (default: ~/.cache/rofi-entry-history.txt).

This may be possible to avoid by using -cache-dir /dev/null, but it's unclear how to tell the wrapper script /usr/bin/pinentry-rofi to pass this when it runs rofi.

[haennes]

Just stumbled upon this issue.
Seems like there is a -disable-history option as well which does nothing on my setup (nixos 24.11)
passing cache dir /dev/null to rofi also failes with: Failed to create cache directory: Not a directory
Seemslike the only solution is to point it to a temp directory which gets deleted instantly. (Don´t know about the security implication of that though)

EDIT: maybe having a symlink or hardlink from $tmpdir/rofi-entry-history.txt to /dev/null could do the trick. Will try out tomorrow.

EDIT: It works

QUICK FIX: let ~/.cache/rofi-entry-history.txt be a symlink to /dev/null

[plattfot]

Hi,

Yeah that is not great.

If I understand rofi correctly it should not write any entry to disk when using the option -password (as seen here in the rofi source code: view.c#L1005). Which is what I'm using when popping up rofi to prompt for passwords/PIN.

I don't see any trace of $XDG_CACHE_HOME/rofi-entry-history.txt on my machines. So it is working fine on my end.

The question is then, why does it write entries to disk for you two? I might have one suspicion on what it might be. But I need more information to be able to reproduce this. Would anyone of you mind answering the following questions?

What version of rofi?

What version of guile?

What version of gnupg? Or are you using something else?

Is the password/PIN visible when typing it in?

Thanks

[haennes]

Hi,

Yeah that is not great.

If I understand rofi correctly it should not write any entry to disk when using the option -password (as seen here in the rofi source code: view.c#L1005). Which is what I'm using when popping up rofi to prompt for passwords/PIN.

I don't see any trace of $XDG_CACHE_HOME/rofi-entry-history.txt on my machines. So it is working fine on my end.

What version of rofi?

1.7.5

What version of guile?

3.0.9

What version of gnupg? Or are you using something else?

according to gpg --version:

gpg (GnuPG) 2.4.5
libgcrypt 1.10.3
Copyright (C) 2024 g10 Code GmbH

Is the password/PIN visible when typing it in?

No

OS: NixOS
package branch: unstable

[plattfot]

What version of rofi?

1.7.5

Could it be that you are using the next branch?

I did some more code spelunking and the rofi entry cache history was added after the 1.7.5 release. Which also explains why I'm not seeing it on my side, as Guix is using the 1.7.5 release.

I can reproduce the behavior by using rofi from this commit.
My steps are as follows:

Build it from source:

$ guix shell --pure -D rofi meson ninja pkg-config gcc-toolchain -- meson setup build
$ guix shell --pure -D rofi meson ninja pkg-config gcc-toolchain -- meson compile -C build

Then I ran:

./build/rofi -dmenu

Typed in foo when prompted

Then I ran:

./build/rofi -dmenu -password

Typed in bar

And the resulting history file is:

$ cat $XDG_CACHE_HOME/rofi-entry-history.txt
foo
bar

I would expect it to just capture foo and not bar. As the latter is using the -password option (same that is used in pinentry-rofi when prompting for passwords/PIN). Which I assume the commit message means when it says "disable when dmenu password is set".

Running the same with rofi-1.7.5 does not produce any output on disk.

Please report this issue to the rofi maintainers given that this looks to be a bug in rofi and not pinentry-rofi.

[haennes]

could you provide me with a/the commit of the upstream it still works on? i cant figure out where i have to look

[plattfot]

I'm using the 1.7.5 tag: https://github.com/davatorium/rofi/tree/1.7.5
That one is the latest release, which is ~2 years ago. Not sure why there hasn't been any new official release since then.

[haennes]

opened an upstream issue. Is confirmed by the developer. davatorium/rofi#1995

I think this should be left open until it is patched in upstream and on a realease. Such that people will find it

[plattfot]

Sounds good. I'll leave this open until this is patched upstream.

[trinitronx]

Could it be that you are using the next branch?

Yes, in effect I'm using the Wayland forked version of rofi that was based on the next branch of the original repo, davatorium/rofi.

This is the lbonn/rofi fork that supports Wayland natively, and it's installed by default in Manjaro Sway, as manjaro-sway/rofi-wayland version 1.7.5-2.

[plattfot]

Yes, in effect I'm using the Wayland forked version of rofi that was based on the next branch of the original repo, davatorium/rofi.

This is the lbonn/rofi fork that supports Wayland natively

Ok, it seems that they track the upstream rofi repository. Once the fix lands in davatorium/rofi then lbonn/rofi should eventually get it.