All examples on https://github.com/Agnoctopus/libu2f-emu/ don't
simply include u2f-emu.h without any added directory.

The additional include directory does not exist when libu2f
was built with meson.

It's up to pkgconfig to make sure that u2f-emu.h is found in any case.

Signed-off-by: Stefan Weil <sw@weilnetz.de>
---

libu2f-emu seems to be unmaintained. There are no Debian/Ubuntu packages,
and I am afraid that it is also not part of the CI tests.

Should it be deprecated/removed?

I recently was asked by a user to add it to QEMU for Windows.
It seems to work basically, but the user also noticed some issues.

Regards
Stefan

Citing the user's feedback:

As promised, I have tested the u2f and so far, it works as expected.
However, I do have a few notes.

1)
If you send the u2f emulation a malformed USB HID packet either to the HID Control EP
or the HID Interrupt EP, it crashes QEmu. Windows will show the "busy" mouse cursor
for a few seconds and then it will shut down QEmu. I am guessing the u2f emulation
doesn't do much error checking on that part.

2)
There are two versions of the u2f, one dated 11/04/2017 and one dated 12/20/2023.
The emulation is for the later, not the former. There is enough of a difference that it
is not backward compatible. I wonder if a note can be placed in the documentation
that the emulation is for the version dated 12/20/2023.

old version (11/04/2017)
https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/

new version (12/20/2023)
https://fidoalliance.org/specs/u2f-specs-master/

3)
If I don't send a "challenge" request first, the u2f seems to still process a successful
transfer even though the CID value is invalid. I guess the emulation doesn't check
for a valid CID before processing the request. This is a huge security problem, though
only in emulation, not host related.

4) (not really a QEmu problem, but still worth mentioning)
The specs don't specifically state that each transaction must be only a 64-byte
USB transaction. For example, if you need to send a message that is two 64-byte packets,
you must send them as individual USB transactions. You cannot send a single 128-byte USB transaction.
After reading the specs a bit more, it is implied, but not directly specified.
It took me a little trial and error to figure this out. I had a message that was more
than 64 bytes and less than 128 bytes so I was sending a single 128-byte USB transaction.
The u2f emulation didn't like this and only works if I send two consecutive 64-byte USB transactions.

5)
I only used the following in my command line:

  -device u2f-emulated

I did not try the 'passthru' nor the two following examples from the QEmu documentation.

 -device u2f-emulated,dir=$dir
 -device u2f-emulated,cert=$DIR1/$FILE1,priv=$DIR2/$FILE2,counter=$DIR3/$FILE3,entropy=$DIR4/$FILE4

All in all, if you have a properly coded u2f driver, I believe the QEmu u2f emulation to work as expected.
However, it does need some error checking added.



 hw/usb/u2f-emulated.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/usb/u2f-emulated.c b/hw/usb/u2f-emulated.c
index 196d05a83a..b82a315019 100644
--- a/hw/usb/u2f-emulated.c
+++ b/hw/usb/u2f-emulated.c
@@ -31,7 +31,7 @@
 #include "hw/usb/usb.h"
 #include "hw/core/qdev-properties.h"
 
-#include <u2f-emu/u2f-emu.h>
+#include <u2f-emu.h>
 
 #include "u2f.h"
 
-- 
2.47.3

On Wed, 18 Mar 2026 at 17:46, Stefan Weil via qemu development
<qemu-devel@nongnu.org> wrote:
>
> All examples on https://github.com/Agnoctopus/libu2f-emu/ don't
> simply include u2f-emu.h without any added directory.
>
> The additional include directory does not exist when libu2f
> was built with meson.
>
> It's up to pkgconfig to make sure that u2f-emu.h is found in any case.
>
> Signed-off-by: Stefan Weil <sw@weilnetz.de>

Hi, Stefan. Could I ask you to try a tweak to your git config
which (assuming you use git-send-email) I hope will fix the problem
where the mailing list rewrites the From headers of your emails
to "Stefan Weil via qemu development <qemu-devel@nongnu.org>" and
then when a maintainer picks them up they need to manually adjust
the git commit author line ?

This is the suggestion that our .mailmap has:

# If the mailing list munges your emails, use:
#   git config sendemail.from '"Your Name" <your.email@example.com>'
# the use of "" in that line will differ from the typically unquoted
# 'git config user.name', which in turn is sufficient for 'git send-email'
# to add an extra From: line in the body of your email that takes
# precedence over any munged From: in the mail's headers.
# See https://lists.openembedded.org/g/openembedded-core/message/166515
# and https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg06784.html

Hopefully that will help...

(I don't really understand why our mailing list still does some
address rewriting -- I thought we had configured it so it never
changes the mails any more and so shouldn't need to rewrite senders,
but a few people still seem to have their addresses rewritten :-( )

thanks
-- PMM

On 23.03.2026 20:12, Peter Maydell wrote:

> Hi, Stefan. Could I ask you to try a tweak to your git config
> which (assuming you use git-send-email) I hope will fix the problem
> where the mailing list rewrites the From headers of your emails
> to "Stefan Weil via qemu development <qemu-devel@nongnu.org>" and
> then when a maintainer picks them up they need to manually adjust
> the git commit author line ?
> 
> This is the suggestion that our .mailmap has:
> 
> # If the mailing list munges your emails, use:
> #   git config sendemail.from '"Your Name" <your.email@example.com>'
> # the use of "" in that line will differ from the typically unquoted
> # 'git config user.name', which in turn is sufficient for 'git send-email'
> # to add an extra From: line in the body of your email that takes
> # precedence over any munged From: in the mail's headers.
> # See https://lists.openembedded.org/g/openembedded-core/message/166515
> # and https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg06784.html
> 
> Hopefully that will help...

It might help if the original email did not have From: header at all.
But I doubt that was the case here, as From-less emails (messages w/o
From: header) gets dropped almost everywhere, so there should be
delivery probs for other places too.  But I can't know if original
email had the header or not, - but mailman definitely tweaked this
header (either adding it, or, most likely, modifying it).

What will help, most likely, is to configure DKIM on the sender side
(for weilnetz.de domain in this case).  For postfix, opendkim works
quite well, and there are other solutions which can be used.

> (I don't really understand why our mailing list still does some
> address rewriting -- I thought we had configured it so it never
> changes the mails any more and so shouldn't need to rewrite senders,
> but a few people still seem to have their addresses rewritten :-( )

I guess most uses who's From addresses gets rewritten have DKIM set up.
Your domain definitely does use DKIM signing, and so is mine.

/mjt

On Mon, 23 Mar 2026 at 17:22, Michael Tokarev <mjt@tls.msk.ru> wrote:
>
> On 23.03.2026 20:12, Peter Maydell wrote:
>
> > Hi, Stefan. Could I ask you to try a tweak to your git config
> > which (assuming you use git-send-email) I hope will fix the problem
> > where the mailing list rewrites the From headers of your emails
> > to "Stefan Weil via qemu development <qemu-devel@nongnu.org>" and
> > then when a maintainer picks them up they need to manually adjust
> > the git commit author line ?
> >
> > This is the suggestion that our .mailmap has:
> >
> > # If the mailing list munges your emails, use:
> > #   git config sendemail.from '"Your Name" <your.email@example.com>'
> > # the use of "" in that line will differ from the typically unquoted
> > # 'git config user.name', which in turn is sufficient for 'git send-email'
> > # to add an extra From: line in the body of your email that takes
> > # precedence over any munged From: in the mail's headers.
> > # See https://lists.openembedded.org/g/openembedded-core/message/166515
> > # and https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg06784.html
> >
> > Hopefully that will help...
>
> It might help if the original email did not have From: header at all.
> But I doubt that was the case here, as From-less emails (messages w/o
> From: header) gets dropped almost everywhere, so there should be
> delivery probs for other places too.

The point about the change is that it puts a From line in
the *body* of the email. git will pay attention to that if
it is there and ignore the incorrect email-header From: header.

> > (I don't really understand why our mailing list still does some
> > address rewriting -- I thought we had configured it so it never
> > changes the mails any more and so shouldn't need to rewrite senders,
> > but a few people still seem to have their addresses rewritten :-( )
>
> I guess most uses who's From addresses gets rewritten have DKIM set up.
> Your domain definitely does use DKIM signing, and so is mine.

Yeah, but the theory was that the mailing list should not need
to ever rewrite emails, regardless of whether DKIM is set up or not.

-- PMM