kylehuff / webpg-npapi Goto Github PK

Firefox does not make bundled plugins private to the extension, so we need a compile time flag to limit the plugins use to the extension background and content script pages.

Failing that, a website could call the methods in the plugin and retrieve the result if a user has their passphrase cached.

Only the packaging extension should be able to access the plugin methods.

After executing a key edit method in some windows 32 environments the method never returns, thus locking the browser.

More than likely caused by the case switch never allowing the edit method to break out of the loop.

I see two option:

1. developer have to install GnuPG in order to compile webpg
2. each user that installs webpg have to install GnuPG on his PC.

Which option is correct?

I see compiled binaries here that webpg is depending on. So I guess that GnuPG library is needed only during compilation when header files are required. But at runtime webpg links with dynamic libraries and doesn't require GnuPG installed.

Hello.
I built the library according to https://webpg.org/docs/webpg-npapi/. After I had added extention to chrome I got "WebPG NPAPI Plugin valid: undefined; version undefined". Code, which uses the extention below:

     webpg.plugin = document.getElementById("webpgPlugin");
    console.log("WebPG NPAPI Plugin valid: " + webpg.plugin.valid + "; version " + webpg.plugin.version);

What did I do wrong?

within the method gpgDecrypt, there is no detection for GPG_ERR_NO_DATA or GPG_ERR_INV_ARMOR, which consequently results in a segfault when retrieving and releasing the nonexistent data buffer.

Google has discontinued NPAPI support, WebPG is not working on latest Chrome browser in our Linux boxes.
Are you planning to implement PPAPI for Chrome compatibility?
thanks in advance

Hello,

I built webpg-npapi in Win 7 64. "gpgImportExternalKey" works well in Win 7 32 but returns error in Win 7 64.

We need the ability to export public keys. (with strong emphasis on the public key part)

Hello, Kyle

I see here compiled binaries of liberror, libassuan, ligpgme. My question is how did you get them compiled on Windows? My goal is to update gpgme with custom functionality. I've updated gpgme sources and successfully rebuild gpgme library on linux, but I can't do the same on windows.

All these libs (liberror, libassuan, ligpgme) are open-source projects based on gnu make utility. And none of them includes VC++ project files.

The most obvious way to build them is to run "./configure && make" in MinGW or Cygwin environment. But I doubt if I can use binaries compiled with gcc/g++ in VC++ projects (here is a question from a guy who met this issue).

The next option I see is to create VC++ project manually by adding all *.h, *.c, *.cpp files into the project. I think it is very shaky approach.

It would be great if there is way to pass Makefile directly to vc++ compiler, but I didn't manage to find it. Also this approach will require to run "./configure" script in order to get Makefile. I don't think this is possible in the Windows CLI.

Thanks in advance for your help

The build instructions for windows are incorrect, or perhaps there is something else wrong. In step 2, you say to use:

cmake --build . --config MinSizeRel --target webpgPlugin

But, for me, at least, devenv errored out, saying the solution was invalid. Changing the line to:

cmake --build . --config MinSizeRel --target webpg

... made it work. Also notable is the fact the output file is named "npwebpg-ext-v0.6.5-WINNT_x86-msvc.dll". However, when I dropped that file in my Extensions folder, I was able to install the extension and things appear to be working.

Of course, I probably wouldn't have built from source if the Windows binaries on the download page were working... :P

Tested on IceWeasel 7.0.1 and Chromium 15.0.871.0~svn20110904r99583.

Calling getPublicKeyList() blocks longer that I want to wait (I tried for 5 minutes, no user would wait that long in a real usecase).
Having only few (one) public keys in my GNUPGHOME solves the issue, but well, there are "only" 517 keys in there, nothing unusual for a regular OpenPGP user.

Any ideas how to debug this further?

gpgconf_detected is never refreshed and could be stale. need to make this more up-to-date.

Hi,

After signing a piece of text with

gpgSignText([signing_key]), _message, 1);

gpgVerify(_message_signed);

{
    data: "-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.10 (GNU/Linux)\n\niQIcBAEBAgAGBQJQ5hhUAAoJEAUkJ3wRQIgAOTkP/iEYfbilHGmlvBh3pAEUcp31\ndrw1PF9RRDUR+3pAId66VZ8m9AofSNy3WqQYahpMVKOSEVkCKodv8qeV1m41PGff\n0wNKPrH8GuyEdfuHdUbXredWHPpFJxuVvGca6Dz0W+pZXZOoALOahyvYAgENDawL\nIUwlOXYxBxjQ4lUZBgLTiyMQQFdfqWaBOjZsKpUrW/wg+9ROVobnKI/dFxdU2IRs\nGNOd0GNP9yezEcDMVvTL1xzGfilfONwu2nltvWHTsicULBaeP8fNWeHks311cH1D\n3QMHkYB31k8FLWnRCBTtB8pGS7i0z4RNJ8T4tZltsENB3x5oIRaM9PkvN7SSzFGc\nFbzVccDrI68HYaHlTvC/8rqvbQGUXaUdYoE6AGA/MT9O4g8OiLivGOF0+VfoK4kS\nfmCqsjpjthmBKIBRDh6iT1ud7Mi/D/rqljXgLp+N05UEPsTrOZiwRI3MSU9Qtfum\nSC8aiF3Vdlo67o/ivyykZmiQ1VgfxcJi8wTZOIz+2Ix5APoPmVHMKI4o/3PzJj7V\namJyIZwLr6UxkQuanYCb7nq6bNqI9sQVTebbmVHFiCMKautx4tGfvC2lJaFDjX0w\n7dZVmzwZR09ilLllDYbjDkCwysjBj/PFNv2+0U6KxzE4laaXIEC7348YkMggLtRQ\nGiUHr5Xampvq8AKbEvfE\n=qgfi\n-----END PGP SIGNATURE-----\n",
    error: "false",
    message_type: "detached_signature",
    signatures: {
        0: {
            expiration: "0",
            fingerprint: "0524277C11408800",
            status: "BAD_SIG",
            timestamp: "0",
            validity: "unknown"
        }
    }
}

but if I call

gpgSignText

I use Debian Squeeze x64, gpg v1.4.10, gpg2 v2.0.14, libgcrypt v1.4.5.

Cheers ;)

Heya,

webpg-chrome calls gpgGetPreference('default-key') and gpgGetPreference('encrypt-to'), but both calls give 'Invalid crypto engine' on my system. What info do you need to debug this?

The system is a Debian unstable amd64 with:
libgpg-error-dev 1.10-2
libgpg-error0 1.10-2
libgpgme11 1.2.0-1.4
libgpgme11-dev 1.2.0-1.4

The method gpgGenSubKey fails to pass the keyid to the threaded method threaded_gpgGenSubKey() - consequently, you can only add subkeys to the first key in the keyring.

When using the enable or disable methods for keys, the iter must not be getting reset or something because you can only use the method one time per plugin lifecycle.

The return the property gpg_status is never refreshed, so could be stale.

The linking of libgpgme to gpgconf is FUBAR, causing 32bit Linux installations to not detect gpgconf.

Downstream bug kylehuff/webpg-chrome#73 relies on this fix.

Thanks for reporting this and testing the fixes Sentynel!

The method gpgVerify calls gpgDecryptVerify(<message to decrypt/verify>, <use_agent 0>), which attempts to both decrypt the message, as well as verify the data. This catches instances where the message is a signature, or an encrypted and signed message. Before the operation is executed, the method poisons the environment variable GPG_AGENT_INFO in order to prevent the passphrase dialog from displaying, as we don't want to actually decrypt the data, just get information about any signatures found.

The problem is when using gpg2 as the binary for gpgme - gpg2 prompts for the passphrase regardless of the value of GPG_AGENT_INFO, since gpg2 requires use of the agent.

To get around this, we will need to disable use of the agent temporarily so we can do what we need to do.

Now for the tricky part(s) -

Applying a gpgme_passphrase_cb on the context will only work for gpg1, and even if we send an arbitrary passphrase via the callback, it will cause messages using symmetrical encryption to fail with a missing key error, since the passphrase is the key...

For gpg2, we could set the mode to batch, and assign an arbitrary passphrase using "passphrase ", but that will have the same issue with symmetrically encrypted messages.

To catch all instances (gpg1 and gpg2), we will need to assign a gpgme_passphrase_cb to send an empty passphrase, and also set the gpg.conf options as follows:

batch
passphrase ""

This should prevent errors, and ensure that the return is always GPG_ERR_BAD_PASSPHRASE, even with symmetrically encrypted messages.

The gpgVerifyDecrypt() method needs to poison the environment variable GPG_AGENT_INFO when doing an automated verification (this is one of a number of steps in order to prevent the request from prompting the key-agent to request a passphrase), and when the environment variable is restored after the operation, it foolishly assumes that GPG_AGENT_INFO was ever anything but NULL.

This unfortunately causes a segfault when there is no instance of GPG_AGENT_INFO in the current environment.

We need a gpgGetPreference() method

There is currently no way to just verify data, the verification happens along with the decrypt (gpgme_op_decrypt_verify).

This is bad because we cannot readily identify the difference between a message that is signed or a message that is encrypted (the both begin with "-----BEGIN PGP MESSAGE-----"). This presents a problem because we don't want to be prompting the user for a passphrase to decrypt data that is found inline on a webpage -- that should only happen when the user performs a requesting action and is aware that a decrytion attempt is about to be made using their secret key.

There is an issue with the resetting of the static integer "step", causing the trust assignment value to only apply one time per webpgPlugin instance.