syslogd multiple listen addresses

2016-12-30 Thread Alexander Bluhm
Hi,

Currently syslogd accepts network input only for either IPv4 or
IPv6.  To overcome this limitation, allow to specify more than one
listen addresses.

As multiple TLS contexts need more thought, implement it only for
TCP and UDP sockets now.

ok?

bluhm

Index: usr.sbin/syslogd/syslogd.8
===
RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/syslogd.8,v
retrieving revision 1.52
diff -u -p -r1.52 syslogd.8
--- usr.sbin/syslogd/syslogd.8  17 Oct 2016 11:19:55 -  1.52
+++ usr.sbin/syslogd/syslogd.8  30 Dec 2016 23:48:23 -
@@ -174,6 +174,10 @@ This includes the year and the timezone,
 in UTC.
 .El
 .Pp
+The options
+.Fl a , Fl T , Fl U
+can be given more than once to specify multiple input sources.
+.Pp
 .Nm
 reads its configuration file,
 .Xr syslog.conf 5 ,
Index: usr.sbin/syslogd/syslogd.c
===
RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/syslogd.c,v
retrieving revision 1.226
diff -u -p -r1.226 syslogd.c
--- usr.sbin/syslogd/syslogd.c  30 Dec 2016 23:21:26 -  1.226
+++ usr.sbin/syslogd/syslogd.c  30 Dec 2016 23:33:40 -
@@ -214,13 +214,6 @@ intNoDNS = 0;  /* when true, refrain fr
 intZuluTime = 0;   /* display date and time in UTC ISO format */
 intIncludeHostname = 0;/* include RFC 3164 hostnames when forwarding */
 intFamily = PF_UNSPEC; /* protocol family, may disable IPv4 or IPv6 */
-char   *bind_host = NULL;  /* bind UDP receive socket */
-char   *bind_port = NULL;
-char   *listen_host = NULL;/* listen on TCP receive socket */
-char   *listen_port = NULL;
-char   *tls_hostport = NULL;   /* listen on TLS receive socket */
-char   *tls_host = NULL;
-char   *tls_port = NULL;
 char   *path_ctlsock = NULL;   /* Path to control socket */
 
 struct tls *server_ctx;
@@ -340,6 +333,7 @@ voidusage(void);
 void   wallmsg(struct filed *, struct iovec *);
 intloghost_parse(char *, char **, char **, char **);
 intgetmsgbufsize(void);
+void   address_alloc(const char *, const char *, char ***, char ***, int *);
 intsocket_bind(const char *, const char *, const char *, int,
 int *, int *);
 intunix_socket(char *, int, mode_t);
@@ -359,8 +353,10 @@ main(int argc, char *argv[])
char*p;
int  ch, i;
int  lockpipe[2] = { -1, -1}, pair[2], nullfd, fd;
-   int  fd_ctlsock, fd_klog, fd_sendsys, fd_bind, fd_listen;
-   int *fd_unix;
+   int  fd_ctlsock, fd_klog, fd_sendsys, *fd_bind, *fd_listen;
+   int *fd_unix, nbind, nlisten;
+   char**bind_host, **bind_port, **listen_host, **listen_port;
+   char*tls_hostport, *tls_host, *tls_port;
 
/* block signal until handler is set up */
sigemptyset();
@@ -373,6 +369,10 @@ main(int argc, char *argv[])
path_unix[0] = _PATH_LOG;
nunix = 1;
 
+   bind_host = bind_port = listen_host = listen_port = NULL;
+   tls_hostport = tls_host = NULL;
+   nbind = nlisten = 0;
+
while ((ch = getopt(argc, argv, "46a:C:c:dFf:hK:k:m:nP:p:S:s:T:U:uVZ"))
!= -1)
switch (ch) {
@@ -385,7 +385,7 @@ main(int argc, char *argv[])
case 'a':
if ((path_unix = reallocarray(path_unix, nunix + 1,
sizeof(*path_unix))) == NULL)
-   err(1, "malloc %s", optarg);
+   err(1, "unix path %s", optarg);
path_unix[nunix++] = optarg;
break;
case 'C':   /* file containing CA certificates */
@@ -440,18 +440,12 @@ main(int argc, char *argv[])
path_ctlsock = optarg;
break;
case 'T':   /* allow tcp and listen on address */
-   if ((p = strdup(optarg)) == NULL)
-   err(1, "strdup listen address");
-   if (loghost_parse(p, NULL, _host, _port)
-   == -1)
-   errx(1, "bad listen address: %s", optarg);
+   address_alloc("listen", optarg, _host,
+   _port, );
break;
case 'U':   /* allow udp only from address */
-   if ((p = strdup(optarg)) == NULL)
-   err(1, "strdup bind address");
-   if (loghost_parse(p, NULL, _host, _port)
-   == -1)
-   errx(1, "bad bind address: %s", optarg);
+   address_alloc("bind", optarg, _host, _port,
+   );
break;
case 'u':   /* allow 

Re: snapshot installs

2016-12-30 Thread Benjamin Baier
On Fri, 30 Dec 2016 11:30:10 -0700
Theo de Raadt  wrote:

> I'm wondering if anyone doing an install/upgrade has noticed any
> behaviour changes in the last week...
Did an auto_upgrade with pre-downloaded sets today. Got curious and did one
normal/manual update again from a mirror. No regressions.

> There's a secret diff being tested :-)
Found it. It's in install.sub in bsd.rd's ramdisk.



arm: remove pio.h and isa_machdep.h

2016-12-30 Thread Jeremie Courreges-Anglas

As discussed, these files aren't used and aren't useful.  make build +
make release are ok with this.

(Well, make release is ok until
  COPY/usr/local/share/u-boot/am335x_boneblack/MLO/usr/mdec/am335x/MLO
  cp: /usr/local/share/u-boot/am335x_boneblack/MLO: No such file or directory
because I don't have u-boot installed.)

ok to remove them?


Index: arch/arm/include/isa_machdep.h
===
RCS file: arch/arm/include/isa_machdep.h
diff -N arch/arm/include/isa_machdep.h
--- arch/arm/include/isa_machdep.h  23 Mar 2011 16:54:34 -  1.7
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,176 +0,0 @@
-/* $OpenBSD: isa_machdep.h,v 1.7 2011/03/23 16:54:34 pirofti Exp $ */
-/* $NetBSD: isa_machdep.h,v 1.3 2002/01/07 22:58:07 chris Exp $*/
-
-/*-
- * Copyright (c) 1996, 1997, 1998 The NetBSD Foundation, Inc.
- * All rights reserved.
- *
- * This code is derived from software contributed to The NetBSD Foundation
- * by Jason R. Thorpe of the Numerical Aerospace Simulation Facility,
- * NASA Ames Research Center.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- *
- * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
- * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
- * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
- * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
- * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
- * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
- * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
- * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
- * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
- * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
- * POSSIBILITY OF SUCH DAMAGE.
- */
-
-#ifndef _ARM_ISA_MACHDEP_H_
-#define _ARM_ISA_MACHDEP_H_
-
-#include 
-#include 
-
-#define __NO_ISA_INTR_CHECK
-/*
- * Types provided to machine-independent ISA code.
- */
-struct arm32_isa_chipset {
-   /*
-   struct isa_dma_state ic_dmastate;
-   */
-};
-
-typedef struct arm32_isa_chipset *isa_chipset_tag_t;
-
-struct device; /* XXX */
-struct isabus_attach_args; /* XXX */
-
-/*
- * Functions provided to machine-independent ISA code.
- */
-void   isa_attach_hook(struct device *, struct device *,
-   struct isabus_attach_args *);
-void   *isa_intr_establish(isa_chipset_tag_t ic, int irq, int type,
-   int level, int (*ih_fun)(void *), void *ih_arg, char *name);
-void   isa_intr_disestablish(isa_chipset_tag_t ic, void *handler);
-
-#if 0
-#defineisa_dmainit(ic, bst, dmat, d)   
\
-   _isa_dmainit(&(ic)->ic_dmastate, (bst), (dmat), (d))
-#defineisa_dmacascade(ic, c)   
\
-   _isa_dmacascade(&(ic)->ic_dmastate, (c))
-#defineisa_dmamaxsize(ic, c)   
\
-   _isa_dmamaxsize(&(ic)->ic_dmastate, (c))
-#defineisa_dmamap_create(ic, c, s, f)  
\
-   _isa_dmamap_create(&(ic)->ic_dmastate, (c), (s), (f))
-#defineisa_dmamap_destroy(ic, c)   
\
-   _isa_dmamap_destroy(&(ic)->ic_dmastate, (c))
-#defineisa_dmastart(ic, c, a, n, p, f, bf) 
\
-   _isa_dmastart(&(ic)->ic_dmastate, (c), (a), (n), (p), (f), (bf))
-#defineisa_dmaabort(ic, c) 
\
-   _isa_dmaabort(&(ic)->ic_dmastate, (c))
-#defineisa_dmacount(ic, c) 
\
-   _isa_dmacount(&(ic)->ic_dmastate, (c))
-#defineisa_dmafinished(ic, c)  
\
-   _isa_dmafinished(&(ic)->ic_dmastate, (c))
-#defineisa_dmadone(ic, c)  
\
-   _isa_dmadone(&(ic)->ic_dmastate, (c))
-#defineisa_dmafreeze(ic)   
\
-   _isa_dmafreeze(&(ic)->ic_dmastate)
-#defineisa_dmathaw(ic) 
\
-   _isa_dmathaw(&(ic)->ic_dmastate)
-#defineisa_dmamem_alloc(ic, c, s, ap, f)   
\
-   _isa_dmamem_alloc(&(ic)->ic_dmastate, (c), (s), 

Re: snapshot installs

2016-12-30 Thread Ville Valkonen
On Dec 30, 2016 20:32, "Theo de Raadt"  wrote:

I'm wondering if anyone doing an install/upgrade has noticed any
behaviour changes in the last week...

There's a secret diff being tested :-)


Hello,

so far I haven't noticed anything peculiar. Two or three distinct machines,
two for surfing and one acting as a server.

Obviously quite well hidden and secret diff :)

--
Regards,
Ville


Re: syslogd block signals

2016-12-30 Thread Jeremie Courreges-Anglas
Alexander Bluhm  writes:

> On Mon, Dec 26, 2016 at 04:54:54PM -0700, Theo de Raadt wrote:
>> I think programs should only block the absolutely critical things, and this
>> is overreach.
>
> Yes, blocking SIGINT and SIGQUIT is not clever.  I thought there
> were races with SIGCHLD and SIGTERM where only one process would
> survive.  But races don't exist as parent and child communicate
> over the socketpair and terminate if the other one dies.
>
> I have seen problems with SIGHUP during debugging, instead of
> restarting syslogd died.  I think this could also happen during
> normal operation.
>
> - edit syslog.conf
> - send SIGHUP
> - syslogd execs itself
> - newsyslog rotates logfile and sends SIGHUP
> - syslogd dies as signal handlers are not installed yet
>
> So I suggest to block SIGHUP during startup.

ok jca@

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: snapshot installs

2016-12-30 Thread Dimitris Papastamos
On Fri, Dec 30, 2016 at 11:30:10AM -0700, Theo de Raadt wrote:
> I'm wondering if anyone doing an install/upgrade has noticed any
> behaviour changes in the last week...
> 
> There's a secret diff being tested :-)

i was building from source but just tried a snapshot

is it a scheduler or librthread change? :)



Re: syslogd block signals

2016-12-30 Thread Theo de Raadt
Yes, that's much better.  It solves the problem, without trying to
solve other problems which don't exist.

> On Mon, Dec 26, 2016 at 04:54:54PM -0700, Theo de Raadt wrote:
> > I think programs should only block the absolutely critical things, and this
> > is overreach.
> 
> Yes, blocking SIGINT and SIGQUIT is not clever.  I thought there
> were races with SIGCHLD and SIGTERM where only one process would
> survive.  But races don't exist as parent and child communicate
> over the socketpair and terminate if the other one dies.
> 
> I have seen problems with SIGHUP during debugging, instead of
> restarting syslogd died.  I think this could also happen during
> normal operation.
> 
> - edit syslog.conf
> - send SIGHUP
> - syslogd execs itself
> - newsyslog rotates logfile and sends SIGHUP
> - syslogd dies as signal handlers are not installed yet
> 
> So I suggest to block SIGHUP during startup.
> 
> bluhm
> 
> Index: usr.sbin/syslogd/privsep.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/privsep.c,v
> retrieving revision 1.65
> diff -u -p -r1.65 privsep.c
> --- usr.sbin/syslogd/privsep.c27 Dec 2016 19:16:24 -  1.65
> +++ usr.sbin/syslogd/privsep.c30 Dec 2016 18:24:00 -
> @@ -175,6 +175,7 @@ priv_exec(char *conf, int numeric, int c
>   struct stat cf_info, cf_stat;
>   struct addrinfo hints, *res0;
>   struct sigaction sa;
> + sigset_t sigmask;
>  
>   if (pledge("stdio rpath wpath cpath dns getpw sendfd id proc exec",
>   NULL) == -1)
> @@ -209,6 +210,10 @@ priv_exec(char *conf, int numeric, int c
>   setproctitle("[priv]");
>   logdebug("[priv]: fork+exec done\n");
>  
> + sigemptyset();
> + if (sigprocmask(SIG_SETMASK, , NULL) == -1)
> + err(1, "sigprocmask priv");
> +
>   if (stat(conf, _info) < 0)
>   err(1, "stat config file failed");
>  
> @@ -409,6 +414,10 @@ priv_exec(char *conf, int numeric, int c
>   int status;
>  
>   waitpid(child_pid, , 0);
> + sigemptyset();
> + sigaddset(, SIGHUP);
> + if (sigprocmask(SIG_SETMASK, , NULL) == -1)
> + err(1, "sigprocmask exec");
>   execvp(argv[0], argv);
>   err(1, "exec restart '%s' failed", argv[0]);
>   }
> Index: usr.sbin/syslogd/syslogd.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/syslogd.c,v
> retrieving revision 1.225
> diff -u -p -r1.225 syslogd.c
> --- usr.sbin/syslogd/syslogd.c27 Dec 2016 19:16:24 -  1.225
> +++ usr.sbin/syslogd/syslogd.c30 Dec 2016 17:55:37 -
> @@ -354,6 +354,7 @@ main(int argc, char *argv[])
>   struct event*ev_klog, *ev_sendsys, *ev_udp, *ev_udp6,
>   *ev_bind, *ev_listen, *ev_tls, *ev_unix,
>   *ev_hup, *ev_int, *ev_quit, *ev_term, *ev_mark;
> + sigset_t sigmask;
>   const char  *errstr;



Re: syslogd block signals

2016-12-30 Thread Alexander Bluhm
On Mon, Dec 26, 2016 at 04:54:54PM -0700, Theo de Raadt wrote:
> I think programs should only block the absolutely critical things, and this
> is overreach.

Yes, blocking SIGINT and SIGQUIT is not clever.  I thought there
were races with SIGCHLD and SIGTERM where only one process would
survive.  But races don't exist as parent and child communicate
over the socketpair and terminate if the other one dies.

I have seen problems with SIGHUP during debugging, instead of
restarting syslogd died.  I think this could also happen during
normal operation.

- edit syslog.conf
- send SIGHUP
- syslogd execs itself
- newsyslog rotates logfile and sends SIGHUP
- syslogd dies as signal handlers are not installed yet

So I suggest to block SIGHUP during startup.

bluhm

Index: usr.sbin/syslogd/privsep.c
===
RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/privsep.c,v
retrieving revision 1.65
diff -u -p -r1.65 privsep.c
--- usr.sbin/syslogd/privsep.c  27 Dec 2016 19:16:24 -  1.65
+++ usr.sbin/syslogd/privsep.c  30 Dec 2016 18:24:00 -
@@ -175,6 +175,7 @@ priv_exec(char *conf, int numeric, int c
struct stat cf_info, cf_stat;
struct addrinfo hints, *res0;
struct sigaction sa;
+   sigset_t sigmask;
 
if (pledge("stdio rpath wpath cpath dns getpw sendfd id proc exec",
NULL) == -1)
@@ -209,6 +210,10 @@ priv_exec(char *conf, int numeric, int c
setproctitle("[priv]");
logdebug("[priv]: fork+exec done\n");
 
+   sigemptyset();
+   if (sigprocmask(SIG_SETMASK, , NULL) == -1)
+   err(1, "sigprocmask priv");
+
if (stat(conf, _info) < 0)
err(1, "stat config file failed");
 
@@ -409,6 +414,10 @@ priv_exec(char *conf, int numeric, int c
int status;
 
waitpid(child_pid, , 0);
+   sigemptyset();
+   sigaddset(, SIGHUP);
+   if (sigprocmask(SIG_SETMASK, , NULL) == -1)
+   err(1, "sigprocmask exec");
execvp(argv[0], argv);
err(1, "exec restart '%s' failed", argv[0]);
}
Index: usr.sbin/syslogd/syslogd.c
===
RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/syslogd.c,v
retrieving revision 1.225
diff -u -p -r1.225 syslogd.c
--- usr.sbin/syslogd/syslogd.c  27 Dec 2016 19:16:24 -  1.225
+++ usr.sbin/syslogd/syslogd.c  30 Dec 2016 17:55:37 -
@@ -354,6 +354,7 @@ main(int argc, char *argv[])
struct event*ev_klog, *ev_sendsys, *ev_udp, *ev_udp6,
*ev_bind, *ev_listen, *ev_tls, *ev_unix,
*ev_hup, *ev_int, *ev_quit, *ev_term, *ev_mark;
+   sigset_t sigmask;
const char  *errstr;
char*p;
int  ch, i;
@@ -361,6 +362,12 @@ main(int argc, char *argv[])
int  fd_ctlsock, fd_klog, fd_sendsys, fd_bind, fd_listen;
int *fd_unix;
 
+   /* block signal until handler is set up */
+   sigemptyset();
+   sigaddset(, SIGHUP);
+   if (sigprocmask(SIG_SETMASK, , NULL) == -1)
+   err(1, "sigprocmask block");
+
if ((path_unix = malloc(sizeof(*path_unix))) == NULL)
err(1, "malloc %s", _PATH_LOG);
path_unix[0] = _PATH_LOG;
@@ -839,6 +846,10 @@ main(int argc, char *argv[])
 
logmsg(LOG_SYSLOG|LOG_INFO, "syslogd: start", LocalHostName, ADDDATE);
logdebug("syslogd: started\n");
+
+   sigemptyset();
+   if (sigprocmask(SIG_SETMASK, , NULL) == -1)
+   err(1, "sigprocmask unblock");
 
event_dispatch();
/* NOTREACHED */




snapshot installs

2016-12-30 Thread Theo de Raadt
I'm wondering if anyone doing an install/upgrade has noticed any
behaviour changes in the last week...

There's a secret diff being tested :-)



Re: if attach/detach netlocks

2016-12-30 Thread Mike Belopuhov
On Thu, Dec 29, 2016 at 09:30 +0100, Martin Pieuchot wrote:
> On 29/12/16(Thu) 01:15, Alexander Bluhm wrote:
> > On Fri, Dec 23, 2016 at 12:09:32AM +0100, Martin Pieuchot wrote:
> > > On 22/12/16(Thu) 20:45, Mike Belopuhov wrote:
> > > > I think this is what is required here.  Works here, but YMMV.
> > > 
> > > splnet() in a pseudo-driver seems completely wrong, you could get rid of
> > > it.
> > 
> > Yes, but that is another issue.  Can we get the netlock splasserts
> > fixed first?  This diff looks good to me.
> 
> Sure I'm ok with the diff.
> 

I agree with Martin and have cooked a diff but couldn't test it yet.
This is it for the reference.

diff --git sys/net/if_vxlan.c sys/net/if_vxlan.c
index e9bc1cb8305..74437b8b79c 100644
--- sys/net/if_vxlan.c
+++ sys/net/if_vxlan.c
@@ -178,13 +178,13 @@ int
 vxlan_clone_destroy(struct ifnet *ifp)
 {
struct vxlan_softc  *sc = ifp->if_softc;
int  s;
 
-   s = splnet();
+   NET_LOCK(s);
vxlan_multicast_cleanup(ifp);
-   splx(s);
+   NET_UNLOCK(s);
 
vxlan_enable--;
LIST_REMOVE(sc, sc_entry);
 
ifmedia_delete_instance(>sc_media, IFM_INST_ANY);
@@ -392,11 +392,11 @@ int
 vxlanioctl(struct ifnet *ifp, u_long cmd, caddr_t data)
 {
struct vxlan_softc  *sc = (struct vxlan_softc *)ifp->if_softc;
struct ifreq*ifr = (struct ifreq *)data;
struct if_laddrreq  *lifr = (struct if_laddrreq *)data;
-   int  error = 0, s;
+   int  error = 0;
 
switch (cmd) {
case SIOCSIFADDR:
ifp->if_flags |= IFF_UP;
/* FALLTHROUGH */
@@ -417,24 +417,20 @@ vxlanioctl(struct ifnet *ifp, u_long cmd, caddr_t data)
case SIOCSIFMEDIA:
error = ifmedia_ioctl(ifp, ifr, >sc_media, cmd);
break;
 
case SIOCSLIFPHYADDR:
-   s = splnet();
error = vxlan_config(ifp,
(struct sockaddr *)>addr,
(struct sockaddr *)>dstaddr);
-   splx(s);
break;
 
case SIOCDIFPHYADDR:
-   s = splnet();
vxlan_multicast_cleanup(ifp);
bzero(>sc_src, sizeof(sc->sc_src));
bzero(>sc_dst, sizeof(sc->sc_dst));
sc->sc_dstport = htons(VXLAN_PORT);
-   splx(s);
break;
 
case SIOCGLIFPHYADDR:
if (sc->sc_dst.ss_family == AF_UNSPEC) {
error = EADDRNOTAVAIL;
@@ -451,14 +447,12 @@ vxlanioctl(struct ifnet *ifp, u_long cmd, caddr_t data)
ifr->ifr_rdomainid > RT_TABLEID_MAX ||
!rtable_exists(ifr->ifr_rdomainid)) {
error = EINVAL;
break;
}
-   s = splnet();
sc->sc_rdomain = ifr->ifr_rdomainid;
(void)vxlan_config(ifp, NULL, NULL);
-   splx(s);
break;
 
case SIOCGLIFPHYRTABLE:
ifr->ifr_rdomainid = sc->sc_rdomain;
break;
@@ -468,14 +462,12 @@ vxlanioctl(struct ifnet *ifp, u_long cmd, caddr_t data)
error = EINVAL;
break;
}
if (sc->sc_ttl == (u_int8_t)ifr->ifr_ttl)
break;
-   s = splnet();
sc->sc_ttl = (u_int8_t)(ifr->ifr_ttl);
(void)vxlan_config(ifp, NULL, NULL);
-   splx(s);
break;
 
case SIOCGLIFPHYTTL:
ifr->ifr_ttl = (int)sc->sc_ttl;
break;
@@ -489,14 +481,12 @@ vxlanioctl(struct ifnet *ifp, u_long cmd, caddr_t data)
 ifr->ifr_vnetid < VXLAN_VNI_MIN)) {
error = EINVAL;
break;
}
 
-   s = splnet();
sc->sc_vnetid = (int)ifr->ifr_vnetid;
(void)vxlan_config(ifp, NULL, NULL);
-   splx(s);
break;
 
case SIOCGVNETID:
if ((sc->sc_vnetid != VXLAN_VNI_ANY) &&
(sc->sc_vnetid > VXLAN_VNI_MAX ||
@@ -507,14 +497,12 @@ vxlanioctl(struct ifnet *ifp, u_long cmd, caddr_t data)
 
ifr->ifr_vnetid = sc->sc_vnetid;
break;
 
case SIOCDVNETID:
-   s = splnet();
sc->sc_vnetid = VXLAN_VNI_UNSET;
(void)vxlan_config(ifp, NULL, NULL);
-   splx(s);
break;
 
default:
error = ether_ioctl(ifp, >sc_ac, cmd, data);
break;
@@ -923,57 +911,56 @@ vxlan_output(struct ifnet *ifp, struct mbuf *m)
 void
 vxlan_addr_change(void *arg)
 {
struct vxlan_softc  *sc = arg;
struct ifnet*ifp = >sc_ac.ac_if;
-   int  s, error;
+   int  

OpenSSL 1.1 API migration path (or the lack thereof...)

2016-12-30 Thread Joel Sing
As many of you will already be aware, the OpenSSL 1.1.0 release intentionally
introduced significant API changes from the previous release[0][1]. In summary,
a large number of data structures that were previously publically visible have
been made opaque, with accessor functions being added in order to get and
set some of the fields within these now opaque structs. It is worth noting that
the use of opaque data structures is generally beneficial for libraries, since
changes can be made to these data structures without breaking the ABI. As 
such, the overall direction of these changes is largely reasonable.

However, while API change is generally necessary for progression, in this case
it would appear that there is NO transition plan and a complete disregard for
the impact that these changes would have on the overall open source ecosystem.

So far it seems that the only approach is to place the migration burden onto
each and every software project that uses OpenSSL, pushing significant code
changes to each project that migrates to OpenSSL 1.1, while maintaining
compatibility with the previous API (such as [2] and [3]). This is forcing
each project to provide their own backwards compatibility shims, which is
practically guaranteeing that there will be a proliferation of variable
quality implementations; it is almost a certainty that some of these will
contain bugs, potentially introducing security issues or memory leaks.

Due to a number of factors, software projects that make use of OpenSSL cannot
simply migrate to the 1.1 API and drop support for the 1.0 API - in most cases
they will need to continue to support both. Firstly, I am not aware of any
platform that has shipped a production release with OpenSSL 1.1 - any software
that supported OpenSSL 1.1 only, would effectively be unusable on every
platform for the time being. Secondly, the OpenSSL 1.0.2 release is supported
until the 31st of December 2019[4], while OpenSSL 1.1.0 is only supported
until the 31st of August 2018[4] - any LTS style release is clearly going to
consider shipping with 1.0.2 as a result.

Platforms that are attempting to ship with OpenSSL 1.1 are already
encountering significant challenges - for example, Debian currently has 257
packages (out of 518) that do not build against OpenSSL 1.1[5][6]. There are
also hidden gotchas for situations where different libraries are linked against
different OpenSSL versions and then share OpenSSL data structures between
them[7] - many of these problems will be difficult to detect since they only
fail at runtime.

But here's the thing - there are at least two options that OpenSSL had (and
still have) that would have avoided this situation and allowed for software
projects to make a smooth transition from the old API to the new API, without
every single project carrying backwards compatibility glue for at least the
next three years (and in reality, much longer).
 
I would implore the OpenSSL project to seriously reconsider their approach
to this API change and more importantly the associated migration, especially
keeping in mind what is going to be best for the overall ecosystem and not
just for the OpenSSL project. I would also ask software projects that make use
of OpenSSL to think carefully about how they approach this situation and in
particular consider how long they will need to carry compatibility code and
#ifs for.
 
Last but not least I would like to note that this is not a LibreSSL problem -
if we added all of the OpenSSL 1.1 accessors tomorrow, software written for
OpenSSL 1.0 or OpenSSL 1.1 would work seamlessly with LibreSSL. However,
software will still have to maintain compatibility with both of the OpenSSL
APIs, regardless of what we do.

[0] https://wiki.openssl.org/index.php/1.1_API_Changes

[1] https://abi-laboratory.pro/tracker/timeline/openssl/

[2] 
https://github.com/php/php-src/commit/2ecce94756bebda9eca3084b586f5bc821174c50

[3] https://github.com/openssh/openssh-portable/pull/48/files

[4] https://www.openssl.org/policies/releasestrat.html

[5] https://wiki.debian.org/OpenSSL-1.1

[6] https://breakpoint.cc/openssl-trans/html/openssl.html

[7] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844018



Re: ntpd.conf

2016-12-30 Thread Jason McIntyre
On Wed, Dec 28, 2016 at 09:59:06PM +0100, Jan Stary wrote:
> Markup a forgotten keyword.
> 
>   Jan
> 

fixed, thanks.
jmc

> Index: ntpd.conf.5
> ===
> RCS file: /cvs/src/usr.sbin/ntpd/ntpd.conf.5,v
> retrieving revision 1.33
> diff -u -p -r1.33 ntpd.conf.5
> --- ntpd.conf.5   23 Oct 2015 14:52:20 -  1.33
> +++ ntpd.conf.5   28 Dec 2016 20:58:06 -
> @@ -127,7 +127,9 @@ sensor nmea0 refid GPS
>  .Ed
>  .Pp
>  A stratum value other than the default of 1 can be assigned using
> -the stratum keyword.
> +the
> +.Ic stratum
> +keyword.
>  .It Xo Ic server Ar address
>  .Op Ic weight Ar weight-value
>  .Xc
>