xscreensaver-5.42

[Bruce Dubbs]

New point version.

[Bruce Dubbs]

5.42 28-Dec-2018

• macOS: Fixed Sparkle auto-updater.

5.41 26-Dec-2018

• X11: Those new font-loading fallback heuristics work again. Oops.
• iOS, Android: Plugged many memory leaks at exit.
• New hack, handsy.
• Fixed noof from displaying minimalistically.
• Rewrote unknownpleasures to be faster, and a true waterfall graph.
• BSOD Solaris improved. DVD added.
• Linux: If the xscreensaver daemon is setuid, then we can implore the

kernel's out-of-memory killer to pretty please not unlock the screen.

• macOS: Upgraded Sparkle (the “Check for Updates” library).
• macOS: Screen saver settings work again on 10.14.

[Bruce Dubbs]

Fixed at revision 20922.

[Douglas R. Reno]

Catching up on my email, and I saw these change notes.

Why would we want to make it so the OOM killer doesn't unlock the screen? That would hide important information from the user, and also means that xscreensaver-daemon would set it's priority higher than even X, which doesn't sound right to me. This is coming from someone who used to OOM with parallelism though, so maybe I'm biased.

This is dangerous. Should we see if there is a way to disable that?

[Bruce Dubbs]

Replying to renodr:

Catching up on my email, and I saw these change notes.

Why would we want to make it so the OOM killer doesn't unlock the screen? That would hide important information from the user, and also means that xscreensaver-daemon would set it's priority higher than even X, which doesn't sound right to me. This is coming from someone who used to OOM with parallelism though, so maybe I'm biased.

This is dangerous. Should we see if there is a way to disable that?

This is a very low probability event. Let's wait for a problem report. Generally upstream knows better than we do.

[ken@…]

Replying to bdubbs:

Replying to renodr:

Catching up on my email, and I saw these change notes.

Why would we want to make it so the OOM killer doesn't unlock the screen? That would hide important information from the user, and also means that xscreensaver-daemon would set it's priority higher than even X, which doesn't sound right to me. This is coming from someone who used to OOM with parallelism though, so maybe I'm biased.

This is dangerous. Should we see if there is a way to disable that?

This is a very low probability event. Let's wait for a problem report. Generally upstream knows better than we do.

I think the change is intended as a security fix: if you have sensitive information available and the screensaver activates with a password enabled, you need the password to unlock the screen. If the screensaver is killed, loss of security.