Re: syslogd TLS verify
On Sat, Jan 24, 2015 at 07:05:43PM -0500, Ted Unangst wrote: > I think it would be better to do as ftp(1) does and have one > command line option that sets all the options, instead of exploding > getopt() with every possibility. I have copied the -S ssl_options from ftp(1) except CA path, which does not work with privsep. When I tested it with bad cipers it crashed because the tls connect callback was not set when the error occured. So I fixed that in buffertls_connect(). ok? bluhm Index: usr.sbin/syslogd/evbuffer_tls.c === RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/evbuffer_tls.c,v retrieving revision 1.1 diff -u -p -r1.1 evbuffer_tls.c --- usr.sbin/syslogd/evbuffer_tls.c 18 Jan 2015 19:37:59 - 1.1 +++ usr.sbin/syslogd/evbuffer_tls.c 26 Jan 2015 01:40:35 - @@ -287,7 +287,8 @@ buffertls_connect(struct buffertls *buft event_del(&bufev->ev_write); buftls->bt_hostname = hostname; - buffertls_connectcb(fd, 0, buftls); + event_set(&bufev->ev_write, fd, EV_WRITE, buffertls_connectcb, buftls); + bufferevent_add(&bufev->ev_write, bufev->timeout_write); } /* Index: usr.sbin/syslogd/syslogd.c === RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/syslogd.c,v retrieving revision 1.144 diff -u -p -r1.144 syslogd.c --- usr.sbin/syslogd/syslogd.c 19 Jan 2015 16:40:49 - 1.144 +++ usr.sbin/syslogd/syslogd.c 26 Jan 2015 01:48:25 - @@ -141,6 +141,7 @@ struct filed { struct buffertls f_buftls; struct bufferevent *f_bufev; struct tls *f_ctx; + char*f_host; int f_reconnectwait; } f_forw; /* forwarding address */ charf_fname[PATH_MAX]; @@ -215,6 +216,25 @@ intIncludeHostname = 0;/* include RFC char *path_ctlsock = NULL; /* Path to control socket */ +char *const ssl_verify_opts[] = { +#define SSL_CAFILE 0 + "cafile", +#define SSL_CIPHERS 1 + "ciphers", +#define SSL_DONTVERIFY 2 + "dont", +#define SSL_DOVERIFY3 + "do", +#define SSL_VERIFYDEPTH 4 + "depth", + NULL +}; +struct tls_config *tls_config; +const char *CAfile = "/etc/ssl/cert.pem"; /* file containing certificates */ +const char *Ciphers = NULL; /* list of ciphers that may be used */ +intVerify = 1; /* do verify TLS server x509 certificate */ +intDepth = -1; /* TLS verify depth */ + #define CTL_READING_CMD1 #define CTL_WRITING_REPLY 2 #define CTL_WRITING_CONT_REPLY 3 @@ -312,11 +332,11 @@ main(int argc, char *argv[]) { struct addrinfo hints, *res, *res0; struct timeval to; - char*p; + char*cp, *p; int ch, i; int lockpipe[2] = { -1, -1}, pair[2], nullfd, fd; - while ((ch = getopt(argc, argv, "46dhnuf:m:p:a:s:")) != -1) + while ((ch = getopt(argc, argv, "46dhnuf:m:p:a:s:S:")) != -1) switch (ch) { case '4': /* disable IPv6 */ IPv4Only = 1; @@ -349,8 +369,7 @@ main(int argc, char *argv[]) break; case 'a': if (nunix >= MAXUNIX) - fprintf(stderr, "syslogd: " - "out of descriptors, ignoring %s\n", + warnx("out of descriptors, ignoring %s\n", optarg); else path_unix[nunix++] = optarg; @@ -358,6 +377,49 @@ main(int argc, char *argv[]) case 's': path_ctlsock = optarg; break; + case 'S': + cp = optarg; + while (*cp) { + char *str; + const char *errstr; + + switch (getsubopt(&cp, ssl_verify_opts, &str)) { + case SSL_CAFILE: + if (str == NULL) + warnx("missing CA file"); + else + CAfile = str; + break; + case SSL_CIPHERS: + if (str == NULL) + warnx("missing cipher list"); + else + Ciphers = str; + break; +
Re: elantech-v4 clickpad support
On Wed, Jan 14, 2015 at 12:23:13AM +0100, Ulf Brosziewski wrote: > Currently pms and the wsconscomm module of the synaptics driver offer a > somewhat limited support for Elantech clickpads with hardware version 4. > Above all, I missed the options of performing click-and-drag operations > with two fingers and of using a "soft button area" for the emulation of > right button clicks (tap-and-drag and two-finger tapping are no > alternatives for me, usually I don't enable tapping). > > I have written two patches that provide these options (I'm using them > on an Acer V5-131 netbook with OpenBSD 5.6/amd64, the clickpad hardware > and firmware is identified as "Elantech Clickpad, version 4, firmware > 0x461f02"). There is, however, an open question concerning wsconscomm. > If someone is interested in testing and using the patches, or in > assessing whether they can be useful for the OpenBSD project, some > explanations might help. > > Two-finger scrolling and click-and-drag actions on clickpads require > that the multitouch input is filtered or "translated" into coherent > sequences of coordinate pairs. The pms patch - which I have added > below - implements a simple filter that checks the motion deltas and > ensures that if there is at least one finger moving on the clickpad, a > moving one will be tracked. Some care is needed when the input "slot" > changes, but this works well even within the infrastructure of wscons, > which doesn't define and handle "MT" events. > > The problem with wsconscomm is related to the X/Linux way of handling > multitouches. If I understand it correctly, it produces MT events with > slot data as well as standard events with coordinates for "pointer > control", and the latter are determined by the "oldest" touch. That > mechanism is sufficient if two fingers are moving in parallel, but it > cannot cover the click-and-drag case because usually only one finger > is moving, and it is not necessarily the one that has touched the > clickpad first. This might be the reason why the synaptics driver > implements an additional mapping. It accumulates the motion deltas > of the multitouch slots in a special coordinate pair. As long as no > button is pressed, the pair isn't used, and its values will be > synchronized with the standard coordinates. When clickpad support is > enabled ("$ synclient ClickPad=1") and a button is down, the > "cumulative" values will be used. This makes the cursor movement > independent of the order of touches (and you can create, e.g., a > diagonal cursor movement by combining a horizontal and a vertical > finger movement). > > It seems that the current development version of the synaptics driver > applies the cumulative coordinates to two-finger-scrolling as well > (independently of clickpad support). > > In OpenBSD wsconscomm updates the cumulative coordinates when no > button is being pressed, but it does nothing with them otherwise. If > clickpad support is enabled, this has the effect that the X cursor > "freezes" as long as the clickpad button is down, and no click-and- > drag operation - not even the one-finger variant - is possible (for > this reason I couldn't use soft button areas, which require the > clickpad support). > > As wsconscomm doesn't deal with MT events, couldn't it simply always > keep the coordinates in sync? To make click-and-drag work in my > installation I have applied the following patch to wsconscomm.c: > > diff --git a/wsconscomm.c b/wsconscomm.c > index 0e0c81d..a6540db 100644 > --- a/wsconscomm.c > +++ b/wsconscomm.c > @@ -131,12 +131,6 @@ WSConsReadHwState(InputInfoPtr pInfo, > struct wscons_event event; > Bool v; > > -/* Reset cumulative values if buttons were not previously pressed */ > -if (!hw->left && !hw->right && !hw->middle) { > -hw->cumulative_dx = hw->x; > -hw->cumulative_dy = hw->y; > -} > - > while (WSConsReadEvent(pInfo, &event)) { > switch (event.type) { > case WSCONS_EVENT_MOUSE_UP: > @@ -186,9 +180,11 @@ WSConsReadHwState(InputInfoPtr pInfo, > break; > case WSCONS_EVENT_MOUSE_ABSOLUTE_X: > hw->x = event.value; > +hw->cumulative_dx = hw->x; > break; > case WSCONS_EVENT_MOUSE_ABSOLUTE_Y: > hw->y = priv->maxy - event.value + priv->miny; > +hw->cumulative_dy = hw->y; > break; > case WSCONS_EVENT_MOUSE_ABSOLUTE_Z: > hw->z = event.value; > > Please note that this patch might "unmask" an inconsistent treatment > of multitouches. For example, if I use it without applying the pms > patch, an attempt to click-and-drag can lead to jumps of the cursor > and inverted vertical movements. Could something similar happen with > other hardware where clickpad support would make sense? And if this > is the case, could the change in wsconscomm be restricted in a > reasonable way? > Sorry for the long answer. I tested xenocara part on x201(
Re: [patch] xdm doesn't clear wtmp/utmp entry after log out
On Tue, Jan 13, 2015 at 01:38:36PM -0800, patrick keshishian wrote: > Hi, > > I've noticed this issue for sometime now. I was hoping one > of the Xorg updates would fix it, so finally I decided to > read some man pages, specifically sessreg. > > Evidently the Xservers path is not correct (or has changed) > in OBSD's install. No longer found at: > > /usr/X11R6/lib/X11/xdm/Xservers > is at: > /etc/X11/xdm/Xservers > > [pre-patch] > Log into X using xdm, then log out. Alt+Ctrl+F1 login and > run last as such: > $ last -5 > sidster : Tue Jan 13 12:01 still logged in > sidster ttyC0 Sat Jan 10 16:35 still logged in > reboot~ Sat Jan 10 16:35 > shutdown ~ Sat Jan 10 16:34 > root ttyC0 Sat Jan 10 16:28 - shutdown > (00:06) > > [post-patch below (loally modified files)] > Same procedure as above: > $ last -5 > sidster : Tue Jan 13 13:23 - 13:24 (00:00) > sidster : Tue Jan 13 12:01 - 13:23 (01:22) > sidster ttyC0 Sat Jan 10 16:35 still logged in > reboot~ Sat Jan 10 16:35 > shutdown ~ Sat Jan 10 16:34 > > This is on: > kern.version=OpenBSD 5.7-beta (GENERIC) #701: Sat Jan 10 07:52:06 MST 2015 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > > > Index: GiveConsole > === > RCS file: /cvs/obsd/xenocara/app/xdm/config/GiveConsole,v > retrieving revision 1.4 > diff -u -p -u -p -r1.4 GiveConsole > --- GiveConsole 18 Nov 2013 20:39:48 - 1.4 > +++ GiveConsole 13 Jan 2015 21:26:24 - > @@ -11,4 +11,4 @@ chown $USER /dev/console > if [ -c /dev/drm0 ]; then > chown $USER /dev/drm0 > fi > -/usr/X11R6/bin/sessreg -a -l $DISPLAY -u none -x > /usr/X11R6/lib/X11/xdm/Xservers $USER > +/usr/X11R6/bin/sessreg -a -l $DISPLAY -u none -x /etc/X11/xdm/Xservers $USER > Index: TakeConsole > === > RCS file: /cvs/obsd/xenocara/app/xdm/config/TakeConsole,v > retrieving revision 1.4 > diff -u -p -u -p -r1.4 TakeConsole > --- TakeConsole 18 Nov 2013 20:39:48 - 1.4 > +++ TakeConsole 13 Jan 2015 21:26:24 - > @@ -8,4 +8,4 @@ chown root /dev/console > if [ -c /dev/drm0 ]; then > chown root /dev/drm0 > fi > -/usr/X11R6/bin/sessreg -d -l $DISPLAY -u /var/run/utmp -x > /usr/X11R6/lib/X11/xdm/Xservers $USER > +/usr/X11R6/bin/sessreg -d -l $DISPLAY -u /var/run/utmp -x > /etc/X11/xdm/Xservers $USER > Makes sense. ok matthieu@ -- Matthieu Herrb