Re: ld patch that greatly speeds up linking large programs with debug symbols

On 27/04/16(Wed) 21:12, Aaron Miller wrote: > Hi All, > > I was experiencing ~8 minute linking times for a large C++ application > I have been working on when running -current on amd64. It turns out > that the decade-old version of ld in the OpenBSD source tree has a bug > that causes quadratic co

tcpdump: print router advertisement preference

As defined by https://tools.ietf.org/html/rfc4191, prompted by http://marc.info/?l=openbsd-misc&m=146239072929264&w=2 "pref" is inspired by upstream tcpdump format. Thoughts / ok? Index: print-icmp6.c === RCS file: /cvs/src/usr.sbi

Re: document NOLOCK in syscalls.master

On 02/05/16(Mon) 12:34, Michal Mazurek wrote: > On 10:30:02, 7.04.16, Martin Natano wrote: > > > * mention INDIR and NOLOCK in 'Fields'. > > > > How about something like "one of the types listed below, or one of the > > compatibility options defined in syscalls.conf" instead? > > That's a better

Re: remove MPSAFE from makesyscalls.sh

On 02/05/16(Mon) 12:07, Michal Mazurek wrote: > On 10:22:58, 7.04.16, Martin Natano wrote: > > On Wed, Apr 06, 2016 at 03:42:20PM +0200, Michal Mazurek wrote: > > > MPSAFE is never used, and doesn't look like it's even supported (no > > > matching SY_MPSAFE anywhere). > > > > SY_MPSAFE seems to b

ip_forward mpath fix

Now that ip_forward() is reusing the route fetched by in_ouraddr() we want to make sure we're fetching a possible RTF_MPATH route and not simply picking the first one every time. This restore the behavior of r1.274 when using mpath entries for forwarding, ok? Index: netinet/ip_input.c ===

ip6_input: Double check for mapped v4 addresses

This look like a bad merge from 2000s. This check is present twice in ip6_input(), so let's remove the late one, ok? Index: netinet6/ip6_input.c === RCS file: /cvs/src/sys/netinet6/ip6_input.c,v retrieving revision 1.158 diff -u -p -

Re: enable shadow only pwd

> On 2016/05/04 17:48, Ted Unangst wrote: > > i think it's time. otherwise we'll never find the bugs. > > I don't think it's time since afaicr nobody other than me has fixed > anything for this in ports yet. They're not hard to find, try screen > lockers for starters. Because this is using a diffe

Re: ip6_input: Double check for mapped v4 addresses

On 2016/05/06 15:05, Martin Pieuchot wrote: > This look like a bad merge from 2000s. This check is present twice in > ip6_input(), so let's remove the late one, ok? > > Index: netinet6/ip6_input.c > === > RCS file: /cvs/src/sys/netin

Re: enable shadow only pwd

> Anyways, it would be really nice if we can get the issues resolved > before end of June, because 6.0 should have this. It is a valuable > security improvement. Amen to that! -j.

Re: enable shadow only pwd

On 2016/05/06 16:44, Jyri Hovila [Turvamies.fi] wrote: > > > Anyways, it would be really nice if we can get the issues resolved > > before end of June, because 6.0 should have this. It is a valuable > > security improvement. > > Amen to that! > > -j. Feel free to investigate the ports I mentio

Re: enable shadow only pwd

> On 2016/05/06 16:44, Jyri Hovila [Turvamies.fi] wrote: > > > > > Anyways, it would be really nice if we can get the issues resolved > > > before end of June, because 6.0 should have this. It is a valuable > > > security improvement. > > > > Amen to that! > > > > -j. > > Feel free to investig

Re: changelist(5) [and mtree(8)] entry for rebound(8) config file

On Fri, May 06, 2016 at 06:37:44AM BST, Raf Czlonka wrote: > Hi all, > > Thought rebound(8) config file could be added to changelist(5). > > Regards, > > Raf > > Index: etc/changelist > === > RCS file: /cvs/src/etc/changelist,v > r

Re: enable shadow only pwd

>> Feel free to investigate the ports I mentioned then. That's exactly what I was planning to do already. Just didn't want to make any promises - I've got my hands so full of other OpenBSD related projects that the daily 24 hour limit is getting really troublesome. =P >> Diffs to >> ports@ ple

Re: httpd: patch for portability asprintf use

On Wed, Apr 27, 2016 at 2:41 PM, Hiltjo Posthuma wrote: > Hi, > > The following patch for httpd makes sure the value of the asprintf buffer is > zeroed on error and not relied upon, so at the 'done' label free(body) and > free(hstsheader) is safe. > > from asprintf(3): > > "The asprintf()

Re: httpd: patch for portability asprintf use

> On 06.05.2016, at 17:56, Hiltjo Posthuma wrote: > > On Wed, Apr 27, 2016 at 2:41 PM, Hiltjo Posthuma > wrote: >> Hi, >> >> The following patch for httpd makes sure the value of the asprintf buffer is >> zeroed on error and not relied upon, so at the 'done' labe

Re: httpd: patch for portability asprintf use

> If OpenBSD's behavior of asprintf is non-standard and everyone else is > doing it differently, we would probably have to apply the patch. But this > would also affect many other places in the tree were we rely on our > asprintf semantics. Actually, we have fixed all usage cases in our tree to be

Re: httpd: patch for portability asprintf use

On Fri, 06 May 2016 17:56:16 +0200, Hiltjo Posthuma wrote: > Any OK's for this? > > Please also see my mail with subject "httpd: fix/style: unbalanced > va_start and va_end macros" (don't want to spam the mailinglist :)). I didn't change those before because body and hstsheader are initialized t

Re: httpd: patch for portability asprintf use

> On 06.05.2016, at 18:36, Theo de Raadt wrote: > >> If OpenBSD's behavior of asprintf is non-standard and everyone else is >> doing it differently, we would probably have to apply the patch. But this >> would also affect many other places in the tree were we rely on our >> asprintf semantics. >

Re: httpd: patch for portability asprintf use

On Fri, May 6, 2016 at 6:47 PM, Todd C. Miller wrote: > On Fri, 06 May 2016 17:56:16 +0200, Hiltjo Posthuma wrote: > >> Any OK's for this? >> >> Please also see my mail with subject "httpd: fix/style: unbalanced >> va_start and va_end macros" (don't want to spam the mailinglist :)). > > I didn't c

Re: xclock patch

On Tue, May 03, 2016 at 11:40:31AM -0500, Edgar Pettijohn wrote: > I'll look at it this evening. > Ping... > Sent from my iPhone > > > On May 3, 2016, at 9:40 AM, Sebastien Marie wrote: > > > >> On Mon, May 02, 2016 at 05:39:36PM -0500, Edgar Pettijohn wrote: > >> I saw this in /var/log/messag

Re: ip6_input: Double check for mapped v4 addresses

Stuart Henderson writes: > On 2016/05/06 15:05, Martin Pieuchot wrote: >> This look like a bad merge from 2000s. This check is present twice in >> ip6_input(), so let's remove the late one, ok? >> >> Index: netinet6/ip6_input.c >>

Re: dhclient: use /dev/bpf

On Thu, May 05, 2016 at 09:30:43PM +0100, Stuart Henderson wrote: > On 2016/05/02 09:34, Martin Natano wrote: > > Diff below simplifies the device open path and removes an explanation > > about bpf device nodes from the manpage. > > There's a problem with this. If someone is doing an "untar sets"

Re: dhclient: use /dev/bpf

> > There's a problem with this. If someone is doing an "untar sets" > > upgrade (which is not _supported_ but is pretty much necessary in > > some situations) and relies on dhclient for network to get back > > in to the system, they lose. > > > > Since they won't have a new MAKEDEV at the right t

Re: dhclient: use /dev/bpf

On 2016/05/06 19:35, Martin Natano wrote: > On Thu, May 05, 2016 at 09:30:43PM +0100, Stuart Henderson wrote: > > On 2016/05/02 09:34, Martin Natano wrote: > > > Diff below simplifies the device open path and removes an explanation > > > about bpf device nodes from the manpage. > > > > There's a p

Re: xclock patch

Sent from my iPhone > On May 6, 2016, at 12:13 PM, Matthieu Herrb wrote: > >> On Tue, May 03, 2016 at 11:40:31AM -0500, Edgar Pettijohn wrote: >> I'll look at it this evening. > > Ping... > Sorry. I tried to get it to reproduce and couldn't. Looked through the code and couldn't find anythi

Re: tcpdump: print router advertisement preference

j...@wxcvbn.org (Jeremie Courreges-Anglas) writes: > As defined by https://tools.ietf.org/html/rfc4191, prompted by > http://marc.info/?l=openbsd-misc&m=146239072929264&w=2 > > "pref" is inspired by upstream tcpdump format. > > Thoughts / ok? Committed, thanks for the reviews. What about the sam

Re: httpd: patch for portability asprintf use

> Theo de Raadt wrote: > > > If OpenBSD's behavior of asprintf is non-standard and everyone else is > > > doing it differently, we would probably have to apply the patch. But this > > > would also affect many other places in the tree were we rely on our > > > asprintf semantics. > > > > Actually,

Re: httpd: patch for portability asprintf use

Theo de Raadt wrote: > > If OpenBSD's behavior of asprintf is non-standard and everyone else is > > doing it differently, we would probably have to apply the patch. But this > > would also affect many other places in the tree were we rely on our > > asprintf semantics. > > Actually, we have fixed

current trunk is not accepting tun / link0

Claudio Jeker : 10 years ago ... trunk(4) works only over ethernet devices (more precisely IEEE802 based interfaces). This includes wireless devices but neither of gif, gre or pppoe. tun(4) in layer 2 mode works while a "normal" tun(4) will not. Looks like it s broken on layer 2 tun. # uname -a O

Re: current trunk is not accepting tun / link0

On 2016/05/06 15:19, sven falempin wrote: > Claudio Jeker : 10 years ago > ... > trunk(4) works only over ethernet devices (more precisely IEEE802 based > interfaces). This includes wireless devices but neither of gif, gre or > pppoe. tun(4) in layer 2 mode works while a "normal" tun(4) will not. >

rtadvd.conf.5: document route preference flags

Also motivated by http://marc.info/?l=openbsd-misc&m=146239072929264&w=2 RFC4191 defines route preference flags not only in Route Information options, but also in Router Advertisement messages. Let's try to make this clear. Also, try to document the possible values in a slightly more useful way

Re: httpd: patch for portability asprintf use

On Fri, 06 May 2016 18:53:28 +0200, Hiltjo Posthuma wrote: > It is not an issue, but I thought it was not intended because the > asprintf(3) documentation said: > > "The value of ret in this situation is > implementation-dependent (on OpenBSD, ret will be set to the null >

Re: [ksh] [patch] Make "$@" POSIX-compliant with empty IFS

Op 24-03-16 om 04:04 schreef Theo Buehler: On Fri, Mar 04, 2016 at 11:29:38AM +0100, Dmitrij D. Czarkoff wrote: Martijn Dekker said: So this patch makes quoted "$@" act according to the standard even when IFS is empty. Quoted "$*" is unchanged. For the unspecified (not standardised) cases of un

Re: dhclient: use /dev/bpf

On May 6, 2016 8:17:50 PM GMT+02:00, Stuart Henderson wrote: >On 2016/05/06 19:35, Martin Natano wrote: >> On Thu, May 05, 2016 at 09:30:43PM +0100, Stuart Henderson wrote: >> > On 2016/05/02 09:34, Martin Natano wrote: >> > > Diff below simplifies the device open path and removes an >explanati

Re: current trunk is not accepting tun / link0

On Fri, May 6, 2016 at 3:27 PM, Stuart Henderson wrote: > On 2016/05/06 15:19, sven falempin wrote: > > Claudio Jeker : 10 years ago > > ... > > trunk(4) works only over ethernet devices (more precisely IEEE802 based > > interfaces). This includes wireless devices but neither of gif, gre or > > p

Re: current trunk is not accepting tun / link0

On Fri, May 6, 2016 at 3:27 PM, Stuart Henderson wrote: > On 2016/05/06 15:19, sven falempin wrote: > > Claudio Jeker : 10 years ago > > ... > > trunk(4) works only over ethernet devices (more precisely IEEE802 based > > interfaces). This includes wireless devices but neither of gif, gre or > > p

Re: xclock patch

On Fri, May 06, 2016 at 01:29:11PM -0500, Edgar Pettijohn wrote: > > On May 6, 2016, at 12:13 PM, Matthieu Herrb wrote: > > > >> On Tue, May 03, 2016 at 11:40:31AM -0500, Edgar Pettijohn wrote: > >> I'll look at it this evening. > > > > Ping... > > > > Sorry. I tried to get it to reproduce and