Re: doas: adjust yyerror() output

2016-04-26 Thread Philip Guenther
On Tue, Apr 26, 2016 at 8:06 PM, Ted Unangst wrote: > Gleydson Soares wrote: >> > what about just printing "doas: "? >> >> I prefer not hardcoded string, although I've committed as you pointed out, > > getprogname() doesn't seem any more portable than __progname, which is the

Re: doas: adjust yyerror() output

2016-04-26 Thread Ted Unangst
Gleydson Soares wrote: > > what about just printing "doas: "? > > I prefer not hardcoded string, although I've committed as you pointed out, getprogname() doesn't seem any more portable than __progname, which is the classic means of doing this. It's useful in cases where a program may have more

Re: doas: adjust yyerror() output

2016-04-26 Thread Gleydson Soares
> what about just printing "doas: "? I prefer not hardcoded string, although I've committed as you pointed out,

Re: anti-ROP mechanism in libc

2016-04-26 Thread Vadim Zhukov
26 Apr. 2016 19:58 "Theo de Raadt" wrote: > > Here is a new version that does a more comprehensive test of the new > libc.so before installing it, and uses install -S > > Index: etc/rc > === > RCS file:

BISTRO AT THE OLD FORT INN wins 2016 customer satisfaction award!

2016-04-26 Thread Customer Care
View this email with images. 2016 CUSTOMER SERVICE REPORT RESULTS Call Today! 866-732-9800 WE IDENTIFY OUTSTANDING BUSINESSES [IMAGE] BISTRO AT THE OLD FORT INN IS BEING HONORED AS A WINNER OF THE 2016 SPECTRUM AWARD FOR SERVICE EXCELLENCE! Congratulations are in order to you and your team

Re: Moving away from softnet interrupts

2016-04-26 Thread Janne Johansson
2016-04-25 9:59 GMT+02:00 Martin Pieuchot : > > > The current goal of the Network SMP effort is to have a single CPU > > > process the IP forwarding path in a process context without holding > > > the KERNEL_LOCK(). To achieve this goal we're progressively moving > > > code

longjmp without sigreturn on sparc64

2016-04-26 Thread Mark Kettenis
Diff below simplifies setjmp(3) and longjmp(3) on sparc64 by not using sigreturn(2). This basically uses the logic from _setjmp(3) and _longjmp(3) to save and restore the state (but additionally saves and restores the signal mask). I believe this may make us lose the capability to longjmp() out

Re: anti-ROP mechanism in libc

2016-04-26 Thread Theo de Raadt
Here is a new version that does a more comprehensive test of the new libc.so before installing it, and uses install -S Index: etc/rc === RCS file: /cvs/src/etc/rc,v retrieving revision 1.474 diff -u -p -u -r1.474 rc --- etc/rc

Re: MP-safe TX for cnmac(4)

2016-04-26 Thread Visa Hankala
On Tue, Apr 26, 2016 at 05:29:43PM +1000, David Gwynne wrote: > > > On 25 Apr 2016, at 02:13, Visa Hankala wrote: > > > > This adds MP-safe TX for cnmac(4). OK? > > nearly. see inline. Here is a new try. ifq_serialize() is just what the code needs. Thanks! To simplify things

Re: openssl: ocsp: needs to pledge "dns" promise

2016-04-26 Thread Bob Beck
Yes, ok.. ocsp will need dns. -Bob On Tue, Apr 26, 2016 at 11:19:33AM +0200, Sebastien Marie wrote: > Hi, > > It has been reported to landry and me a pledge problem with the > following openssl command: > > $ /usr/bin/openssl ocsp -issuer bla.sub+ca -cert bla.crt -url >

openssl: ocsp: needs to pledge "dns" promise

2016-04-26 Thread Sebastien Marie
Hi, It has been reported to landry and me a pledge problem with the following openssl command: $ /usr/bin/openssl ocsp -issuer bla.sub+ca -cert bla.crt -url http://ocsp.startssl.com/sub/class2/server/ca -header Host ocsp.startssl.com -respout /tmp/ocsp.rv8rDSvf6f abort (core dumped) and

Re: MP-safe TX for cnmac(4)

2016-04-26 Thread David Gwynne
> On 25 Apr 2016, at 02:13, Visa Hankala wrote: > > This adds MP-safe TX for cnmac(4). OK? nearly. see inline. > > Index: arch/octeon/dev/if_cnmac.c > === > RCS file: src/sys/arch/octeon/dev/if_cnmac.c,v >

Re: failure to send a udp packet is not a fatal error

2016-04-26 Thread Claudio Jeker
On Tue, Apr 26, 2016 at 01:43:31PM +1000, David Gwynne wrote: > the tftp proxy on the firewall is dying these days. i managed to > track the failure down to an error sending the udp packet on. > > rather than err, i think it more appropriate to warn and let the > client retry in this situation. >