Dear Maintainer,

I'm running Sway and use Swaylock to lock the screen when the laptop is asleep.
Sometimes when resuming from sleep, Swaylock will respond to the first keypress
of the password and display a spinner, but then freeze for about half a minute
and then just disappear and thereby allow access to Sway without the password
being entered.

I am not yet sure of the exact conditions that cause this issue but it's
happened >10 times so far on my system.

* Pelle <pelle@riseup.net> [210423 15:45]:

Sounds like it crashes?

Please install swaylock-dbgsym and see if you can get a coredump.

Chris

Here's a couple of coredumps.

Here's another coredump.

Pelle,



Would you be able to add a stack trace?
  Here, or directly with the upstream:
https://github.com/swaywm/swaylock/issues/181





Thanks.

It might not have reached him, the Debian bug tracker defaults to not
sending a copy to the submitter.

I'll answer there with a stacktrace based on the coredump.

cu
Adrian

I'm sad to see that we shipped Bullseye without an essential component
of Sway. Is there anything I can do to assist in getting this bug fixed,
perhaps for a potential future bullseye-packports package?

Hi Pelle,

You reported this issue for swaylock 1.5-2.

Do you still experience same isue with swaylock 1.6-1 now in Debian
unstable?

Perhaps sensible to lower severity of this issue, to allow more exposure
to it in Debian testing - and then hopefully close it for good soon,
when work on ext-session-lock-v1 is finalized:
https://github.com/swaywm/sway/pull/6879

Also, please note that you have been kindly requested to also share a
stack trace: https://bugs.debian.org/987360#25


Kind regards,

 - Jonas

Hi all.

Jonas Smedegaard <dr@jones.dk> writes:

I cannot answer for Pelle, but I was also experiencing this bug back
when it was reported. FWIW: I'm unable to reproduce it with 1.6-1. That
being said, triggering the bug does seem somewhat stochastic, so I can't
rule out that a bunch more suspend/resume cycles would trigger it. But
so far, so good!

I agree; I think we can lower the severity and let swaylock back into
testing, and just raise the severity back up if anyone is able to
reproduce on 1.6-1.


 Best,
 Gard

Same here, no crashes recently, yay, however, I think that this crash bug
illustrates the more general issue that the lock screen is bypassed on
any crash. Swaylock should be able to restart itself on failure, perhaps
with a daemon. There could be more vulnerabilities of this class, right?
I believe XScreensaver has a strategy for mitigating these types of
vulns too.

Thank you so much for your work. I wish I knew C and could help, but now
I can only complain and hope someone else fixes it. I could probably
write a daemon in shell script though if such a patch would be accepted,
although there are probably more elegant solutions to this in the swaylock code itself.

Pelle <pelle@riseup.net> writes:

Great!

Indeed. I believe this is what Jonas was referring to when he linked to
https://github.com/swaywm/sway/pull/6879 (it is about Sway supporting an
extension to the Wayland protocol for performing this kind of locking
reliably).

This is of course the right way forward, but for now, I think we at
least should downgrade the severity of this bug and let swaylock
re-enter testing.


 Best,
 Gard