Re: [PATCH] Provide static_ASN1_*(). From OpenSSL 1.1.0 API.

2019-07-22 Thread Stefan Strogin
Hi Theo, On 24/05/2019 16:27, Theo Buehler wrote: > On Fri, May 24, 2019 at 04:22:06PM +0300, Stefan Strogin wrote: >> Could somebody review the patch please? > > We saw the pull request and will look into it soon. Apologies, we are > all currently very busy. How do you do? Do you expect some

smtpd: Allow labels containing "@"

2019-07-22 Thread Klemens Nanni
My mail is klem...@posteo.de and the provider expects this full address as username, so that makes for the following perfectly valid SMTP URL smtps://klem...@posteo.de@posteo.de:465. I've been doing that with mutt(1) for ages. smtpd.conf(5) has the following syntax: host relay-url

Re: Diff to stop using reserved words for smtpd.conf(5) examples

2019-07-22 Thread Klemens Nanni
On Mon, Jul 22, 2019 at 05:25:28PM -0400, Kurt Mosiejczuk wrote: > If you look at the existing man page, it is left off on the examples > where they aren't using reserved words. For a few seconds I thought it > was a sloppy examples, but then I realized the only reason the quotes > are there are

Re: Diff to stop using reserved words for smtpd.conf(5) examples

2019-07-22 Thread Klemens Nanni
On Mon, Jul 22, 2019 at 05:05:01PM -0400, Kurt Mosiejczuk wrote: > This is a diff for that changes the example smtpd.conf and smtpd.conf.5 > so that it no longer uses words that are parts of the configuration > syntax as labels for actions. A large chunk of my delay to a release > with the new

smtpd: Use IPPORT_HILASTAUTO not 0xffff

2019-07-22 Thread Klemens Nanni
More mnemonic and readable. OK? Index: to.c === RCS file: /cvs/src/usr.sbin/smtpd/to.c,v retrieving revision 1.35 diff -u -p -r1.35 to.c --- to.c30 Dec 2018 23:09:58 - 1.35 +++ to.c22 Jul 2019 22:16:29 -

smtpd: default to standard ports in relay-host

2019-07-22 Thread Klemens Nanni
Using the following configuration, I wrongly assumed smtpd(8) to pick the appropiate ports by default depending on the protocol as it already does for `listen' statements: action "relay" relay host smtps://la...@example.com auth but no matter the protocol ("smtps" here), port 25 is

Re: ping(8): better "-i wait" edge case handling

2019-07-22 Thread Scott Cheloha
> On Jul 22, 2019, at 01:49, Claudio Jeker wrote: > >> On Sun, Jul 21, 2019 at 08:30:23AM -0500, Scott Cheloha wrote: >> On Sun, Jul 21, 2019 at 11:49:10AM +0200, Mark Kettenis wrote: Date: Sun, 21 Jul 2019 10:50:27 +0200 From: Claudio Jeker > On Sat, Jul 20, 2019 at

Re: smtpd: Allow labels containing "@"

2019-07-22 Thread Gilles Chehade
On Mon, Jul 22, 2019 at 11:26:28PM +0200, Klemens Nanni wrote: > My mail is klem...@posteo.de and the provider expects this full address > as username, so that makes for the following perfectly > valid SMTP URL smtps://klem...@posteo.de@posteo.de:465. > > I've been doing that with mutt(1) for

Re: ping(8): better "-i wait" edge case handling

2019-07-22 Thread Claudio Jeker
On Sun, Jul 21, 2019 at 08:30:23AM -0500, Scott Cheloha wrote: > On Sun, Jul 21, 2019 at 11:49:10AM +0200, Mark Kettenis wrote: > > > Date: Sun, 21 Jul 2019 10:50:27 +0200 > > > From: Claudio Jeker > > > > > > On Sat, Jul 20, 2019 at 08:12:40AM -0500, Scott Cheloha wrote: > > > > There are cases

bgpd RIB handling cleanup part 1

2019-07-22 Thread Claudio Jeker
The RIB handling, especially on reloads could be a bit nicer. This diff is one of the preparation steps for this. The goal in the end is it to make it possible to have RIBs (in the multi-RIB case) not only dependent on Adj-RIB-In but also allow to use other RIBs as input. This way the filters for

Re: fix: NULL dereference in bios(4)

2019-07-22 Thread Jan Klemkow
On Sat, Jul 20, 2019 at 07:16:05PM +1000, Jonathan Gray wrote: > On Fri, Jul 19, 2019 at 02:15:03PM +0200, Jan Klemkow wrote: > > On Fri, Jul 19, 2019 at 09:13:38PM +1000, Jonathan Gray wrote: > > > On Fri, Jul 19, 2019 at 01:07:34PM +0200, Jan Klemkow wrote: > > > > fixstring() can return NULL

802.11n Tx aggregation for iwn(4)

2019-07-22 Thread Stefan Sperling
This diff adds support for 11n Tx aggregation to net80211 and implements driver support in iwn(4). Other drivers will follow later. I chose to start with iwn(4) because damien@ left some unfinished bits of Tx agg support in this driver. Please use wifi as usual with this diff applied and check

Re: [patch] Re-add 'proc' to vi(1) when running in secure mode.

2019-07-22 Thread Ingo Schwarze
Hi, Bryan Steele wrote on Sun, Jul 21, 2019 at 01:53:49PM -0400: > On Sat, Jul 20, 2019 at 12:03:03AM +0200, Jesper Wallin wrote: >> Oh, you're right. A bit ironic that I didn't notice the exec violation >> due to the fork being permitted now. Thanks for pointing this out! >> Scrap my old

Re: [patch] Re-add 'proc' to vi(1) when running in secure mode.

2019-07-22 Thread Jesper Wallin
On Mon, Jul 22, 2019 at 03:23:16PM +0200, Ingo Schwarze wrote: > > 3. Jesper, including a patch according to the best of your > understanding is always welcome. Even if it turns out to be a > bad patch, because often even a bad patch helps to understand > what the OP thinks the

Re: [patch] Re-add 'proc' to vi(1) when running in secure mode.

2019-07-22 Thread Ingo Schwarze
Hi Jesper, Jesper Wallin wrote on Mon, Jul 22, 2019 at 06:09:03PM +0200: > On Mon, Jul 22, 2019 at 03:23:16PM +0200, Ingo Schwarze wrote: >> 3. Jesper, including a patch according to the best of your >> understanding is always welcome. Even if it turns out to be a >> bad patch,

Re: [patch] Re-add 'proc' to vi(1) when running in secure mode.

2019-07-22 Thread Jesper Wallin
On Mon, Jul 22, 2019 at 06:24:28PM +0200, Ingo Schwarze wrote: > But make sure that doesn't cause bugs to not get reported at all > because the process causes too much work or takes too long. :) > Oh yeah, no worries! :-)

extend 802.11 Rx aggregation "gap timeout"

2019-07-22 Thread Stefan Sperling
As noted in the description of my Tx agg patch earlier today, there seems to be a small problem in our Rx aggregation code. With 802.11n Tx/Rx aggregation, frames may arrive out of order. But the wireless layer must deliver incoming frames to upper layers in order. Frames received from the driver

Re: extend 802.11 Rx aggregation "gap timeout"

2019-07-22 Thread Mark Kettenis
> Date: Mon, 22 Jul 2019 19:38:59 +0200 > From: Stefan Sperling > Content-Type: text/plain; charset="utf-8" > Content-Disposition: inline > > As noted in the description of my Tx agg patch earlier today, > there seems to be a small problem in our Rx aggregation code. > > With 802.11n Tx/Rx

vfs posix compatibility change

2019-07-22 Thread Moritz Buhl
Hi, here is another POSIX compatibility change I found while running NetBSD system call tests: The incompatibilities can be reproduced with the followding comands: `mv / foo` mv: rename / to foo: Is a directory `man 2 rename` mentions EISDIR: [EISDIR] to is a directory, but from is not

Re: extend 802.11 Rx aggregation "gap timeout"

2019-07-22 Thread Stefan Sperling
On Mon, Jul 22, 2019 at 07:59:40PM +0200, Mark Kettenis wrote: > Given your description above combined with the 100 ms value that Linux > uses, this sounds like a bad idea to me. OK, fine. We can leave it as it is. If I'm not mistaken, an upper bound of "medium busy" time for a single aggregate