[Gnuk-users] Gnuk 1.2.6 / NeuG 1.0.6 / Chopstx 1.5 / Fraucheky 0.5

[Daniel Kahn Gillmor]

On Mon 2017-10-16 10:56:58 +0900, NIIBE Yutaka wrote:
> The agreement is available (it's not FSIJ specific) from USB.org.

oof, what a complicated and annoying arrangement :/

> Is it acceptable for users, my preparing of some tool which generates
> final binary from binary template?  I mean, we will distribute binary
> without VID:PID, and it will be an end user who will put the VID:PID
> at the field.

This seems like a sensible way around the problem to me, but i'm not a
lawyer :)

I note that debian already distributes that VID and PID though, right?
Just not in the firmware explicitly:

0 dkg at alice:~$ grep -A1 Gnuk /lib/udev/rules.d/60-scdaemon.rules
## Gnuk Token
SUBSYSTEM=="usb", ATTR{idVendor}=="234b", ATTR{idProduct}=="0000", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg"
0 dkg at alice:~$ 

As long as you're not somehow enjoined from shipping this set of four
octets in *any* combination as a result of your agreement with USB-IF
(which seems like it would cause trouble for your work on scdaemon) it
seems fine to me to have a firmware image that ships with a slot
designed to hold the VID:PID, and to have that slot filled in by an
argument to the firmware installer tool.

That would also presumably help us verify the reproducibility of the
Gnuk firmware as well (because we wouldn't see a difference based on
different VID:PID options if the firmware we're shipping has a standard
(fixed) placeholder for those values).

thanks for helping explain this complicated situation!

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/gnuk-users/attachments/20171017/0550d15a/attachment.sig>