Re: mg backup directory

Sorry, space got mangled in previous email. Index: fileio.c === RCS file: /cvs/src/usr.bin/mg/fileio.c,v retrieving revision 1.103 diff -u -p -u -p -r1.103 fileio.c --- fileio.c28 Jul 2016 21:40:25 - 1.103 +++ fileio.c

mg backup directory

Hi tech@, mg(1)'s backup-to-home-directory writes backup files to `~/.mg.d' according to the manpage. In order to expand the tilde, it uses a custom function (expandtilde, fileio.c:700) which uses the pw entry for the user name returned by getlogin(2). This can lead to an undesired result if mg

Re: Convert explicit_bzero+free to freezero on smtpd(8)

On Thu, May 11, 2017 at 11:33:10AM +0100, Ricardo Mestre wrote: > Hi, > > This converts explicit_bzero+free to freezero on smtpd(8). > > OK? Sorry i was away from town I'll have a look at freezero() tomorrow as I missed most of the discussion about its semantics and I'll ok then Thanks >

Re: ipv6 mapped address output

On Mon, May 08, 2017 at 05:09:01PM +0200, Alexander Bluhm wrote: > Checking for IPv4 mapped addresses is a bit inconsistent in the > output path. Here comes the remaining part: - Do not check for mapped addresses in tcp_usrreq(PRU_CONNECT), this is done in in6_pcbconnect(). - Do not check for

Pf manpage update for FQ-CoDel

I've tried very hard to make it concise and avoided any references to underlying algorithms. OK? --- share/man/man5/pf.conf.5 | 47 --- 1 file changed, 44 insertions(+), 3 deletions(-) diff --git share/man/man5/pf.conf.5 share/man/man5/pf.conf.5

Re: Pf interface for FQ-CoDel

On Fri, Apr 28, 2017 at 19:58 +0200, Mike Belopuhov wrote: > This is the last bit required in order to actually be able to > use FQ-CoDel. It might require some polish, but I think there's > nothing exceptionally ugly barring the statistics interface. > > fqcodel_stats is constructed to have a

Re: ipv6 mapped address output

On 12 May 2017 at 18:13, Alexander Bluhm wrote: > On Mon, May 08, 2017 at 05:09:01PM +0200, Alexander Bluhm wrote: > > Checking for IPv4 mapped addresses is a bit inconsistent in the > > output path. > > I should split the diff to make review easier. > > - Use the common

Re: ipsec panic early

On 12 May 2017 at 18:08, Alexander Bluhm wrote: > On Fri, May 12, 2017 at 05:56:09PM +0200, Mike Belopuhov wrote: > > No, there's a check just above... > > And without the panic? Remove duplicate code, remove if (proto == 0) > that cannot happen. > > bluhm > > Sure.

Re: ipv6 mapped address output

On Mon, May 08, 2017 at 05:09:01PM +0200, Alexander Bluhm wrote: > Checking for IPv4 mapped addresses is a bit inconsistent in the > output path. I should split the diff to make review easier. - Use the common switch(af) construct for af specific code in tcp_usrreq(PRU_CONNECT). - Do not

Re: ipsec panic early

On Fri, May 12, 2017 at 05:56:09PM +0200, Mike Belopuhov wrote: > No, there's a check just above... And without the panic? Remove duplicate code, remove if (proto == 0) that cannot happen. bluhm Index: net/if_bridge.c === RCS

multipath / route priority support for ospf6d

Hi, our QA reports issues with the ospf6d since the kernel uses more multipath routes. It exits after certain topology changes with: rde_send_change_kroute: no valid nexthop found Since the kernel uses more multipath routes, the lack of multipath support in ospf6d became a problem. The

Re: ipsec panic early

On 12 May 2017 at 17:28, Alexander Bluhm wrote: > On Fri, May 12, 2017 at 01:53:12PM +0200, Alexander Bluhm wrote: > > In bridge_ipsec() tdb comes from > > gettdb() called with proto. There we goto skiplookup if proto != > > IPPROTO_ESP && proto != IPPROTO_AH && proto

Re: ipsec panic early

On Fri, May 12, 2017 at 01:53:12PM +0200, Alexander Bluhm wrote: > In bridge_ipsec() tdb comes from > gettdb() called with proto. There we goto skiplookup if proto != > IPPROTO_ESP && proto != IPPROTO_AH && proto != IPPROTO_IPCOMP. While looking at this, I saw the same code in the IPv4 and IPv6

Re: IPsec IPv4 local delivery

On 12 May 2017 at 15:29, Alexander Bluhm wrote: > Hi, > > IPsec packets are passed through ip_input() a second time after > they have been decrypted. That means that all the IP header fields > are checked twice. Also fragment reassembly is tried twice. > > In pf

Re: Atomic copyin(9)/copyout(9) for amd64

On Mon, May 01, 2017 at 06:02:24PM +0200, Mark Kettenis wrote: > The futex(2) syscall needs to be able to atomically copy the futex in > and out of userland. The current implementation uses copyin(9) and > copyout(9) for that. The futex is a 32-bit integer, and currently our > copyin(9) and

IPsec IPv4 local delivery

Hi, IPsec packets are passed through ip_input() a second time after they have been decrypted. That means that all the IP header fields are checked twice. Also fragment reassembly is tried twice. In pf incoming packets in tunnel mode appear twice on the enc0 interface. Once as IP-in-IP and

Re: ipsec panic early

On Fri, May 12, 2017 at 01:53:12PM +0200, Alexander Bluhm wrote: > On Fri, May 12, 2017 at 07:30:28AM +0100, Tom Cosgrove wrote: > > >>> Alexander Bluhm 11-May-17 23:25 >>> > > > Instead of printing a debug message at the end, panic early if the > > > IPsec security protocol is unknown. > > > >

Re: ipsec panic early

On Fri, May 12, 2017 at 07:30:28AM +0100, Tom Cosgrove wrote: > >>> Alexander Bluhm 11-May-17 23:25 >>> > > Instead of printing a debug message at the end, panic early if the > > IPsec security protocol is unknown. > > Is this before or after we have decrypted and checked MAC? TBH, even if >

Re: [patch] mg: fix overflow on vteeol()

On Sun, May 07, 2017 at 05:31:26PM +0200, Hiltjo Posthuma wrote: > Hey, > > mg crashes with certain (unicode) characters and moving the cursor to the > end of the line. > > The characters are printed to the screen as \nnn in vtpute() and vtcol is > updated, however vteeol() will write beyond the

Re: Atomic copyin(9)/copyout(9) for amd64

On 01/05/17(Mon) 18:02, Mark Kettenis wrote: > The futex(2) syscall needs to be able to atomically copy the futex in > and out of userland. The current implementation uses copyin(9) and > copyout(9) for that. The futex is a 32-bit integer, and currently our > copyin(9) and copyout(9) don't

Replace memset with explicit_bzero on user(8)

Hi, I'm almost sure I sent this aeons ago already, but never got commited. It calls explicit_bzero instead of memset on passwords as soon as they're not needed in memory anymore. Index: user.c === RCS file: