fido2: plug some resource leaks in the client

[kevans91]

The main target here is list_ctaphid_devices: on FreeBSD, this actually breaks nitropy list because our uhid/u2f drivers won't allow a second open() of the device. The devices that do not match will leak the fd, so later _list() calls (or at least the Nitrokey 3 one) cannot enumerate them at all.

filtered_devices() was split out to trivially plug the same leak in find_device().

Apologies in advance if my style/wrapping is atrocious, I only get to write python a little bit every few years.

[robin-nitrokey]

Thanks for the PR! Alternatively, we could also just iterate device descriptors and only connect to the devices that match our selector, like here:

https://github.com/Nitrokey/nitrokey-sdk-py/blob/77aa6f91b408103f516aacd352712f7f0c6cbb94/src/nitrokey/trussed/_device.py#L250-L255

What do you think?

[kevans91]

Thanks for the PR! Alternatively, we could also just iterate device descriptors and only connect to the devices that match our selector, like here:

https://github.com/Nitrokey/nitrokey-sdk-py/blob/77aa6f91b408103f516aacd352712f7f0c6cbb94/src/nitrokey/trussed/_device.py#L250-L255

What do you think?

Yes, good point. I see that still implies a transient open() in fido2.hid, but it's much cleaner here and in consumers if they can just filter the list without worrying as much about what they're discarding. I'll take a look at what that means for consumers of the API, but it seems like it will probably Just Work(TM) as long as find_device continues to open the connection.

[kevans91]

I don't have a device that can use the fido2 client on-hand, so the find_device() part is untested. I realized after writing my last comment that list_ctaphid_devices should just continue opening connections, it's just that we want to apply the filtering on a descriptor list instead. I implemented that both there and for the one path in find_device.

[kevans91]

Gentle ping

[robin-nitrokey]

Thank you!