Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#11489 closed enhancement (fixed)

xscreensaver-5.42

Reported by: Bruce Dubbs Owned by: Bruce Dubbs
Priority: normal Milestone: 8.4
Component: BOOK Version: SVN
Severity: normal Keywords:
Cc:

Description

New point version.

Change History (6)

comment:1 by Bruce Dubbs, 5 years ago

Owner: changed from blfs-book to Bruce Dubbs
Status: newassigned

comment:2 by Bruce Dubbs, 5 years ago

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.

comment:3 by Bruce Dubbs, 5 years ago

Resolution: fixed
Status: assignedclosed

Fixed at revision 20922.

comment:4 by Douglas R. Reno, 5 years ago

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?

in reply to:  4 ; comment:5 by Bruce Dubbs, 5 years ago

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.

in reply to:  5 comment:6 by ken@…, 5 years ago

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.

Note: See TracTickets for help on using tickets.