Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Bitwarden userscript gives "mac failed" error when another session is started somewhere else #7607

Open
user202729 opened this issue Mar 9, 2023 · 4 comments · May be fixed by #7781
Open

Bitwarden userscript gives "mac failed" error when another session is started somewhere else #7607

user202729 opened this issue Mar 9, 2023 · 4 comments · May be fixed by #7781
Labels
component: userscripts Issues related to userscripts in misc/userscripts priority: 2 - low Issues which are currently not very important.

Comments

@user202729
Copy link
Contributor

user202729 commented Mar 9, 2023 •
edited

Version info:
latest master

Does the bug happen if you start with --temp-basedir?:
yes

Description
As in the title.

How to reproduce

  1. Use the userscript, key in the master password successfully.
  2. (now the userscript will store the value with keyctl)
  3. start another session somewhere else (on another terminal) with bw unlock.
  4. (now the old session key will be invalidated)
  5. try to use the userscript again. It will give "mac failed" error message.

Thinking about it a quick hack is

     out = process.stdout.decode(encoding).strip()
 
+    if not out:  # mac failed or something maybe
+        subprocess.call(['keyctl', 'purge', 'user', 'bw_session'])
+
     return out

speaking of which, in this situation the returncode is still 0, so checking returncode doesn't work and it will give JSON decode error later on. (but the returncode might be changed to something nonzero later...?)
@The-Compiler The-Compiler added priority: 2 - low Issues which are currently not very important. component: userscripts Issues related to userscripts in misc/userscripts labels Mar 12, 2023
@dezeroku
Copy link

dezeroku commented Jul 17, 2023 •
edited

There actually seems to be a cleaner way , bw exposes --nointeraction flag that causes commands awaiting for input to fail.
With this in place we can get error code 2 on exit and properly notify the user that something is wrong, PoC here, works fine on my machine (fine as in you enter the if err condition).

Still, I wonder if it's a good idea to check if the stderr contained something like mac failed and just purge the key or leave it to the user (PoC here, works as expected). It sounds good, I just wonder if we accidentally won't catch some real problems and enter kind of an infinite loop.

BTW, thanks a lot for digging into this, I was having this error pop-up from time to time and never once thought it could be some kind of session invalidation behind the scenes.

@dezeroku dezeroku linked a pull request Jul 17, 2023 that will close this issue
Open
@georgettica
Copy link

I used bw unlock --passwordenv and the fix of "--nointeraction" does not help

@dezeroku
Copy link

dezeroku commented Nov 1, 2023

@georgettica Please take a look at the attached MR, the userscript requires adding the noninteractive flag and also an if check

@georgettica
Copy link

I will test it in the future, didn't see the MR returns early if the issue is detected

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
component: userscripts Issues related to userscripts in misc/userscripts priority: 2 - low Issues which are currently not very important.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

userscripts: fix qute-bitwarden failing with expired session dezeroku/qutebrowser
4 participants
@The-Compiler @georgettica @dezeroku @user202729