macos: lacking automatic detection of serial port device path

[quite]

In 0.0.2 we decided to remove the automatic detection of TKey serial port device path on Macos. The implementation (https://github.com/bugst/go-serial/blob/master/enumerator/usb_darwin.go) was not in pure Go and required the use of Golang's Cgo -- that is, calls to C code. To compile it, Macos/Darwin libraries/headers/source code needs to be available (and C compiler is used). Because of this, it became complicated to reproducibly build release binaries (and also to build them all on one platform). We decided to prioritize reproducible builds of these binaries, which are used by customers to verify that their TKey is genuine.

The consequence of removing automatic TKey detection on Macos is that after plugging in the TKey, user has to first list the available serial ports using something like ls -l /dev/cu*, and then run the verification using the relevant serial port like: tkey-verification verify --port /dev/cu.usbmodemN). There will typically only be 1 /dev/cu.usbmodem present, unless the user has some other similar serial-port based devices plugged in. Other platforms does not (usually) require the use of the --port option.

One idea to work around this was to just have the program look for any /dev/cu.usbmodem* devices and if exactly 1 is found, then use it. This runs into the risk of talking to a serial port which does not belong to a TKey. However unlikely, this does not seem like a nice thing to do. The point of using the enumeration of the go-serial library is that it can list serial ports that belong to a USB device with a specific, known VendorID:ProductID (1207:8887 being Tillitis').

The path forward to enable auto-detection on Macos is probably to think through and implement a way to conveniently build reproducible Macos releases (of both architectures) when using CGO (ideally getting the two other platforms built at the same time). Or, could there be a pure-Go way to find out about the origins of a device-node on Macos?

[quite]

It is probably possible to call /usr/bin/ioreg with the right options and parse the output, probably having to dig a second time as well. Not very nice and maybe not reliable. And that's parsing some kind of tree hierarchy realized in ASCII (or if using -a, parsing xml...).

[udf2457]

FYI system_profiler can provide JSON output which might be more attractive than parsing XML 😉

So something along the lines of system_profiler -json SPUSBDataType

[dehanj]

@udf2457 Great suggestion, we will look into it!

[dehanj]

Been looking into this a bit now;

There seems to exists a few different options, (1) ioreg or (2) system_profiler.

(1) ioreg -r -c IOUSBHostDevice -l -x
One can look for the key IODialinDevice which provides the path to the serial device, for example /dev/tty.usbmodem1101. It is also possible to find the USB PID and VID. However, once you add the -aflag to get the output in XML, the VID and PID seems to be removed?! Not sure why. The XML output is huge, and needs to be parsed well, and it is not completely trivial how to know it is the path to the right serial device.

(2) system_profiler SPUSBDataType -json
This gives nice output in json, however does not seem to provide the path to the serial port. So, this is not so useful on its own. It is however very useful to confirm that a device of a certain PID and VID is connected to the computer.

So a solution could be to combination of the two above, even if it will be a lot of parsing and XML/JSON structs.

Maybe a good enough solution is to use (2), see that the correct device is connected to the computer. If there is only one, try to connect to it. If there are two or more devices, print them out for the user to select using --port.

There might be other options as well...