Re: led: use timeout_add_msec(9)

[Claudio Jeker]

On Thu, Jun 20, 2019 at 11:24:15PM +0200, Klemens Nanni wrote:
> The current code wants to wait 1/100 [s] = 10 [ms] but at least one
> tick, that's exactly what the millisecond version provides.
> 
> OK?
> 
> Index: sys/arch/sparc64/dev/led.c
> ===
> RCS file: /cvs/src/sys/arch/sparc64/dev/led.c,v
> retrieving revision 1.1
> diff -u -p -r1.1 led.c
> --- sys/arch/sparc64/dev/led.c29 May 2007 04:08:02 -  1.1
> +++ sys/arch/sparc64/dev/led.c20 Jun 2019 21:08:25 -
> @@ -143,7 +143,7 @@ led_blink(void *v, int on)
>  
>   sc->sc_on = on;
>   bus_space_write_1(sc->sc_iot, sc->sc_ioh, EPIC_ADDR, EPIC_LED_STATE0);
> - timeout_add(&sc->sc_to, max(1, hz / 100));
> + timeout_add_msec(&sc->sc_to, 10);
>  }
>  
>  void
> 

OK claudio@
-- 
:wq Claudio

OCSP Stapling with Nginx in LibreSSL 2.9.x

[Brent Cook]

Hi,

I haven’t looked deeply into this, but there was a reported issue with OCSP 
stapling with Nginx between the LibreSSL portable releases 2.9.0 and 2.9.1 
(which would have been between December 15th, 2018 and April 21st, 2019)

Reposting here for visibility:

https://github.com/libressl-portable/portable/issues/532#issuecomment-501828392 


- Brent

led: use timeout_add_msec(9)

[Klemens Nanni]

The current code wants to wait 1/100 [s] = 10 [ms] but at least one
tick, that's exactly what the millisecond version provides.

OK?

Index: sys/arch/sparc64/dev/led.c
===
RCS file: /cvs/src/sys/arch/sparc64/dev/led.c,v
retrieving revision 1.1
diff -u -p -r1.1 led.c
--- sys/arch/sparc64/dev/led.c  29 May 2007 04:08:02 -  1.1
+++ sys/arch/sparc64/dev/led.c  20 Jun 2019 21:08:25 -
@@ -143,7 +143,7 @@ led_blink(void *v, int on)
 
sc->sc_on = on;
bus_space_write_1(sc->sc_iot, sc->sc_ioh, EPIC_ADDR, EPIC_LED_STATE0);
-   timeout_add(&sc->sc_to, max(1, hz / 100));
+   timeout_add_msec(&sc->sc_to, 10);
 }
 
 void

Re: bgpd minor optimization

[Sebastian Benoit]

ok

Claudio Jeker(cje...@diehard.n-r-g.com) on 2019.06.20 18:53:04 +0200:
> prefix_add() is only called by path_update() and path_update already
> knows if the prefix exists or not (by calling prefix_get()). So doing
> the same check again in prefix_add() is silly and actually rather
> expensive with lots of peers. Just alloc and link the prefix instead.
> 
> OK?
> -- 
> :wq Claudio
> 
> Index: rde_rib.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/rde_rib.c,v
> retrieving revision 1.193
> diff -u -p -r1.193 rde_rib.c
> --- rde_rib.c 20 Jun 2019 13:38:21 -  1.193
> +++ rde_rib.c 20 Jun 2019 16:45:34 -
> @@ -922,24 +922,9 @@ prefix_add(struct bgpd_addr *prefix, int
>   if (re == NULL)
>   re = rib_add(rib, prefix, prefixlen);
>  
> - p = prefix_bypeer(re, peer);
> - if (p == NULL) {
> - p = prefix_alloc();
> - prefix_link(p, re, peer, asp, comm, nexthop, nhflags, vstate);
> - return (1);
> - } else {
> - if (prefix_aspath(p) != asp ||
> - prefix_communities(p) != comm ||
> - prefix_nexthop(p) != nexthop ||
> - prefix_nhflags(p) != nhflags) {
> - /* prefix metadata changed therefor move */
> - return (prefix_move(p, peer, asp, comm, nexthop,
> - nhflags, vstate));
> - }
> - p->lastchange = time(NULL);
> - p->validation_state = vstate;
> - return (0);
> - }
> + p = prefix_alloc();
> + prefix_link(p, re, peer, asp, comm, nexthop, nhflags, vstate);
> + return (1);
>  }
>  
>  /*
> 

Re: Qt5's libtool link scripts are unusable

[Rafael Sadowski]

On Thu Jun 20, 2019 at 04:46:59PM +0100, Stuart Henderson wrote:
> Thanks for the report,
> 
> On 2019/06/20 17:30, Vadim Penzin wrote:
> > I admit that I am not familiar with the release process of pre-built binary
> > packages; I might be writing to a wrong mailing list and I apologize in
> > advance.
> 
> ports@ is the better list for this, I've CC'd and set reply-to.
> 
> > All libtool scripts from qt5 (/usr/local/lib/qt5/*.la) contain the following
> > on their third line:
> > 
> >   LIBQt5XXX_VERSION=5.9# The name that we can dlopen(3).
> > 
> > (XXX above stands for the name of a particular library, such as Core,
> > Network, etc.)
> > 
> > Since shell scripts (that libtool generates) source .la files, sh(1) fails
> > on unexpected '(' because someone, somewhere omitted a space before the
> > comment.
> > 
> > Patching /usr/local/lib/qt5/*.la files programmatically by tucking a space
> > before the hash character brings linking with Qt5 assisted (encumbered?) by
> > libtool back to life.
> > 
> > --Vadim
> > 
> 
> This patch to the qtbase port should fix the problem at source (I'll leave
> it building and test later). However it will also require REVISION bumps
> on all ports including .la files produced by this.
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/qt5/qtbase/Makefile,v
> retrieving revision 1.29
> diff -u -p -w -u -r1.29 Makefile
> --- Makefile  20 May 2019 22:15:29 -  1.29
> +++ Makefile  20 Jun 2019 15:43:00 -
> @@ -15,13 +15,13 @@ PKGNAME-global =  qt5-global-${VERSION}
>  PKGNAME-psql =   qt5-postgresql-${VERSION}
>  PKGNAME-sqlite2 =qt5-sqlite2-${VERSION}
>  PKGNAME-tds =qt5-tds-${VERSION}
> +
>  REVISION-global =   0
> +REVISION-main =  5
>  REVISION-mysql = 0
>  REVISION-psql =  0
>  REVISION-sqlite2 =   0
>  REVISION-tds =   0
> -
> -REVISION-main =  4
>  
>  PKG_ARCH-global =*
>  PKG_ARCH-examples =  *
> Index: patches/patch-qmake_generators_unix_unixmake2_cpp
> ===
> RCS file: 
> /cvs/ports/x11/qt5/qtbase/patches/patch-qmake_generators_unix_unixmake2_cpp,v
> retrieving revision 1.3
> diff -u -p -w -u -r1.3 patch-qmake_generators_unix_unixmake2_cpp
> --- patches/patch-qmake_generators_unix_unixmake2_cpp 5 Jul 2018 09:49:13 
> -   1.3
> +++ patches/patch-qmake_generators_unix_unixmake2_cpp 20 Jun 2019 15:43:00 
> -
> @@ -136,13 +136,14 @@ Index: qmake/generators/unix/unixmake2.c
>   } else if (!project->isEmpty("QMAKE_AIX_SHLIB")) {
>   
> project->values("TARGET_").append(project->first("QMAKE_PREFIX_STATICLIB") + 
> project->first("TARGET")
>   + "." + project->first("QMAKE_EXTENSION_STATICLIB"));
> -@@ -1465,18 +1498,32 @@ UnixMakefileGenerator::writeLibtoolFile()
> +@@ -1465,18 +1498,33 @@ UnixMakefileGenerator::writeLibtoolFile()
> << QT_VERSION_STR << ")";
>   t << "\n";
>   
>  +if (!project->isEmpty("QMAKE_OPENBSD_SHLIB"))
>  +  t << "LIB" << fileVar("QMAKE_ORIG_TARGET") << "_VERSION="
> -+<< project->first("VER_MAJ") << "." << project->first("VER_MIN");
> ++<< project->first("VER_MAJ") << "." << project->first("VER_MIN")
> ++<< "\n";

This's what Qt 5.13 doas. They use "<< endl;" instead of "<< "\n";", I
would like to prefer that. std::endl calls std::flush which synchronizes
with the underlying storage device.

RS

>  +
>   t << "# The name that we can dlopen(3).\n"
>  -  << "dlname='" << fileVar(project->isActiveConfig("plugin") ? "TARGET" 
> : "TARGET_x")
> 

doas environmental security

[Ted Unangst]

I've made some changes to how doas handles environment variables recently. The
diffs were in previous emails, and have been committed. Thanks to Sander Bos
for pointing out some particular edge cases with the old handling.

There are two (or more) ways to run doas. In the first, you use it to run some
commands as root. I use doas to run ifconfig to adjust the network on my
laptop. I also know the root password, but doas is a bit quicker and easier.
Either way, I'm fully trusted.

Another way to use doas is to setup a restricted root setting for an untrusted
user. This is treading on thin ice, in my opinion, since there may be ways for
the untrusted user to escape. The unix security model isn't very good at
letting somebody be root, but only kinda sorta.

Which brings us to environment variables. doas (previously) allowed the new
process to inherit HOME and PATH (among other variables) from the invoking
user. This reflected my attitude that, yeah, I'm running this program as
another user, but I'm still me. This however, causes trouble where if you try
to set up a restricted root setting, an evil doer can specify their own PATH
and possibly get a shell script to exec something. I think people knew this,
but maybe didn't pull on the string to see how far it goes?

So Sander looked into this, and discovered even a simple command like less is
potentially unsafe to run as restricted root. less will execute commands if
specified in the LESSOPEN environemnt variable, however even if that's not
set, it will open $HOME/.less and allow setting it from there. If you study
the manual sufficiently, it's all in there. (Setting LESSSECURE would have
been the safe thing if you wanted to restrict a user to just less, but I think
the general point remains that programs read all sorts of files, and
everything needs to exec everything else.)

After some reflection, I've been convinced that it's unlikely everybody reads
the manuals, or that the manuals are even correct or complete. So the new doas
behavior moving forward is to reset most everything to the target user's
environment.

Your action items, as we like to say in the biz, are:

1. Check existing configs for "restricted root" rules and verify that they are
run with the correct environment.

2. When updating, check for rules that intentionally use inherited environment
variables. They may need to be explicitly passing using setenv in doas.conf.

Re: [patch] relayd OCSP stapling for TLS server

[Reyk Floeter]

Hi Bruno,

thanks for your efforts. I‘ve already written an OCSP patch which was being 
delayed in review.

I don’t have the patch at hand but you can see the branch at 
https://github.com/reyk/relayd/tree/ocsp

Reyk

> Am 20.06.2019 um 19:58 schrieb Bruno Flueckiger :
> 
> Hi,
> 
> The patch below adds OCSP stapling to the TLS server in relayd(8). The
> OCSP response is read from a binary encoded DER file that can be created
> using ocspcheck(8).
> 
> If a file with the same name as the certificate and private key files is
> found, its content is loaded and OCSP stapling is active. If there is no
> file or loading its content fails, OCSP stapling remains disabled.
> 
> relayd(8) uses the same mechanism it uses to find the certificate file,
> only the file name extension is different: .der instead of .pem
> 
> Cheers,
> Bruno
> 
> Index: usr.sbin/relayd/config.c
> ===
> RCS file: /cvs/src/usr.sbin/relayd/config.c,v
> retrieving revision 1.39
> diff -u -p -r1.39 config.c
> --- usr.sbin/relayd/config.c1 Jun 2019 09:54:19 -1.39
> +++ usr.sbin/relayd/config.c20 Jun 2019 17:37:09 -
> @@ -913,6 +913,14 @@ config_setrelay(struct relayd *env, stru
>rlay->rl_conf.name);
>return (-1);
>}
> +if (cert->cert_ocsp_fd != -1 &&
> +config_setrelayfd(ps, id, n,
> +cert->cert_id, cert->cert_relayid,
> +RELAY_FD_OCSP, cert->cert_ocsp_fd) == -1) {
> +log_warn("%s: fd passing failed for "
> +"`%s'", __func__,
> +rlay->rl_conf.name);
> +}
>}
>}
> 
> @@ -992,6 +1000,10 @@ config_setrelay(struct relayd *env, stru
>close(cert->cert_key_fd);
>cert->cert_key_fd = -1;
>}
> +if (cert->cert_ocsp_fd != -1) {
> +close(cert->cert_ocsp_fd);
> +cert->cert_ocsp_fd = -1;
> +}
>}
> 
>return (0);
> @@ -1113,6 +1125,7 @@ config_getrelayfd(struct relayd *env, st
>switch (crfd.type) {
>case RELAY_FD_CERT:
>case RELAY_FD_KEY:
> +case RELAY_FD_OCSP:
>if ((cert = cert_find(env, crfd.id)) == NULL) {
>if ((cert = cert_add(env, crfd.id)) == NULL)
>return (-1);
> @@ -1139,6 +1152,9 @@ config_getrelayfd(struct relayd *env, st
>break;
>case RELAY_FD_CAFILE:
>rlay->rl_tls_cacert_fd = imsg->fd;
> +break;
> +case RELAY_FD_OCSP:
> +cert->cert_ocsp_fd = imsg->fd;
>break;
>}
> 
> Index: usr.sbin/relayd/relay.c
> ===
> RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
> retrieving revision 1.247
> diff -u -p -r1.247 relay.c
> --- usr.sbin/relayd/relay.c31 May 2019 15:15:37 -1.247
> +++ usr.sbin/relayd/relay.c20 Jun 2019 17:37:09 -
> @@ -2130,8 +2130,8 @@ relay_tls_ctx_create(struct relay *rlay)
>struct relay_cert*cert;
>const char*fake_key;
>int fake_keylen, keyfound = 0;
> -char*buf = NULL, *cabuf = NULL;
> -off_t len = 0, calen = 0;
> +char*buf = NULL, *cabuf = NULL, *ocspbuf = NULL;
> +off_t len = 0, calen = 0, ocsplen = 0;
> 
>if ((tls_cfg = tls_config_new()) == NULL) {
>log_warnx("unable to allocate TLS config");
> @@ -2209,9 +2209,19 @@ relay_tls_ctx_create(struct relay *rlay)
>goto err;
>}
> 
> +if (cert->cert_ocsp_fd == -1)
> +goto without;
> +
> +if ((ocspbuf = relay_load_fd(cert->cert_ocsp_fd,
> +&ocsplen)) == NULL) {
> +log_warn("failed to load ocsp staple");
> +ocsplen = 0;
> +}
> +
> + without:
>if (keyfound == 1 &&
>tls_config_set_keypair_ocsp_mem(tls_cfg, buf, len,
> -fake_key, fake_keylen, NULL, 0) != 0) {
> +fake_key, fake_keylen, ocspbuf, ocsplen) != 0) {
>log_warnx("failed to set tls certificate: %s",
>tls_config_error(tls_cfg));
>goto err;
> @@ -2223,7 +2233,7 @@ relay_tls_ctx_create(struct relay *rlay)
>goto err;
> 
>if (tls_config_add_keypair_ocsp_mem(tls_cfg, buf, len,
> -fake_key, fake_keylen, NULL, 0) != 0) {
> +fake_key, fake_keylen, ocspbuf, ocsplen) != 0) {
>log_warnx("failed to add tls certificate: %s",
>tls_config_error(tls_cfg));
>goto err;
> Index: usr.sbin/relayd/relayd.c
> ===
> RCS file: /cvs/src/usr.sbin/relayd/relayd.c,v
> retrieving revision 1.179
> diff -u -p -r1.179 relayd.c
> --- usr.sbin/relayd/relayd.c31 May 2019 15:25:57 -0

mg(1): don't withold data indefinitely.

[Mark Lumsden]

Currently if you have a file 'test' and cat it:

$ cat test
abc
def
ghk
$

Then open 'test' in mg and remove the newline at the end of the buffer and 
try to save it, mg will offer the opportunity to add a newline at the end 
of the buffer:


"No newline at end of file, add one? (y or n)"

Before you answer this question, if you then cat the 'test' file again you 
will see:


$ cat test
$

mg is waiting for your answer before writing the contents of the buffer to 
disk (the file it has already opened for writing).


This diff moves the check for the newline at the end of the buffer earlier 
so file data doesn't 'disappear' for an indefinite period (or arguably 
infinite period, if mg or the machine mg is running on crashes) before 
the user answers yes or no.


Comments/ok?
Mark

Index: def.h
===
RCS file: /cvs/src/usr.bin/mg/def.h,v
retrieving revision 1.157
diff -u -p -u -p -r1.157 def.h
--- def.h   13 Dec 2018 14:59:16 -  1.157
+++ def.h   20 Jun 2019 17:17:06 -
@@ -466,7 +466,7 @@ int  ffropen(FILE **, const char *, str
 voidffstat(FILE *, struct buffer *);
 int ffwopen(FILE **, const char *, struct buffer *);
 int ffclose(FILE *, struct buffer *);
-int ffputbuf(FILE *, struct buffer *);
+int ffputbuf(FILE *, struct buffer *, int);
 int ffgetline(FILE *, char *, int, int *);
 int fbackupfile(const char *);
 char   *adjustname(const char *, int);
Index: file.c
===
RCS file: /cvs/src/usr.bin/mg/file.c,v
retrieving revision 1.100
diff -u -p -u -p -r1.100 file.c
--- file.c  2 Jan 2016 10:39:19 -   1.100
+++ file.c  20 Jun 2019 17:17:06 -
@@ -668,9 +668,10 @@ makebkfile(int f, int n)
 int
 writeout(FILE ** ffp, struct buffer *bp, char *fn)
 {
-   struct stat statbuf;
-   int  s;
-   char dp[NFILEN];
+   struct stat  statbuf;
+   struct line *lpend;
+   int  s, eobnl;
+   char dp[NFILEN];

if (stat(fn, &statbuf) == -1 && errno == ENOENT) {
errno = 0;
@@ -686,10 +687,16 @@ writeout(FILE ** ffp, struct buffer *bp,
return (FIOERR);
}
 }
+   lpend = bp->b_headp;
+   eobnl = 0;
+   if (llength(lback(lpend)) != 0) {
+   if (eyorn("No newline at end of file, add one") == TRUE)
+   eobnl = 1;
+   }
/* open writes message */
if ((s = ffwopen(ffp, fn, bp)) != FIOSUC)
return (FALSE);
-   s = ffputbuf(*ffp, bp);
+   s = ffputbuf(*ffp, bp, eobnl);
if (s == FIOSUC) {
/* no write error */
s = ffclose(*ffp, bp);
Index: fileio.c
===
RCS file: /cvs/src/usr.bin/mg/fileio.c,v
retrieving revision 1.105
diff -u -p -u -p -r1.105 fileio.c
--- fileio.c13 Apr 2018 14:11:37 -  1.105
+++ fileio.c20 Jun 2019 17:17:06 -
@@ -150,11 +150,12 @@ ffclose(FILE *ffp, struct buffer *bp)
  * buffer. Return the status.
  */
 int
-ffputbuf(FILE *ffp, struct buffer *bp)
+ffputbuf(FILE *ffp, struct buffer *bp, int eobnl)
 {
-   struct line   *lp, *lpend;
+   struct line *lp, *lpend;

lpend = bp->b_headp;
+
for (lp = lforw(lpend); lp != lpend; lp = lforw(lp)) {
if (fwrite(ltext(lp), 1, llength(lp), ffp) != llength(lp)) {
dobeep();
@@ -164,14 +165,9 @@ ffputbuf(FILE *ffp, struct buffer *bp)
if (lforw(lp) != lpend) /* no implied \n on last line */
putc('\n', ffp);
}
-   /*
-* XXX should be variable controlled (once we have variables)
-*/
-   if (llength(lback(lpend)) != 0) {
-   if (eyorn("No newline at end of file, add one") == TRUE) {
-   lnewline_at(lback(lpend), llength(lback(lpend)));
-   putc('\n', ffp);
-   }
+   if (eobnl) {
+   lnewline_at(lback(lpend), llength(lback(lpend)));
+   putc('\n', ffp);
}
return (FIOSUC);
 }

[patch] relayd OCSP stapling for TLS server

[Bruno Flueckiger]

Hi,

The patch below adds OCSP stapling to the TLS server in relayd(8). The
OCSP response is read from a binary encoded DER file that can be created
using ocspcheck(8).

If a file with the same name as the certificate and private key files is
found, its content is loaded and OCSP stapling is active. If there is no
file or loading its content fails, OCSP stapling remains disabled.

relayd(8) uses the same mechanism it uses to find the certificate file,
only the file name extension is different: .der instead of .pem

Cheers,
Bruno

Index: usr.sbin/relayd/config.c
===
RCS file: /cvs/src/usr.sbin/relayd/config.c,v
retrieving revision 1.39
diff -u -p -r1.39 config.c
--- usr.sbin/relayd/config.c1 Jun 2019 09:54:19 -   1.39
+++ usr.sbin/relayd/config.c20 Jun 2019 17:37:09 -
@@ -913,6 +913,14 @@ config_setrelay(struct relayd *env, stru
rlay->rl_conf.name);
return (-1);
}
+   if (cert->cert_ocsp_fd != -1 &&
+   config_setrelayfd(ps, id, n,
+   cert->cert_id, cert->cert_relayid,
+   RELAY_FD_OCSP, cert->cert_ocsp_fd) == -1) {
+   log_warn("%s: fd passing failed for "
+   "`%s'", __func__,
+   rlay->rl_conf.name);
+   }
}
}

@@ -992,6 +1000,10 @@ config_setrelay(struct relayd *env, stru
close(cert->cert_key_fd);
cert->cert_key_fd = -1;
}
+   if (cert->cert_ocsp_fd != -1) {
+   close(cert->cert_ocsp_fd);
+   cert->cert_ocsp_fd = -1;
+   }
}

return (0);
@@ -1113,6 +1125,7 @@ config_getrelayfd(struct relayd *env, st
switch (crfd.type) {
case RELAY_FD_CERT:
case RELAY_FD_KEY:
+   case RELAY_FD_OCSP:
if ((cert = cert_find(env, crfd.id)) == NULL) {
if ((cert = cert_add(env, crfd.id)) == NULL)
return (-1);
@@ -1139,6 +1152,9 @@ config_getrelayfd(struct relayd *env, st
break;
case RELAY_FD_CAFILE:
rlay->rl_tls_cacert_fd = imsg->fd;
+   break;
+   case RELAY_FD_OCSP:
+   cert->cert_ocsp_fd = imsg->fd;
break;
}

Index: usr.sbin/relayd/relay.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.247
diff -u -p -r1.247 relay.c
--- usr.sbin/relayd/relay.c 31 May 2019 15:15:37 -  1.247
+++ usr.sbin/relayd/relay.c 20 Jun 2019 17:37:09 -
@@ -2130,8 +2130,8 @@ relay_tls_ctx_create(struct relay *rlay)
struct relay_cert   *cert;
const char  *fake_key;
int  fake_keylen, keyfound = 0;
-   char*buf = NULL, *cabuf = NULL;
-   off_tlen = 0, calen = 0;
+   char*buf = NULL, *cabuf = NULL, *ocspbuf = NULL;
+   off_tlen = 0, calen = 0, ocsplen = 0;

if ((tls_cfg = tls_config_new()) == NULL) {
log_warnx("unable to allocate TLS config");
@@ -2209,9 +2209,19 @@ relay_tls_ctx_create(struct relay *rlay)
goto err;
}

+   if (cert->cert_ocsp_fd == -1)
+   goto without;
+
+   if ((ocspbuf = relay_load_fd(cert->cert_ocsp_fd,
+   &ocsplen)) == NULL) {
+   log_warn("failed to load ocsp staple");
+   ocsplen = 0;
+   }
+
+ without:
if (keyfound == 1 &&
tls_config_set_keypair_ocsp_mem(tls_cfg, buf, len,
-   fake_key, fake_keylen, NULL, 0) != 0) {
+   fake_key, fake_keylen, ocspbuf, ocsplen) != 0) {
log_warnx("failed to set tls certificate: %s",
tls_config_error(tls_cfg));
goto err;
@@ -2223,7 +2233,7 @@ relay_tls_ctx_create(struct relay *rlay)
goto err;

if (tls_config_add_keypair_ocsp_mem(tls_cfg, buf, len,
-   fake_key, fake_keylen, NULL, 0) != 0) {
+   fake_key, fake_keylen, ocspbuf, ocsplen) != 0) {
log_warnx("failed to add tls certificate: %s",
tls_config_error(t

bgpd minor optimization

[Claudio Jeker]

prefix_add() is only called by path_update() and path_update already
knows if the prefix exists or not (by calling prefix_get()). So doing
the same check again in prefix_add() is silly and actually rather
expensive with lots of peers. Just alloc and link the prefix instead.

OK?
-- 
:wq Claudio

Index: rde_rib.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_rib.c,v
retrieving revision 1.193
diff -u -p -r1.193 rde_rib.c
--- rde_rib.c   20 Jun 2019 13:38:21 -  1.193
+++ rde_rib.c   20 Jun 2019 16:45:34 -
@@ -922,24 +922,9 @@ prefix_add(struct bgpd_addr *prefix, int
if (re == NULL)
re = rib_add(rib, prefix, prefixlen);
 
-   p = prefix_bypeer(re, peer);
-   if (p == NULL) {
-   p = prefix_alloc();
-   prefix_link(p, re, peer, asp, comm, nexthop, nhflags, vstate);
-   return (1);
-   } else {
-   if (prefix_aspath(p) != asp ||
-   prefix_communities(p) != comm ||
-   prefix_nexthop(p) != nexthop ||
-   prefix_nhflags(p) != nhflags) {
-   /* prefix metadata changed therefor move */
-   return (prefix_move(p, peer, asp, comm, nexthop,
-   nhflags, vstate));
-   }
-   p->lastchange = time(NULL);
-   p->validation_state = vstate;
-   return (0);
-   }
+   p = prefix_alloc();
+   prefix_link(p, re, peer, asp, comm, nexthop, nhflags, vstate);
+   return (1);
 }
 
 /*

Re: Qt5's libtool link scripts are unusable

[Stuart Henderson]

Thanks for the report,

On 2019/06/20 17:30, Vadim Penzin wrote:
> I admit that I am not familiar with the release process of pre-built binary
> packages; I might be writing to a wrong mailing list and I apologize in
> advance.

ports@ is the better list for this, I've CC'd and set reply-to.

> All libtool scripts from qt5 (/usr/local/lib/qt5/*.la) contain the following
> on their third line:
> 
>   LIBQt5XXX_VERSION=5.9# The name that we can dlopen(3).
> 
> (XXX above stands for the name of a particular library, such as Core,
> Network, etc.)
> 
> Since shell scripts (that libtool generates) source .la files, sh(1) fails
> on unexpected '(' because someone, somewhere omitted a space before the
> comment.
> 
> Patching /usr/local/lib/qt5/*.la files programmatically by tucking a space
> before the hash character brings linking with Qt5 assisted (encumbered?) by
> libtool back to life.
> 
> --Vadim
> 

This patch to the qtbase port should fix the problem at source (I'll leave
it building and test later). However it will also require REVISION bumps
on all ports including .la files produced by this.

Index: Makefile
===
RCS file: /cvs/ports/x11/qt5/qtbase/Makefile,v
retrieving revision 1.29
diff -u -p -w -u -r1.29 Makefile
--- Makefile20 May 2019 22:15:29 -  1.29
+++ Makefile20 Jun 2019 15:43:00 -
@@ -15,13 +15,13 @@ PKGNAME-global =qt5-global-${VERSION}
 PKGNAME-psql = qt5-postgresql-${VERSION}
 PKGNAME-sqlite2 =  qt5-sqlite2-${VERSION}
 PKGNAME-tds =  qt5-tds-${VERSION}
+
 REVISION-global =   0
+REVISION-main =5
 REVISION-mysql =   0
 REVISION-psql =0
 REVISION-sqlite2 = 0
 REVISION-tds = 0
-
-REVISION-main =4
 
 PKG_ARCH-global =  *
 PKG_ARCH-examples =*
Index: patches/patch-qmake_generators_unix_unixmake2_cpp
===
RCS file: 
/cvs/ports/x11/qt5/qtbase/patches/patch-qmake_generators_unix_unixmake2_cpp,v
retrieving revision 1.3
diff -u -p -w -u -r1.3 patch-qmake_generators_unix_unixmake2_cpp
--- patches/patch-qmake_generators_unix_unixmake2_cpp   5 Jul 2018 09:49:13 
-   1.3
+++ patches/patch-qmake_generators_unix_unixmake2_cpp   20 Jun 2019 15:43:00 
-
@@ -136,13 +136,14 @@ Index: qmake/generators/unix/unixmake2.c
  } else if (!project->isEmpty("QMAKE_AIX_SHLIB")) {
  
project->values("TARGET_").append(project->first("QMAKE_PREFIX_STATICLIB") + 
project->first("TARGET")
  + "." + project->first("QMAKE_EXTENSION_STATICLIB"));
-@@ -1465,18 +1498,32 @@ UnixMakefileGenerator::writeLibtoolFile()
+@@ -1465,18 +1498,33 @@ UnixMakefileGenerator::writeLibtoolFile()
<< QT_VERSION_STR << ")";
  t << "\n";
  
 +if (!project->isEmpty("QMAKE_OPENBSD_SHLIB"))
 +  t << "LIB" << fileVar("QMAKE_ORIG_TARGET") << "_VERSION="
-+<< project->first("VER_MAJ") << "." << project->first("VER_MIN");
++<< project->first("VER_MAJ") << "." << project->first("VER_MIN")
++<< "\n";
 +
  t << "# The name that we can dlopen(3).\n"
 -  << "dlname='" << fileVar(project->isActiveConfig("plugin") ? "TARGET" : 
"TARGET_x")

Qt5's libtool link scripts are unusable

[Vadim Penzin]

I admit that I am not familiar with the release process of pre-built 
binary packages; I might be writing to a wrong mailing list and I 
apologize in advance.


All libtool scripts from qt5 (/usr/local/lib/qt5/*.la) contain the 
following on their third line:


  LIBQt5XXX_VERSION=5.9# The name that we can dlopen(3).

(XXX above stands for the name of a particular library, such as Core, 
Network, etc.)


Since shell scripts (that libtool generates) source .la files, sh(1) 
fails on unexpected '(' because someone, somewhere omitted a space 
before the comment.


Patching /usr/local/lib/qt5/*.la files programmatically by tucking a 
space before the hash character brings linking with Qt5 assisted 
(encumbered?) by libtool back to life.


--Vadim

Re: ntpd auto time setting

[sven falempin]

On Thu, Jun 20, 2019 at 6:46 AM Otto Moerbeek  wrote:

> Hi,
>
> I have been working on a nice feature that improves startup behaviour of
> ntpd.
>
> Summary: make sure you have at least one constraint source configured
> and use no options. ntpd will set the clock if needed, even if you
> machines has no battery backed up clock and is running a DNSSEC
> validating resolver.
>
> Previoulsy, using constraints or a DNSSEC validating resolver would
> break initial time setting, since doing https certificate and DNSSEC
> validation requires a proper clock. An we do not have that in above
> circumstances.
>
> In addition to previous work from jsing@ regarding https certificate
> validation my commits enable time bootstrapping in these adverse
> conditions.
>
> You want to stop using -s if you did, since the new method is more
> robust and more secure. (-s trusts any ntp reply, while the new
> automatic mode only does so if several ntp replies were validated).
>
> The last commit was a few hours ago, upcoming snaps should have all
> the nice things.
>
> -Otto
>
>
>
It works here (complied from source).
Device go back to right time after Destroying date at boot and only
accepting DNSSEC .

snaps# date
Thu Jun 20 15:52:57 CEST 2019
snaps# uptime
 3:52PM  up 2 mins, 1 user, load averages: 0.07, 0.04, 0.01
snaps# head /etc/rc
#   $OpenBSD: rc,v 1.537 2019/05/10 13:29:21 guenther Exp $
# System startup script run by init on autoboot or after single-user.
# Output and error are redirected to console by init, and the console is the
# controlling terminal.
date 201806041030.00
# Turn off Strict Bourne shell.

Best.

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: another go at bypass support for sparc64 iommu and BUS_DMA_64BIT

[Klemens Nanni]

Upgraded my T5240 using the latest bsd.rd, all is fine - no noticable
regression in production.

Re: devel/cvsweb: README (patch)

[Christian Weisgerber]

w...@disroot.org:

> after locate(1)'ing and adding those files i could happily run cvsweb on 
> openbsd 6.5-release
> 
> i'm sending patch for README (2 lines) as suggested by \renaud on #openbsd 
> (freenode)

Thanks, but this was already fixed in -current seven weeks ago.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

ntpd auto time setting

[Otto Moerbeek]

Hi,

I have been working on a nice feature that improves startup behaviour of
ntpd.

Summary: make sure you have at least one constraint source configured
and use no options. ntpd will set the clock if needed, even if you
machines has no battery backed up clock and is running a DNSSEC
validating resolver.

Previoulsy, using constraints or a DNSSEC validating resolver would
break initial time setting, since doing https certificate and DNSSEC
validation requires a proper clock. An we do not have that in above
circumstances. 

In addition to previous work from jsing@ regarding https certificate
validation my commits enable time bootstrapping in these adverse
conditions.

You want to stop using -s if you did, since the new method is more
robust and more secure. (-s trusts any ntp reply, while the new
automatic mode only does so if several ntp replies were validated).

The last commit was a few hours ago, upcoming snaps should have all
the nice things.

-Otto

Re: libcrypto: recognize HW acceleration support on arm64

[Remco]

On 19-06-19 07:13, Patrick Wildt wrote:

Hi,

this diff adds the necessary helpers to arm64 so that libcrypto knows
which of the hardware crypto features are available on the machine.
Those helpers are used by the existing and matching armv7 code.

ok?

Patrick



Does it make sense to query the ID_AA64PFR0_EL1 and ID_AA64ISAR0_EL1 
system registers for that using the mrs instruction ?


I've only got a Linux system to play with and it's not clear to me how 
to specify these registers with the mrs instruction on that system. I 
resorted to encoding the instructions directly into the assembly code as 
a byte sequence. I don't know if this also applies to OpenBSD.


In case you're interested, these functions seem to return reasonable 
results on the one hardware board I have. It does crash on qemu though 
with an "Illegal instruction" message.



.arch armv8-a


.text
.p2align 5
.globl cpuid_get_id_aa64isar0_el1
cpuid_get_id_aa64isar0_el1:

  # ID_AA64ISAR0_EL1:
  # op0  op1  CRn   CRm   op2
  # 11   000    0110  000

  # mrs  x0, ID_AA64ISAR0_EL1
  # 1101 0101 0011 1000  0110  
  .byte 0x00, 0x06, 0x38, 0xd5

  ret

.size cpuid_get_id_aa64isar0_el1, .-cpuid_get_id_aa64isar0_el1
.type cpuid_get_id_aa64isar0_el1, @function


.text
.p2align 5
.globl cpuid_get_id_aa64pfr0_el1
cpuid_get_id_aa64pfr0_el1:

  # ID_AA64PFR0_EL1:
  # op0  op1  CRn   CRm   op2
  # 11   000    0100  000

  # mrs  x0, ID_AA64PFR0_EL1
  # 1101 0101 0011 1000  0100  
  .byte 0x00, 0x04, 0x38, 0xd5

  ret

.size cpuid_get_id_aa64pfr0_el1, .-cpuid_get_id_aa64pfr0_el1
.type cpuid_get_id_aa64pfr0_el1, @function

devel/cvsweb: README (patch)

[w17t]

hello,

after installing devel/cvsweb, doing `sh README`, and modifying cvsweb and 
cvsweb.conf files:

i got 500 internal server error

doing chroot /var/www /cgi-bin/cvsweb i noticed from the output that some files 
were missing:


Can't locate parent.pm in @INC (you may need to install the parent module) 
(@INC contains: /usr/local/libdata/perl5/site_perl/amd64-openbsd 
/usr/local/libdata/perl5/site_perl /usr/libdata/perl5/amd64-openbsd 
/usr/libdata/perl5) at /usr/libdata/perl5/Time/Local.pm line 10.

Can't locate loadable object for module Cwd in @INC (@INC contains: 
/usr/local/libdata/perl5/site_perl/amd64-openbsd 
/usr/local/libdata/perl5/site_perl /usr/libdata/perl5/amd64-openbsd 
/usr/libdata/perl5) at /cgi-bin/cvsweb line 1831


after locate(1)'ing and adding those files i could happily run cvsweb on 
openbsd 6.5-release

i'm sending patch for README (2 lines) as suggested by \renaud on #openbsd 
(freenode)

references:
readme: 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/devel/cvsweb/pkg/README?rev=1.18&content-type=text/x-

thank you for the attention


README.cvsweb.patch
Description: Binary data