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.

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

Workaround for lack of NPAPI support in Google Chrome #102

Open
1 of 3 tasks
kylehuff opened this issue May 27, 2014 · 4 comments
Open
1 of 3 tasks

Workaround for lack of NPAPI support in Google Chrome #102

kylehuff opened this issue May 27, 2014 · 4 comments

Comments

@kylehuff
Copy link
Owner

In order to continue to supporting Google Chrome after their discontinuation of NPAPI, WebPG will need to use "Native Messaging".

Native Messaging is a mechanism whereby request/response messsages are sent/collected using chrome.runtime.sendNativeMessage or via a native messaging port.

The underlying WebPG binary component has been designed to support Native Messaging, however, it requires that a manifest file (and registry key in Windows) be installed on the host system along with a binary. An installer will be necessary in order to accomplish this.

The contents of said file are as follows -

{
   "name": "org.webpg.nativeHost",
   "description": "WebPG Native Messaging Host",
   "path": "C:\\Users\\{USER}\\AppData\\WebPG\\webpg_message_host.exe",
   "type": "stdio",
   "allowed_origins": [
     "chrome-extension://<EXTENSION_ID>" // Production extension ID
     "chrome-extension://<EXTENSION_ID>" // Development extension ID
     "chrome-extension://<EXTENSION_ID>" // Offline extension ID
  ]
}

File Location (Proposed):

  • Linux: ~/.config/google-chrome/NativeMessagingHosts/org.webpg.nativeHost.json
  • OSX: ~/Library/Application Support/Google/Chrome/NativeMessagingHosts/org.webpg.nativeHost.json
  • Windows: C:\Users\{USER}\AppData\WebPG\nativeHost.json

Additional install items

  • Linux: ~/bin/webpg/webpg_message_host
  • OSX: ~/bin/webpg/webpg_message_host (?? better location in OSX)
  • Windows
    • C:\Users{USER}\AppData\WebPG\webpg_message_host.exe
    • C:\Users{USER}\AppData\WebPG\libassuan-0.dll
    • C:\Users{USER}\AppData\WebPG\libgpg-error-0.dll
    • C:\Users{USER}\AppData\WebPG\libgpgme-11.dll
    • Registry key: HKEY_CURRENT_USER\SOFTWARE\Google\Chrome\NativeMessagingHosts\org.webpg.nativeHost
      • Value: C:\Users\{USER}\AppData\WebPG\nativeHost.json

Points of discussion -

  • File locations
  • binary naming convention
  • Should the release version be included in the path or binary naming scheme?
  • More?

Objectives -

  • Easy to install
  • Should be easy to uninstall
  • Aware of system vs. user installation
  • As least "hokey" as possible.

Ancillary items -

  • Extension needs to be modified to in order to communicate with the host (assigned: kylehuff)
  • Need to hook into installation events of extension to catch uninstall
  • PGPMime methods need to be moved from webpg-npapi to libwebpg (completed with kylehuff/libwebpg@e31f59c)
  • Others?

References -

Persons tagged in this issue -

@dhyannataraj
Copy link

Hi!
I have a dumb question:
What should I build to get webpg_message_host executable?
I did not find any unswer.
Or it is just a concept with no real executable available?

@dhyannataraj
Copy link

Oh, I found https://webpg.org/download/webpg-native-host/archive/ installers, but not source code... I do not like to download binaries... Is code avalable?

@dhyannataraj
Copy link

dhyannataraj commented Sep 28, 2017

I found an answer. It took me a while (I was ready to write native host of my own)
webpg-native-host is a part of libwebpg project (surprise!)
once you build it, you get webpg executable that can work in native host mode.

@deed02392
Copy link
Contributor

Should the release version be included in the path or binary naming scheme?

I think not. Installers can determine installed version and deal with accordingly. Users can inspect binary attributes/properties to determine version numbers (which will probably be more precise anyway). Besides, cannot think of a good use case for exposing the version number in path or filename, and doing so increases risk of mistakes being made when installing, updating or removing files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants