What version of libfido2 are you using?
1.12.0, git main
What operating system are you running?
macOS
What application are you using in conjunction with libfido2?
https://github.com/riastradh/fidocrypt
How does the problem manifest itself?
fido_dev_set_sigmask unconditionally fails with FIDO_ERR_INTERNAL on macOS, requiring a special case for macOS.
Most likely there is a way to change the sigmask during a CFRunLoop in macOS so that it atomically unblocks signals, but I'm not familiar enough with it to say.
Simply not using fido_dev_set_sigmask doesn't work, because then the signal will never be unblocked, so the effect of the signal will be lost. So the best alternative is to never block signals in the first place, which leads to a race condition where the effect of the signal may be lost depending on timing, or may not be lost if it is delivered during the blocking syscall underlying fido_hid_read/write.
In this case, the signal handler doesn't even need to do anything except guarantee that the next blocking syscall, or current one if it has already begun, will fail promptly with EINTR.
Is the problem reproducible?
yes
What are the steps that lead to the problem?
Call fido_dev_set_sigmask on macOS.
Does the problem happen with different authenticators?
yes
Please include the output of fido2-token -L.
N/A
Please include the output of fido2-token -I.
N/A
Please include the output of FIDO_DEBUG=1.
N/A
What version of libfido2 are you using?
1.12.0, git main
What operating system are you running?
macOS
What application are you using in conjunction with libfido2?
https://github.com/riastradh/fidocrypt
How does the problem manifest itself?
fido_dev_set_sigmask unconditionally fails with FIDO_ERR_INTERNAL on macOS, requiring a special case for macOS.
Most likely there is a way to change the sigmask during a CFRunLoop in macOS so that it atomically unblocks signals, but I'm not familiar enough with it to say.
Simply not using fido_dev_set_sigmask doesn't work, because then the signal will never be unblocked, so the effect of the signal will be lost. So the best alternative is to never block signals in the first place, which leads to a race condition where the effect of the signal may be lost depending on timing, or may not be lost if it is delivered during the blocking syscall underlying fido_hid_read/write.
In this case, the signal handler doesn't even need to do anything except guarantee that the next blocking syscall, or current one if it has already begun, will fail promptly with EINTR.
Is the problem reproducible?
yes
What are the steps that lead to the problem?
Call fido_dev_set_sigmask on macOS.
Does the problem happen with different authenticators?
yes
Please include the output of
fido2-token -L.N/A
Please include the output of
fido2-token -I.N/A
Please include the output of
FIDO_DEBUG=1.N/A