Getting in touch

L.S., Trying for a bit over a week to gt a response re: libressl. 1) If you have a established mailing-list for libressl - I did not find it. That of course says something about me - and maybe you are trying to keep people who cannot seek well enough away. I can only hope that you take this a

pf congestion handling

i started looking at locking on interface send queues (which use struct ifqueue) and got distracted cos the same data structure is used for the stack input queues. the stack input queues dont need the pri or hfsc queing bits, theyre just used as a fifo, so they can largely get directly replaced wi

pfsync: include set prio

what $subject says. no real compat issue since we're using spare bytes. old -> new ends up with set prio (0, 0) equivalent new -> old is entirely harmless, old ignores the prios. acceptable imo, since the effects of set prio aren't all THAT big and the other option, bumping the pfsync version, is

pf log(matches to pflog42)

pf's log(matches), essentially rule match tracing, is a great debugging method. You probably don't want that to end up in your regular pf logs tho. So just use a different pflog interface for that. Didn't work yet, because the target pflog interface was taken from the rule that matches, not the log

Re: ntpd: Do not allow privsep user to be a privileged user

> On Mon, Feb 09, 2015 at 10:37:01PM -0600, Brent Cook wrote: > > Since openntpd-portable allows configuring the privsep user, do a > > couple of sanity checks at runtime to make sure the privsep user wasn't > > configured as root. > > > > This might be overkill. > > > > I wouldn't like if ntpd

Re: ntpd: Do not allow privsep user to be a privileged user

On Mon, Feb 09, 2015 at 10:37:01PM -0600, Brent Cook wrote: > Since openntpd-portable allows configuring the privsep user, do a > couple of sanity checks at runtime to make sure the privsep user wasn't > configured as root. > > This might be overkill. > I wouldn't like if ntpd has anything speci

ntpd and SOCK_NONBLOCK...

Start using SOCK_NONBLOCK and SOCK_CLOEXEC in ntpd as well. Make sure we handle EAGAIN and EINTR on the recvmsg and sendto calls. OK? -- :wq Claudio Index: client.c === RCS file: /cvs/src/usr.sbin/ntpd/client.c,v retrieving revision

ntpd: Do not allow privsep user to be a privileged user

Since openntpd-portable allows configuring the privsep user, do a couple of sanity checks at runtime to make sure the privsep user wasn't configured as root. This might be overkill. --- src/usr.sbin/ntpd/ntp.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/usr.sbin/ntpd/ntp.c b/sr

ntpd: be more verbose when logging privsep errors

This makes it easier for a sysadmin to diagnose a privilege separation path problem without looking at the source code for why 'stat' failed. ok? --- src/usr.sbin/ntpd/ntp.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/usr.sbin/ntpd/ntp.c b/src/usr.sbin/ntp

ntpd: prefer %z when formatting size_t

Pretty trivial conversion. ok? Index: ntp_msg.c === RCS file: /cvs/src/usr.sbin/ntpd/ntp_msg.c,v retrieving revision 1.20 diff -u -p -u -p -r1.20 ntp_msg.c --- ntp_msg.c 9 Jan 2015 07:35:37 - 1.20 +++ ntp_msg.c 10 Feb 20

Re: OK... how dare you both even to not publish patches...

Sebastian's emails don't make it to the list, but in the interest of transparency and not hiding any secrets about OpenBSD's security, I'm forwarding it along as requested. I'm not going to comment further except to say that my mom's OpenBSD laptop does not have linux compat enabled. Sebastian Ro

rcvif in wireless drivers

Now that ieee80211_input() calls if_input() there's no need to set the `rcvif' pointer befotre. This shrinks my conversion diff :) ok? Index: ic/acx.c === RCS file: /cvs/src/sys/dev/ic/acx.c,v retrieving revision 1.109 diff -u -p -r

Re: Change the way we handle interface/connected networks

On 10/02/15(Tue) 03:04, Claudio Jeker wrote: > There is no need to not allow the same network to be configured more then > once. Instead just rely on the multipath and priority handling of the > routing table to select the right route. > Additionally this removes cloned routes (arp/npd cache) when

Re: dhclient should be more specific on routes

On 10/02/15(Tue) 03:07, Claudio Jeker wrote: > This diff makes sure that the route dhclient installes is actually over > the interface dhclient runs on and not an other one with the same network. > This also removes the conflict detection we have at the moment. In general it's a good practice to g

dhclient should be more specific on routes

This diff makes sure that the route dhclient installes is actually over the interface dhclient runs on and not an other one with the same network. This also removes the conflict detection we have at the moment. OK? -- :wq Claudio Index: dhclient.c

Change the way we handle interface/connected networks

There is no need to not allow the same network to be configured more then once. Instead just rely on the multipath and priority handling of the routing table to select the right route. Additionally this removes cloned routes (arp/npd cache) when the interface goes down or when the any of the multip

lmc(4) and de(4) abuse

These two drivers abuse the 'rcvif' pointer for something else. Let's do like for wireless driver and use a cookie, this way it will be easier to get rid of the ifp pointer in the mbuf. Ok? Index: dev/pci/if_devar.h === RCS file: /c

make em(4) smarter at finding gcu0

iterating over alldevs when we have device_lookup is silly. also, i want to protect alldevs in the future, so fumbling with it directly isnt the best. can someone with a gcu0 test this? Index: dev/pci/files.pci === RCS file: /cvs/sr

Re: sys/mbuf.h: tedu m_act

> On 9 Feb 2015, at 1:40 pm, Lawrence Teo wrote: > > m_act was the historical name of m_nextpkt, and was already deprecated > at the time D&I of 4.4BSD was published. Nothing in our tree uses it, > so I would like to propose removing it. Both FreeBSD and NetBSD have > removed theirs. > > I ha