WebExtensions with firefox sync 1.1

Question

XCOM & XPCOMに基づいた古いFirefoxアドオンを更新し、WebExtentionに再実装しようとしています。この新しいアドオンは、thisに基づいて、一部の情報を安全に交換するためにfirefox sync server 1.1を使用します。これはJ-PAKEを使用しないため、firefox sync server 1.5を使用することはできません。私はサーバとうまくやり取りすることができましたが、プロトコルの第2段階に遭遇しました。

モバイル/デスクトップがv2のJ-PAKEのMSG 1.新規、チャネルIDランダム弱い秘密（4つの文字-Z0-9）からと PINを生成する計算とアップロード： にケース内に二重アップロードを防ぎますIf-None-Match：*ヘッダー が指定されています。これにより、 チャネルが空の場合にのみメッセージがアップロードされます。そうでなければ、要求は412 前提条件失敗で失敗します。これは200 OKと同じとみなされます。 412には、クライアントのデータのEtagも含まれており、 がアップロードされました。

C: PUT /a7id HTTP/1.1 
C: If-None-Match: * 
C: 
C: { 
C: 'type': 'receiver1', 
C: 'payload': { 
C:  'gx1': '45...9b', 
C:  'zkp_x1': { 
C:   'b': '09e22607ead737150b1a6e528d0c589cb6faa54a', 
C:   'gr': '58...7a' 
C:   'id': 'receiver', 
C:  } 
C:  'gx2': 'be...93', 
C:  'zkp_x2': { 
C:   'b': '222069aabbc777dc988abcc56547cd944f056b4c', 
C:   'gr': '5c...23' 
C:   'id': 'receiver', 
C:  } 
C: } 
C: } 

問題は、古い実装がXPCOMオブジェクトを使用している：

var jpake = Component.Classes["@mozilla.org/services-crypto/sync-jpake;1"].createInstance(Ci.nsISyncJPAKE); 

と機能を使用することができますがhereを説明し、発電の世話をしたhere

jpake.round1(singerId, gx1, gv1, r1, gx2, gv2, r2) 

を実装： gx1, gv1, r1, gx2, gv2 and r2。

WebExtentionsにXPCOMオブジェクトを使用する方法はありますか？あるいは、私はAdd-on SDKと、強制的にXPCOM low-level APIを使用していますか？

hereから値をエミュレートするのに、curve25519.jsを使用しようとしましたが、成功しませんでした。

すべてのヘルプは、これはあなたが古典的なアドオン内WebExt foromを使用することができますDevチャンネル上で送信された電子メールで、 おかげ

Answer 1

歓迎され、それは私がわからないんだけど、移行の目的のためのものどのくらい永続的であるか：

Hi all, 
As part of the ongoing changes to the WebExtensions internals, we are working to enable any restartless classic extension (restartless add-ons based on a bootstrap.js file and add-ons created using the SDK) to embed a WebExtension inside them, 
as a path for gradually porting existent addons into a WebExtension and gradually move into the embedded WebExtension any features that has better support as WebExtensions APIs. 

The related bugzilla issues are: 
- "Bug 1252227: Embed WebExtension in Classic Extensions" 
- "Bug 1252215: Expose WebExtension messaging to Classic Extensions" 
- "Bug 1269342: XPIProvider should provide optional embedded webextension instance to classic extensions" 
- "Bug 1269347 - Expose the optional embedded webextension as a builtin SDK module" 

Any classic extension that is going to use this feature will have, besides the classic extension code which is running with "browser" privileges, an embedded webextension running inside it (with the same addon id of the container addon) and the classic extension code will be able to exchange messages with any of the available embedded webextension contexts 
(e.g. a background page, a popup page or a content script) using a subset of the WebExtension `runtime` API (in particular it will be able to subscribe listeners to `onMessage` and `onConnect`). 

All the embedded webextension resources will be loaded from the `webextension/` sub directory of the container add-on resources (and the embedded webextension will not be able to load anything from outside that directory, 'cause it is going to be its base URI). 

As you can imagine (many thanks to Andrew for pointing it out during our brief planning chats), this new feature is probably going to need some sort of special handling by both AMO and the addons linter, and I'm starting this email thread to collect more feedback and ideas. 

Some initial thoughts about the `addons linter`: 

- the addons linter should be able to recognize hybrid addons and do not confuse hybrid addons for a pure webextension addon 
    (e.g. the hybrid addons will have potentially more privileges that the ones listed in the webextension manifest file) 

- the addons linter should check that there are no conflicts betwen the metadata in the install.rdf/package.json and the metadata in the `webextension/manifest.json` file. 

- the linting of the webextension part can probably ignore the file which are not in the `webextension/` subdir, because the webextension will not being able to load anything from outside that directory 

- the linting of the classic extension part needs to lint all the files in the addon (because the resources in the `webextension/` can be accessed from the classic extension part of the addon) 

- the linting of the classic extension part should warn the reviewer on any suspicious usage of files manipulation? (can the classic extension part potentially change the packages resources? e.g. the manifest file or a background script, loaded in the embedded webextension and trick the linter) 

Some initial thoughts about `AMO`: 

- the hybrid addons submission on AMO should be supported, e.g. for signing or listing (probably not a lot of changes are needed, it should be recognized as a classic extension addon and the addon metadata retrieved from the install.rdf file) 

- during the add-onreview, should AMO highlight when an addon is an hybrid add-on? 

Any further thoughts, feedback or ideas are absolutely welcome.