Password decryption appears not to be attempted

[rgammans]

General information

• Operating system Debian 9.1
• Browser + version: firefox-esr_60.0.2esr-1 (from debian experimental)
• Information about the host app:
  • How did you install it?
    Compiled myself; -v = "Browserpass host app version: 2.0.19"
    from commit id #4ca5c7c0d557f4aece063da54683eb04436d59be
• Information about the browser extension:
  • How did you install it?
    • Installed via webstore, downloaded a pre-built extension, compiled yourself?
      Install from the extensions tab and seaching by name inside firefox.
  • Browserpass extension version as reported by your browser:
    browserpass-ce 2.0.21

---

Exact steps to reproduce the problem

1. Visit a sign on page
2. Click on the browerpass icon, or use the Ctrl-Shift-L hotkey
3. Search for password; if not already there (this works)
4. Click to decode and fill password.

What should happen?

I would expect gpg to ask me for my passphrase (via the gnome-sessions gpg-agent feature) ; then the password to be decoded and filled into the password on the current page.

What happened instead?

I got busy logo for a few seconds and then the dialog box disappeared. I didn't get any gpg passphrase prompts at all.

Some notes;

This version of the Native host app works fine with the same extension under google-chrome. I updated the native host helper app to commit id #62bda2a62348be40ab64b2a603ae756fb5f7b869 (2.0.21+) as part wrting this bug report and I still have the same behaviour

[maximbaz]

The native app just calls the gpg binary, it doesn't handle gpg prompts and things like that, this is all done by gpg itself. If this works in Chrome, this suggests something is wrong with the Firefox itself in your installation — it works for me in both Chromium and Firefox.

Things to try: run Firefox from terminal, see if you get some extra error logs. Try unlocking the gpg-agent beforehand, see if Firefox able to fill passwords when gpg doesn't need passphrase anymore.

[rgammans]

If I unlock the gpg key in advices it does seem to work; I'm not seeing any error messages from firefox on the command line.

Do you have any advice on how to debug this further? Given it works on chrome my first suspect is firefox isn't setting the host-app's environment 'correctly'

[maximbaz]

Hmm, this sounds extremely suspicious that your Firefox can make gpg to get the password, but not to show the pinentry dialog. What is the location of your gpg binary, full path? What is the contents of your ~/.gnupg/gpg.conf and ~/.gnupg/gpg-agent.conf? Try to remove the Firefox configs by purging browserpass from /usr/lib/mozilla/native-messaging-hosts and/or ~/.mozilla/native-messaging-hosts, and then re-running the install.sh script.

[rgammans]

Yeah. Very suspicious.
Delete those files and re-running install.sh and then restart firefox doesn't change the behaviour.

I have no gpg-agent.conf ; just the attached gpg.conf (it's pretty ancient)

# Options for GnuPG
# Copyright 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
# 
# This file is free software; as a special exception the author gives
# unlimited permission to copy and/or distribute it, with or without
# modifications, as long as this notice is preserved.
# 
# This file is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
#
# Unless you you specify which option file to use (with the
# commandline option "--options filename"), GnuPG uses the
# file ~/.gnupg/options by default.
#
# An option file can contain all long options which are
# available in GnuPG. If the first non white space character of
# a line is a '#', this line is ignored.  Empty lines are also
# ignored.
#
# See the man page for a list of options.

# Uncomment the next line to get rid of the copyright notice
#no-greeting

# If you have more than 1 secret key in your keyring, you may want
# to uncomment the following option and set your preffered keyid

default-key ADBE6B00


# GnuPG ultimately trusts all keys in the secret keyring.  If you do
# not have all your secret keys online available you should use this
# option to tell GnuPG about ultimately trusted keys.
# You have to give the long keyID here which can be obtained by using
# the --list-key command along with the option --with-colons; you will
# get a line similiar to this one:
#    pub:u:1024:17:5DE249965B0358A2:1999-03-15:2006-02-04:59:f:
# the 5th field is what you want.

#trusted-key 12345678ABCDEF01


# If you do not pass a recipient to gpg, it will ask for one.
# Using this option you can encrypt to a default key.  key validation
# will not be done in this case.
# The second form uses the default key as default recipient.

#default-recipient some-user-id
default-recipient-self

# The next option is enabled because this one is needed for interoperation
# with PGP 5 users.  To enable full OpenPGP compliance you have to remove
# this option.

#force-v3-sigs

# Because some mailers change lines starting with "From " to ">From "
# it is good to handle such lines in a special way when creating
# cleartext signatures; all other PGP versions do it this way too.
# To enable full OpenPGP compliance you have to remove this option.

escape-from-lines

# If you do not use the Latin-1 (ISO-8859-1) charset, you should
# tell GnuPG which is the native character set.  Please check
# the man page for supported character sets. 
#charset utf-8


# You may define aliases like this:
#   alias mynames  -u 0x12345678 -u 0x456789ab -z 9
# everytime you use --mynames, it will be expanded to the options
# in the above defintion.  The name of the alias may not be abbreviated.
# NOTE: This is not yet implemented

# lock the file only once for the lifetime of a process.
# if you do not define this, the lock will be obtained and released
# every time it is needed - normally this is not needed.
lock-once

# If you have configured GnuPG without a random gatherer
# (./configure --enable-static-rnd=none), you have to
# uncomment _one_ of the following lines.  These
# extensions won't get used if you have a random gatherer
# compiled in (which is the default for GNU and xxxBSD systems)
#load-extension rndlinux
#load-extension rndunix
#load-extension rndegd


# GnuPG can import a key from a HKP keyerver if one is missing
# for certain operations. Is you set this option to a keyserver
# you will be asked in such a case whether GnuPG should try to
# import the key from that server (server do syncronize with each
# other and DNS Round-Robin may give you a random server each time).
# Use "host -l pgp.net | grep www" to figure out a keyserver.
#
# If you do not want to use the default port 11371, you can give the
# name of the keyserver like this: 
#   x-hkp://keyserver.example.net:22742
# If you have problems connecting through a buggy proxy, you can use this:
#   x-broken-hkp://keyserver.example.net:11371
# But first you should make sure that you have read the man page regarding
# proxies (--honor-http-proxy)
# Most users just set the name of the preferred keyserver.
keyserver wwwkeys.uk.pgp.net

# The environment variable http_proxy is only used when the
# this option is set.

#honor-http-proxy

Path to gpg is /usr/bin/gpg

[rgammans]

I've checked the communication both ways on both firefox and chrome; also chcked the environment with a wrapper script around the host app.

While chrome is sending autoSubmit:True; and firefox autoSubmit:False; I don't t think this is relevant as I can send the firefox request verbatim to the host app (using a python repl to ensure the binary length field is not corrupted.) and I get the password unlocked correctly.

I no see an error being returned form the hsot app in failure cases "exit status 2\ngpg: decryption failed: No secret key\n" ; but it doesn't show on the UI

Could there be some sort of very small timeout in firefox which I am hitting in some manner?

I have also tried debian's firefox 52.8.1_esr-2; and mozilla binaty download of firefox 60.0.2.
All have the same behaviour.

[maximbaz]

The reason I asked about gpg.conf and gpg-agent.conf is because macOS users have to explicitly declare use-agent and pinentry configs - see here. I didn't have to configure that on my Arch Linux.

autoSubmit is something that is configured in extension options, and the default value changed at some point, that could be the cause.

Wow this is very difficult case... One more idea, try to see if you can get to a browser console, or developer tools in chromium, and see maybe browserpass is writing some error logs there. I think the link to devtools is somewhere in Addons > Debug addons.

[rgammans]

Ok; I'm seeing the following when it fails

18:52:42.404 exit status 2
gpg: decryption failed: No secret key
  background.js:173:13
18:52:42.401 [Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIMessageSender.sendAsyncMessage]"  nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame :: resource://gre/modules/ExtensionUtils.jsm :: sendAsyncMessage :: line 533"  data: no]

(Sorry about the formatting - it's just cut and pasted from the add-on debugger console)

I'm intrigued by 1) The NS error is shown after the status - but it does have an earlier timestamp.
2) The error from the backend is getting to firefox.

If I unlock the password key and try I get the following:-

18:57:56.107 Unchecked lastError value: Error: Script 'moz-extension://ebd80c62-27da-498c-8efd-554d4d2ac42d/inject.js' result is non-structured-clonable data

[okennedy]

I'm having exactly the same issue with PureOS (Debian-based). This seems to be an issue with gnome-shell. The following shows up in journalctl -xe after trying to get browserpass-ce to prompt for a password:

Jun 30 21:35:12 Loki gnome-shell[1867]: remove_mnemonics: assertion 'label != NULL' failed
Jun 30 21:35:12 Loki gnome-shell[1867]: remove_mnemonics: assertion 'label != NULL' failed
Jun 30 21:35:12 Loki gnome-shell[1867]: pushModal: invocation of begin_modal failed
Jun 30 21:35:12 Loki gnome-shell[1867]: keyringPrompt: Failed to show modal dialog. Dismissing prompt request
Jun 30 21:35:12 Loki gpg-agent[4298]: failed to unprotect the secret key: Operation cancelled
Jun 30 21:35:12 Loki gpg-agent[4298]: failed to read the secret key
Jun 30 21:35:12 Loki gpg-agent[4298]: command 'PKDECRYPT' failed: Operation cancelled <Pinentry>

It's a pretty weak workaround at the moment, but pinentry-gnome will let you register your GPG password with the gnome keychain.

[maximbaz]

Unfortunately I don't know how I can help, it does seem the pinentry you are using is buggy. If you can set a different pinentry in ~/.gnupg/gpg-agent.conf that will not crash, do so.

pinentry-program /path/to/different/pinentry