Bug#869773: xdm logs failed logins that may be sensitive
Le decadi 10 thermidor, an CCXXV, Julien Cristau a écrit : > Isn't that true pretty much whichever way you log in (ssh, login, ...), > not just xdm? Probably. I just noticed it and verified it on xdm. If other login prompts have the same issue, a common solution may be better. Note that with ssh, there is no login prompt, normally. Regards, -- Nicolas George signature.asc Description: Digital signature
Bug#869773: xdm logs failed logins that may be sensitive
Package: xdm Version: 1:1.1.11-3 Severity: normal Dear Maintainer, When somebody tries to log in and fails, xdm writes the given user name in the system logs. Unfortunately, typing the password in the login field is a common mistake. When that happens, xdm logs it too. That leaves the password of an user in clear in the system logs. It is not very important, but still a little security concern since normally passwords are stored permanently on the system only in hashed form. The corresponding log line looks like this: Jul 26 11:32:31 hellroy xdm[1004]: LOGIN FAILURE ON :0, XXX (I have redacted the login that was actually a password.) It may be better to not log it at all, or maybe only log it when it matches an actual login name. Regards, -- Nicolas George -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xdm depends on: ii cpp4:6.3.0-4 ii debconf [debconf-2.0] 1.5.61 ii libc6 2.24-11+deb9u1 ii libpam0g 1.1.8-3.6 ii libselinux12.6-3+b1 ii libx11-6 2:1.6.4-3 ii libxau61:1.0.8-1 ii libxaw72:1.0.13-1+b2 ii libxdmcp6 1:1.1.2-3 ii libxext6 2:1.3.3-1+b2 ii libxft22.3.2-1+b2 ii libxinerama1 2:1.1.3-1+b3 ii libxmu62:1.1.2-2 ii libxpm41:3.5.12-1 ii libxrender11:0.9.10-1 ii libxt6 1:1.1.5-1 ii lsb-base 9.20161125 ii procps 2:3.3.12-3 ii x11-utils 7.7+3+b1 ii x11-xserver-utils 7.7+7+b1 xdm recommends no packages. xdm suggests no packages. -- debconf information: xdm/daemon_name: /usr/bin/xdm * shared/default-x-display-manager: xdm xdm/stop_running_server_with_children: false signature.asc Description: Digital signature
Bug#578243: can't change bell pitch: reported upstream?
Hi. Le decadi 20 floréal, an CCXVIII, Julien Cristau a écrit : > from a quick look I find 27118 and 27926 in upstream bugzilla, and > <4bc946d7.60...@oracle.com>, > and > <727c2185-fb31-428d-bd49-f6520a2c1...@apple.com> on the mailing list > which sound similar. Bug #27926 in the upstream bugzilla was submitted by me a few days after I submitted it to Debian (compiling xserver from Git takes more effort). My patch has just been applied to the upstream as commit 968a79dcf5e17ac3963953ef56b8f94dbd75323b ( http://cgit.freedesktop.org/xorg/xserver/commit/?id=968a79dcf5e17ac3963953ef56b8f94dbd75323b ). I just checked, it applies seamlessly to xorg-server-1.7.7 currently packages by Debian. Regards, -- Nicolas George signature.asc Description: Digital signature
Bug#549377: xinit: xserverrc ignores arguments from startx
Package: xinit Version: 1.1.1-1 The startx script invokes xinit like this: xinit "$client" $clientargs -- "$server" $display $serverargs If there are no explicit arguments and no local .xserverrc script, $server has been previously initialized to /etc/X11/xinit/xserverrc. $serverargs holds, among other things, the auth file. The xinit line in a typical system looks like this: xinit /home/cigaes/.xinitrc -- /etc/X11/xinit/xserverrc :0 -auth /tmp/serverauth.axdsHbFbfp The problem is that the default xserverrc script looks like this: exec /usr/bin/X11/X -nolisten tcp Which means it completely ignores its arguments, including the -auth stuff. Cookie-based authentication is therefore not enabled in the server. Suggested fix: exec /usr/bin/X11/X -nolisten tcp "$@" Seems to work for me. Regards, -- Nicolas George signature.asc Description: Digital signature
Bug#397485: [i965] Xv causes ring lockups with v1.7.0 intel driver
Package: xserver-xorg-video-i810 Version: 2:1.7.2-1 The current version of the driver has a bug that makes XVideo unusable with a 965G chipset. See https://bugs.freedesktop.org/show_bug.cgi?id=8594 The fix is already in the GIT repository: http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-intel.git;a=commit;h=fbb376bd1a4daad4c86e349df98438989ce173f1 Please consider importing the fix in Debian soon. Regards, -- Nicolas George signature.asc Description: Digital signature
Bug#376297: Xt man pages are gone
Package: libxt-dev Version: 1:1.0.0-5 Old versions of libxt-dev contain man pages, for example /usr/X11R6/man/man3/XtAppInitialize.3x.gz (found in 6.9.0.dfsg.1-6). With the new version from X.org 7, these man pages are nowhere to be seen (except in Japanese). The man pages are still in the source package. System information (is it really necessary?): Debian Etch ii libsm-dev 1.0.0-4 X11 Inter-Client Exchange library (development ii libx11-dev1.0.0-6 X11 client-side library (development headers) ii libxt61.0.0-5 X11 toolkit intrinsics library ii x11-common7.0.22 X Window System (X.Org) infrastructure ii x11proto-core-dev 7.0.4-3 X11 core wire protocol and auxiliary headers Linux ssecem 2.6.14.1 #1 PREEMPT Wed Nov 9 20:27:50 CET 2005 i686 GNU/Linux Regards, -- Nicolas George signature.asc Description: Digital signature
Bug#285396: [ARM] wide chars don't work
Package: xterm Version: 4.3.0.dfsg.1-8 xterm is built with the default -mstructure-size-boundary value, 32. This leads to sizeof(XChar2b) being 4 and not 2 as it should be. The result is that xterm with wide-chars enabled will display a null character between each second character. Steps to see the problem: xterm -fn -adobe-courier-medium-r-normal--12-120-75-75-m-70-iso10646-1 +wc (display is ok) xterm -fn -adobe-courier-medium-r-normal--12-120-75-75-m-70-iso10646-1 -wc (display is obviously wrong) The problem disappears if xterm is build with the -mstructure-size-boundary=8 option. I report the problem against the xterm package because that is the one I found it, and the one with which I experimented, and probably the worst, but it is probably present with all programs that use wide characters with the non-Xft X11 API. I am told that emacs suffers from the same problem. Miscellaneous config information (should not be relevant): xlibs-data 4.3.0.dfsg.1-8 libc6 2.3.2.ds1-18 libexpat1 1.95.8-1 libfontconfig1 2.2.3-4 libfreetype6 2.1.7-2.3 libx11-6 4.3.0.dfsg.1-8 libncurses5 5.4-4 libxaw7 4.3.0.dfsg.1-8 libxrender1 0.8.3-7 Linux zaurus 2.4.20 #1 Thu, 28 Oct 2004 09:59:43 +0900 armv5tel GNU/Linux pgpjLAcLWkoCH.pgp Description: PGP signature
Bug#233691: new xterm (4.3.0-2) fails to show bold fonts
Le primidi 1er ventôse, an CCXII, Vincent Fourmond a écrit : > The man pages show also no bold anymore. I give you a sample of my > .Xresource file, just to make sure I didn't do anything stupid in the > configuration: I know this problem. Try to add .VT100.VeryBoldColors: 6 to your XTerm resources.
