[pkg-gnupg-maint] Bug#911189: Bug#911189: gpgme-json packaging

[Daniel Kahn Gillmor]

On Thu 2024-08-08 20:49:42 +0200, Sébastien Noel wrote:
> Mailvelope has 2 "backends", one is OpenPGP.js, where it works without 
> interacting with the local GnuPG install and the keys are stored in the 
> browser's local folder. This just works, today, without change in any 
> gnupg component.

thanks, that's great to hear.

> But I'm more interested in the second backend where it use the local 
> GnuPG install, so I can access keys stored on hardware token.

I see -- so your goal here in particular is for mailvelope to have
access to secret key material that is backed by a hardware token.  is
that right?

And, afaict, Mailvelope itself is *not* in debian, right?

Most browsers already permit some kinds of access to hardware-backed
asymmetric secret key material, via their PKCS#11 stacks, but that
tooling doesn't necessarily do what OpenPGP needs specifically.

I worry as well about secret key access because with GnuPG, secret key
access to hardware-backed secrets typically is gpg → gpg-agent →
scdaemon (possibly also involving pinentry and pcscd).

Now we're talking about browser → gpgme-json → gpg → gpg-agent →
scdaemon (+ maybe pinentry and pcscd). This is kind of a teetering
edifice of tech, with lots of ways for each layer to fail -- either
failing open (creating a security concern) or failing closed (creating a
usability concern).

Has mailvelope considered any other simplifying approach to talking to
hardware-backed asymmetric secret keys?  Does it depend on the specific
hardware?

> But to communicate with GnuPG the Mailvelope browser plugin needs the
> gpgme-json binary (+ a json manifest that tells the browser "open the
> gates, it's ok").

What are the other consequences of "opening the gates" of the browser in
this way, so that parts of it can access or manipulate GnuPG directly?
Can we clarify those risks clearly in the package description?

> That's what i'm using, and trying to push to src:gpgme1.0, so that i
> can stop to maintain my own "fork"

understood, i can see why you'd want to do that.

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 324 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20240814/64c4119f/attachment.sig>