Control: priority -1 wishlist Control: reassign -1 wnpp Control: retitle -1 RFP: u2f-hidraw-policy -- Future-proof U2F device discovery
Hi Will!
Sorry for only getting around to looking at this bug now :(
On Fri, Aug 03, 2018 at 05:48:44PM +0100, Will Thompson wrote:
> libu2f-udev makes U2F devices accessible to users by matching hidraw
> devices against a list of vendor/product pairs. This means that any
> newly-released device will not work until libu2f-host is updated to add it
> to this list.
Yes, this is correct.
> I noticed that Fedora takes a different approach: u2f-hidraw-policy[0] uses
> the discovery mechanism defined in the U2F HID spec[1] to determine whether
> a hidraw device supports U2F.
This is interesting, I was unaware Fedora did it that way.
> This has the nice property that newly-released devices work immediately,
> rather than needing an update to libu2f-host.
Yes, that should achieve this.
> Is there some reason to prefer the libu2f-udev approach?
I would be hesitant to change this within the release cycle for Buster, as we
would need exposure to many different users (and their devices and
configurations) to build confidence that this works correctly and introduces no
regression.
In particular, if it relies purely on the uaccess mechanism, this will not
work for Debian users who do not use systemd (or even just not pam-systemd).
This is fixable, though.
Moreover, this is C code, running as root and unconfined, every time a USB
device is plugged in, so I'd rather take the time to audit it before shipping it
to users. :)
(Re: unconfined, it would likely be worth writing a restrictive AppArmor policy
and submit it back upstream.)
> The approach seems cleaner than the list-of-devices approach.
At least, it should be more future-proof :)
> I'm wondering if there's any interest in Debian adopting this mechanism!
I'd be interested in at least trying it out.
If you would like, I can help getting your package into shape, and into
experimental.
Once it's there, the next logical staps would be to:
- get contributors to test it (feedback from EndlessOS would be useful, but
also getting people to use it on Debian) ;
- assuage security concerns, by reviewing the C code, making it drop privileges,
and adding an AppArmor profile;
- get it into unstable;
- eventually update the dependency of task-desktop (and other packages) to use
u2f-hidraw-policy (or at least u2f-hidraw-policy | libu2f-udev).
That's all things I can help with (I'm even a tasksel uploader, so I can deal
with
that part too), but I've been struggling with health issues so I might not be
the
most responsive.
Please feel free to poke me, either on the bug, or over IRC (nicoo on freenode
or OFTC), if I'm not replying.
@Simon, Klas: Do you have any thoughts on this, or experience with the
reliability of U2F autodetection?
Best,
nicoo
signature.asc
Description: PGP signature
