Re: [Patch] smtpd.conf - change 'priorly' to 'beforehand'
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 revision 1.127 diff -u -p -r1.127 smtpd.conf.5 --- smtpd.conf.511 Aug 2015 21:57:24 -1.127 +++ smtpd.conf.513 Aug 2015 02:13:00 - @@ -635,7 +635,7 @@ able to establish an SMTP session. .Ic secure may be specified to provide both STARTTLS and SMTPS services. Host certificates may be used for these connections, -and must be priorly declared using the pki directive. +and must be declared beforehand using the pki directive. If .Ic pki is specified, I personally prefer the following: 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.conf.5 --- smtpd.conf.511 Aug 2015 21:57:24 -1.127 +++ smtpd.conf.513 Aug 2015 02:13:00 - @@ -635,7 +635,7 @@ able to establish an SMTP session. .Ic secure may be specified to provide both STARTTLS and SMTPS services. Host certificates may be used for these connections, -and must be priorly declared using the pki directive. +and must be declared previously using the pki directive. If .Ic pki is specified,
[Patch] smtpd.conf - change 'priorly' to 'beforehand'
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.conf.5 --- smtpd.conf.511 Aug 2015 21:57:24 - 1.127 +++ smtpd.conf.513 Aug 2015 02:13:00 - @@ -635,7 +635,7 @@ able to establish an SMTP session. .Ic secure may be specified to provide both STARTTLS and SMTPS services. Host certificates may be used for these connections, -and must be priorly declared using the pki directive. +and must be declared beforehand using the pki directive. If .Ic pki is specified,
Re: LibreSSL 2.2.2 release
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 > >version number for openssl.pc, libcrypto.pc and libssl.pc might make > >sense. Probably best to involve ports people in that decision though. > > The openssl API did not change very often. Many build recipes > request "pkgconfig(libcrypto) >= 0.9.7" or >= 1.0.0 > for example, which the libressl files satisfy thanks to their 2.x > numbering (well, 35:0:0 also satisfies it, numerically). This is quite errorprone, given the millions of possible config possibilities for the library. neither here nor there i suppose, just thought i'd mention it. you'd need a uint1024_t to accurately capture the API as a number.
Re: LibreSSL 2.2.2 release
> 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, libcrypto.pc and libssl.pc might make > >sense. Probably best to involve ports people in that decision though. > > The openssl API did not change very often. Many build recipes > request "pkgconfig(libcrypto) >= 0.9.7" or >= 1.0.0 > for example, which the libressl files satisfy thanks to their 2.x > numbering (well, 35:0:0 also satisfies it, numerically). I agree. Any API change would either be a removal (result: major crank of ABI), or an API addition/change (result: minor crank of ABI). On occasion we make API changes which don't meet those bars, but they are rare. And since we have these libraries "linked together", we try to be more cautious, and agressive cranking is already the norm It might work out.
Re: LibreSSL 2.2.2 release
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, libcrypto.pc and libssl.pc might make >sense. Probably best to involve ports people in that decision though. The openssl API did not change very often. Many build recipes request "pkgconfig(libcrypto) >= 0.9.7" or >= 1.0.0 for example, which the libressl files satisfy thanks to their 2.x numbering (well, 35:0:0 also satisfies it, numerically).
Re: LibreSSL 2.2.2 release
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 change/add/remove > > No. Shared library versions are tracking the ABI. What's wanted here > is something that tracks API, including bug fixes and such. > > People really expect something like a package version here such that > they can add a check into their autoconf script that the installed > version of a package is new enough to provide the functionality their > software needs. Doing something clever here is not going to help > people. If a configure script fails telling me to get libcrypto > version 34.2, how do I determine what version of LibreSSL I need to > install? > > 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, libcrypto.pc and libssl.pc might make > sense. Probably best to involve ports people in that decision though. Back in June I had the following log entries from stunnel: Jun 16 16:56:10 fuseki stunnel: LOG5[ui]: Compiled with LibreSSL 2.1 Jun 16 16:56:10 fuseki stunnel: LOG5[ui]: Running with LibreSSL 2.2 I did build stunnel on one host and installed it on my main machine (see above), were I use it from time to time. Both hosts had the same version of libssl/libcrypto installed, but the LibreSSL version was newer on the main host. I usually update snapshots more often there, on the build mostly if library versions got bumped. Regards, Markus
Re: LibreSSL 2.2.2 release
> 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's wanted here is something that tracks API, including bug fixes and such. People really expect something like a package version here such that they can add a check into their autoconf script that the installed version of a package is new enough to provide the functionality their software needs. Doing something clever here is not going to help people. If a configure script fails telling me to get libcrypto version 34.2, how do I determine what version of LibreSSL I need to install? 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, libcrypto.pc and libssl.pc might make sense. Probably best to involve ports people in that decision though.
Re: LibreSSL 2.2.2 release
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, but such is life. Not sure how the colon-separated version strings >> interact with --atleast-version. Might be worth checking that out. > >The main exception I found was that ffmpeg encoded ABI rather than API >in its .pc files too, but your explanations make sense to me. Well, at least ffmpeg's liba* use the MMM [major.minor.micro] version, and thus '.' as a separator, rather than trying to stuff the libtool CRA [current:release:age] spec into the .pc file.
Call for Testing: rtalloc(9) change
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 route corresponding to "your"
next hop as early as possible. Let's assume you're using a common
dhcp-based network:
mpi@goiaba $ netstat -rnf inet|egrep "(default|Dest)"
DestinationGatewayFlags Refs Use Mtu Prio Iface
default192.168.0.1UGS5 508 - 8 em0
Here my default route points to a gateway (G) whose address is
192.168.0.1. In such setup your computer generally sends most of the
packets to the internet through this gateway. But to do that it needs
more informations:
mpi@goiaba $ netstat -rnf inet|egrep "(192.168.0.1.*L|Dest)"
DestinationGatewayFlags Refs Use Mtu Prio Iface
192.168.0.1bc:05:43:bd:3e:29 UHLc 1 149 - 8 em0
Yes this is another route. This one contains link-layer informations
(L) and has been cloned (c). This route is what I described before as
"your" next hop. In this case, "your" is a shortcut for "the next hop
of your default route" but all of this is valid for any route pointing
to a gateway (G).
In order to send packets via my default route, the kernel needs to know
the link-layer address corresponding to the IP address of the gateway.
This is called "Address Resolution" in network jargon. In OpenBSD,
resolved addresses appear in the routing table with a link-layer address
in the "Gateway" field, as shown previously.
This resolution is done in the kernel by calling rtalloc(9) with the
RT_RESOLVE flag for the wanted destination, in my case 192.168.0.1.
Once the resolution is complete, a corresponding entry appears in the
routing table and there's no need to redo it for a certain period of
time. That is what I meant with "cache".
Currently this resolution is done "late" in the journey of a packet and
that's fine since it is not done often. Late means that it is done when
the packet reaches a L2 output function, nd6_output() or arpresolve().
The problem is that having a proper reference count on route entries in
these functions is really complicated because you can end up using 3
different routes. So this diff starts the resolution early: as soon as
a gateway route is returned by rtalloc(9).
It also makes sense to do the resolution as soon as possible since we
need the link-layer address to send the packet.
One important point: gateway routes (rt_gwroute) are only returned to
the stack in L2 functions and when that happens, their reference
counter is not incremented. That's why the reference count for such
routes is almost always 1. They are the simplest example of working
route caching in our kernel*. That means that when you purge your
cloned route, rt_gwroute will still be valid but marked as RTP_DOWN
until a new resolution is started.
This diff changes rt_checkgate() to only do sanity checks (finally!).
Do not hesitate to ask questions if something is not clear, I believe
it's important that more people understand this.
Note that this diff includes other bits to be committed separately:
- Deprecate the use of RTF_XRESOLVE in rtalloc(9)
- Remove PF_KEY-specific code & comments now that SPD lookups no
longer use rtalloc(9).
- Make rtfree(9) accept NULL
* That's why I'm slowly killing "struct route" & friends to use the
simplest route caching mechanism everywhere.
Index: net/route.c
===
RCS file: /cvs/src/sys/net/route.c,v
retrieving revision 1.217
diff -u -p -r1.217 route.c
--- net/route.c 18 Jul 2015 15:51:16 - 1.217
+++ net/route.c 12 Aug 2015 13:54:56 -
@@ -153,6 +153,7 @@ int rtable_alloc(void ***, u_int);
intrtflushclone1(struct rtentry *, void *, u_int);
void rtflushclone(unsigned int, struct rtentry *);
intrt_if_remove_rtdelete(struct rtentry *, void *, u_int);
+struct rtentry *rt_match(struct sockaddr *, int, unsigned int);
struct ifaddr *ifa_ifwithroute(int, struct sockaddr *, struct sockaddr *,
u_int);
@@ -297,17 +298,31 @@ rtable_exists(u_int id) /* verify table
return (1);
}
+/*
+ * Do the actual lookup for rtalloc(9), do not use directly!
+ *
+ * Return the best matching entry for the destination ``dst''.
+ *
+ * "RT_RESOLVE" means that a corresponding L2 entry should
+ * be added to the routing table and resolved (via ARP or
+ * NDP), if it does not exist.
+ *
+ * "RT_REPORT" indicates that a message should be sent to
+ * userland if no matching route has been found or if an
+ * error occured while adding a L2 entry.
+ */
struct rtentry *
-rtalloc(struct sockaddr *dst, int flags, unsigned int tableid)
+rt_match(struct sockaddr *dst, int flags, unsigned int tableid)
{
s
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
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 > > > disclosed to allow others to continue their work. > > > > So you think others "should" do work for you, right? Whether that work is in > > discovering and reporting bugs, or in preparing their code for release so > > you > > can use it (maybe tidying, writing docs, fielding bug reports, > > etc.etc.etc.)? > > This is how the capitalist system has always worked. Exploiting the weakness, > folly > or fanaticism. OpenBSD is the OS created mostly by a group of people with a > strong > belief that capitalism and/or democracy is right things for society. What is > surprising? Gift economy doesn't seem like capitalism to me. Anyway this is off-topic for tech@. Please redirect any replies to misc, or /dev/null.
"fix" ld -Z on powerpc
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 now "absolute" symbols as the section they referenced to is no longer there. For example, an older libc has: 845: 000eeb68 0 NOTYPE GLOBAL DEFAULT 17 __got_start whereas -current has: 810: 000eeb58 0 NOTYPE GLOBAL DEFAULT ABS __got_start On powerpc, crt0.o has weak references to __got_start and __got_end. When building a binary with ld -Z, these are resolved to the absolute symbols from libc. At runtime we then use these values, relocated as if they were addresses within the binary itself, to change protections and flush the instruction cache. This is very likely to result in a segmentation fault. There is probably a linker bug here, as it doesn't make any sense for the linker to pick the address of these symbols from libc and stick it into the binary. But I'm not sure about this. And it isn't all that obvious what the fix would be. Is the bug that the symbols end up as absolute? Or is the problem that it sibsequently resolves these to the values from libc.so? It does point out a fundamental weakness about the approach we've taken with the __plt_start/end and __got_start/end synbols. They work fine of you use something like dlsym(3) to lookup the value for a specific object, but if you rely on the default symbol resolution, it isn't clear if you get the right version. Therefore I think that the powerpc crt0.o code shouldn't be doing what it is doing. The diff below removes that code. This diff has a downside though. The GOT on -static -nopie binaries will no longer be read-only. I don't think that is a big loss, as -static -pie binaries are the default now and those do get a read-only GOT. If we think a read-only GOT for -static binaries is still important, there are a few other potential options to achive this that don't need to rely on __got_start/end. Index: powerpc/md_init.h === RCS file: /cvs/src/lib/csu/powerpc/md_init.h,v retrieving revision 1.3 diff -u -p -r1.3 md_init.h --- powerpc/md_init.h 26 Dec 2014 13:52:01 - 1.3 +++ powerpc/md_init.h 12 Aug 2015 13:08:28 - @@ -64,88 +64,20 @@ #include/* for SYS_mprotect */ #define STR(x) __STRING(x) + #defineMD_CRT0_START \ __asm( \ " .text \n" \ " .section\".text\" \n" \ " .align 2\n" \ -" .size __got_start, 0 \n" \ -" .type __got_start, @object\n" \ -" .size __got_end, 0\n" \ -" .type __got_end, @object \n" \ -" .weak __got_start \n" \ -" .weak __got_end \n" \ " .globl _start \n" \ " .type _start, @function \n" \ " .globl __start \n" \ " .type __start, @function \n" \ "_start: \n" \ "__start: \n" \ -" # move argument registers to saved registers for startup flush \n" \ -" # ...except r6 (auxv) as ___start() doesn't need it \n" \ -" mr %r25, %r3\n" \ -" mr %r24, %r4\n" \ -" mr %r23, %r5\n" \ -" mr %r22, %r7\n" \ -" mflr%r27/* save off old link register */\n" \ -" bl 1f \n" \ -" # this instruction never gets executed but can be used \n" \ -" # to find the virtual address where the page is loaded. \n" \ -" bl _GLOBAL_OFFSET_TABLE_@local-4\n" \ -"1:\n" \ -" mflr%r6 # this stores where we are (+4) \n" \ -" lwz %r18, 0(%r6)# load the instruction at offset_sym\n" \ -" # it contains an offset to the
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
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. > > So you think others "should" do work for you, right? Whether that work is in > discovering and reporting bugs, or in preparing their code for release so you > can use it (maybe tidying, writing docs, fielding bug reports, > etc.etc.etc.)? This is how the capitalist system has always worked. Exploiting the weakness, folly or fanaticism. OpenBSD is the OS created mostly by a group of people with a strong belief that capitalism and/or democracy is right things for society. What is surprising?
Re: Brainy: User-Triggerable Kernel Memory Leak in execve()
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's found, and we're glad to continue to > > receive his reports, whether or not they include patches. My > > apologies if we've failed to do so. > > Thanks for saying that Philip. > > I would like to point out the noise is coming from *users* -- not from > actual developers in the project. .so let's get rid of the users! I don't understand the purpose of your observations.
Re: ikectl: ikeca.c cleanup: invalid 644 mode
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)
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 numeric in numeric eq (==) at /usr/bin/pkg-config
> line 662.
> yes
>
> So it works but spits out that error. The issue is that the libevent
> port reports its version as 2.0.22-stable, which does not follow the
> convention used by the compare() sub in pkg-config. The attached
> patch gets rid of the error albeit in a very pointilistic way; perhaps
> a more general solution is desired, but I'm not sure what the best
> approach is, especially given that there is something called
> pkg-config available pretty much everywhere but based on very
> different implementations...
>
> It doesn't appear as though my patch introduces any regressions,
> although I'm still sussing out how the regression tests work so I'm
> not sure if I'm doing anything wrong... it appears that five of
> pkg-config's regression tests fail regardless of my patch:
>
> FAIL usr.bin/pkg-config/static-cflags2
> FAIL usr.bin/pkg-config/static-libs2
> FAIL usr.bin/pkg-config/static-libs3
> FAIL usr.bin/pkg-config/static-libs4
> FAIL usr.bin/pkg-config/missing-req-2
>
> In all cases it looks like the difference is ordering, except for the
> last where two errors are produced but only one is expected. I'll
> work on a patch to fix these failures next.
That's indeed the case and patches to fix that are welcome.
> Feedback, comments most welcome.
Could you please add regress tests for this issue you're solving too?
> Pax, -A
> --
> http://trac.haqistan.net | att...@stalphonsos.com | 0xE6CC1EDB
>
> Index: pkg-config
> ===
> RCS file: /cvs/src/usr.bin/pkg-config/pkg-config,v
> retrieving revision 1.85
> diff -u -p -r1.85 pkg-config
> --- pkg-config17 Nov 2014 22:16:23 - 1.85
> +++ pkg-config11 Aug 2015 17:53:24 -
> @@ -625,16 +625,16 @@ sub compare
> # is there a valid non-numeric suffix to deal with later?
> # accepted are (in order): a(lpha) < b(eta) < rc < ' '.
> # suffix[0] is the 'alpha' part, suffix[1] is the '1' part in 'alpha1'.
> - if ($a =~ s/(rc|beta|b|alpha|a)(\d+)$//) {
> - say_debug("valid suffix $1$2 found in $a$1$2.");
> - $suffix_a[0] = $1;
> - $suffix_a[1] = $2;
> + if ($a =~ s/(|-)(stable|rc|beta|b|alpha|a)(|\d+)$//) {
> + say_debug("valid suffix $2$3 found in $a$2$3.");
> + $suffix_a[0] = $2;
> + $suffix_a[1] = $3;
> }
>
> - if ($b =~ s/(rc|beta|b|alpha|a)(\d+)$//) {
> - say_debug("valid suffix $1$2 found in $b$1$2.");
> - $suffix_b[0] = $1;
> - $suffix_b[1] = $2;
> + if ($b =~ s/(|-)(stable|rc|beta|b|alpha|a)(|\d+)$//) {
> + say_debug("valid suffix $2$3 found in $b$2$3.");
> + $suffix_b[0] = $2;
> + $suffix_b[1] = $3;
> }
>
> # The above are standard suffixes; deal with single alphabetical
--
jasper
ikectl: ikeca.c cleanup: invalid 644 mode
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 === RCS file: /cvs/src/usr.sbin/ikectl/ikeca.c,v retrieving revision 1.30 diff -u -p -r1.30 ikeca.c --- ikeca.c 16 Jan 2015 06:40:17 - 1.30 +++ ikeca.c 12 Aug 2015 07:09:38 - @@ -683,7 +683,7 @@ ca_export(struct ca *ca, char *keyname, de->d_name); snprintf(dst, sizeof(dst), "%s/export/%s", p, de->d_name); - fcopy(src, dst, 644); + fcopy(src, dst, 0644); } closedir(dexp); }
