-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add nitrokey3 update in qubes #248
Conversation
lgtm, merge? |
.. _installation instructions: ../../software/nitropy/all-platforms/installation.html | ||
|
||
|
||
Firmware Release Types |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't copy text from other files but include it instead or refer to it.
Images don't belong to the "fido2" folder so move it to "nitrokey3" folder. |
@daringer please update so the documentation can be tested in goal of closing Nitrokey/nitrokey-app2#249, Nitrokey/pynitrokey#542 and then merging linuxboot/heads#1684 to close their associated issues as well. |
Dodging sys-usb requirement and redoing under debian-12 test qube, where sys-usb should never have network access and where passing device through device widget once mode is switched to flashing should mitigate the problem altogether. Using debian-12 as template base in my use case so:
Then the instructions are misleading and don't include the important bits from linuxboot/heads#1684 (comment)
(changed mode of usb devices, needs repassing usb security dongle from qubes device widget which is not connected anymore)
That's where QubesOS/qubes-issues#8953 (comment) comes into play nitropy nk3 reboot --bootloader
|
@daringer @jans23 provided proper feedback at QubesOS/qubes-issues#8953 (comment) and pinged @DemiMarie and @marmarek there and here to hopefully fix this upstream once and for all, this impacts not only nk3 but android debugging, android tethering and basically all usb passthrough outside of using everything in sys-usb which should not happen. |
@marmarek @daringer @DemiMarie @fepitre the root of the underlying issue here is that even if qvm-usb "thinks" that the device is passed to the destination qube (by usb port of sys-usb), the destination qube itself doesn't see it anymore (pid:vid changed, in case of usb composite devices), with standard tools not seeing the composite usb device having change pid:vid, nor being able to reset the device nor the hub to force a redetection since usb proxy only passes the usb port. Replication notes after #248 (comment) 's commands from testing qube:
The problem here is that qubesos assigns sys-usb:4-3, not associated pid:vid, and that the device (usb port) not having been disconnected shows as if it was already passed to the qube, where
Shows that the device is still under sys-usb control here, the control haven't been relinquished to the destination qube for change pid:vid. This is common issue for all usb devices passed by usb port instead of pid:vid, basically affecting all composite usb devices including android and muli-purpose usb devices that don't play nice with QubesOS today. Fix would be to offer pid:vid qvm-usb assignation, permitting temporary/permanent assignation through qvm-usb and even the widget resolving whole class of issues QubesOS have had from that design decision. TLDR: qvm-usb should pass pid:vid, not a usb usb port.
The stack is confused with reason. |
Having users activate network under sys-usb and do this stuff under sys-usb instead of dedicated qube should not be recommended for QubesOS users. Ideally:
And the issue would be non-issue as well as all other usb composite devices having issues under QubesOS today. @marmarek @DemiMarie @fepitre: Can this be prioritized?Alternative/workaround if root issue cannot be fixed promptly:
|
@nestire please add small description in this PR reflecting goal of this PR |
Cross reference for tracking QubesOS/qubes-issues#8953 (comment) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instructions to unset sys-usb networking are missing which would currently add network persistently to sys-usb.
@marmarek reproduced issue in nk3a nfc |
@nestire please add PR small description |
No description provided.