I have a USB keyboard with a builtin smart card reader. With this keyboard attached and while trying to emerge notmuch, the ebuild fails during the configure phase with a sandbox access violation. It seems like the configure script tries to communicate with the keyboard over /dev/bus/usb, which is denied by the sandbox. Unplugging the keyboard and emerging the package works. This is the output of lsusb containing the keyboard: Bus 003 Device 015: ID 03f0:164a HP, Inc HP SC Keyboard - Apollo (Liteon) Reproducible: Always Steps to Reproduce: 1. Plug in keyboard with builtin smartcard reader. 2. Emerge net-mail/notmuch. 3. Observe sandbox violation during the configure phase.
Created attachment 748041 [details] build.log
Created attachment 748044 [details] emerge --info
Created attachment 748047 [details] emerge -pqv
reproduced without a cardreader even. investigating.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=678a6fa4106e18456ed9dadb6814a673de81fb32 commit 678a6fa4106e18456ed9dadb6814a673de81fb32 Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2021-11-04 02:48:44 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2021-11-04 02:49:57 +0000 net-mail/notmuch: add GMime sandbox violation workaround Checking for GMime session key extraction support... * ACCESS DENIED: open_wr: /dev/bus/usb/001/011 notmuch configure compiles a program _check_session_keys.c, inline in ./configure script gmime/gpg/scdaemon tries to open usb devices in GMime test we pretend to allow it, without actually allowing it to read or write. Bug: https://bugs.gentoo.org/821328 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> net-mail/notmuch/notmuch-0.33.2.ebuild | 8 ++++++++ 1 file changed, 8 insertions(+)
does not seem to be directly notmuch's fault, it's somewhere in gmime<->gnupg interaction. just curious, which version of gnupg you have?
(In reply to Georgy Yakovlev from comment #6) > just curious, which version of gnupg you have? I'm seeing this with gnupg 2.3.3.
Not yet tried to reproduce but chipping in at least some thoughts for now: - The configure script is handwritten and contains a call to gpg to verify gpgme is working; this has been there for a while, but gpg 2.3.x added new scdaemon magic, so that's probably why this started happening; - gpg-agent has an argument --disable-scdaemon we could pass but I don't know how to get gpg to pass *that* to gpg-agent, as gpg is the thing we invoke; - Could try include --no-autostart to the gpg call (there's also --disable-dirmngr) to avoid starting an agent at all?
thanks for suggestions, I'll try it. could tofu be related here btw? that's one of the recent changes. need to test without tofu
