[rb-general] [Gnuk-users] Reproducible builds for gnuk?

[Peter Stuge]

(I'm not subscribed to gnuk-users.)

Vagrant Cascadian wrote:
> > It would be nice if it was possible to compile Gnuk as a reproducible
> > build.
> 
> Indeed!
> 
> We had a breif discussion about pakaging it for Debian, which has
> infrastructure for automated reproducibility testing, but the main
> blocker seemed to be issues around the USB ID enbedded in the binary,
> and maybe the unique serial as well:
> 
>   https://lists.alioth.debian.org/pipermail/gnuk-users/2017q4/000603.html

That makes no sense to me. I began developing with USB in 2006,
but have admittedly not bothered much with USB-IF yet.

One one hand I am curious to know whether FSIJ is a full USB-IF
member or if they "only" signed the VID-Only agreement, on the
other hand it shouldn't matter.


The purpose of the agreement is to ensure that VID assignees only
use their own VID, and, perhaps more importantly, that they do not
sell PIDs, really nothing else. USB-IF had problems with VOTI back
in the day. See http://www.voti.nl/docs/usb-pid.html

Several USB chip manufacturers provide customers with a PID "under"
the manufacturer VID on request. This is in the interest of everyone,
because a microcontroller with USB hardware costs less than 1¤, while
a VID costs $2000 (or more, I haven't looked in a while).

OpenMoko paid for a VID but since their product development discontinued
they offer PIDs to free and open source projects at no cost, under some
conditions. They are legally experienced, have had no trouble with the
USB-IF so far, and I don't see any reason why they would. They've
assigned a fair number of PIDs so far. See
http://wiki.openmoko.org/wiki/USB_Product_IDs

Here are my common sense points:

1. I don't see why a given (unchanged) Gnuk firmware source would
ever be built with different VID+PIDs. VID+PID is a unique device
identifier, the definition of a device is the firmware behavior.
(Strictly speaking, there are more: bcdDevice specifies a "device
version" which may mean the same VID+PID with differen bcdDevice
numbers behaves differently. That's fine. The device manufacturer
writes a driver (or not, if using a standardized device class)
that works, that's all.)

2. I don't see why USB-IF would care at all whether Gnuk firmware
images are distributed with or without FSIJ VID+PID. If anything,
I expect the USB-IF to prefer that identical firmware images *do*
contain the appropriate VID+PID. It makes no sense for *end users*
to deal with VID+PID patching:

At best, the user successfully patches in the single correct VID+PID
combination out of 2^32, and everything works just like if the VID+PID
was included in a binary. (Oh, and thosee two 16-bit numbers have to
be known by - ie. somehow distributed to - the user for that to happen.)

At worst, the user fails to set that one correct combination, and the
device does not work. This scenario is clearly *not* in the interest
of the USB-IF, nor anyone else. ;)


> The best way forward seemed to be to figure out a way to build a
> Gnuk binary with an empty placeholder for USB ID/serial and a way
> to inject them when installing to the actual device.

I don't think that makes any sense at all, but if that's what people
want to do then that's what people will do... :\


//Peter