Re: ifconfig.8 doco for vnetid and parent options

> On 6 Jun 2017, at 18:12, Jason McIntyre wrote: > > On Tue, Jun 06, 2017 at 11:56:28AM +1000, David Gwynne wrote: >> this adds doco for the parent options in ifconfig, and moves vnetid >> up into generic options list. >> >> the vlan(4) specific doco has enough lies and

Re: htpasswd: use crypt_newhash instead of bcrypt API

> On 20:49:05, 6.06.17, Jason McIntyre wrote: > > right now this man page suggests that people will use "bcrypt,a" > > to "automatically suggest rounds based on system performance". is > > that right? i'd have expected people to just use "bcrypt" (w/o > > args). Because you can't change

Re: htpasswd: use crypt_newhash instead of bcrypt API

On Tue, Jun 06, 2017 at 08:49:32PM +0200, Adam Wolk wrote: > On Tue, Jun 06, 2017 at 12:28:59PM -0600, Theo de Raadt wrote: > > > The only thing against using automatic rounds would be having them > > > guessed on a > > > weaker machine and used on a more powerful server - doubt though that > >

Re: htpasswd: use crypt_newhash instead of bcrypt API

On 20:49:05, 6.06.17, Jason McIntyre wrote: > right now this man page suggests that people will use "bcrypt,a" > to "automatically suggest rounds based on system performance". is > that right? i'd have expected people to just use "bcrypt" (w/o > args). in fact, why have "a" at all? why not just

Re: htpasswd: use crypt_newhash instead of bcrypt API

On Tue, Jun 06, 2017 at 09:16:08PM +0200, Michal Mazurek wrote: > When talking about this with mulander@ it came out that the docs could > use a touch. > > The commit message for the diff that didn't update the docs was: > > permit "bcrypt" as an alias for "blowfish". this is, after all,

Re: htpasswd: use crypt_newhash instead of bcrypt API

When talking about this with mulander@ it came out that the docs could use a touch. The commit message for the diff that didn't update the docs was: permit "bcrypt" as an alias for "blowfish". this is, after all, what 99% of the world calls it. allow just "bcrypt" without params to

g/c ASPICFLAG

This used to be necessary in the gcc 2.95 days. Nowadays nothing in base or X uses it. Index: share/mk/bsd.own.mk === RCS file: /OpenBSD/src/share/mk/bsd.own.mk,v retrieving revision 1.184 diff -u -p -r1.184 bsd.own.mk ---

Re: htpasswd: use crypt_newhash instead of bcrypt API

On Tue, Jun 06, 2017 at 12:28:59PM -0600, Theo de Raadt wrote: > > The only thing against using automatic rounds would be having them guessed > > on a > > weaker machine and used on a more powerful server - doubt though that would > > ever > > pick something below 8 rounds. > > I don't see the

Re: Makefile.cross tweaks

>> The following diff attempts to cross-build more things, in particular >> gnu/lib (except for libiberty). It also passes the proper optimization >> flags so that libstdc++-v3 gets built with optimization. > > Doesn't build for arm64, probably because BUILD_GCC4 is transparently > set by the

Re: htpasswd: use crypt_newhash instead of bcrypt API

> The only thing against using automatic rounds would be having them guessed on > a > weaker machine and used on a more powerful server - doubt though that would > ever > pick something below 8 rounds. I don't see the concern. It has a lower bound.

Re: htpasswd: use crypt_newhash instead of bcrypt API

On Tue, Jun 06, 2017 at 02:20:38PM -0400, Bryan Steele wrote: > > > > - if (strlcpy(salt, bcrypt_gensalt(8), sizeof(salt)) >= sizeof(salt)) > > - errx(1, "salt too long"); > > - if (strlcpy(hash, bcrypt(pass, salt), sizeof(hash)) >= sizeof(hash)) > > - errx(1, "hash too

Re: htpasswd: use crypt_newhash instead of bcrypt API

On Tue, Jun 06, 2017 at 07:43:02PM +0200, Adam Wolk wrote: > Hi tech@ > > While reading htpasswd and htpasswd handling in httpd I noticed that both use > different APIs to handle encrypting/decrypting the passwords. > > - htpasswd uses the bcrypt API > - httpd uses the new crypt API > > The

htpasswd: use crypt_newhash instead of bcrypt API

Hi tech@ While reading htpasswd and htpasswd handling in httpd I noticed that both use different APIs to handle encrypting/decrypting the passwords. - htpasswd uses the bcrypt API - httpd uses the new crypt API The documentation for bcrypt states: These functions are deprecated in favor of

Re: soassertlocked() & protocol families

On Tue, Jun 06, 2017 at 05:37:46PM +0200, Martin Pieuchot wrote: > Our plan is to work on the socket layer protocol per protocol. claudio@ > already sent some diffs to make the iteration on the PF_ROUTE socket > list MP-safe. However that isn't enough for the inner par of the loop. > > Since

Re: Towards tcp_input() w/o KERNEL_LOCK()

On Tue, Jun 06, 2017 at 05:15:40PM +0200, Martin Pieuchot wrote: > TCP/UDP are almost ready to run without KERNEL_LOCK() because accesses > to their sockets are serialized via the NET_LOCK(). On the other hand > pfkey and routing sockets accesses still rely on the KERNEL_LOCK(). > > Since we're

qsort(3): restore switch to insertion sort

The 4.4BSD qsort has a heuristic for detecting whether the input is partially sorted, in which case it switches to insertion sort. This is provides a large speed up for partially sorted workloads, which are common. However, this resulted in quadratic behavior for certain inputs. For more details

Re: pfsync and option WITH_PF_LOCK

On 06/06/17(Tue) 17:32, Hrvoje Popovski wrote: > Hi all, > > i'm getting these traces with "option WITH_PF_LOCK" enaled. > Setup is quite standard, trunk, vlan, carp, pfsync > > > splassert: pf_state_insert: want 1 have 0 > splassert: pf_remove_state: want 1 have 0 This is a known issue.

soassertlocked() & protocol families

Our plan is to work on the socket layer protocol per protocol. claudio@ already sent some diffs to make the iteration on the PF_ROUTE socket list MP-safe. However that isn't enough for the inner par of the loop. Since socket flag access and socket buffer modifications need to be atomic until

pfsync and option WITH_PF_LOCK

Hi all, i'm getting these traces with "option WITH_PF_LOCK" enaled. Setup is quite standard, trunk, vlan, carp, pfsync splassert: pf_state_insert: want 1 have 0 splassert: pf_remove_state: want 1 have 0 with kern.splassert=2 splassert: pf_state_insert: want 1 have 0 Starting stack

Towards tcp_input() w/o KERNEL_LOCK()

TCP/UDP are almost ready to run without KERNEL_LOCK() because accesses to their sockets are serialized via the NET_LOCK(). On the other hand pfkey and routing sockets accesses still rely on the KERNEL_LOCK(). Since we're going to work at the socket layer, first to remove the KERNEL_LOCK() from

Re: routing sockets vs KERNEL_LOCK()

On Tue, Jun 06, 2017 at 01:03:33PM +0200, Martin Pieuchot wrote: > On 05/06/17(Mon) 16:52, Martin Pieuchot wrote: > > On 05/06/17(Mon) 12:12, Martin Pieuchot wrote: > > > Routing sockets are not protected by the NET_LOCK(). That's one of the > > > boundaries of the network stack. That's whhy

radix lookup w/o KERNEL_LOCK()

One of the reasons IPsec still requires the KERNEL_LOCK() in the forwarding path is that it uses the radix tree for the SPD lookup. Since the radix code is used by other subsystems (NFS export list, PIPEX, PF) we want it to be able to run on parallel, at least when callers aren't manipulating the

Re: routing sockets vs KERNEL_LOCK()

On 6.6.2017. 13:03, Martin Pieuchot wrote: > On 05/06/17(Mon) 16:52, Martin Pieuchot wrote: >> On 05/06/17(Mon) 12:12, Martin Pieuchot wrote: >>> Routing sockets are not protected by the NET_LOCK(). That's one of the >>> boundaries of the network stack. That's whhy claudio@ sent some diffs >>>

remove hostname not IP addr test in libtls tls_servername_cb()

It turns out that despite RFC 6066 stating 'Literal IPv4 and IPv6 addresses are not permitted in "HostName".' for SNI the implementations of TLS in python and ruby do this. While chromium, firefox, lua(sec), java, go, ftp(1), curl, wget, and others when acting as TLS clients all manage to get it

Re: routing sockets vs KERNEL_LOCK()

On 05/06/17(Mon) 16:52, Martin Pieuchot wrote: > On 05/06/17(Mon) 12:12, Martin Pieuchot wrote: > > Routing sockets are not protected by the NET_LOCK(). That's one of the > > boundaries of the network stack. That's whhy claudio@ sent some diffs > > to no longer require the KERNEL_LOCK() to

Re: ifconfig.8 doco for vnetid and parent options

On Tue, Jun 06, 2017 at 11:56:28AM +1000, David Gwynne wrote: > this adds doco for the parent options in ifconfig, and moves vnetid > up into generic options list. > > the vlan(4) specific doco has enough lies and omissions that id > rather get rid of it. > > ok? > morning. you are breaking