On Wed, Jun 07, 2017 at 02:51:42PM +1000, David Gwynne wrote:
> >
> > you are breaking the format of this page if you start to move specific
> > subsytems into the main body.
> >
> > that makes things less clear. for example, can i use the parent-device
> > stuff on any type of interface or just
> 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 omissions that id
>> rat
> 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 everythin
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
> > >
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 ha
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, what
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 me
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
--- share/mk/bs
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 c
>> 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 host
> 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.
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 lo
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 docu
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
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 soc
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 g
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 o
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.
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 som
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 trace.
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 ro
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 clau
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
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
>>> to
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 r
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 protec
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 th
27 matches
Mail list logo
