NetBSD Problem Report #59051

From www@netbsd.org  Fri Feb  7 11:27:41 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 4215F1A923A
	for <gnats-bugs@gnats.NetBSD.org>; Fri,  7 Feb 2025 11:27:41 +0000 (UTC)
Message-Id: <20250207112739.C33321A923C@mollari.NetBSD.org>
Date: Fri,  7 Feb 2025 11:27:39 +0000 (UTC)
From: jon.brase@gmail.com
Reply-To: jon.brase@gmail.com
To: gnats-bugs@NetBSD.org
Subject: edt-1.9's "keypad_configure" function performs global configuration of remote X session
X-Send-Pr-Version: www-1.0

>Number:         59051
>Category:       misc
>Synopsis:       edt-1.9's "keypad_configure" function performs global configuration of remote X session
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    misc-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Feb 07 11:30:01 +0000 2025
>Last-Modified:  Sun Feb 16 07:50:01 +0000 2025
>Originator:     Jon Brase
>Release:        10.1
>Organization:
N/A
>Environment:
NetBSD <hostname redacted> 10.1 NetBSD 10.1 (GENERIC) #0: Mon Dec 16 13:08:11 UTC 2024  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/vax/compile/GENERIC vax
>Description:
The "edt" editor has a function that tries to determine what character sequences keys on the user's keypad produce. The first phase opens an X11 window (the editor does not seem to otherwise use X) and asks the user to type a sequence of keys into that window, then a phase is run that asks the user to type different keys into the terminal window. After both phases have run, edt asks if the user wishes to commit the keybindings determined from the probe to a file, which can then be passed in to future invocations of edt with the EDT_KEYPAD_SETUP environment variable.

My impression was that this process only probes what keycodes are produced and does not configure anything outside of edt itself, and that the configuration for edt that is produced only takes effect if the appropriate environment variable is set.

However, even if the process is aborted before edt saves the resulting configuration to disk, the phase that opens the X11 window appears to actually somehow affect global configuration on the X Server, and to do so over forwarded X sessions! (But I suppose the last bit is the price you pay for network transparency...).

Specifically, after running keypad_configure on a remote instance of edt, Num Lock no longer responds on my local machine, and numpad keys now generate responses for local X11 clients that are not consistent with their normal num-lock-on or num-lock-off functions.
>How-To-Repeat:
Remote machine setup:

Install NetBSD 10.01 Vax on simh (or other Vax emulator)

Configure sshd to forward X11

Install edt


Local machine setup:

Install x86_64 Kubuntu 22.04 on a VM (or use an existing install on real hardware, but be aware that successful reproduction of the issue will cause potentially annoying reconfiguration of the keymapping for your keypad).

Connect to the Vax system with ssh -X.

Run edt (preferably for the first time since installed).

Once the editor presents you with a prompt, run "keypad_configure", follow the instructions on screen.
>Fix:
No fix is known.

I'm not sure if the issue at hand counts as a "bug" in the original context edt was written in, but edt appears to make assumptions about the environment that it is running in that are not appropriate on modern platforms. Whether the functionality provided by "keypad_configure" is still relevant and/or whether it can be implemented in friendlier ways is to be considered.

Also, while given that behavior at hand provides a great object lesson on the security implications of X11 forwarding, it is probably best not to include functionality in an X client that is likely to produce surprises in that environment.

I have not yet attempted logging out and restarting X on the server end as I have ongoing work I'm attempting to finish. Depending on whether the configuration changes persist beyond the end of the X session, I may need assistance in determining what changes edt actually made so that they can be reverted.

>Audit-Trail:
From: RVP <rvp@SDF.ORG>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: misc/59051: edt-1.9's "keypad_configure" function performs global
 configuration of remote X session
Date: Tue, 11 Feb 2025 07:48:35 +0000 (UTC)

 On Fri, 7 Feb 2025, jon.brase@gmail.com wrote:

 > However, even if the process is aborted before edt saves the resulting configuration to disk, the phase that opens the X11 window appears to actually somehow affect global configuration on the X Server, and to do so over forwarded X sessions! (But I suppose the last bit is the price you pay for network transparency...).
 >
 > Specifically, after running keypad_configure on a remote instance of edt, Num Lock no longer responds on my local machine, and numpad keys now generate responses for local X11 clients that are not consistent with their normal num-lock-on or num-lock-off functions.
 >

 This version of EDT uses xmodmap to remap keys, and running xmodmap _will_
 change the way keys are interpreted on the X server (whether local or remote).

 >From a quick scan of the source (I know nothing about EDT), it looks like
 there is a `rk' command which can be used to "restore" the num keypad to its
 orig. state...but, this doesn't work because:

 1. There's a bug in the source (patch for this below) for the command.

 2. Even if this bug was fixed, the `rk' command would only work _after_ this
     config was saved--ie. after you get an .xml file which can be passed via
     `EDT_KEYPAD_SETUP=...'. The first time through, you get a messed up keyboard
     state as you found out.

 3. and even if you did manage all that (by saving and restoring the keyboard
     config.), the `rk' command would still not restore the old keys correctly
     because it only restores the 1st set of keysyms (corresponding to the
     normal keys). Since this is the num keypad we're dealing with, one has to
     save and put back the keysyms for the other modifier keys too:

  	$ xmodmap -pke | fgrep KP_Home
  	keycode  79 = KP_Home KP_7 KP_Home KP_7
  	$

     This, EDT doesn't do, so the num keypad is still wonky after a manual `rk'
     before exiting.

 So, this isn't a NetBSD bug at all, and edt-1.9 will have to be fixed. Until
 then you could save and restore the keymaps explicitly:

 ```
 #!/bin/sh
 #
 # https://www.gnu.org/software/emacs/manual/html_mono/edt.html

 KEYMAP=/tmp/xmodmap.$$

 # Save current keymap.
 #
 xmodmap -pke > $KEYMAP

 # Restore orig. keymap on exit.
 #
 trap 'test -s $KEYMAP && xmodmap $KEYMAP; rm -f $KEYMAP' 0 1 2 3 15

 if [ -f /PATH/TO/edt_keypad.xml ]
 then	export EDT_KEYPAD_SETUP=/PATH/TO/edt_keypad.xml
 fi

 /PATH/TO/edt "$@"
 ```

 Or, try out a different version of EDT:

 http://www.o3one.org/edt.html

 This one only needed 2 minor changes for NetBSD:

 - adding `#include <sys/ioctl.h>' to os.c, and,
 - changing `-lreadline' to `-ledit' to make it use NetBSD's editline(3) library
    instead of readline(3).

 HTH,

 -RVP

 ```
 diff -urN edt_1.9.orig/edt_1.9.c edt_1.9/edt_1.9.c
 --- edt_1.9.orig/edt_1.9.c	2012-01-01 12:24:03.000000000 +0000
 +++ edt_1.9/edt_1.9.c	2025-02-08 08:24:05.561453444 +0000
 @@ -828,7 +828,7 @@
             xml_grab_attrib( tag, name, mapto, MAXSTR );
   	  if (strcmp(name,"mapto") != 0)
   	   printf("Error: Reading keypad setup, expected 'mapto' in key_set tag, but found '%s',\n",name);
 -	  sprintf(cmd,"xmodmap xmodmap -e \"keycode %d = %s\"", keyval, mapto );
 +	  sprintf(cmd,"xmodmap -e \"keycode %d = %s\"", keyval, mapto );
   	  system( cmd );
   	  setnum++;
           } /*key_set*/
 ```

From: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: misc/59051: edt-1.9's "keypad_configure" function performs
 global configuration of remote X session
Date: Tue, 11 Feb 2025 09:02:43 +0100

 On Tue, Feb 11, 2025 at 07:50:02AM +0000, RVP via gnats wrote:
 >  Or, try out a different version of EDT:
 >  
 >  http://www.o3one.org/edt.html

 I've just packaged this as pkgsrc/editors/edt-o3one.

 Cheers,
  Thomas

From: RVP <rvp@SDF.ORG>
To: gnats-bugs@netbsd.org
Cc: jon.brase@gmail.com, wiz@netbsd.org
Subject: Re: misc/59051: edt-1.9's "keypad_configure" function performs global
 configuration of remote X session
Date: Sat, 15 Feb 2025 22:56:16 +0000 (UTC)

 On Tue, 11 Feb 2025, Thomas Klausner via gnats wrote:

 > On Tue, Feb 11, 2025 at 07:50:02AM +0000, RVP via gnats wrote:
 > >  Or, try out a different version of EDT:
 > >
 > >  http://www.o3one.org/edt.html
 >
 > I've just packaged this as pkgsrc/editors/edt-o3one.
 >

 Oh, thanks, but you'll need a patch like this if the `edt.hlp' file is not in
 the same dir. as the executable itself (which is what this prog. expects):

 ```
 diff -urN edtdist_20161222.orig/makefile edtdist_20161222/makefile
 --- edtdist_20161222.orig/makefile	2016-12-23 00:28:13.000000000 +0000
 +++ edtdist_20161222/makefile	2025-02-15 22:45:23.851226174 +0000
 @@ -119,7 +119,7 @@
   	$(CC) md5.c

   os.linux.o: os.c
 -	$(CC) -DUSE_LIBREADLINE -o os.linux.o os.c
 +	$(CC) -DUSE_LIBREADLINE -DEDT_HELPFILE=\"${EDT_HELPFILE}\" -o os.linux.o os.c

   output.o: output.c
   	$(CC) output.c
 diff -urN edtdist_20161222.orig/os.c edtdist_20161222/os.c
 --- edtdist_20161222.orig/os.c	2016-12-23 00:35:48.000000000 +0000
 +++ edtdist_20161222/os.c	2025-02-15 22:46:27.605856430 +0000
 @@ -265,6 +265,14 @@
       abort ();
     }

 +#ifdef EDT_HELPFILE
 +  help_name = malloc(strlen(EDT_HELPFILE) + 1);
 +  if (help_name == NULL) {
 +    fprintf (stderr, "out of memory\n");
 +    exit (1); 
 +  }
 +  strcpy(help_name, EDT_HELPFILE);
 +#else
     /* Try to find help file - same directory as executable */

     pathstring = NULL;						/* haven't allocated a string yet */
 @@ -303,6 +311,7 @@
     strcat (help_name, ".hlp");					/* append .hlp for the help file name */

     if (pathstring != NULL) string_delete (pathstring);		/* free off string if we allocated one */
 +#endif

   #endif

 ```

 Compile as (usual):

  	make EDT_HELPFILE=/PATH/TO/edt.hlp

 -RVP

From: Thomas Klausner <wiz@netbsd.org>
To: RVP <rvp@SDF.ORG>
Cc: gnats-bugs@netbsd.org
Subject: Re: misc/59051: edt-1.9's "keypad_configure" function performs
 global configuration of remote X session
Date: Sun, 16 Feb 2025 00:06:30 +0100

 On Sat, Feb 15, 2025 at 10:56:16PM +0000, RVP wrote:
 > Oh, thanks, but you'll need a patch like this if the `edt.hlp' file is not in
 > the same dir. as the executable itself (which is what this prog. expects):

 Thank you, I've applied your changes to the package!
  Thomas

From: "Thomas Klausner" <wiz@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/59051 CVS commit: pkgsrc/editors/edt-o3one
Date: Sat, 15 Feb 2025 23:06:05 +0000

 Module Name:	pkgsrc
 Committed By:	wiz
 Date:		Sat Feb 15 23:06:05 UTC 2025

 Modified Files:
 	pkgsrc/editors/edt-o3one: Makefile distinfo
 	pkgsrc/editors/edt-o3one/patches: patch-os.c
 Added Files:
 	pkgsrc/editors/edt-o3one/patches: patch-makefile

 Log Message:
 edt-o3one: fix help file handling

 From RVP in PR 59051.

 Bump PKGREVISION.


 To generate a diff of this commit:
 cvs rdiff -u -r1.2 -r1.3 pkgsrc/editors/edt-o3one/Makefile
 cvs rdiff -u -r1.1 -r1.2 pkgsrc/editors/edt-o3one/distinfo
 cvs rdiff -u -r0 -r1.1 pkgsrc/editors/edt-o3one/patches/patch-makefile
 cvs rdiff -u -r1.1 -r1.2 pkgsrc/editors/edt-o3one/patches/patch-os.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

Home	PR Database Search