Re: /usr/src/usr.bin/ssh/lib/../key.c:469: error: too few arguments to function 'sshkey_in_file'

On Fri, Dec 05, 2014 at 06:44:03AM +0100, Jiri Navratil wrote: [...] > > I got this error > > /usr/src/usr.bin/ssh/lib/../key.c: In function 'key_in_file': > /usr/src/usr.bin/ssh/lib/../key.c:469: error: too few arguments to > function 'sshkey_in_file' > *** Error 1 in usr.bin/ssh/lib (:40 'key.o':

constant seeds sorted roughly by popularity

Taking a closer look at randomness in the software ecosystem. This is a rough sorting of the popular 'constant' seeds people like to use. 1 srand (42) 1 srand(0x1234) 1 srand(0xabad1dea) 1 srand(1) 1 srand(100) 1 srand(121212) 1 srand(14878) 1 srand(1729) 1 srand(1806)

/usr/src/usr.bin/ssh/lib/../key.c:469: error: too few arguments to function 'sshkey_in_file'

Hello, I'm following -current. After issuing these commands cd /usr/src cvs -d$CVSROOT up -Pd rm -rf /usr/obj/* && make obj cd /usr/src/etc && env DESTDIR=/ make distrib-dirs && cd /usr/src && make build I got this error /usr/src/usr.bin/ssh/lib/../key.c: In function 'key_in_file': /usr/src/us

Re: faster rand()

The following 81 packages use arc4random from libc. In each case, I am not checking whether the use is due to upstream selecting to use arc4random, or because the ports tree contains a patch. But I suspect most of them are upstream choices. I will not do an analysis for the drand48, erand48, lra

Re: faster rand()

> Thanks for making my day :) If random() is changed in the same way, the following 1144 packages are possibly impacted. They directly link in rand(), srand(), random() or srandom() from libc. In a few cases, the application calls srandomdev() which then short-cuts random() calls direct to arc4r

Re: faster rand()

Thanks for making my day :) I actually propose the following instead: Index: rand.c === RCS file: /cvs/src/lib/libc/stdlib/rand.c,v retrieving revision 1.10 diff -u -p -r1.10 rand.c --- rand.c 1 Aug 2013 19:42:08 - 1.

two new kernel errata

Patches are now available for 5.5 and 5.6 which fix two kernel errata. 5.5 errata 16 and 5.6 errata 10: Several bugs were fixed that allowed a crash from remote when an active pipex session exists. 5.5 errata 17 and 5.6 errata 11: An incorrect memcpy call would result in corrupted MAC addresses w

Re: less string history

> On Thu, 04 Dec 2014 22:32:39 +0100, Ingo Schwarze wrote: > > > > Or: > > > A strdup() macro was first used in the 4.1cBSD debugger, dbx. > > > > > > Not helpful. > > > > It would be misleading to just say that it appeared in 4.3BSD-Reno > > because it was used in various programs for eigh

Re: less string history

On Thu, Dec 4, 2014 at 5:53 PM, Todd C. Miller wrote: > On Thu, 04 Dec 2014 22:32:39 +0100, Ingo Schwarze wrote: > >> That's beside the point. The HISTORY section generally wants to >> convey two pieces of information: Where an interface was originally >> invented (in this case, System V) and wh

Re: less string history

On Thu, 04 Dec 2014 22:32:39 +0100, Ingo Schwarze wrote: > > Or: > > A strdup() macro was first used in the 4.1cBSD debugger, dbx. > > > > Not helpful. > > It would be misleading to just say that it appeared in 4.3BSD-Reno > because it was used in various programs for eight years before > f

Re: less string history

On Thu, 04 Dec 2014 22:32:39 +0100, Ingo Schwarze wrote: > That's beside the point. The HISTORY section generally wants to > convey two pieces of information: Where an interface was originally > invented (in this case, System V) and when it became available in > the direct ancestry of OpenBSD.

Re: less string history

On Thu, 04 Dec 2014 22:32:39 +0100, Ingo Schwarze wrote: > > Or: > > The strcpy() function first appeared in the Programmer's Workbench > > (PWB/UNIX) and was ported to Version 7 AT&T UNIX. > > > > Ported? What is involved in porting strcpy? > > Nothing much, obviously. You have sugge

Re: faster rand()

>After consultation with the C standard, deraadt and I have determined >that some speedups can be made the to algorithm used by rand(). > >Theo initially proposed seed++, but I think seed-- is less expected >and therefore makes a better random number generator. > >Index: rand.c >===

upd(4) buggy firmware

I am trying to figure out how to handle the buggy USB firmware in my UPS (see misc@ thread from last week). With some kernel debug enabled, I see "usb_transfer_complete: short transfer 3<5" messages. Since the BatteryPresent sensor could not be read, all battery-related sensors were forced int

faster rand()

After consultation with the C standard, deraadt and I have determined that some speedups can be made the to algorithm used by rand(). Theo initially proposed seed++, but I think seed-- is less expected and therefore makes a better random number generator. Index: rand.c ===

Re: less string history

On Thu, 04 Dec 2014 15:43:11 -0500, Ted Unangst wrote: > Ported? What is involved in porting strcpy? I was curious enough to check and the only change between the pwb strcpy.c and the v7 version is the variable holding the return value was changed from int to char *. I'd call that a bug fix rath

Re: less string history

Hi Ted, Ted Unangst wrote on Thu, Dec 04, 2014 at 03:43:11PM -0500: > The string man pages are full of not so interesting history sections. > I don't think they are helpful, and they are in some cases misleading > or incorrect. I strongly dislike your proposal to summarily delete HISTORY section

leftover kerberos remnant

I found a kerberosV left over. Index: special.4bsd === RCS file: /cvs/src/usr.bin/spell/special.4bsd,v retrieving revision 1.9 diff -u -p -r1.9 special.4bsd --- special.4bsd24 Mar 2014 17:08:09 - 1.9 +++ special.4bsd

less string history

The string man pages are full of not so interesting history sections. I don't think they are helpful, and they are in some cases misleading or incorrect. For example: The memmove() function first appeared in 4.3BSD-Reno. That's arguably wrong, since it appeared in C89 which predates Reno. (C

Re: Convert bgpd to use siphash

On Thu, Dec 04, 2014 at 12:52:04PM -0500, Ted Unangst wrote: > Ah, so this won't work. That's not how siphash works. > > The key needs to last as long as the hash table does, which is > generally as long as the program. Different keys result in different > hashes, which makes it hard to look thing

Re: Convert bgpd to use siphash

On 2014/12/04 17:41, Dimitris Papastamos wrote: > Admittedly it would have been better to store the key in the struct > and then use arc4random_buf() only once or so. I am not familiar with the > code so I will investigate this option. > I suspect attr_alloc() is going to be a rather hot functio

Re: Convert bgpd to use siphash

On Thu, Dec 04, 2014 at 17:32, Dimitris Papastamos wrote: > Hi, > > This is my attempt at converting bgpd to use siphash. This does > *not* link as is because the userland implementation of siphash > is currently missing. Indeed. That should be coming in a few days. I have a diff ready. > > +

Re: Convert bgpd to use siphash

Admittedly it would have been better to store the key in the struct and then use arc4random_buf() only once or so. I am not familiar with the code so I will investigate this option.

Convert bgpd to use siphash

Hi, This is my attempt at converting bgpd to use siphash. This does *not* link as is because the userland implementation of siphash is currently missing. In certain cases where multiple data is hashed in succession, it might have been better to use a siphash context and call SipHash24_Update().