Hi Chris, Thanks again for your work on this!
On Sun, Sep 08, 2019 at 09:32:20AM +0100, Chris Lamb wrote: > I can partly reproduce this, as well as some other strange behaviour > upon "plugging in" a device that, like your descriptions, are quite involved > to explain! > > > So the regrab doesn't actually solve things. What is even weirder is > > that this problem with the screen not being "correctly" grabbed will > > persist on future xtrlock runs > […] > > Can you reproduce this pretty weird behavior? Does it make any sense to > > you? > > I did once actually but I think I dismissed it as some kind of weird > errant process or just an issue as I was doing lot of recompilation, > etc. etc. Hmpf. Glad that you can reproduce these weird problems and confirm that I not alone in seeing them. ;-P > > [The exact same behavior seems to occur if I replace xinput > > enable/disable with the corresponding play with the authorized file.] > > I am pleased that we can also get the same behaviour using xinput vs > "authorized" as I would have more confidence that the latter emulates > Eve plugging in a external USB device versus xinput in terms of > abstraction layers. Agreed, plus as the latter doesn't work for you it would have been more complicated to figure things out. ;) > I'm a little stuck on how to proceed code-wise so my next steps are to > contact the maintainers of the Input Extension and see if they have > any insight. This sounds like a good idea -- also I wonder if the weird behavior "xtrlock persistently puts an input in a strange state" doesn't reveal a bug someplace else... As this is getting a bit open-ended, though, do you think it could be worth it to release one of these patches soon (the first one, or the second one with the missing initializations I pointed out) as a first step that fixes the vulnerability at least when Eve cannot plug in new devices? Best, -- Antoine Amarilli
signature.asc
Description: PGP signature
