Distribution of binary

[Peter Lebbing]

Hi Gniibe,

Thanks for getting back to me so quickly! I've been playing around some
more.

On 11/12/2018 03:33, NIIBE Yutaka wrote:
> As long as it's an experimental use (it's not commercial product) with
> the condition of:
> 
>      * Distribution here means delivery of a limited number of hardware
>        by hand (in person)
> 
>      * Both sides have enough knowledge, and agree it's an experiment
> 
>      * Both sides actually have official Gnuk Token already
> 
> Then, I'd say, it's OK even with 234b:0000.

Ah, okay, that's good to know! That's a really good compromise.

But there might be people who don't have a GnuK yet and might want to
experiment with a Maple Mini with GnuK. Given an explanation of the
risks involved with regard to supply chain (which includes me), they
might still be interested. The biggest hurdle: programming the Maple
Mini if you don't have equipment. If I can give them a Maple Mini with
GnuK but with a VID:PID of 0000:0000, they could build their own GnuK on
Debian stable, which is really simple, and reGNUal their design into it.
Would you be OK with a Maple Mini with GnuK with VID:PID 0000:0000,
purely for the functionality of reGNUal? Note that NeuG did not come up
on the Maple Mini and I haven't investigated why, since I didn't see any
advantage to using NeuG with reGNUal over GnuK with reGNUal.

Another option would be DFU. But I've been struggling with this for a
bit; I'll split off the thread with a mail about that.

> If done for commercial product, I think that both cases (distributing
> a hardware with 0000:0000, distributing a hardware with 234b:0000)
> anyway violate the assumption of USB governance.  In the (ideal) USB
> world, it assumes it is only done by the vendor.

Hehe, yes, 0000:0000 is definitely not okay in general. But I don't care
about that if it works under Linux for a single limited purpose. What I
care about is violating licence or spirit of GnuK and FSIJ.

>> GnuPG was less willing to work with such a GnuK; it reports:
>>> ccid-driver: usb_open failed: LIBUSB_ERROR_IO
> 
> This is because of configuration.  In Debian, for example, it is the
> distribution which arranges udev rules to access the hardware.

PEBKAC. I /had/ configured udev, but it appears something had started
pcscd without my knowledge.[1] It is working now even for GnuPG with a
VID:PID of 0000:0000. Not that I intend anyone use it as that, just
noting that technically, under Linux, it /does/ work.

Cheers,

Peter.

[1] Hypothesis: if you insert a CCID-class device which does not have an
udev rule that says ENV{ID_SMARTCARD_READER_DRIVER}="gnupg", does pcscd
start on a systemd-managed Debian stable? Because I inserted the device
before I wrote the udev rule. Anyway, it's not important, it just
occured to me that might have been it.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.  My key is
available at <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20181212/e13e2de7/attachment.sig>