Re: key guessing for signify -C

2020-01-20 Thread Ted Unangst
Theo Buehler wrote: > Two small things for signify -C: > > Contrary to what usage suggests, the -p pubkey argument for signify -C > is optional in that signify will use the key specified in the untrusted > comment. In -V mode, the key can be tied down a little by specifying -t. > > Right now,

key guessing for signify -C

2020-01-20 Thread Theo Buehler
Two small things for signify -C: Contrary to what usage suggests, the -p pubkey argument for signify -C is optional in that signify will use the key specified in the untrusted comment. In -V mode, the key can be tied down a little by specifying -t. Right now, the -t keytype argument is silently

Re: [patch] signify's file name parsing broken

2020-01-20 Thread Theo de Raadt
Ted Unangst wrote: > MarcusMüller wrote: > > I've just stumbled across a malfunction in signify: It cannot handle > > file names that contain a `)` character, when checking a list of hashes > > generated by `sha256` command line utilities (`sha256sum --tags` on > > Linux). > > This fix is

Re: [patch] signify's file name parsing broken

2020-01-20 Thread Ted Unangst
MarcusMüller wrote: > I've just stumbled across a malfunction in signify: It cannot handle > file names that contain a `)` character, when checking a list of hashes > generated by `sha256` command line utilities (`sha256sum --tags` on > Linux). This fix is unfortunately rather complicated for

Re: bgpd, remove getifaddrs call in RDE

2020-01-20 Thread Claudio Jeker
On Thu, Jan 09, 2020 at 02:45:46PM +0100, Claudio Jeker wrote: > The RDE needs to know the local v4 and v6 address of a session so that > nexthop self works. Until now the lookup for the other AF address was done > in the RDE when the session got established. This diff moves this code > over to

Re: piixpm(4) on ATI SBx00

2020-01-20 Thread Claudio Jeker
On Tue, Jan 07, 2020 at 12:44:59PM +0100, Claudio Jeker wrote: > On Tue, Jan 07, 2020 at 09:27:50AM +0100, Claudio Jeker wrote: > > In -current I added support for the additional I2C busses on piixpm(4) > > now I noticed that on my old AMD system the I2C bus seems to either > > connect all those 4

Re: securelevel.7: Clarify mem(4) semantics

2020-01-20 Thread Theo de Raadt
Klemens Nanni wrote: > On Sun, Jan 19, 2020 at 11:50:01AM -0700, Theo de Raadt wrote: > > Your text seems somewhat backwards, because if you can't open it, it > > doesn't matter if it is read-only, it is read-not. > It starts with what holds true unconditionally: the fact that you cannot >

Re: bnxt(4), myx(4), vr(4): refill timeouts: timeout_add(..., 0) -> timeout_add(..., 1)

2020-01-20 Thread Hrvoje Popovski
On 20.1.2020. 17:40, Scott Cheloha wrote: > Appreciate the testing. np, i like testing network stuff :) > Given what dlg@ has said in the past I think there should only be a > performance change in a livelock situation. yeah, that could be problem with this testing ... kern.netlivelocks=6

Naive patch to allow amd(8) to mount NFS with wxallowed

2020-01-20 Thread Andreas Kusalananda Kähäri
I noticed that the following amd(8) map did not actually mount the remote NFS filesystem with the wxallowed mount option: /defaults sublink:=${key} * host==eeyore;type:=link;fs:=/vol/local/${host}; \

Re: em(4) diff to test

2020-01-20 Thread Hrvoje Popovski
On 20.1.2020. 16:42, Martin Pieuchot wrote: > Diff below is a refactoring of the actual em(4) code and defines that > will allows me to present a shorter diff to interrupt multiple CPUs and > make use of multiple queues. > > It contains the following items: > > - Abstract the

Re: New pseudo-driver dt(4): dynamic tracer

2020-01-20 Thread Martin Pieuchot
On 20/01/20(Mon) 07:19, Mark Kettenis wrote: > > [...] > > I'd appreciate particular review of the following items: > > > > * Event producer/consumer code which currently needs a mutex. The > >current implementation doesn't always use a PCB per-CPU. Moving > >to a lockless

Re: bnxt(4), myx(4), vr(4): refill timeouts: timeout_add(..., 0) -> timeout_add(..., 1)

2020-01-20 Thread Scott Cheloha
> On Jan 20, 2020, at 4:47 AM, Hrvoje Popovski wrote: > > On 16.1.2020. 18:45, Scott Cheloha wrote: >> Here's a first batch of conversions: rx refill timeouts for bnxt(4), >> myx(4), and vr(4). All of these can run during a softclock(). Will >> changing these to one tick break these drivers? >

Re: ospf(6)d: allow "type p2p" globally or per area

2020-01-20 Thread Denis Fondras
On Sun, Jan 19, 2020 at 11:04:16PM +0100, Remi Locherer wrote: > This makes the interface setting "type p2p" configurable globally or > per area. ospf(6)d allows this for almost all interface related settings. > > As a side-effect of this diff ospf(6)d -nv prints "type p2p" also for >

ospf6d: simplify lsa_snap()

2020-01-20 Thread Denis Fondras
No need to pass peerid to lsa_snap() While at it, remove unused variable. Index: rde.c === RCS file: /cvs/src/usr.sbin/ospf6d/rde.c,v retrieving revision 1.82 diff -u -p -r1.82 rde.c --- rde.c 2 Jan 2020 10:16:46 -

em(4) diff to test

2020-01-20 Thread Martin Pieuchot
Diff below is a refactoring of the actual em(4) code and defines that will allows me to present a shorter diff to interrupt multiple CPUs and make use of multiple queues. It contains the following items: - Abstract the allocation/freeing of TX/RX ring into em_dma_malloc(). This will ease

upd(4): force boolean indicator to be 0 or 1

2020-01-20 Thread Boudewijn Dijkstra
Some upd(4) devices use -1 for "On" and some use 1. sysctl(8) and sensorsd(8) hide this detail from the user, which makes it difficult to define low and high values in sensorsd.conf(5). Also see https://marc.info/?l=openbsd-misc=144529176814155=2 I'd like to suggest a diff like the

Re: bnxt(4), myx(4), vr(4): refill timeouts: timeout_add(..., 0) -> timeout_add(..., 1)

2020-01-20 Thread Hrvoje Popovski
On 16.1.2020. 18:45, Scott Cheloha wrote: > Here's a first batch of conversions: rx refill timeouts for bnxt(4), > myx(4), and vr(4). All of these can run during a softclock(). Will > changing these to one tick break these drivers? Hi all, i tried this diff with myx and performance are the