Re: Move ancient ksh bug from README to man page

On Sun, Dec 06, 2015 at 12:00:36AM -0500, Michael McConville wrote: > Thoughts? ok? > It makes sense to me to document this in the manual, and not in a README file that no-one reads, so ok from me, but please wait for jmc@'s input. Note that this bug used to be documented in the manual, but it

Re: libgtop2: Use getifaddrs(3) instead of KVM

On Sat, Dec 05, 2015 at 05:05:07PM +0100, Martin Pieuchot wrote: > Here's a rewrite of glibtop_get_netload_p(). I tested it with custom > code because I could not trigger this code path with our ports. > > This unbreaks devel/libgtop2 after the recent commit. > > I believe this should go

Re: [patch v3] cwm: Preserve stacking order during cycling

Even when cycling in group, all visible windows should be restacked. Patch version 3. Vadik. Quoth Vadim Vygonets on Sun, Nov 22, 2015: > I accidentally killed restacking on group_show(). Sorry about > that. Here's version 2 of the patch. > > Quoth Vadim Vygonets on Sat, Nov 21, 2015: > >

[patch] cwm: Simplify client_toggle_*()

Use XOR for toggling bits. Mostly cosmetic. Vadik. -- When in doubt, be yourself. And if that fails, su root. Index: client.c === RCS file: /cvs/xenocara/app/cwm/client.c,v retrieving revision 1.214 diff -u -r1.214 client.c ---

[PATCH] vmm(4) manpage missed the vmctl rename

Update manpage reference from vmmctl(8) to vmctl(8) Tim. Index: vmm.4 === RCS file: /cvs/src/share/man/man4/man4.amd64/vmm.4,v retrieving revision 1.3 diff -u -p -r1.3 vmm.4 --- vmm.4 13 Nov 2015 07:55:37 - 1.3 +++

Re: ugenctl for attaching USB devices to ugen instead of their specific driver

On 2015/12/06 06:02, Mickael Torres wrote: > Hello, > > This is a kernel patch plus a utility called ugenctl I use to allow > selected USB devices to attach as ugen(4) instead of their more specific > driver. My use case is a Microchip "PICkit 2 Microcontroller Programmer" > that attaches as

Re: Move ancient ksh bug from README to man page

Jérémie Courrèges-Anglas wrote: > Jason McIntyre writes: > > > On Sun, Dec 06, 2015 at 04:03:16AM -0500, Ted Unangst wrote: > >> Jason McIntyre wrote: > >> > the trouble is i think there are some known bugs with ksh. i > >> > think it probably would be better to keep a note

Re: taskctx and revisiting if_start serialisation

On 6.12.2015. 5:00, David Gwynne wrote: > the current code for serialising if_start calls for mpsafe nics does what it > says. > > however, kettenis realised it doesnt help us much when we're trying > to coordinate between the start and txeof side of a driver when > setting or clearing oactive.

Re: taskctx and revisiting if_start serialisation

On 6.12.2015. 15:56, Hrvoje Popovski wrote: > On 6.12.2015. 5:00, David Gwynne wrote: >> the current code for serialising if_start calls for mpsafe nics does what it >> says. >> >> however, kettenis realised it doesnt help us much when we're trying >> to coordinate between the start and txeof

[patch] cwm: Fix moving of clients to group 0

Hi, I have a shy client (stalonetray) that hides at start-up. What normally happens with new clients assigned to group 0 is this: - client appears - client is initialized by cwm - cwm decides it should be in group 0 - group_assign() sends it a _NET_WM_DESKTOP property change request So far

Re: [PATCH] vmm(4) manpage missed the vmctl rename

On Sun, Dec 06, 2015 at 11:32:24AM -0500, trondd wrote: > Update manpage reference from vmmctl(8) to vmctl(8) > > Tim. > > > Index: vmm.4 > === > RCS file: /cvs/src/share/man/man4/man4.amd64/vmm.4,v > retrieving revision 1.3 > diff

Re: OpenBSD errata, Dec 3, 2015

As many people have already noticed and mentioned, s/-13/-31/g in the CVE numbers assigned as part of the great CVE game. No, I can't "change the announcement" as I can't go edit the internet to change public mailing list archives.. The CVE numbers are correct in the patches and everywhere else

Re: vmm update

On Thu, Nov 26, 2015 at 06:31:34PM +0100, Norman Golisz wrote: > On Thu Nov 26 2015 15:11, Karel Gardas wrote: > > Not sure, but on misc you can search for "vmm uvm_fault in vmware > > player/workstation when Intel VT/AMD-v not enabled" thread from which > > it looks like vmm requires

nc -r: remove modulo bias and better shuffling

The current implementation of the selection of a random sequence of ports in nc -r suffers from modulo bias and a biased shuffling procedure. Use arc4random_uniform() and the Fisher-Yates shuffle instead. Index: usr.bin/nc/netcat.c

Re: Move ancient ksh bug from README to man page

Michael McConville writes: > Jeremie Courreges-Anglas wrote: >> Jason McIntyre writes: >> >> > On Sun, Dec 06, 2015 at 04:03:16AM -0500, Ted Unangst wrote: >> >> Jason McIntyre wrote: >> >> > the trouble is i think there are some known bugs with ksh. i >>

Re: Move ancient ksh bug from README to man page

Ted Unangst wrote: > Jason McIntyre wrote: > > the trouble is i think there are some known bugs with ksh. i think > > it probably would be better to keep a note of them in a separate > > file, as is done now. i'm not really sure if we want to try and > > clutter the page with every bug we find. >

Re: OpenBSD errata, Dec 3, 2015

On Sun, Dec 06, 2015 at 06:04:18AM -0500, Ted Unangst wrote: > Bob Beck wrote: > > Fixes have been commited for both CVE-2015-1394 and CVE-2015-1395. > > CVE-2015-1394 warrants an errata. > > > The errata for CVE-2015-1394 is available for OpenBSD 5.8 and OpenBSD > > 5.7 from the master site as

Re: Move ancient ksh bug from README to man page

On Sun, Dec 06, 2015 at 09:17:21AM +0100, Theo Buehler wrote: > On Sun, Dec 06, 2015 at 12:00:36AM -0500, Michael McConville wrote: > > Thoughts? ok? > > > > It makes sense to me to document this in the manual, and not in a README > file that no-one reads, so ok from me, but please wait for

Re: OpenBSD errata, Dec 3, 2015

Bob Beck wrote: > Fixes have been commited for both CVE-2015-1394 and CVE-2015-1395. > CVE-2015-1394 warrants an errata. > The errata for CVE-2015-1394 is available for OpenBSD 5.8 and OpenBSD > 5.7 from the master site as well as the mirrors: To clear up any confusion, the CVE numbers should be

Re: [UPDATE] freetype-2.6.2

David Coppa: > Here's the update to freetype-2.6.2. > > It shouldn't cause any fallout, but who knows with freetype... So > probably a ports bulk build can be useful. I ran a bulk build with this on amd64. Unfortunately, a few hundred packages couldn't be built due to unrelated fallout from

Re: mpsafe re(4)

On Sat, Dec 05, 2015 at 06:11:51PM +0100, Jonathan Matthew wrote: > The main interesting bit here is the txeof and start loops, which previously > operated based on the prod/cons indices and the contents of the tx queue, > but now just uses the indices as that's the only way to get a consistent

Re: taskctx and revisiting if_start serialisation

Hi, I can't comment on the code itself, but there's > The > taskq > API provides a mechanism to defer work to a process context. > .Pp > +The > +taskctx > +API provides a mechanism to serialise work in a single context. > +A taskctx guarantees that all work submitted to it will not run >

ugenctl for attaching USB devices to ugen instead of their specific driver

Hello, This is a kernel patch plus a utility called ugenctl I use to allow selected USB devices to attach as ugen(4) instead of their more specific driver. My use case is a Microchip "PICkit 2 Microcontroller Programmer" that attaches as uhid(4), but the command line utility pk2cmd wants a

Re: [patch] cwm: Preserve stacking order during cycling

On Wed, Nov 25, 2015 at 05:44:28PM +0100, Vadim Vygonets wrote: > Quoth Артур Истомин on Tue, Nov 24, 2015: > > Yes, exactly. Example: https://imgur.com/rUPxpTF There is mplayer behind > > firefox. In the beginning everything is working properly. Alt+Tab work for > > all three windows. Some time

Re: malloc canaries and validation

> It would also be interesting to try out a more aggressive form of > freeunmap for 64-bit where the allocations are purged with MADV_FREE > and then the virtual memory is kept out of circulation with a similar > FIFO queue approach. Could potentially do it by default when malloc > hints are

Re: nc -r: remove modulo bias and better shuffling

> Since I don't think your name is Steve, you're going to touch that, > please get rid of the PORT_MAX_LEN/calloc/snprintf dance and just use > asprintf() instead so I don't need more therapy reading it.. (look at > my eye twitching...) The part I find most incredible in the code is...

Re: malloc canaries and validation

It would be great to land this simple initial implementation and move from there. I have ideas on how to make these features better but I'm wary of doing a lot of work out-of-tree. If it lands in some form, that would go a long way to encouraging further work on it. I basically just don't want to

Re: malloc canaries and validation

On Sun, 2015-12-06 at 17:10 -0700, Theo de Raadt wrote: > Kept out of circulation?  It sounds like it would be incredibly > expensive data-structure wise for the kernel to even attempt such a > gaurantee.. I was just expecting it to be a FIFO ring buffer. It would have a limit on the number of

Re: nc -r: remove modulo bias and better shuffling

Since I don't think your name is Steve, you're going to touch that, please get rid of the PORT_MAX_LEN/calloc/snprintf dance and just use asprintf() instead so I don't need more therapy reading it.. (look at my eye twitching...) On Sun, Dec 6, 2015 at 2:01 PM, Theo Buehler

Re: malloc canaries and validation

It would also be interesting to try out a more aggressive form of freeunmap for 64-bit where the allocations are purged with MADV_FREE and then the virtual memory is kept out of circulation with a similar FIFO queue approach. Could potentially do it by default when malloc hints are enabled, so it

Re: ugenctl for attaching USB devices to ugen instead of their specific driver

On 2015-12-06 20:10, Ian Darwin wrote: On 2015-12-06 12:23 PM, Stuart Henderson wrote: On 2015/12/06 06:02, Mickael Torres wrote: Hello, This is a kernel patch plus a utility called ugenctl I use to allow selected USB devices to attach as ugen(4) instead of their more specific driver. My use

Re: nc -r: remove modulo bias and better shuffling

> and then digging deeper... to see how the portname (as a string) > is passed down to socks... and reversed into an integer... > > AGhh... I just went blind. Maybe since we're already linking in libcrypto/asn1 - if he needs to store integers as strings all the time..

Re: nc -r: remove modulo bias and better shuffling

Someone help.. Both Theo and I can't reach our epi-pens On Sun, Dec 6, 2015 at 6:54 PM, Theo de Raadt wrote: >> Since I don't think your name is Steve, you're going to touch that, >> please get rid of the PORT_MAX_LEN/calloc/snprintf dance and just use >>

Re: nc -r: remove modulo bias and better shuffling

Theo (not deraadt) ignore our screams of pain, fix the thing to use asprintf and then I'll go further with you on it ;) On Sun, Dec 6, 2015 at 7:11 PM, Bob Beck wrote: >> and then digging deeper... to see how the portname (as a string) >> is passed down to socks... and

Re: nc -r: remove modulo bias and better shuffling

On Sun, Dec 06, 2015 at 07:12:28PM -0700, Bob Beck wrote: > Theo (not deraadt) ignore our screams of pain, fix the thing to use > asprintf and then I'll go further with you on it ;) ok, there you go :) > On Sun, Dec 6, 2015 at 7:11 PM, Bob Beck wrote: > >> and then digging

Re: nc -r: remove modulo bias and better shuffling

On Mon, Dec 07, 2015 at 03:20:21AM +0100, Theo Buehler wrote: > On Sun, Dec 06, 2015 at 07:12:28PM -0700, Bob Beck wrote: > > Theo (not deraadt) ignore our screams of pain, fix the thing to use > > asprintf and then I'll go further with you on it ;) > > ok, there you go :) > > > On Sun, Dec 6,

Re: nc -r: remove modulo bias and better shuffling

On Sun, Dec 06, 2015 at 07:37:27PM +0100, Theo Buehler wrote: > The current implementation of the selection of a random sequence of > ports in nc -r suffers from modulo bias and a biased shuffling > procedure. Use arc4random_uniform() and the Fisher-Yates shuffle > instead. daniel@ pointed out

Re: nc -r: remove modulo bias and better shuffling

On Sun, Dec 06, 2015 at 07:37:27PM +0100, Theo Buehler wrote: > The current implementation of the selection of a random sequence of > ports in nc -r suffers from modulo bias and a biased shuffling > procedure. Use arc4random_uniform() and the Fisher-Yates shuffle > instead. Sorry, I attached the

Re: ugenctl for attaching USB devices to ugen instead of their specific driver

Hello Stuart, On 2015-12-06 18:23, Stuart Henderson wrote: On 2015/12/06 06:02, Mickael Torres wrote: Hello, This is a kernel patch plus a utility called ugenctl I use to allow selected USB devices to attach as ugen(4) instead of their more specific driver. My use case is a Microchip "PICkit

Re: Overflowable int -> size_t in grep

Michael McConville wrote: > This isn't a grave issue, but I came across it while exploring integer > overflow and think it's worth sharing. > > grep represents line numbers with an int, which predictably overflows > for inputs with >= 2^31 newlines. This is easy to demonstrate using the > -n

[patch] Convert modulus to arc4random_uniform

Theo's diff inspired me to look for other cases of modulo bias. The following diff converts most modulus operations on a random number to use arc4random_uniform or & as appropriate. I excluded lib/libsqlite3/src/resolve.c regress/lib/libevent/test-time.c usr.sbin/nsd/rrl.c usr.sbin/nsd/util.c

Re: Overflowable int -> size_t in grep

On Mon, Dec 07, 2015 at 01:36:22AM -0500, Michael McConville wrote: > This isn't a grave issue, but I came across it while exploring integer > overflow and think it's worth sharing. > > grep represents line numbers with an int, which predictably overflows > for inputs with >= 2^31 newlines. This

Overflowable int -> size_t in grep

This isn't a grave issue, but I came across it while exploring integer overflow and think it's worth sharing. grep represents line numbers with an int, which predictably overflows for inputs with >= 2^31 newlines. This is easy to demonstrate using the -n option and a debugging printf. The below

Re: Overflowable int -> size_t in grep

Otto Moerbeek wrote: > On Mon, Dec 07, 2015 at 01:36:22AM -0500, Michael McConville wrote: > > This isn't a grave issue, but I came across it while exploring integer > > overflow and think it's worth sharing. > > > > grep represents line numbers with an int, which predictably overflows > > for

Re: [UPDATE] freetype-2.6.2

On Sun, Dec 06, 2015 at 01:44:46PM +0100, Christian Weisgerber wrote: > David Coppa: > > > Here's the update to freetype-2.6.2. > > > > It shouldn't cause any fallout, but who knows with freetype... So > > probably a ports bulk build can be useful. > > I ran a bulk build with this on amd64.