less: tighten pledge in secure mode

2021-09-21 Thread Tobias Stoeckmann
Hi, upstream (greenwood) less has disabled history file support for secure mode, i.e. LESSSECURE=1: https://github.com/gwsw/less/pull/201 The problem was about permanent marks for which we do not have support anyway. Users could possibly access files they should not be able to. Since upstream

Re: ksh(1) search-history fix

2021-09-21 Thread Alexander Hall
On Tue, Sep 21, 2021 at 10:24:47PM +0200, Alexander Hall wrote: > OK? Unless someone finds a clever and horrible way of abusing this, I won't be committing it pre-release. Comments and/or OK's still appreciated though. :-) /Alexander

Re: pf.conf(5) & reply-to

2021-09-21 Thread Sebastian Benoit
Alexander Bluhm(alexander.bl...@gmx.net) on 2021.09.21 22:34:09 +0200: > On Mon, Sep 20, 2021 at 03:54:58PM +0200, Landry Breuil wrote: > > did i screwup something somewhere in my config and there's a better way > > for that ? > > This was changed in February. No more interface, but gateway >

Re: pf.conf(5) & reply-to

2021-09-21 Thread Alexander Bluhm
On Mon, Sep 20, 2021 at 03:54:58PM +0200, Landry Breuil wrote: > did i screwup something somewhere in my config and there's a better way > for that ? This was changed in February. No more interface, but gateway addresses. It seems that some parts of the documentation were missed. > should the

ksh(1) search-history fix

2021-09-21 Thread Alexander Hall
Hi, In ksh(1) emacs editing mode, the search-history editing command (normally bound to ^R), is used for interactive searching through the history of previously given commands. While performing such a search, emitting a NUL character (i.e. '\0', or ^@) adds said character to the search

Re: ksh emacs search-history misbehaviour

2021-09-21 Thread Alexander Hall
On Sun, Sep 19, 2021 at 02:29:57AM +0100, ropers wrote: > I appreciate not everyone is as verbose as I can be, but your initial > email was very terse. For example, when you say: > > > in emacs search-history mode, abort if ^@ is encountered > > is that the desired behaviour or the problem

Re: relayd regress tcp performance

2021-09-21 Thread Alexander Bluhm
On Sat, Sep 18, 2021 at 02:35:20PM +0200, Jan Klemkow wrote: > The following diff removes the every 2nd ACK feature again and ensures > that we send out an ACK if soreceive() empties the receive buffer. Looks good in my perform tests, 22% tcp throughput increase.