Question

我正在尝试更新基于XUL＆amp ;;的旧Firefox附加组件。 XPCOM并在WebExtention中重新实现它。这个新的插件将使用firefox sync server 1.1根据this安全地交换一些信息。我不能使用firefox同步服务器1.5，因为这不使用J-PAKE。我已经能够很好地与服务器通信，但现在在协议的第二步绊倒了。

移动/桌面从随机弱密钥生成PIN（4个字符a-z0-9）和通道ID，计算和上传J-PAKE msg 1. v2：To的新功能防止重试时双重上传，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？

我尝试使用curve25519.js来模拟here中的值，但没有成功。

欢迎任何帮助，感谢

Answer 1

这是在开发频道上发送的电子邮件，您可以在其中使用经典插件中的WebExt forom，它意味着过渡目的，我不确定它的永久性：

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.

使用firefox sync 1.1的WebExtensions

1 个答案: