Bug#911189: src:gpgme1.0: please ship gpgme-json with native messaging hooks for chromium and firefox

[Daniel Kahn Gillmor]

Package: src:gpgme1.0
Version: 1.12.0-1
Severity: wishlist

as of gpgme 1.12.0-1, GPGME ships a javascript binding that works with
so-called "Native Messaging" in both chrome and firefox.

we should ship this as a separate binary package, along with the
appropriate extension manifests.

for more details, see lang/js/README in the GPGME sources, and the
following web references:

Firefox:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_manifests

Chrome:
https://developer.chrome.com/extensions/nativeMessaging

I plan to work on this, but if anyone wants to send patches before i
get to it, i'd be happy to get them too :)

at the moment, i assume that we just would disallow access to any
extensions, until some extension shows up that wants to use it.

We probably also need to build gpgme.js, which will require working
with node.

i don't know how we'll get the test suites to run cleanly yet either.

--dkg

-- System Information:
Debian Release: buster/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

[Dr. Oliver Muth]

Package: libgpgme11
Version: 1.12.0-4~bpo9+1
Followup-For: Bug #911189

Dear Maintainer,

the Firefox and Chrome extension Mailvelope needs gpgme-json.
The extension provides GPG encryption/decryption via webmail.



-- System Information:
Debian Release: 9.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/3 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE:de (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libgpgme11 depends on:
ii gnupg 2.2.12-1~bpo9+1
ii gpg 2.2.12-1~bpo9+1
ii libassuan0 2.5.2-1~bpo9+1
ii libc6 2.24-11+deb9u3
ii libgpg-error0 1.26-2

Versions of packages libgpgme11 recommends:
ii dirmngr 2.2.12-1~bpo9+1
ii gpg-agent 2.2.12-1~bpo9+1
ii gpg-wks-client 2.2.12-1~bpo9+1
ii gpgsm 2.2.12-1~bpo9+1

libgpgme11 suggests no packages.

-- no debconf information

[Daniel Kahn Gillmor]

Hi Maximilian--

On Wed 2019-07-10 10:12:37 +0200, Maximilian Krambach wrote:
> I have been tasked to prepare "debian packages" for the gpgme-json browser
> integration, to ease installation of native messaging between gnupg and browser
> extensions.

great, thanks for working on this! I assume you're aware of
https://bugs.debian.org/911189 (in cc as well). That's the best place
to talk about the debian packaging for this stuff.

> I'm working on a patch for salsa.debian.org/debian/gpgme/, as I think this is
> probably the best place for it.

Sounds reasonable to me.

> Basically, the two packages (chromium-gpgme and firefox-gpgme) just need to
> ensure that the gpgme-json binary ships, and that a configuration file is
> present at paths the browsers like.
>
> My question:
> Is it okay and maintainable to add "approved" extension ids (in this case,
> mailvelope) to these configuration files?
>
> In the end, it is an authorization between the extension(s) and the browser
> (based on ids assigned by the browser publisher).
> gpgme-json itself does not care who communicates with them (as long as it stays
> the same actor). Still, I have the feelings that some link between worlds is
> created that may not be desired.

This is an excellent question, and one that i did not figure out the
answer to when i was briefly researching the situation.

I wonder whether it makes more sense (and whether it's possible) to ship
the gpgme-json binary and wrapper files in one package, without any
"approved" extension IDs. And then in the extension-specific package
(e.g. the "mailvelope" package), include the approved extension IDs.
Does that even make sense? I don't remember the exact layouts expected.

Thanks for stepping up to do this work!

--dkg

[Teemu Ikonen]

Has there been any progress with this bug?

gpgme-json is already built in the Debian sources, so adding it to a
(possibly separate) binary package should not be a big problem. Are
there tests failing or missing?

Best,
Teemu

[Bernhard Reiter]

Hello,

sorry the work from our side got stuck.
We (from Intevation) will be looking into it.
Timeframe: first look next week, fix can take a few more days.

From my rough understanding: The extension ID would need to go into the
personal configuration of the webbrowsers and cannot be configured globally,
could it?

What is the standard solution for such a situation in Debian?
(Hints for this point may help us to get this solved faster.)

Best Regards,
Bernhard

[Sascha Wilde]

Hello,

as promised by Bernhard in his mail we stated to work on this again.

As a first step I created a merge request to deploy gpgme-json together
with the library:
https://salsa.debian.org/debian/gpgme/-/merge_requests/1

Next I will look into creating specific packages with browser
manifests...

Cheers
sascha
--
Sascha Wilde OpenPGP key: 4365844304077279
http://www.intevation.de/ http://www.intevation.de/~wilde/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

[Sascha Wilde]

Sascha Wilde <wi...@intevation.de> writes:
> As a first step I created a merge request to deploy gpgme-json together
> with the library:
> https://salsa.debian.org/debian/gpgme/-/merge_requests/1

After realizing that the current MR breaks multi arch compatibility for
the library I revised it and added a new -bin package, which for now
only provides gpgme-json.

I also added a rudimentary man page for gpgme-json.

> Next I will look into creating specific packages with browser
> manifests...

I have implemented that and created a new merge request:
https://salsa.debian.org/debian/gpgme/-/merge_requests/2

In addition to the new -bin package two more new packages are created:
- libgpgme-chromium-native-messaging
- libgpgme-firefox-native-messaging

Each of the packages provides a native messaging manifest for the
respective browser which allows using GPGME via gpgme-json for a set of
well known extensions. For now the only supported extension is
mailvelope but more could be easily added later on.

Upstream encourages distributors to create manifest packages for their
distributions, therefor I think adding these packages here is The Right
Thing To Do™.

Some remarks/requests for comment:

1. Currently the manifest installed for chromium is installed as:
/etc/chromium/native-messaging-hosts/gpgmejson.json

Upstream recommends a slightly different file name schema[0]:
/etc/chromium/native-messaging-hosts/com.my_company.my_application.json

As you can see, following this recommendation would mean adding a
domain. I'm not sure whether to follow this scheme, and if so, which
domain to add: org.debian, org.gnupg or ..?

2. The manifest for chromium is automatically marked configuration file,
as it resides under /etc, which IMO is correct. A sysadmin might
want to edit the manifest, e.g. to add the IDs of further
extensions.

However: the manifest for firefox is installed as

/usr/lib/mozilla/native-messaging-hosts/gpgmejson.json

(This is dictated by firefox searching for global manifests in that
place). So it is not automatically marked as configuration. And as
of compatibility level 12 of debhelper it seems to be no longer
possible to mark the file as configuration manually (dh_installdeb
simply ignores any debian/package.conffiles.

Is there a way to work around this? For the reason given above I
think the manifest should be marked as a conffile for firefox,
too...

cheers,
sascha

[0] https://developer.chrome.com/apps/nativeMessaging

[Sascha Wilde]

Hello,

so far I haven't received any reply to either my pull request or my
questions in the bug report issue from Fri, 11 Sep 2020 15:38:13 +0200.

I would still appreciate input on my work, especially if there is
anything I need to do to make the changes acceptable for the Debian
package.

Thank you for your support,
sascha

[Daniel Kahn Gillmor]

On Thu 2020-10-01 14:05:59 +0200, Sascha Wilde wrote:
> so far I haven't received any reply to either my pull request or my
> questions in the bug report issue from Fri, 11 Sep 2020 15:38:13 +0200.
>
> I would still appreciate input on my work, especially if there is
> anything I need to do to make the changes acceptable for the Debian
> package.

Hi Sascha--

thanks for this, and sorry for my delay in responding to you. It's on
my queue, and i'll try to look at it soon.

If anyone else on the debian GnuPG packaging team wants to take a look
and give feedback, i'd appreciate it too!

--dkg

[Andrew Gallagher]

Has there been any progress on this? Ubuntu currently ships an
equivalent package, although it doesn't contain the firefox manifest
(presumably because of the config file issue mentioned by Sascha above).

From my understanding, a per-extension manifest file is intended to be
shipped as part of the webext-* package for the extension, and not with
the native helper. Compare with webext-browserpass:

```
$ dpkg -L webext-browserpass | grep native-messaging
/etc/chromium/native-messaging-hosts
/etc/chromium/native-messaging-hosts/com.github.browserpass.native.json
/usr/lib/mozilla/native-messaging-hosts
/usr/lib/mozilla/native-messaging-hosts/com.github.browserpass.native.json
```

Confusion may have arisen because most webextensions (such as
browserpass) ship the extension and the native helper app in the same
package, making it unclear where the manifest belongs when the native
helper is in a separate package (as gpgme must if it is to be shared
between applications).

This would imply that the correct place for the manifests is in a
notional `webext-mailvelope` package, where they SHOULD NOT be marked as
config. Packaging mailvelope properly would greatly improve the user
experience (see e.g. https://github.com/mailvelope/mailvelope/issues/628
, https://github.com/mailvelope/mailvelope/issues/699 ).

--
Andrew Gallagher

[Teemu Ikonen]

Building gpgme by hand and and installing gpgme-json manually every
time after gpgme updates is getting rather tedious.

The MR by Sascha Wilde at
https://salsa.debian.org/debian/gpgme/-/merge_requests/2 works
perfectly here. This bug is three years old and the patch more than a
year, could someone please have a look at merging it?

Best,
Teemu

[Ángel]

Sascha Wilde wrote:
> /etc/chromium/native-messaging-hosts/gpgmejson.json
>
> Upstream recommends a slightly different file name schema[0]:
> /etc/chromium/native-messaging-hosts/com.my_company.my_application.json
>
> As you can see, following this recommendation would mean adding a
> domain. I'm not sure whether to follow this scheme, and if so, which
> domain to add: org.debian, org.gnupg or ..?

I think the upstream org.gnupg.gpgme would be more fitting, but since
this is a distro, just the package name would work imho.

>
> 2. The manifest for chromium is automatically marked configuration
> file,
> as it resides under /etc, which IMO is correct. A sysadmin might
> want to edit the manifest, e.g. to add the IDs of further
> extensions.
>
> However: the manifest for firefox is installed as
>
> /usr/lib/mozilla/native-messaging-hosts/gpgmejson.json
>
> (This is dictated by firefox searching for global manifests in that
> place). So it is not automatically marked as configuration. And as
> of compatibility level 12 of debhelper it seems to be no longer
> possible to mark the file as configuration manually (dh_installdeb
> simply ignores any debian/package.conffiles.
>
> Is there a way to work around this? For the reason given above I
> think the manifest should be marked as a conffile for firefox,
> too...

Install the file in /etc/, e.g. /etc/mozilla/native-messaging-
hosts/gpgmejson.json and make a symlink to that from
/usr/lib/mozilla/native-messaging-hosts/

I'm not convinced this should be a conffile, though. Couldn't other
externsions be added with a new file?

So you could install webext-mailvelope-gpgme if you wanted mailvelope
with GnuPG backend, and webext-foobar-gpgme if foobar extension should
be enabled access to gpgme

[Ángel]

I have tested https://salsa.debian.org/debian/gpgme/-/merge_requests/1
and it works fine.
I would however name the new package gpgme-json, not libgpgme-bin

The package is only providing gpgme-json(1). If it is going to ship
more binaries in the future, it can always be replaced. If someone is
told they need gpgme-json the expected package name is 'gpgme-json',
not libgpgme-bin. Plus, that lib prefix is even more confusing.

Even the description (“This package contains the gpgme-json binary to
access GPGME...”) seem to ask for that name.

That is the only nitpick I have. It "just works". :-)

The debian/changelog would need updating, and rebased on top of gpgme
1.18 (bookworm/sid) from the current 1.14.

[Norbert Lange]

How about just playing the binary into a package name "gpgme", like Fedora does
https://packages.fedoraproject.org/pkgs/gpgme/gpgme/fedora-rawhide.html#files