Bug#1028029: xscreensaver: contains non-free fonts
On Jan 6, 2023, at 1:50 AM, Bastian Germann wrote: > > But there is a version available at > https://sourceforge.net/projects/ocr-a-font/ that might be free. > You can certainly replace it. This one seems better than that one: https://tsukurimashou.osdn.jp/ocr.php.en Annoyingly, the name changes from "OCR A Std" to "OCR A".
Bug#1028029: xscreensaver: contains non-free fonts
Correction, Gallant is in fact BSD licensed: http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/dev/wsfont/gallant12x22.h
Bug#1028029: xscreensaver: contains non-free fonts
False. Luxi Mono is from Red Hat, I'm sure you've heard of them. OCRA is an ANSI Standard, and is public domain. Gallant is a reproduction of the Sun font created by Joshua M. Clulow and released, as far as I am aware, into the public domain.
Bug#987149: xscreensaver: allows starting external programs with cap_net_raw
As I said, it's already fixed in 6.00. The fix is just to configure without setcap and use setuid instead, which works properly with Mesa. I assume that having 6.00 distributed by Debian prior to 2035 would be asking too much, but we dare to dream.
Bug#987149: xscreensaver: allows starting external programs with cap_net_raw
Already fixed in XScreenSaver 6.00. The bug is in Mesa: it has a panoply of env vars that do what LD_PRELOAD does, except Mesa only checks geteuid instead of checking getauxval AT_SECURE, as the kernel does. So anything that uses both Mesa and setcap is vulnerable. Ironically, using setuid instead of setcap does not have the vulnerability.
Bug#979562: lightdm session termination does not stop xscreensaver
> my .icewm/startup file at the moment contains: > > xscreensaver -nosplash -log wtf-xscreensaver.txt & > > When icewm starts, I see the splash screen for a brief moment (not joking, > looks -nosplash has no effect there), but it does not happen every time. This kinda sounds like *something else* is launching xscreensaver at the same time, and whatever that is is doing it without -nosplash. The two of them racing would explain the "already running" error. > Or, if run ps quick enough before it's killed, I see: > > user 3904 0.0 0.0 5712 1128 ?SN 21:13 0:00 > xscreensaver-systemd -verbose > lightdm11997 0.1 0.0 18948 5952 ?Ss 21:55 0:00 > xscreensaver > lightdm12068 0.0 0.0 5712 1128 ?SN 21:55 0:00 > xscreensaver-systemd > user 12416 0.0 0.0 3748 664 pts/0S+ 21:56 0:00 grep saver Note that pid 11997 does not have -nosplash on its command line. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#979562: lightdm session termination does not stop xscreensaver
> Why would a xscreensaver instance running for user A have any influence on a > xscreensaver instance running for user B? That seems absolutely weird to me > and something I don't understand. Yeah, that sounds impossible, assuming that the X server has restarted between user A and user B. If things have gone wrong in a weird way, the "xscreensaver-systemd" process of user A might linger, but it won't be able to communicate with user B's xscreensaver. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#979562: lightdm session termination does not stop xscreensaver
On Jan 10, 2021, at 3:20 AM, Tormod Volden wrote: > > For a multi-user host the administrator expectations are different, since > there might be various login managers and user desktop environments, and > xscreensaver should only run in some of them. I would think that if an administrator installed xscreensaver on a multi-user system, the expectation would be for it to run in all graphical login sessions. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#979562: lightdm session termination does not stop xscreensaver
> In xscreensaver (or maybe lightdm). > Why is xscreensaver started in the lightdm session anyway? > Is xscreensaver really usable as a per user service or should it be per > session? > Why is the lightdm xscreensaver instance interfering with the xscreensaver > instance of the logged in user? > Questions that only the xscreensaver maintainer can answer. > > If he thinks there is a genuine systemd issue, then I'd appreciate if it was > reassigned back with more details. XScreenSaver author here. I know nothing about lightdm, and didn't write the code attempting to integrate the two. However: 1) XScreenSaver should be running as the logged-in user, and terminate when they log out. Typically this happens when the X server dies and the $DISPLAY socket is closed, but SIGTERM works just as well. 2) It is also reasonable to configure things so that XScreenSaver is running when no one is logged in (so that there is a screensaver atop the login screen). If it is launched as root, it will setuid to "nobody" at startup, etc. But in this case, when a user logs in, it must be killed and re-started as that user.
Bug#953098: xscreensaver: Crashes with XIO: fatal IO error
For best logging: xscreensaver -verbose -log log.txt
Bug#953098: xscreensaver: Crashes with XIO: fatal IO error
As far as I know, an XIO error means the X server dropped the connection to the xscreensaver client. So either the X server itself crashed, or it decided to disconnect xscreensaver for some unknown reason. If the client had done something wrong, X11-protocol-wise, this would have been a more verbose "X" error, not an "XIO" error. Maybe this is the kernel OOM-killer shooting down random long-running processes, as it sometimes likes to do? "Resource temporarily unavailable" sure sounds like it could be the X11 server trying to say that it ran out of memory.
Bug#876087: xscreensaver: source-less and unlicensed code at hacks/images/m6502/dmsc.asm
Oh FFS, the pedantry of you people knows no bounds. It's not even a *real emulator*. Did you even try emailing him? -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#873108: xscreensaver does not trap errors from intltool-update
Well, on every system I've ever had access to, intltool rarely works, so I took to just ignoring it entirely. YMMV.
Bug#757448: xscreensaver-data-extra included non-free contents.
It's all fair use, and you're a pinhead. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625770: xscreensaver: Corrupted unlock dialogs on dual head hardlocking machine randomly
Driver bug, not xscreensaver. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595273: If xscreensaver child dies, screen is deadlocked
On Sep 2, 2010, at 9:22 AM, Yves Lambert wrote: It looks like when xscreensaver child dies, xscreensaver does not launch another child and the keyboard is locked, only magic keys still works, no way to switch to another VT. This statement makes no sense to me at all. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594728: xscreensaver crashes leaving screen unlocked
That's a new one... Yes, -sync will probably help, as will a core file stack trace. I suspect we will discover that some sub-process launched by your PAM stack is crashing and taking libpam with it. That line about an unknown process dying means that we got a SIGCHLD for a pid that xscreensaver did not launch by itself. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566984: closed by Jose Luis Rivas josel...@rivco.net (reply to josel...@rivco.net) (Re: Bug#566984: xscreensaver: screensaver only shows a blackscreen instead of the actual animation)
If the problem here is that you launched xscreensaver-demo while gnome-screensaver was running but xscreensaver was not, then you should have gotten a dialog box saying exactly that, and offering to shut down gnome-screensaver, instead of simply saying that xscreensaver was not running. See driver/demo-Gtk.c:4296, gnome_screensaver_window(). Hi, when launching the xscreensaver demo a message pops up: the XScreenSaver daemon doesn't seem to be running on display :0.0 Launch it now? I choose ok, and quit, launch it again, and the same message reappears. It seems the daemon is not being loaded as it should. If this is happening, there's something very strange going on, not just user error. I don't know what could cause this. Run xscreensaver-demo with --debug ? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#482385: xscreensaver and RANDR
Please try this patch against xscreensaver 5.05 and let me know if it helps? http://www.jwz.org/xscreensaver/xscreensaver-randr-patch.txt (Please don't distribute builds incorporating this patch -- it's not tested well enough yet. Consider it a dangerous alpha.) Things I'm interested in hearing about: - Systems with multiple monitors. Do all monitors go black when xscreensaver activates? - Adding and removing monitors while the screen is not blanked. Does it look right once the screen blanks? - Adding and removing monitors while the screen is already blanked. Does everything reconfigure properly? - Changing the resolution of the monitor(s) using the xrandr command. - Does it correctly realize which monitors are actually attached to the system and in use? - Does it work with multiple X screens (the :0.1 style)? - Does it work when using the old Xinerama extension instead of RANDR. - Does it work using the VidMode extension to zoom and pan around (that is, monitor and desktop are different resolutions, via Ctrl-Alt-KP_Plus and KP_Minus.) There is a bug if: - It ever crashes (obviously!) - There is ever a situation where a screen is not completely covered by the xscreensaver windows. (Unless two screens are configured to overlap). Thanks! -- Jamie Zawinski [EMAIL PROTECTED] http://www.jwz.org/ [EMAIL PROTECTED] http://www.dnalounge.com/ http://jwz.livejournal.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482385: xscreensaver disappears (segfaults/aborts?) when xrandr is used.
You said that it works to start xscreensaver and then add an additional screen -- but I don't see how that's possible. si-screens is never resized after startup. I tried to restructure the code so that the screens array could be regenerated every time an XRRScreenChangeNotifyEvent came in (taking care to re-use screens when possible, and go through check_xinerama_sanity each time instead of just once at startup) but I got completely confused about the current relationship between RANDR and Xinerama. I've seen claims that Xinerama is obsolete, but I don't know how to ask RANDR for a list of the sizes and positions of all active glass. Can both extensions exist at the same time? What happens if there's RANDR but no Xinerama? The fact that the documentation for RANDR blows chunks does not help. So, I gave up again. I was going to try and just test-harness this, and debug it with manual simulation, but it really sounds like it's going to be impossible to make this work without access to a machine that can actually do this stuff, so that I can reverse-engineer how these damned extensions actually interact with each other. I'm not about to buy a new computer just for this. -- Jamie Zawinski [EMAIL PROTECTED] http://www.jwz.org/ [EMAIL PROTECTED] http://www.dnalounge.com/ http://jwz.livejournal.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482385: xscreensaver disappears (segfaults/aborts?) when xrandr is used.
Did you test what happens if nscreens remains 0 for some length of time, e.g., through another idle cycle? I'm guessing the answer is nothing good... It's hard to tell just by looking at it, but I suspect that, for example, with that change it's going to be running hacks on screens that no longer exist. (This may actually be true any time the number of screens is reduced, even when reduced to non-zero.) I need someone to put this through an exhaustive set of test cases of screens being added, removed, resized, overlapping, etc. -- something more comprehensive than it works for me in the one case that happens in my normal daily use. Since I don't have access to a system capable of doing this, it needs to be someone other than me. I asked for volunteers a few weeks ago, and got no useful responses so far: http://jwz.livejournal.com/894714.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#471920: xscreensaver: Crash at startup
I think this is fixed by the patch in bug 473681? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469099: xscreensaver: Package split leaves non-working screensavers in KDE configuration
On Mar 3, 2008, at 2:19 AM, Tormod Volden wrote: Believe me, the reason for the package split is exactly to make things easier for third-party screensaver infrastructures (like gnome-screensaver and kscreensaver), so that they can use xscreensaver hacks without the user having xscreensaver installed I don't understand why you're wasting your time on this. The xscreensaver executable is only 200kb. A good principle is don't fix what ain't broke. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450907: xscreensaver: fireworxx shows live screen contents when xcompmgr is running
Obviously, fireworkx should not be showing a transparent background. Equally obviously, this is not a bug in xscreensaver. It's a bug in the X server, or in some lower layer like the video driver. You should reassign this. Is fireworkx the only OpenGL saver that provokes this bug? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448157: CVE-2007-5585 authentication bypass (FTBFS with patch)
On Nov 5, 2007, at 4:11 PM, Steffen Joeris wrote: With this patch, xscreensaver fails to build: Sorry, typo: pw-prompt_screen should have been pw-prompt_screen- screen. Revised patch: diff -u -r1.85 lock.c --- lock.c 10 Jul 2007 20:27:24 - 1.85 +++ lock.c 1 Nov 2007 09:34:59 - @@ -1076,9 +1076,10 @@ pw-user_entry_pixmap = 0; } - pw-user_entry_pixmap = XCreatePixmap(si-dpy, si-passwd_dialog, - rects[0].width, rects[0].height, pw-prompt_screen-current_depth); - + pw-user_entry_pixmap = +XCreatePixmap (si-dpy, si-passwd_dialog, + rects[0].width, rects[0].height, + DefaultDepthOfScreen (pw-prompt_screen-screen)); XFillRectangle (si-dpy, pw-user_entry_pixmap, gc2, 0, 0, rects[0].width, rects[0].height);
Bug#448157: CVE-2007-5585 authentication bypass
I don't understand how xscreensaver-gl-helper not being installed could cause this sort of thing. However, this does sound vaguely like another bug: can one of you who is able to reproduce the problem try this patch and let me know if it works? Thanks... diff -u -r1.85 lock.c --- lock.c 10 Jul 2007 20:27:24 - 1.85 +++ lock.c 1 Nov 2007 09:34:59 - @@ -1076,9 +1076,10 @@ pw-user_entry_pixmap = 0; } - pw-user_entry_pixmap = XCreatePixmap(si-dpy, si-passwd_dialog, - rects[0].width, rects[0].height, pw-prompt_screen-current_depth); - + pw-user_entry_pixmap = +XCreatePixmap (si-dpy, si-passwd_dialog, + rects[0].width, rects[0].height, + DefaultDepthOfScreen (pw-prompt_screen)); XFillRectangle (si-dpy, pw-user_entry_pixmap, gc2, 0, 0, rects[0].width, rects[0].height);
Bug#433964: possible security problem with xscreensaver
That patch is already included in 5.03. But you people are still shipping 4.24, which is nearly eighteen months old. I really wish you'd upgrade already. Also, it is damned near impossible to exploit that. For it to be a problem, the attacker needs to have already compromised either the auth server or the LAN. After having done that, *then* one could make xscreensaver crash and unlock the screen. If that's a possibility, it seems to me that you've already got much bigger problems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
