Re: [Patch] smtpd.conf - change 'priorly' to 'beforehand'

2015-08-12 Thread Edgar Pettijohn
On 08/12/15 21:21, Larry Hynes wrote: This is a minor quibble, and possibly a purely personal one, but 'priorly' is not really in common usage. Index: smtpd.conf.5 === RCS file: /cvs/src/usr.sbin/smtpd/smtpd.conf.5,v retrieving re

[Patch] smtpd.conf - change 'priorly' to 'beforehand'

2015-08-12 Thread Larry Hynes
This is a minor quibble, and possibly a purely personal one, but 'priorly' is not really in common usage. Index: smtpd.conf.5 === RCS file: /cvs/src/usr.sbin/smtpd/smtpd.conf.5,v retrieving revision 1.127 diff -u -p -r1.127 smtpd.con

Re: LibreSSL 2.2.2 release

2015-08-12 Thread Ted Unangst
Jan Engelhardt wrote: > > On Wednesday 2015-08-12 20:29, Mark Kettenis wrote: > > > >One possible reason to deviate from using the LibreSSL release version > >would be if we want to continue to be a drop-in replacement for > >OpenSSL. In that case continuing to adevrtise a reasonable OpenSSL > >v

Re: LibreSSL 2.2.2 release

2015-08-12 Thread Theo de Raadt
> On Wednesday 2015-08-12 20:29, Mark Kettenis wrote: > >One possible reason to deviate from using the LibreSSL release version > >would be if we want to continue to be a drop-in replacement for > >OpenSSL. In that case continuing to adevrtise a reasonable OpenSSL > >version number for openssl.pc,

Re: LibreSSL 2.2.2 release

2015-08-12 Thread Jan Engelhardt
On Wednesday 2015-08-12 20:29, Mark Kettenis wrote: > >One possible reason to deviate from using the LibreSSL release version >would be if we want to continue to be a drop-in replacement for >OpenSSL. In that case continuing to adevrtise a reasonable OpenSSL >version number for openssl.pc, libcry

Re: LibreSSL 2.2.2 release

2015-08-12 Thread Markus Lude
On Wed, Aug 12, 2015 at 08:29:09PM +0200, Mark Kettenis wrote: > > Date: Tue, 11 Aug 2015 09:15:43 -0600 > > From: Bob Beck > > > > I'm wondering out loud if these versions should follow the openbsd shlib > > major minor numbers. That is where we are careful about semantic > > versioning for api

Re: LibreSSL 2.2.2 release

2015-08-12 Thread Mark Kettenis
> Date: Tue, 11 Aug 2015 09:15:43 -0600 > From: Bob Beck > > I'm wondering out loud if these versions should follow the openbsd shlib > major minor numbers. That is where we are careful about semantic > versioning for api change/add/remove No. Shared library versions are tracking the ABI. What

Re: LibreSSL 2.2.2 release

2015-08-12 Thread Jan Engelhardt
On Tuesday 2015-08-11 03:39, Brent Cook wrote: > >> So I think all the .pc files in LibreSSL should simply use the LibreSSL >> version number (2.2.2) like the openssl.pc does. This does mean that >> checking >> for individual libraries in LibreSSL version 2.2.2 and older will probably >> busted,

Call for Testing: rtalloc(9) change

2015-08-12 Thread Martin Pieuchot
I'm currently working on the routing table interface to make is safe to use by multiple CPUs at the same time. The diff below is a big step in this direction and I'd really appreciate if people could test it with their usual network setup and report back. The goal of this diff is to "cache" the

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

2015-08-12 Thread Stuart Henderson
On 2015/08/12 17:10, Артур Истомин wrote: > On Mon, Aug 10, 2015 at 12:23:44PM +0100, Stuart Henderson wrote: > > On 2015/08/10 11:54, sam wrote: > > > I am also of the opinion that if somebody/a method can discover bugs, > > > they should report them. And if they can't, that method should be > > >

"fix" ld -Z on powerpc

2015-08-12 Thread Mark Kettenis
I spent some time today figuting out why the binutils update broke ld -Z on powerpc. Turns out to be a fairly thorny issue. The new binutils discard empty setions. As a result the .gotpad0 and .gotpad1 sections have disappeared. And a s a consequence the __got_start and __got_end symbols are no

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

2015-08-12 Thread Артур Истомин
On Mon, Aug 10, 2015 at 12:23:44PM +0100, Stuart Henderson wrote: > On 2015/08/10 11:54, sam wrote: > > I am also of the opinion that if somebody/a method can discover bugs, > > they should report them. And if they can't, that method should be > > disclosed to allow others to continue their work. >

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

2015-08-12 Thread Артур Истомин
On Sun, Aug 09, 2015 at 03:38:25PM -0600, Theo de Raadt wrote: > > Awful lot of noise wherein people tell someone else what they should > > need to do with their time and their code. > > > > > > To the best of my knowledge, we've cited and/or thanked Maxime in the > > commits fixing the issues he

Re: ikectl: ikeca.c cleanup: invalid 644 mode

2015-08-12 Thread Sebastien Marie
On Wed, Aug 12, 2015 at 09:17:35AM +0200, Sebastien Marie wrote: > > The previous mode requested was 1610 (644 in octal), but the value is > modified by umask value. I need base 8 revision... it was 1204. -- Sebastien Marie

Re: [PATCH] pkg-config compare() fails for libevent (at least)

2015-08-12 Thread Jasper Lievisse Adriaanse
On Tue, Aug 11, 2015 at 01:20:24PM -0500, attila wrote: > Hello tech@, > > On the 6 Aug snap I ran into this issue: > > $ pkg_info | grep libevent > libevent-2.0.22 event notification library > $ pkg-config --atleast-version=2.0.1 libevent && echo yes > Argument "22-stabl" isn't numer

ikectl: ikeca.c cleanup: invalid 644 mode

2015-08-12 Thread Sebastien Marie
Hi, The following patch corrects an invalid 644 mode to 0644. fcopy() set the mode using open(3). The previous mode requested was 1610 (644 in octal), but the value is modified by umask value. This file is the zip exported archive. -- Sebastien Marie Index: ikeca.c ==