Closed travankor closed 4 years ago
Good point, wanted to double check that but it slipped out of my mind.
I've actually reverted this change following the discussion in #12. The security issue should not be too common as executing rofi while the lock screen is on seems to be quite a weird workflow.
If there is enough interest, this could be made configurable (contributions welcome).
If there is enough interest, this could be made configurable (contributions welcome).
TBH, most people using this fork are compiling from source and can edit the code to suit their needs, so I think it's better to stick to one option. That said, @davedavenport and @sardemff7 were probably right in rejecting this fork given that wlroots-specific protocols have these weird idiosyncracies due to being poorly designed (and hence avoided exposing their users to potential security issues, too).
Well, most specifications and protocols have bugs, that does not mean they should be discarded entirely; things can be improved iteratively. In this case, you could argue that maintainers have not prioritized this issue enough but then it would be more constructive to bring back the issue there and look for solutions.
In the related Sway thread, ddevault says "input inhibit protocol should give swaylock exclusive access to input events, preventing these applications from being interacted with."
So even if you manage to leave rofi open just before the computer sleeps and locks, it should not be usable.
Rofi appears over lock screens which might be a security risk for some people. For now, the suggested fix for this is to use the TOP layer instead of the OVERLAY layer, which is what bemenu and wofi both do.
See: https://github.com/swaywm/swaylock/issues/107
Suggested patch: