[patch] www faq/current.html - validation

2018-05-26 Thread lists
Tue, 22 May 2018 02:43:22 -0600 (MDT) Stuart Henderson

> CVSROOT:  /cvs
> Module name:  www
> Changes by:   st...@cvs.openbsd.org   2018/05/22 02:43:22
> 
> Modified files:
>   faq: current.html 
> 
> Log message:
> mention php default version switch
> 

Hi tech@,

Two minor changes for fixing markup, caught by validating browser Dillo.

http://validator.w3.org/check?uri=http://www.openbsd.org/faq/current.html
http://www.htmlhelp.org/cgi-bin/validate.cgi?url=http://www.openbsd.org/faq/current.html

Kind regards,
Anton Lazarov

$ diff -u current.html-1.{899,900}   
--- current.html-1.899  Sun May 27 04:23:45 2018
+++ current.html-1.900  Sun May 27 04:26:50 2018
@@ -128,7 +128,7 @@
 command require adjustment.
 
 
-2018/05/22 - [packages] PHP default version changed
+2018/05/22 - [packages] PHP default version changed
 
 With a few exceptions, most packages using PHP have switched to
 using PHP 7.0 dependencies by default.
@@ -150,7 +150,7 @@
 
 $ rcctl disable php56_fpm; rcctl enable php70_fpm
 $ rcctl stop php56_fpm; rcctl start php70_fpm
-
+
 If using the module for Apache httpd, update the symlink for
 /var/www/conf/modules/php.conf as shown in the pkg-readme.
 



Re: route: improve inet6_makenetandmask

2018-05-26 Thread Klemens Nanni
On Sat, May 26, 2018 at 11:49:29PM +0200, Denis Fondras wrote:
> Not related to this diff but RFC2374 has been made obsolete by RFC3587 for 
> some
> years : "implementations should not make any assumptions about 2000::/3 being
> special". I think we can simplify this "else if" :)
Agreed, although this should probably go into a separate diff; Your post
on misc@ made me look at this in the first place, so I refrained from
taking over your work.

> > +   rtm_addrs |= RTA_NETMASK;
> 
> Can't we consider this done in prefixlen() ?
Yes. Missed to remove it from here, thanks.

Updated diff below without the null and curly bracket cosmetics to avoid
churn (and leave it for the RFC 3587 update around there).

Index: route.c
===
RCS file: /cvs/src/sbin/route/route.c,v
retrieving revision 1.214
diff -u -p -r1.214 route.c
--- route.c 1 May 2018 18:14:10 -   1.214
+++ route.c 27 May 2018 01:04:36 -
@@ -786,15 +786,11 @@ inet_makenetandmask(u_int32_t net, struc
sin->sin_len = 1 + cp - (char *)sin;
 }
 
-/*
- * XXX the function may need more improvement...
- */
 int
 inet6_makenetandmask(struct sockaddr_in6 *sin6, char *plen)
 {
struct in6_addr in6;
-   const char *errstr;
-   int i, len, q, r;
+   int i;
 
if (NULL==plen) {
if (IN6_IS_ADDR_UNSPECIFIED(>sin6_addr) &&
@@ -809,27 +805,13 @@ inet6_makenetandmask(struct sockaddr_in6
}
}
 
-   if (!plen || strcmp(plen, "128") == 0)
+   if (!plen || prefixlen(AF_INET6, plen))
return (1);
-   else {
-   rtm_addrs |= RTA_NETMASK;
-   prefixlen(AF_INET6, plen);
-
-   len = strtonum(plen, 0, 128, );
-   if (errstr)
-   errx(1, "prefixlen %s is %s", plen, errstr);
-
-   q = (128-len) >> 3;
-   r = (128-len) & 7;
-   i = 15;
-
-   while (q-- > 0)
-   sin6->sin6_addr.s6_addr[i--] = 0;
-   if (r > 0)
-   sin6->sin6_addr.s6_addr[i] &= 0xff << r;
 
-   return (0);
-   }
+   for (i = 0; i < 16; ++i)
+   sin6->sin6_addr.s6_addr[i] &= so_mask.sin6.sin6_addr.s6_addr[i];
+
+   return (0);
 }
 
 /*



eoip(4): MikroTik Ethernet over IP support

2018-05-26 Thread David Gwynne
this implements MikroTiks Ethernet over IP protocol support.

The Mikrotik protocol is basically GRE, so this is implemented as
eoip(4) as (yet another) part of if_gre. the main differences between
egre and eoip is that eoip uses gre version 1 (not 0) and 0x6400
as the protocol identifier (not transparent ethernet as per rfc
1701), mandates a key header, but splits the key into 16bit len and
tunnel id fields (a bit like pptp).

the keepalive semantics are also different. keepalives are just 0
length packets, and arent echoed. each side listens for the others
packet to see if theyre up, but doesn't relay the keepalives. theyre
more hellos maybe?

like egre though, it still misaligns the payload, but what doesnt
these days?

this also tweaks tcpdump to better support the protocol.

ok?

Index: sys/net/if_gre.c
===
RCS file: /cvs/src/sys/net/if_gre.c,v
retrieving revision 1.122
diff -u -p -r1.122 if_gre.c
--- sys/net/if_gre.c12 Mar 2018 12:47:35 -  1.122
+++ sys/net/if_gre.c27 May 2018 00:12:36 -
@@ -124,6 +124,13 @@ struct gre_h_key {
uint32_tgre_key;
 } __packed __aligned(4);
 
+#define GRE_EOIP   0x6400
+
+struct gre_h_key_eoip {
+   uint16_teoip_len;   /* network order */
+   uint16_teoip_tunnel_id; /* little endian */
+} __packed __aligned(4);
+
 #define NVGRE_VSID_RES_MIN 0x00 /* reserved for future use */
 #define NVGRE_VSID_RES_MAX 0x000fff
 #define NVGRE_VSID_NVE2NVE 0xff /* vendor specific NVE-to-NVE comms */
@@ -211,6 +218,12 @@ static struct mbuf *
 #define gre_encap(_t, _m, _p, _ttl, _tos) \
gre_encap_dst((_t), &(_t)->t_dst, (_m), (_p), (_ttl), (_tos))
 
+static struct mbuf *
+   gre_encap_dst_ip(const struct gre_tunnel *,
+   const union gre_addr *, struct mbuf *, uint8_t, uint8_t);
+#define gre_encap_ip(_t, _m, _ttl, _tos) \
+   gre_encap_dst_ip((_t), &(_t)->t_dst, (_m), (_ttl), (_tos))
+
 static int
gre_ip_output(const struct gre_tunnel *, struct mbuf *);
 
@@ -266,7 +279,7 @@ static int  gre_ioctl(struct ifnet *, u_l
 
 static int gre_up(struct gre_softc *);
 static int gre_down(struct gre_softc *);
-static voidgre_link_state(struct gre_softc *);
+static voidgre_link_state(struct ifnet *, unsigned int);
 
 static int gre_input_key(struct mbuf **, int *, int, int,
struct gre_tunnel *);
@@ -457,6 +470,61 @@ struct nvgre_ucast_tree nvgre_ucast_tree
 struct nvgre_mcast_tree nvgre_mcast_tree = RBT_INITIALIZER();
 
 /*
+ * MikroTik Ethernet over IP protocol (eoip)
+ */
+
+struct eoip_softc {
+   struct gre_tunnel   sc_tunnel; /* must be first */
+   uint16_tsc_tunnel_id;
+   RBT_ENTRY(eoip_softc)   sc_entry;
+
+   struct arpcom   sc_ac;
+   struct ifmedia  sc_media;
+
+   struct timeout  sc_ka_send;
+   struct timeout  sc_ka_hold;
+
+   unsigned intsc_ka_state;
+   unsigned intsc_ka_timeo;
+   unsigned intsc_ka_count;
+
+   unsigned intsc_ka_holdmax;
+   unsigned intsc_ka_holdcnt;
+};
+
+RBT_HEAD(eoip_tree, eoip_softc);
+
+static inline int
+   eoip_cmp(const struct eoip_softc *, const struct eoip_softc *);
+
+RBT_PROTOTYPE(eoip_tree, eoip_softc, sc_entry, eoip_cmp);
+
+static int eoip_clone_create(struct if_clone *, int);
+static int eoip_clone_destroy(struct ifnet *);
+
+static voideoip_start(struct ifnet *);
+static int eoip_ioctl(struct ifnet *, u_long, caddr_t);
+
+static voideoip_keepalive_send(void *);
+static voideoip_keepalive_recv(struct eoip_softc *);
+static voideoip_keepalive_hold(void *);
+
+static int eoip_up(struct eoip_softc *);
+static int eoip_down(struct eoip_softc *);
+
+static struct mbuf *
+   eoip_encap(struct eoip_softc *, struct mbuf *, uint8_t);
+
+static struct mbuf *
+   eoip_input(struct gre_tunnel *, struct mbuf *,
+   const struct gre_header *, int);
+struct if_clone eoip_cloner =
+IF_CLONE_INITIALIZER("eoip", eoip_clone_create, eoip_clone_destroy);
+ 
+/* protected by NET_LOCK */
+struct eoip_tree eoip_tree = RBT_INITIALIZER();
+
+/*
  * It is not easy to calculate the right value for a GRE MTU.
  * We leave this task to the admin and use the same default that
  * other vendors use.
@@ -482,6 +550,7 @@ greattach(int n)
if_clone_attach(_cloner);
if_clone_attach(_cloner);
if_clone_attach(_cloner);
+   if_clone_attach(_cloner);
 }
 
 static int
@@ -725,6 +794,65 @@ nvgre_clone_destroy(struct ifnet *ifp)
return (0);
 }
 
+static int
+eoip_clone_create(struct if_clone *ifc, int unit)
+{
+   struct eoip_softc *sc;
+   struct ifnet *ifp;
+
+   sc = malloc(sizeof(*sc), M_DEVBUF, 

add clock_nanosleep(2)

2018-05-26 Thread Scott Cheloha
Hi,

Here's a first attempt at adding clock_nanosleep(2).

Its use cases are admittedly more niche than nanosleep(2),
and indeed there are just a handful of spots in base where
I think it would be an improvement over existing code, but
it's definitely an improvement, particularly in simplicity,
where applicable.

This implementation introduces a rwlock in tc_setrealtimeclock()
and wakes threads when it exits the critical section, so absolute
CLOCK_REALTIME timeouts never miss a clock jump.

I feel that this is more of a hack than adjusting timeouts from
hardclock(9), and something like that that will probably be the
better solution if other absolute CLOCK_REALTIME timeouts are made
sensitive to jumps in the future, but I wanted to start here with
something minimally invasive.  I'm still unsure if making absolute
timeouts sensitive to clock jumps is even worth it, particularly in
cases where there is no portable alternative clock choice, like with
pthread_mutex_timedlock(3).

(Maybe of note is that this was guenther@'s approach several years
ago [1], but that patch did not land.)

... but with clock_nanosleep(2) you can use any clock, so I think
it's a perfectly valid feature with no real downsides to inclusion.

The patch also generalizes rwsleep(9) to cover both write and
read locks.  This seems like an obvious extension preferable to
adding yet another *sleep() wrapper just for read locks.

The patch puts the sleeps in tick-loops to handle arbitrary
timeouts for both nanosleep(2) and clock_nanosleep(2), removing
nanosleep's 100-million second upper bound.  Starting here, I want
to remove the 100-million second upper bound from system calls with
timeouts because:

  (a) It's a lie: 100 million seconds at 100hz is way, way
  more ticks than a signed 32-bit int can represent.

  (b) It's one less platform-specific thing for userspace to
  check; particularly cross-platform high-level languages,
  effectively all of which have an interface to nanosleep(2).

  Lots of sleeps don't check the return code: eliminating
  the 100-million second gotcha case makes debugging and
  reasoning about code easier.

Looking for feedback that I can spruce things up with and then
ask for OKs later (assuming there's no objection to including
the interface itself).

Thoughts & feedback?

--
Scott Cheloha

[1] https://marc.info/?l=openbsd-tech=128245846500419=2

Index: include/time.h
===
RCS file: /cvs/src/include/time.h,v
retrieving revision 1.30
diff -u -p -r1.30 time.h
--- include/time.h  5 Sep 2017 03:16:13 -   1.30
+++ include/time.h  26 May 2018 22:42:20 -
@@ -165,6 +165,7 @@ int nanosleep(const struct timespec *, s
 
 #if __POSIX_VISIBLE >= 200112
 int clock_getcpuclockid(pid_t, clockid_t *);
+int clock_nanosleep(clockid_t, int, const struct timespec *, struct timespec 
*);
 #endif
 
 #if __POSIX_VISIBLE >= 200809
Index: lib/libc/Symbols.list
===
RCS file: /cvs/src/lib/libc/Symbols.list,v
retrieving revision 1.62
diff -u -p -r1.62 Symbols.list
--- lib/libc/Symbols.list   5 Dec 2017 13:45:31 -   1.62
+++ lib/libc/Symbols.list   26 May 2018 22:42:21 -
@@ -58,6 +58,7 @@ _thread_sys_chown
 _thread_sys_chroot
 _thread_sys_clock_getres
 _thread_sys_clock_gettime
+_thread_sys_clock_nanosleep
 _thread_sys_clock_settime
 _thread_sys_close
 _thread_sys_closefrom
@@ -254,6 +255,7 @@ chown
 chroot
 clock_getres
 clock_gettime
+clock_nanosleep
 clock_settime
 close
 closefrom
Index: lib/libc/hidden/time.h
===
RCS file: /cvs/src/lib/libc/hidden/time.h,v
retrieving revision 1.5
diff -u -p -r1.5 time.h
--- lib/libc/hidden/time.h  5 Sep 2017 03:16:13 -   1.5
+++ lib/libc/hidden/time.h  26 May 2018 22:42:21 -
@@ -30,6 +30,7 @@ PROTO_STD_DEPRECATED(clock);
 PROTO_DEPRECATED(clock_getcpuclockid);
 PROTO_NORMAL(clock_getres);
 PROTO_NORMAL(clock_gettime);
+PROTO_CANCEL(clock_nanosleep);
 PROTO_NORMAL(clock_settime);
 PROTO_STD_DEPRECATED(ctime);
 PROTO_DEPRECATED(ctime_r);
Index: lib/libc/sys/Makefile.inc
===
RCS file: /cvs/src/lib/libc/sys/Makefile.inc,v
retrieving revision 1.154
diff -u -p -r1.154 Makefile.inc
--- lib/libc/sys/Makefile.inc   12 Jan 2018 04:36:12 -  1.154
+++ lib/libc/sys/Makefile.inc   26 May 2018 22:42:21 -
@@ -27,7 +27,7 @@ SRCS+=canceled.c
 
 # syscalls that would be normal...except for cancellation or SIGTHR
 CANCEL=accept accept4 \
-   close closefrom connect \
+   clock_nanosleep close closefrom connect \
fcntl fsync \
msgrcv msgsnd msync \
nanosleep \
@@ -175,8 +175,8 @@ ${HIDDEN}:  ; @${GENERATE.rsyscall_hidde
 
 MAN+=  __get_tcb.2 __thrsigdivert.2 __thrsleep.2 _exit.2 accept.2 \
access.2 acct.2 adjfreq.2 

[PATCH] Define IMSG_DATA_SIZE() in imsg.h

2018-05-26 Thread Consus
To reduce code duplication a little bit.

diff --git a/lib/libutil/imsg.h b/lib/libutil/imsg.h
index 8bf9414789b..8436e157b38 100644
--- a/lib/libutil/imsg.h
+++ b/lib/libutil/imsg.h
@@ -23,6 +23,7 @@
 
 #define IBUF_READ_SIZE 65535
 #define IMSG_HEADER_SIZE   sizeof(struct imsg_hdr)
+#define IMSG_DATA_SIZE(imsg)   ((imsg)->hdr.len - IMSG_HEADER_SIZE)
 #define MAX_IMSGSIZE   16384
 
 struct ibuf {
diff --git a/sbin/iked/iked.h b/sbin/iked/iked.h
index 49b7333c7b1..d95fbc0656e 100644
--- a/sbin/iked/iked.h
+++ b/sbin/iked/iked.h
@@ -64,7 +64,6 @@ struct imsgev {
if (IMSG_DATA_SIZE(imsg) < sizeof(*p))  \
fatalx("bad length imsg received"); \
 } while (0)
-#define IMSG_DATA_SIZE(imsg)   ((imsg)->hdr.len - IMSG_HEADER_SIZE)
 
 #define IKED_ADDR_EQ(_a, _b)   \
((_a)->addr_mask == (_b)->addr_mask &&  \
diff --git a/usr.sbin/httpd/httpd.h b/usr.sbin/httpd/httpd.h
index aff1a6c5e2a..f506ec13d05 100644
--- a/usr.sbin/httpd/httpd.h
+++ b/usr.sbin/httpd/httpd.h
@@ -195,7 +195,6 @@ struct imsgev {
if (IMSG_DATA_SIZE(imsg) < sizeof(*p))  \
fatalx("bad length imsg received"); \
 } while (0)
-#define IMSG_DATA_SIZE(imsg)   ((imsg)->hdr.len - IMSG_HEADER_SIZE)
 #define MAX_IMSG_DATA_SIZE (MAX_IMSGSIZE - IMSG_HEADER_SIZE)
 
 struct ctl_conn {
diff --git a/usr.sbin/relayd/relayd.h b/usr.sbin/relayd/relayd.h
index bcf47a6f709..4433c9455b6 100644
--- a/usr.sbin/relayd/relayd.h
+++ b/usr.sbin/relayd/relayd.h
@@ -897,7 +897,6 @@ struct imsgev {
if (IMSG_DATA_SIZE(imsg) < sizeof(*p))  \
fatalx("bad length imsg received"); \
 } while (0)
-#define IMSG_DATA_SIZE(imsg)   ((imsg)->hdr.len - IMSG_HEADER_SIZE)
 
 struct ctl_conn {
TAILQ_ENTRY(ctl_conn)entry;
diff --git a/usr.sbin/snmpd/snmpd.h b/usr.sbin/snmpd/snmpd.h
index 6d93ac66144..b2bbe1ffa2e 100644
--- a/usr.sbin/snmpd/snmpd.h
+++ b/usr.sbin/snmpd/snmpd.h
@@ -105,7 +105,6 @@ struct imsgev {
if (IMSG_DATA_SIZE(imsg) < sizeof(*p))  \
fatalx("bad length imsg received"); \
 } while (0)
-#define IMSG_DATA_SIZE(imsg)   ((imsg)->hdr.len - IMSG_HEADER_SIZE)
 
 /* initially control.h */
 struct control_sock {
diff --git a/usr.sbin/switchd/proc.h b/usr.sbin/switchd/proc.h
index f219d1c379d..1df8a2402bb 100644
--- a/usr.sbin/switchd/proc.h
+++ b/usr.sbin/switchd/proc.h
@@ -94,10 +94,6 @@ struct imsgev {
const char  *name;
 };
 
-#ifndef IMSG_DATA_SIZE
-#defineIMSG_DATA_SIZE(_imsg)   ((_imsg)->hdr.len - IMSG_HEADER_SIZE)
-#endif
-
 #ifndef IMSG_SIZE_CHECK
 #defineIMSG_SIZE_CHECK(_imsg, _type)   \
do {\
diff --git a/usr.sbin/vmd/proc.h b/usr.sbin/vmd/proc.h
index b91f3a5fecb..48ac5736f5b 100644
--- a/usr.sbin/vmd/proc.h
+++ b/usr.sbin/vmd/proc.h
@@ -52,7 +52,6 @@ struct imsgev {
if (IMSG_DATA_SIZE(imsg) < sizeof(*p))  \
fatalx("bad length imsg received (%s)", #p);\
 } while (0)
-#define IMSG_DATA_SIZE(imsg)   ((imsg)->hdr.len - IMSG_HEADER_SIZE)
 
 /* control socket */
 struct control_sock {



Re: route: improve inet6_makenetandmask

2018-05-26 Thread Denis Fondras
On Sat, May 26, 2018 at 12:54:03PM +0200, Klemens Nanni wrote:
> inet6_makenetandmask() parses the provided prefix length `plen' twice:
> first from inside prefixlen() which sets the mask, then right again
> doing almost the same dance to find out which bits to zero in the
> provided address.
> 
> But once prefixlen() set so_mask, we can just use it to actually mask
> the address.
> 
> prefixlen() returns `(len == max)' where `max = 128' for `AF_INET6', so
> it's equivalent to the strcmp() call.
> 
> Regress tests pass on amd64, also no issue after manually adding,
> testing and removing routes on my machine.
> 
> Feedback? OK?
> 
> Index: route.c
> ===
> RCS file: /cvs/src/sbin/route/route.c,v
> retrieving revision 1.214
> diff -u -p -r1.214 route.c
> --- route.c   1 May 2018 18:14:10 -   1.214
> +++ route.c   26 May 2018 10:49:50 -
> @@ -786,21 +786,17 @@ inet_makenetandmask(u_int32_t net, struc
>   sin->sin_len = 1 + cp - (char *)sin;
>  }
>  
> -/*
> - * XXX the function may need more improvement...
> - */
>  int
>  inet6_makenetandmask(struct sockaddr_in6 *sin6, char *plen)
>  {
>   struct in6_addr in6;
> - const char *errstr;
> - int i, len, q, r;
> + int i;
>  
> - if (NULL==plen) {
> + if (!plen) {
>   if (IN6_IS_ADDR_UNSPECIFIED(>sin6_addr) &&
> - sin6->sin6_scope_id == 0) {
> + sin6->sin6_scope_id == 0)
>   plen = "0";
> - } else if ((sin6->sin6_addr.s6_addr[0] & 0xe0) == 0x20) {
> + else if ((sin6->sin6_addr.s6_addr[0] & 0xe0) == 0x20) {
>   /* aggregatable global unicast - RFC2374 */
>   memset(, 0, sizeof(in6));
>   if (!memcmp(>sin6_addr.s6_addr[8],

Not related to this diff but RFC2374 has been made obsolete by RFC3587 for some
years : "implementations should not make any assumptions about 2000::/3 being
special". I think we can simplify this "else if" :)

> @@ -809,27 +805,14 @@ inet6_makenetandmask(struct sockaddr_in6
>   }
>   }
>  
> - if (!plen || strcmp(plen, "128") == 0)
> + if (!plen || prefixlen(AF_INET6, plen))
>   return (1);
> - else {
> - rtm_addrs |= RTA_NETMASK;
> - prefixlen(AF_INET6, plen);
> -
> - len = strtonum(plen, 0, 128, );
> - if (errstr)
> - errx(1, "prefixlen %s is %s", plen, errstr);
> -
> - q = (128-len) >> 3;
> - r = (128-len) & 7;
> - i = 15;
> -
> - while (q-- > 0)
> - sin6->sin6_addr.s6_addr[i--] = 0;
> - if (r > 0)
> - sin6->sin6_addr.s6_addr[i] &= 0xff << r;
> + rtm_addrs |= RTA_NETMASK;

Can't we consider this done in prefixlen() ?

>  
> - return (0);
> - }
> + for (i = 0; i < 16; ++i)
> + sin6->sin6_addr.s6_addr[i] &= so_mask.sin6.sin6_addr.s6_addr[i];
> +
> + return (0);
>  }
>  
>  /*
> 



Re: [Patch] mg(1) set column-number-mode on by default

2018-05-26 Thread Leonid Bobrov
On Sat, May 26, 2018 at 09:49:22PM +0200, Florian Obser wrote:
> Not OK.
> 
> With column-number-mode on mg has to redraw the modeline (maybe even
> the whole window?) on every cursor move. Try it on a 9600 serial
> console.
>

Oh, I forgot we use slow hardware. I didn't know it is necessary to
redraw the whole window to redraw one line. *puke*

> With line-number-mode on the redraw is only necessary when a cursor
> move changes the line number. Happens considerably less often.
>

And still even line-number-mode can noticeable slow performance?

> Also note how this is in line with what emacs does.
>

Should mg look/act completely like Emacs does?

> The tutorial should be fixed.
>

Fine, I hope my recent diff for tutorial is good for that.

> On Sat, May 26, 2018 at 08:03:24PM +0300, Leonid Bobrov wrote:
> > From https://marc.info/?t=15272488061=1=2
> > 
> > If line-number-mode is on by default, I don't get what is
> > the problem with these "slow serial lines", plus without
> > this patch below we have confusing tutorial for new users:
> > 
> > Index: display.c
> > ===
> > RCS file: /cvs/src/usr.bin/mg/display.c,v
> > retrieving revision 1.48
> > diff -u -p -r1.48 display.c
> > --- display.c   6 Jul 2017 19:27:37 -   1.48
> > +++ display.c   26 May 2018 13:27:35 -
> > @@ -91,7 +91,7 @@ struct videoblanks;   /* Blank line im
> >  struct score *score;   /* [NROW * NROW] */
> >  
> >  static int  linenos = TRUE;
> > -static int  colnos = FALSE;
> > +static int  colnos = TRUE;
> >  
> >  /* Is macro recording enabled? */
> >  extern int macrodef;
> > 
> 
> -- 
> I'm not entirely sure you are real.
> 



Re: [Patch] mg(1) set column-number-mode on by default

2018-05-26 Thread Leonid Bobrov
> I already suggested exactly this:
> https://marc.info/?l=openbsd-tech=152727379111353=2
>

This tutorial doesn't mention using different modes, so it is unclear
to new user how to switch to that mode. I'm extending your diff to
make less confusions (plus date needs update, I'm using my local time,
so don't bother if you have 26-th of May at your clock):

Index: tutorial
===
RCS file: /cvs/src/usr.bin/mg/tutorial,v
retrieving revision 1.17
diff -u -p -r1.17 tutorial
--- tutorial30 May 2017 07:11:40 -  1.17
+++ tutorial26 May 2018 21:12:40 -
@@ -207,28 +207,6 @@ type C-g to cancel the operation.
 To paste the region that you've cut or copied above, simply move your cursor 
 to the desired location and then type C-y to paste it.
 
-Status Line

-
-At the bottom of your screen is a reverse highlighted line. This is the status
-line and lets you know some useful information about the file you're editing.
-
-On the status line, you should see "Mg: tutorial". This lets you know that 
-you're editing a file named "tutorial". If you've edited this file and not 
-saved it, it should have a "**" to the left of those words. If this file is 
-read-only, you should see a "%%" to the left of those words. 
-
-To the right of the status line, you should see L followed by digits and C
-followed by some more digits. These indicate the line number and column number
-of the file that your cursor is currently on. If you move the cursor around,
-you should see the line and column number change.
-
-In the middle of the screen, you should see the word "(fundamental)" which 
-indicates that the current editing mode is "fundamental-mode". The mg editor
-also supports a c-mode that is more suited to editing C code. There are also
-some other useful editing modes for different situations. See the man page 
-for mg(1) to learn about the various editing modes.
-
 Opening and Saving Files
 
 
@@ -324,6 +302,29 @@ the replace-text command. To cancel this
 
 To see a list of all available mg(1) commands, consult the man page.
 
+Status Line
+---
+
+At the bottom of your screen is a reverse highlighted line. This is the status
+line and lets you know some useful information about the file you're editing.
+
+On the status line, you should see "Mg: tutorial". This lets you know that 
+you're editing a file named "tutorial". If you've edited this file and not 
+saved it, it should have a "**" to the left of those words. If this file is 
+read-only, you should see a "%%" to the left of those words. 
+
+To the right of the status line, you should see L followed by digits and, if
+column-number-mode is enabled (M-x col TAB Enter), C followed by some more
+digits. These indicate the line number and column number of the file that your
+cursor is currently on. If you move the cursor around, you should see the line
+and column number change.
+
+In the middle of the screen, you should see the word "(fundamental)" which 
+indicates that the current editing mode is "fundamental-mode". The mg editor
+also supports a c-mode that is more suited to editing C code. There are also
+some other useful editing modes for different situations. See the man page 
+for mg(1) to learn about the various editing modes.
+
 Exiting mg
 --
 
@@ -346,7 +347,7 @@ Author Info
 ---
 
 Original Author of this document: Mayukh Bose, 
-Date last updated: 2015-12-21
+Date last updated: 2018-05-27
 
 Copyright
 -



Re: [Patch] mg(1) set column-number-mode on by default

2018-05-26 Thread Brian Callahan
Hi Florian --

On 5/26/2018 3:49 PM, Florian Obser wrote:
> Not OK.
>
> With column-number-mode on mg has to redraw the modeline (maybe even
> the whole window?) on every cursor move. Try it on a 9600 serial
> console.
>
> With line-number-mode on the redraw is only necessary when a cursor
> move changes the line number. Happens considerably less often.
>
> Also note how this is in line with what emacs does.
>
> The tutorial should be fixed.

I already suggested exactly this:
https://marc.info/?l=openbsd-tech=152727379111353=2

~Brian

> On Sat, May 26, 2018 at 08:03:24PM +0300, Leonid Bobrov wrote:
>> From https://marc.info/?t=15272488061=1=2
>>
>> If line-number-mode is on by default, I don't get what is
>> the problem with these "slow serial lines", plus without
>> this patch below we have confusing tutorial for new users:
>>
>> Index: display.c
>> ===
>> RCS file: /cvs/src/usr.bin/mg/display.c,v
>> retrieving revision 1.48
>> diff -u -p -r1.48 display.c
>> --- display.c6 Jul 2017 19:27:37 -   1.48
>> +++ display.c26 May 2018 13:27:35 -
>> @@ -91,7 +91,7 @@ struct video blanks;   /* Blank line im
>>  struct score *score;/* [NROW * NROW] */
>>  
>>  static int   linenos = TRUE;
>> -static int   colnos = FALSE;
>> +static int   colnos = TRUE;
>>  
>>  /* Is macro recording enabled? */
>>  extern int macrodef;
>>



Re: Automatic configuration of /etc/ttys in installer

2018-05-26 Thread Mark Kettenis
> Date: Tue, 8 May 2018 08:51:14 +0200 (CEST)
> From: Mark Kettenis 
> 
> After my recent changes to armv7 and arm64 the installer and
> single-user mode are usable with a non-standard serial console speed.
> However, the installer will still install an /etc/ttys file with
> std.115200 in it.  This means that getty(8) will change the speed
> which means you get garbage or nothing on your serial connections.
> 
> Here is an attempt to make the installer modify the console entry in
> /etc/ttys to reflect the correct speed.  This uses some of the same
> code that we use to offer i386/amd64 users to switch the console to
> serial.  But it doesn't ask the question since we don't have to guess
> what the console will be.  I restricted the patching to the set of
> speeds that we actually support.
> 
> Is there a better way to do this?

Ping?

> Index: distrib/arm64/ramdisk/install.md
> ===
> RCS file: /cvs/src/distrib/arm64/ramdisk/install.md,v
> retrieving revision 1.9
> diff -u -p -r1.9 install.md
> --- distrib/arm64/ramdisk/install.md  23 Mar 2018 05:02:27 -  1.9
> +++ distrib/arm64/ramdisk/install.md  8 May 2018 06:40:44 -
> @@ -150,4 +150,12 @@ md_congrats() {
>  }
>  
>  md_consoleinfo() {
> + CTTY=console
> + DEFCONS=y
> + case $CSPEED in
> + 9600|19200|38400|57600|115200|150)
> + ;;
> + *)
> + CSPEED=115200;;
> + esac
>  }
> Index: distrib/miniroot/install.sub
> ===
> RCS file: /cvs/src/distrib/miniroot/install.sub,v
> retrieving revision 1.1067
> diff -u -p -r1.1067 install.sub
> --- distrib/miniroot/install.sub  7 May 2018 10:44:01 -   1.1067
> +++ distrib/miniroot/install.sub  8 May 2018 06:40:44 -
> @@ -2637,6 +2637,7 @@ apply() {
>   if [[ $DEFCONS == y ]]; then
>   cp /mnt/etc/ttys /tmp/i/ttys
>   sed -e "/^$CTTY/s/std.9600/std.${CSPEED}/" \
> + -e "/^$CTTY/s/std.115200/std.${CSPEED}/" \
>   -e "/^$CTTY/s/unknown/vt220 /" \
>   -e "/$CTTY/s/off.*/on secure/" /tmp/i/ttys 
> >/mnt/etc/ttys
>   [[ -n $CPROM ]] &&
> 
> 



Re: [Patch] mg(1) set column-number-mode on by default

2018-05-26 Thread Florian Obser
Not OK.

With column-number-mode on mg has to redraw the modeline (maybe even
the whole window?) on every cursor move. Try it on a 9600 serial
console.

With line-number-mode on the redraw is only necessary when a cursor
move changes the line number. Happens considerably less often.

Also note how this is in line with what emacs does.

The tutorial should be fixed.

On Sat, May 26, 2018 at 08:03:24PM +0300, Leonid Bobrov wrote:
> From https://marc.info/?t=15272488061=1=2
> 
> If line-number-mode is on by default, I don't get what is
> the problem with these "slow serial lines", plus without
> this patch below we have confusing tutorial for new users:
> 
> Index: display.c
> ===
> RCS file: /cvs/src/usr.bin/mg/display.c,v
> retrieving revision 1.48
> diff -u -p -r1.48 display.c
> --- display.c 6 Jul 2017 19:27:37 -   1.48
> +++ display.c 26 May 2018 13:27:35 -
> @@ -91,7 +91,7 @@ struct video  blanks;   /* Blank line im
>  struct score *score; /* [NROW * NROW] */
>  
>  static intlinenos = TRUE;
> -static intcolnos = FALSE;
> +static intcolnos = TRUE;
>  
>  /* Is macro recording enabled? */
>  extern int macrodef;
> 

-- 
I'm not entirely sure you are real.



Re: smtpd.conf new grammar

2018-05-26 Thread Leighton Sheppard
On Thu, May 24, 2018 at 02:18:56PM +0200, Gilles Chehade wrote:
> Hi,
> 
> I have just committed a major change in smtpd that'll require smtpd.conf
> to be rewritten before your update to the new code.
> 
> The new grammar is not TOO different from the former one, a lot of stuff
> remains exactly identical, but the ruleset is now split into two parts:
> 
> - a named action
> - a matching pattern which is associated to a named action
> 
> In effect, instead of having:
> 
> accept from any for local deliver to mbox
> 
> 
> You will have:
> 
> action "my_action" mbox
> 
> match from any for local action "my_action"
> 
> 
> There are a few keywords that have been shortened too but all in all the
> switch to new grammar is easy, the smtpd.conf man page has been updated,
> and it continues being improved thanks to ingo and jmc.
> 
> The man page by itself should be enough to do the switch.
> 
> Since this is quite a major change, I also wrote a post that describes a
> conversion of my own complex smtpd.conf to new grammar:
> 
> https://poolp.org/posts/2018-05-21/switching-to-opensmtpd-new-config/
> 
> 
> I have also compiled a list of directives recognized by the parser which
> I intend to use for regress tests:
> 
> https://poolp.org/~gilles/smtpd.conf
> 
> 
> As for the reasons behind the change they are numerous, I explained some
> at EuroBSDCon 2017, I explained some on my blog, the bottom line is that
> while one-line rules were apparently an awesome idea, they were actually
> a design error that had consequences on pretty much the entire daemon.
> 
> We didn't realize it until a few months ago, we tried hard to maintain a
> one-line rule grammar but it became more and more obvious that this just
> isn't doable without creating issues and unnecessary complexity.
> 
> The new grammar is cleaner, it helped remove ~700 lines of complex code,
> made the handling of .forward files as well much safer, removed a lot of
> very unpleasant side-effects most people didn't even realize existed ...
> until they hit that one case for which we had no way to work around.
> 
> 
> Anyways,
> looking forward for you to test and report how it works for you :-)
> 
> 
> -- 
> Gilles Chehade
> 
> https://www.poolp.org  @poolpOrg
> 

Hi,

I upgraded my laptop and VM both to the latest snapshot this morning, and 
migrated the configuration for smtpd.conf to the new grammar. No issues 
to report and I like the new format!

Regards,
Leighton



[Patch] mg(1) set column-number-mode on by default

2018-05-26 Thread Leonid Bobrov
>From https://marc.info/?t=15272488061=1=2

If line-number-mode is on by default, I don't get what is
the problem with these "slow serial lines", plus without
this patch below we have confusing tutorial for new users:

Index: display.c
===
RCS file: /cvs/src/usr.bin/mg/display.c,v
retrieving revision 1.48
diff -u -p -r1.48 display.c
--- display.c   6 Jul 2017 19:27:37 -   1.48
+++ display.c   26 May 2018 13:27:35 -
@@ -91,7 +91,7 @@ struct videoblanks;   /* Blank line im
 struct score *score;   /* [NROW * NROW] */
 
 static int  linenos = TRUE;
-static int  colnos = FALSE;
+static int  colnos = TRUE;
 
 /* Is macro recording enabled? */
 extern int macrodef;



[diff] httpd: pass through basic tls peer info to fcgi

2018-05-26 Thread Jack Burton
This diff adds three new TLS_PEER_* fastcgi variables: ISSUER, SERIAL &
SUBJECT.

That seems the logical next step in making tls client certs usable for
authorisation & accounting. Last week's commit (thanks Joel!) took care
of authentication.

The cert subject on its own should suffice for the simplest cases.

For anything more involved, {issuer,serial} is the bare minimum
necessary to identify any certificate uniquely (at least within the
realm of trusted CAs, which is all that's relevant after
authentication).

That should be enough for any fastcgi responder to record tls client
cert accounting data.

It should also be enough for any fastcgi responder which has out-of-band
access to relevant CA metadata to complete tls client cert authorisation
tasks of any complexity.

That requirement for out-of-band access to CA metadata is why this
approach is not as flexible as passing through the raw client cert to
fastcgi (although admittedly passing the whole chain, as I proposed
last year, was probably overkill). It's probably still worth coming back
to revisit passing the client cert itself once the issues currently
blocking that approach have been resolved.

But in the meantime this approach should cover the majority of use
cases (and has the benefit of not requiring fastcgi responders to link
to libcrypto just for cert authorisation, as would be the case when
passing through the raw cert).


Index: usr.sbin/httpd/httpd.conf.5
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
retrieving revision 1.95
diff -u -p -r1.95 httpd.conf.5
--- usr.sbin/httpd/httpd.conf.5 23 May 2018 19:02:50 -  1.95
+++ usr.sbin/httpd/httpd.conf.5 26 May 2018 13:01:21 -
@@ -342,11 +342,27 @@ The revision of the HTTP specification u
 .It Ic SERVER_SOFTWARE
 The server software name of
 .Xr httpd 8 .
+.It Ic TLS_PEER_ISSUER
+The issuer of the TLS client certificate.
+.It Ic TLS_PEER_SERIAL
+The serial number of the TLS client certificate, expressed in hexadecimal.
+.It Ic TLS_PEER_SUBJECT
+The subject of the TLS client certificate.
 .It Ic TLS_PEER_VERIFY
 A variable that is set to a comma separated list of TLS client verification
-features in use
-.Pq omitted when TLS client verification is not in use .
+features in use.
 .El
+.Pp
+All
+.Ic TLS_PEER_*
+variables are omitted when TLS client verification is not in use.
+All except
+.ic TLS_PEER_VERIFY
+are also omitted if no TLS client certificate is offered when the
+.Ic optional
+argument to the
+.Ic tls client ca
+directive is in use.
 .It Ic hsts Oo Ar option Oc
 Enable HTTP Strict Transport Security.
 Valid options are:
Index: usr.sbin/httpd/server_fcgi.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_fcgi.c,v
retrieving revision 1.76
diff -u -p -r1.76 server_fcgi.c
--- usr.sbin/httpd/server_fcgi.c19 May 2018 13:56:56 -  1.76
+++ usr.sbin/httpd/server_fcgi.c26 May 2018 13:01:21 -
@@ -34,6 +34,13 @@
 #include 
 #include 
 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
 #include "httpd.h"
 #include "http.h"
 
@@ -87,17 +94,22 @@ int fcgi_add_param(struct server_fcgi_pa
 int
 server_fcgi(struct httpd *env, struct client *clt)
 {
+   ASN1_INTEGER*sn;
+   BIGNUM  *bn = NULL;
+   BIO *bio = NULL;
+   X509*cert = NULL;
struct server_fcgi_param param;
struct server_config*srv_conf = clt->clt_srv_conf;
struct http_descriptor  *desc = clt->clt_descreq;
struct fcgi_record_header   *h;
struct fcgi_begin_request_body  *begin;
char hbuf[HOST_NAME_MAX+1];
-   size_t   scriptlen;
+   size_t   chainlen, scriptlen;
int  pathlen;
int  fd = -1, ret;
const char  *stripped, *p, *alias, *errstr = NULL;
-   char*str, *script = NULL;
+   char*str, *serial = NULL, *script = NULL;
+   const uint8_t   *chain;
 
if (srv_conf->socket[0] == ':') {
struct sockaddr_storage  ss;
@@ -290,6 +302,35 @@ server_fcgi(struct httpd *env, struct cl
if (srv_conf->tls_flags != 0 && fcgi_add_param(,
"TLS_PEER_VERIFY", printb_flags(srv_conf->tls_flags,
TLSFLAG_BITS), clt) == -1) {
+   errstr = "failed to encode param";
+   goto fail;
+   }
+   }
+   if ((srv_conf->flags & SRVFLAG_TLS) &&
+   tls_peer_cert_provided(clt->clt_tls_ctx)) {
+   if (fcgi_add_param(, "TLS_PEER_ISSUER",
+   

Re: [diff] missing quotes in tls_peer_cert_chain_pem(3)

2018-05-26 Thread Ingo Schwarze
Hi Jack,

Jack Burton wrote on Sat, May 26, 2018 at 08:27:54PM +0930:

> Just noticed this in passing while working on something else.

Committed, thanks.
  Ingo


> Index: lib/libtls/man/tls_conn_version.3
> ===
> RCS file: /cvs/src/lib/libtls/man/tls_conn_version.3,v
> retrieving revision 1.7
> diff -u -p -r1.7 tls_conn_version.3
> --- lib/libtls/man/tls_conn_version.3 10 Feb 2018 04:43:16 -  1.7
> +++ lib/libtls/man/tls_conn_version.3 26 May 2018 10:52:07 -
> @@ -54,8 +54,8 @@
>  .Fc
>  .Ft const uint8_t *
>  .Fo tls_peer_cert_chain_pem
> -.Fa struct tls *ctx
> -.Fa size_t *size
> +.Fa "struct tls *ctx"
> +.Fa "size_t *size"
>  .Fc
>  .Ft const char *
>  .Fn tls_peer_cert_issuer "struct tls *ctx"



[diff] missing quotes in tls_peer_cert_chain_pem(3)

2018-05-26 Thread Jack Burton
Just noticed this in passing while working on something else.

Index: lib/libtls/man/tls_conn_version.3
===
RCS file: /cvs/src/lib/libtls/man/tls_conn_version.3,v
retrieving revision 1.7
diff -u -p -r1.7 tls_conn_version.3
--- lib/libtls/man/tls_conn_version.3   10 Feb 2018 04:43:16 -  1.7
+++ lib/libtls/man/tls_conn_version.3   26 May 2018 10:52:07 -
@@ -54,8 +54,8 @@
 .Fc
 .Ft const uint8_t *
 .Fo tls_peer_cert_chain_pem
-.Fa struct tls *ctx
-.Fa size_t *size
+.Fa "struct tls *ctx"
+.Fa "size_t *size"
 .Fc
 .Ft const char *
 .Fn tls_peer_cert_issuer "struct tls *ctx"



route: improve inet6_makenetandmask

2018-05-26 Thread Klemens Nanni
inet6_makenetandmask() parses the provided prefix length `plen' twice:
first from inside prefixlen() which sets the mask, then right again
doing almost the same dance to find out which bits to zero in the
provided address.

But once prefixlen() set so_mask, we can just use it to actually mask
the address.

prefixlen() returns `(len == max)' where `max = 128' for `AF_INET6', so
it's equivalent to the strcmp() call.

Regress tests pass on amd64, also no issue after manually adding,
testing and removing routes on my machine.

Feedback? OK?

Index: route.c
===
RCS file: /cvs/src/sbin/route/route.c,v
retrieving revision 1.214
diff -u -p -r1.214 route.c
--- route.c 1 May 2018 18:14:10 -   1.214
+++ route.c 26 May 2018 10:49:50 -
@@ -786,21 +786,17 @@ inet_makenetandmask(u_int32_t net, struc
sin->sin_len = 1 + cp - (char *)sin;
 }
 
-/*
- * XXX the function may need more improvement...
- */
 int
 inet6_makenetandmask(struct sockaddr_in6 *sin6, char *plen)
 {
struct in6_addr in6;
-   const char *errstr;
-   int i, len, q, r;
+   int i;
 
-   if (NULL==plen) {
+   if (!plen) {
if (IN6_IS_ADDR_UNSPECIFIED(>sin6_addr) &&
-   sin6->sin6_scope_id == 0) {
+   sin6->sin6_scope_id == 0)
plen = "0";
-   } else if ((sin6->sin6_addr.s6_addr[0] & 0xe0) == 0x20) {
+   else if ((sin6->sin6_addr.s6_addr[0] & 0xe0) == 0x20) {
/* aggregatable global unicast - RFC2374 */
memset(, 0, sizeof(in6));
if (!memcmp(>sin6_addr.s6_addr[8],
@@ -809,27 +805,14 @@ inet6_makenetandmask(struct sockaddr_in6
}
}
 
-   if (!plen || strcmp(plen, "128") == 0)
+   if (!plen || prefixlen(AF_INET6, plen))
return (1);
-   else {
-   rtm_addrs |= RTA_NETMASK;
-   prefixlen(AF_INET6, plen);
-
-   len = strtonum(plen, 0, 128, );
-   if (errstr)
-   errx(1, "prefixlen %s is %s", plen, errstr);
-
-   q = (128-len) >> 3;
-   r = (128-len) & 7;
-   i = 15;
-
-   while (q-- > 0)
-   sin6->sin6_addr.s6_addr[i--] = 0;
-   if (r > 0)
-   sin6->sin6_addr.s6_addr[i] &= 0xff << r;
+   rtm_addrs |= RTA_NETMASK;
 
-   return (0);
-   }
+   for (i = 0; i < 16; ++i)
+   sin6->sin6_addr.s6_addr[i] &= so_mask.sin6.sin6_addr.s6_addr[i];
+
+   return (0);
 }
 
 /*