Arch Linux

70-u2f.rules file is obsolete and should not be installed, see https://bugs.archlinux.org/task/65209 . I'm able to use u2f functionality with my yubikey just fine without it.

70-u2f.rules is already supplied by libu2f-host.
providing it in libfido2 leads to a conflict.

error: failed to commit transaction (conflicting files)
libfido2: /usr/lib/udev/rules.d/70-u2f.rules exists in filesystem (owned by libu2f-host)
Errors occurred, no packages were upgraded.

the packages each have a different version of whitelisted devices, and the rules files are different.

That's true, but the github page of libu2f-host says the following:

"This project is deprecated and is no longer being maintained. libfido2 is a new project with support for U2F and FIDO2."

But with the changes to systemd it seems that the udev rules are really not required anymore.
I'm fine if you close this.

With libfido2 1.5.0-3 we have this file now, but the package earned said file conflict.

Not sure how accurate my testing was but after removing `libu2f-host` and installing `libfido2` I was indeed able to keep using my SOMU U2F device.

It was the only way to proceed with a full system upgrade since I was getting:

```
error: failed to commit transaction (conflicting files)
libfido2: /usr/lib/udev/rules.d/70-u2f.rules exists in filesystem (owned by libu2f-host)
Errors occurred, no packages were upgraded.
error installing repo packages
```

After update libfido2 I've had such errors in my log:
lis 03 13:23:11 pc systemd-udevd[253]: /usr/lib/udev/rules.d/70-u2f.rules:15 Unknown group 'plugdev', ignoring
lis 03 13:23:11 pc systemd-udevd[253]: /usr/lib/udev/rules.d/70-u2f.rules:18 Unknown group 'plugdev', ignoring
lis 03 13:23:11 pc systemd-udevd[253]: /usr/lib/udev/rules.d/70-u2f.rules:21 Unknown group 'plugdev', ignoring
lis 03 13:23:11 pc systemd-udevd[253]: /usr/lib/udev/rules.d/70-u2f.rules:24 Unknown group 'plugdev', ignoring
lis 03 13:23:11 pc systemd-udevd[253]: /usr/lib/udev/rules.d/70-u2f.rules:27 Unknown group 'plugdev', ignoring
lis 03 13:23:11 pc systemd-udevd[253]: /usr/lib/udev/rules.d/70-u2f.rules:30 Unknown group 'plugdev', ignoring
lis 03 13:23:11 pc systemd-udevd[253]: /usr/lib/udev/rules.d/70-u2f.rules:33 Unknown group 'plugdev', ignoring
lis 03 13:23:11 pc systemd-udevd[253]: /usr/lib/udev/rules.d/70-u2f.rules:36 Unknown group 'plugdev', ignoring
lis 03 13:23:11 pc systemd-udevd[253]: /usr/lib/udev/rules.d/70-u2f.rules:39 Unknown group 'plugdev', ignoring
lis 03 13:23:11 pc systemd-udevd[253]: /usr/lib/udev/rules.d/70-u2f.rules:42 Unknown group 'plugdev', ignoring
lis 03 13:23:11 pc systemd-udevd[253]: /usr/lib/udev/rules.d/70-u2f.rules:45 Unknown group 'plugdev', ignoring
lis 03 13:23:11 pc systemd-udevd[253]: /usr/lib/udev/rules.d/70-u2f.rules:48 Unknown group 'plugdev', ignoring
lis 03 13:23:11 pc systemd-udevd[253]: /usr/lib/udev/rules.d/70-u2f.rules:51 Unknown group 'plugdev', ignoring
lis 03 13:23:11 pc systemd-udevd[253]: /usr/lib/udev/rules.d/70-u2f.rules:54 Unknown group 'plugdev', ignoring
lis 03 13:23:11 pc systemd-udevd[253]: /usr/lib/udev/rules.d/70-u2f.rules:57 Unknown group 'plugdev', ignoring
lis 03 13:23:11 pc systemd-udevd[253]: /usr/lib/udev/rules.d/70-u2f.rules:60 Unknown group 'plugdev', ignoring
lis 03 13:23:11 pc systemd-udevd[253]: /usr/lib/udev/rules.d/70-u2f.rules:63 Unknown group 'plugdev', ignoring
lis 03 13:23:11 pc systemd-udevd[253]: /usr/lib/udev/rules.d/70-u2f.rules:66 Unknown group 'plugdev', ignoring
lis 03 13:23:11 pc systemd-udevd[253]: /usr/lib/udev/rules.d/70-u2f.rules:69 Unknown group 'plugdev', ignoring
lines 91-116

Shouldn't this either provide or conflict with 'libu2f-host' so that pacman doesn't error on the file conflict?

I don't know why the libfido2 maintainer added /usr/lib/udev/rules.d/70-u2f.rules to it?

@anthraxx why did you make a change that I proved unnecessary in[1] which resulted in useless messages as showed in[2]? If anyone has issue they should report it to systemd which is now responsible for making things work out of the box. Upstream clearly states that rules file is supposed to be used only for non-systemd systems[3] which is why it isn't installed by default. Please refrain from making changes you don't understand, thank you.

[1] https://bugs.archlinux.org/task/68502#comment193949
[2] https://bugs.archlinux.org/task/68502#comment193966
[3] https://github.com/Yubico/libfido2/issues/131#issuecomment-592931639

@your_doomsday: Please refrain from any personal insults in all places, let this be a warning. this is a place for technical statements exclusively, thank you.

I'm sorry if you felt insulted. I hope I made enough of exclusive technical statements for revert that change however I don't understand why it was done such rapidly, bypassing discussion happened on this ticket. That fact it created conflict only proves it was rushed change.

I had to uninstall libu2f-host in order to do a full upgrade. Probably related to this bug somehow. Same error as @yparitcher posted yesterday.

Just take an example from here https://aur.archlinux.org/packages/libfido2-git which correctly installs libfido2.

@your_doomsday, this issue would also be mitigated if the upstream wasn't using the same name as libu2f-host. This is still a valid upstream issue, arch wrongly installing the file is parallel to that. If you are part of the upstream, please fix it.

I'd recommend removing this file, as @your_doomsday pointed out, because the systemd approach is superior -- it only sets the permission on the U2F authenticator hidraw node, not all hidraw nodes that come from the device. However, we need to be aware that some tools might be expecting this udev rules to be installed and setting permissive access to all device hidraw nodes. I can see how easily a vendor tool might depend on libfido2 or libu2f-host and think they do not need to set permissions on the device because that is already handled. So, I think removing this file would actually be the rushed change, in contrast to what @your_doomsday believes.

@FFY00 libu2f-host is depreciated, nothing uses it, nothing depends on it and it can be safely removed from arch repos. Upstream doesn't support it anymore so this is distro problem if it ship both packages with same files inside.

I don't understand how removing this file can be rushed change when it was added just 2 days ago and nobody reported any issues for months without that file and systemd has support for this functionality since 4 major releases.

"However, we need to be aware that some tools might be expecting this udev rules to be installed and setting permissive access to all device hidraw nodes."

What tools? Why they don't depend on libu2f-host package if it's required for them?

Please provide example (not theoretical speculation) of broken behaviour when this file doesn't exist on systemd enabled system (I assume Arch doesn't support non-systemd systems). You may notice that even person who opened this ticket agreed this file isn't needed[1].

[1] https://bugs.archlinux.org/task/68502#comment193958

> @FFY00 libu2f-host is depreciated, nothing uses it, nothing depends on it and it can be safely removed from arch repos. Upstream doesn't support it anymore so this is distro problem if it ship both packages with same files inside.

Sure, but that is not really an excuse. I see no reason for the libfido2 upstream to deliberately not fix libfido2 conflicting with libu2f-host when the fix is this simple...

> I don't understand how removing this file can be rushed change when it was added just 2 days ago and nobody reported any issues for months without that file and systemd has support for this functionality since 4 major releases.

??? literally this bug

> Please provide example of broken behaviour when this file doesn't exist on systemd enabled system

Please read my reply again, I explained how this can happen.

> (I assume Arch doesn't support non-systemd systems).

It seems you completely missed the point. I described possible broken behavior on systemd systems.

Overall I think this is a change we want to do, but we should keep in mind that not having this udev rules *might* break some apps, as they are not equivalent to the new handling of FIDO devices by systemd.

> Sure, but that is not really an excuse. I see no reason for the libfido2 upstream to deliberately not fix libfido2 conflicting with libu2f-host when the fix is this simple...

This is beyond this discussion. If you want you may open upstream issue.

> ??? literally this bug

I repeat again: person who opened this bug agreed systemd behaviour is sufficient. There was nor real bug here just lack of awareness of systemd feature: https://bugs.archlinux.org/task/68502#comment193958

> Please read my reply again, I explained how this can happen.

You provided some theoretical speculation. I asked for example, real one otherwise this in unprovable claim that can't be falsified.

> It seems you completely missed the point. I described possible broken behavior on systemd systems.

See above. If you claim that systemd behaviour is broken for some cases please report this to systemd however I doubt it will be acted on without saying what exactly doesn't work.

> I repeat again: person who opened this bug agreed systemd behaviour is sufficient. There was nor real bug here just lack of awareness of systemd feature: https://bugs.archlinux.org/task/68502#comment193958

After the udev rules were added to the package. It was not clear at the time.

> You provided some theoretical speculation. I asked for example, real one otherwise this in unprovable claim that can't be falsified.

I pointed out the udev rules are not equivalent to the systemd approach. And then speculated that some projects might be relying on this udev rules behavior, and this was something we should keep in mind.

> See above. If you claim that systemd behaviour is broken for some cases please report this to systemd.

That is not what I said at all...

The systemd behavior is more correct than what was happening in the udev rules, but **it is not equivalent**.

I simply pointed out some people might be relying on the old behavior.

> After the udev rules were added to the package. It was not clear at the time.

That's why I complained about rushed change that bypassed discussion. I made my first comment before package change but I don't know if someone even read it.

> I simply pointed out some people might be relying on the old behavior.

They might rely on it or they might not. Is it acceptable to override systemd approach forever without knowing this for sure? I don't see how this can be proven without letting those people speak for themselves. Also for libfido2 the old behaviour is pure systemd approach, udev rules are brand new here.

Keep in mind that shipping udev rules file will force less correct behaviour for everyone alongside 'plugdev' debianism which is annoying in Arch.

> That's why I complained about rushed change that bypassed discussion. I made my first comment before package change but I don't know if someone even read it.

People might have missed it, that is no excuse to act like this.

> They might rely on it or they might not. Is it acceptable to override systemd approach forever without knowing this for sure?

*sigh*

> I'd recommend removing this file, as @your_doomsday pointed out, because the systemd approach is superior

> Overall I think this is a change we want to do, but we should keep in mind that not having this udev rules *might* break some apps

There is no point replying to you if you are not gonna read my messages, or deliberately ignore chunks of them.

> I don't see how this can be proven without letting those people speak for themselves.

It does not need to be proven, it *can* happen.

> Also for libfido2 the old behaviour is pure systemd approach, udev rules are brand new here.

By old behavior I meant the udev rules, before the systemd changes. Most people would not be affected because it is very likely they'd have libu2f-host or other package that installed udev rules for their devices.

I read all your messages multiple times. If saying someone doesn't understand something is considered an insult then saying I don't read messages I reply to or deliberately ignore parts of them is insulting too as it suggests I'm doing it in bad faith.

I really don't want to comment on every single sentence of yours to keep this discussion readable but this doesn't mean I ignore it. You wrote both:

> I'd recommend removing this file

and:

> I think removing this file would actually be the rushed change

in the same comment which muddles your overall message however I guess the former is what you really stand for currently.

> It does not need to be proven, it *can* happen.

By proven I mean finding actual tool that is affected. If there are no such tools then nothing will break and any theoretical speculation will be fruitless. Why non-u2f tool would depend on udev list of u2f tokens is beyond me. Actually if I believed your claims that some tools may break I would alter my conclusions and argue for keeping udev rules (or reporting it to systemd as even correct behaviour isn't sufficient if it doesn't work) because I think not breaking users should be the priority. That's why practical matter of your argument is crucial for me and I'm surprised that you believe it can break something but still recommend to move on. So even if we agree(?) what should be done we disagree about the details (I'm ok with agreeing to disagree).

> You wrote both:
*snip*
> in the same comment which muddles your overall message however I guess the former is what you really stand for currently.

Yes, I was not very clear here. This was in response to your comment saying that adding the file was a rushed change. It did not have the effect I was going for, sorry.

> By proven I mean finding actual token that is affected. If there are no such tokens then nothing will break and any theoretical speculation will be fruitless.

It is not, this is how you prevent hardware from breaking, by being preventive. But taking everything in this specific situation into account, I think that the approach we want to take is removing the file. But that is up to the maintainer.

> Actually if I believed your claims that some tokens may break I would alter my conclusions and argue for keeping udev rules (or reporting it to systemd as even correct behaviour isn't sufficient if it doesn't work) because I think not breaking users should be the priority.

I'll indulge....

I am not sure if this is happening in the wild, it *might*, that's why I said that it should be taken into account.
But I can show you this can indeed break thing for some users, since you seem so sure.

The current rules set permissions on every device from the hidraw subsystem with the specified USB VID and PID, correct?

I am gonna create a test device with a FIDO U2F Authenticator HID usage and a Vendor HID usage.


$ lshid
can't open '/dev/hidraw15': [Errno 13] Permission denied: '/dev/hidraw15'
Device /dev/hidraw14: ID 0000:0000 Example Security Key (U2F interface)

$ sudo lshid
Device /dev/hidraw15: ID 0000:0000 Example Security Key (vendor interface)
Device /dev/hidraw14: ID 0000:0000 Example Security Key (U2F interface)

$ sudo lshid -v
Device /dev/hidraw15: ID 0000:0000 Example Security Key (vendor interface)
Report Descriptor:
Usage Page (Vendor Page)
Usage (0x0001)
Collection (Application)
Report Size (8)
Report Count (6)
Logical Minimum (0)
Logical Maximum (255)
Usage (0x0001)
Input (Data, Array, Absolute, No Wrap, Linear, Preferred State, No Null position, Bit Field)
Usage (0x0001)
Output (Data, Array, Absolute, No Wrap, Linear, Preferred State, No Null position, Bit Field)
End Collection

Device /dev/hidraw14: ID 0000:0000 Example Security Key (U2F interface)
Report Descriptor:
Usage Page (FIDO Alliance)
Usage (U2F Authenticator Device)
Collection (Application)
Usage (Input Report Data)
Logical Minimum (0)
Logical Maximum (255)
Report Size (8)
Report Count (64)
Input (Data, Array, Absolute, No Wrap, Linear, Preferred State, No Null position, Bit Field)
Usage (Output Report Data)
Logical Minimum (0)
Logical Maximum (255)
Report Size (8)
Report Count (64)
Output (Data, Array, Absolute, No Wrap, Linear, Preferred State, No Null position, Bit Field)
End Collection

(for formatting) https://gist.github.com/FFY00/e246390a01bdd8e5c9a63d47428f0777


With this VID/PID combination included in the udev files in contrast, /dev/hidraw15 is available in my user. This happens because systemd looks for the 0xF1D0 0x0001 HID usage (U2F Authenticator Device) rather than the VID/PID combination.

If I was creating a vendor app for a security key and I had a dependency on some of the libraries that provided the udev rules, the vendor interface (/dev/hidraw15) would be accessibly and I would not need to install my own udev rule.

> That's why practical matter of your argument is crucial for me and I'm surprised that you believe it can break something but still recommend to move on.

There is a chance it will break, but I think it's pretty small. I think we are fine moving on, but we should keep this in mind and be on the lookout for issues like this. But anyway, it is up to Levente, not me.

Completely unrelated to the greater discussion of whether the rules should be supplied or not, I'd just like to add:

> @FFY00 libu2f-host is depreciated, nothing uses it, nothing depends on it and it can be safely removed from arch repos. Upstream doesn't support it anymore so this is distro problem if it ship both packages with same files inside.

It still shouldn't cause an error when doing a standard `pacman -Syu` about a file conflict. If the two packages are incompatible, shouldn't `libu2f-host` be in `libfido2`'s conflicts() array?

Hello, another affected user is here.

My upgrade is currently broken, and I'm not quite sure about the proper way to go. Would be good to have a working system state.

```
error: failed to commit transaction (conflicting files)
libfido2: /usr/lib/udev/rules.d/70-u2f.rules exists in filesystem (owned by libu2f-host)
Errors occurred, no packages were upgraded.
```

The maintainer should either remove the file or rename it to avoid conflicts. In the meantime, you can remove one of the packages if you don't have anything depending on them.