Stuart Henderson wrote:
> I don't think there's much else you can do if you want to run this on
> OpenBSD.
>
> Does it not also need access to some ugen or uhid device node as well as
> /dev/usbX?
I am afraid /dev/ugen* also needs its permissions adjusted. I have
updated the README to address this. I have also included some
workarounds for an upstream bug I have just discovered.
> The license marker comment should use the more restrictive license then,
> not MIT.
I have switched to GPL-3-0-or-later since it is the most restrictive of
the bunch.
> As a special case, I would suggest using sed -i rather than patching
> files with names embedding a version number e.g.
>
${WRKDIR}/modcargo-crates/nitrokey-sys-*/libnitrokey-*/libnitrokey/hidapi/hidapi.h
> (do you really need to patch what looks like a comment line in the other
> patch?)
I have removed the patches I had included and replaced them with a sed
command in the Makefile. Maybe there is a prettier way to accomplish the
same thing. I am open to suggestions.
Patch is attached.
diff -uar nitrocli.old/Makefile nitrocli/Makefile
--- nitrocli.old/Makefile Thu Nov 9 03:21:39 2023
+++ nitrocli/Makefile Thu Nov 9 14:58:43 2023
@@ -9,7 +9,7 @@
MAINTAINER = Ruben Llorente <port...@use.startmail.com>
-# MIT
+# GPL-3.0-or-later
PERMIT_PACKAGE = Yes
MODULES = devel/cargo
@@ -97,5 +97,12 @@
MODCARGO_VENDOR_DIR = ${WRKSRC}/modcargo-crates
RUN_DEPENDS = security/gnupg
+
+MY_REPLACE_CMD = sed -i s/hid_init/hidapi_hid_init/g
+MY_HIDAPI_DIR = /nitrokey-sys-*/libnitrokey-*/libnitrokey/
+MY_HIDAPI_HEADER = hidapi/hidapi.h
+
+post-patch:
+ ${MY_REPLACE_CMD} ${MODCARGO_VENDOR_DIR}${MY_HIDAPI_DIR}${MY_HIDAPI_HEADER}
.include <bsd.port.mk>
Only in nitrocli.old: patches
diff -uar nitrocli.old/pkg/README nitrocli/pkg/README
--- nitrocli.old/pkg/README Thu Nov 9 03:31:11 2023
+++ nitrocli/pkg/README Thu Nov 9 15:19:48 2023
@@ -2,18 +2,38 @@
| Running ${FULLPKGNAME} on OpenBSD
+-----------------------------------------------------------------------
+Granting access to users
+===============================
The user running nitrocli needs the necessary privileges to access
the device. You may need to change the permissions of the corresponding
-usb(4) controller as a result. In order to do this, plug your
-NitroKey and use usbdevs(8) to identify the usb(4) controller it
-is attached to. Then use chmod(1) and/or chown(8) to give the user
-read/write access to the corresponding /dev/usb* character special
-device. Beware this may allow the user unintended access to other
-hardware associated to the same usb(4) controller, so do this with
-extreme caution.
+usb(4) and ugen(4) controllers as a result.
+You may identify the usb(4) device the NitroKey is attatched to with
+usbdevs(8). The corresponding ugen(4) device can be obtained from the
+ouput of dmesg(8). You may then use chgrp(1) and chmod(8) to grant
+access to the NitroKey. For example, in order to allow users from the
+wheel group to use the NitroKey you would issue commands such as:
+
+chgrp wheel /dev/usb1 /dev/ugen0.*
+chmod 640 /dev/usb1 /dev/ugen0.*
+
+Beware this may allow the user unintended access to other hardware
+associated to the same usb(4) controller, so do this with extreme
+caution.
+
+Interaction with gpg-agent
+===============================
A working gpg-agent is required for a number of operations. You may
need to add the following line to your $HOME/.profile in order to
ensure the agent is invoked properly:
export GPG_TTY=$(tty)
+
+There is a known bug in libnitrokey that may cause the NitroKey to hang
+if a smartcard operation is performed and a libnitrokey operation is
+attempted immediately afterwards. The implication is that if you use a
+NitroKey for decrypting or signing via gpg, you will need to either
+unplug and plug again the NitroKey right after, or restart the
+gpg-agent with:
+
+gpgconf --kill gpg-agent
