Re: Disable DSA_FLAG_NO_EXP_CONSTTIME, always enable constant-time behavior

No problem, I undid that bit. Thanks all. On Mon, Jun 20, 2016 at 11:32 AM, Ted Unangst wrote: > Brent Cook wrote: > > diff --git a/src/lib/libssl/src/crypto/dsa/dsa_key.c > b/src/lib/libssl/src/crypto/dsa/dsa_key.c > > index 2968fa2..e01bacb 100644 > > ---

Re: pf.conf macro with space

sven falempin(sven.falem...@gmail.com) on 2016.06.20 17:38:40 -0400: > Dear Tech Readers, > > in a pf.conf file one can do > "silly things" = egress Thanks for your diff, but one, i dont think spaces in macros are useful in pf.conf. second, we want to keep this consistent across all the

Re: pf divert port reuse

Alexander Bluhm(alexander.bl...@gmx.net) on 2016.06.21 00:14:19 +0200: > Hi, > > I have seen a problem with pf divert when the dynamic port in a nat > rule got reused. The function pf_state_key_attach() reused the > state as it was in TCPS_FIN_WAIT_2. The corresponding socket was > not reused,

Re: fix iwm association problems

On Mon, Jun 20, 2016 at 12:34:17PM +0200, Stefan Sperling wrote: > I found that my 8260 iwm(4) device has trouble associating to my 5 GHz > AP, which runs OpenBSD with athn(4) in hostap mode. Most of the time > it won't even get a DHCP lease. Some frames it believes it has sent > are not even

pf divert port reuse

Hi, I have seen a problem with pf divert when the dynamic port in a nat rule got reused. The function pf_state_key_attach() reused the state as it was in TCPS_FIN_WAIT_2. The corresponding socket was not reused, as the the TCPS_TIME_WAIT case in tcp_input() has additional checks for timestamps

Re: Stop mesa W^X violations

>Note that the existing code would have worked just fine if mmap >returned MAP_FAILED for W^X violations instead of terminating the >program. Not entirely sure what the long-term plans are. Yeah, I am not sure of the long-term plans yet either. In discussions with the ports people the idea was

pf.conf macro with space

Dear Tech Readers, in a pf.conf file one can do "silly things" = egress as defined in parse.y like varset : STRING '=' varstring { if (pf->opts & PF_OPT_VERBOSE) printf("%s = \"%s\"\n", $1, $3); if

Stop mesa W^X violations

As reported by several people, mesa contains code that violates W^X. As a result glxgears aborts when using the swrast driver. The diff below disables the offending code. The code seems to deal the absence of W|X memory just fine. There is a fallback path that is also used on SELinux systems.

Re: bgpd logging nexthop valid

On 2016 Jun 19 (Sun) at 17:39:53 +0200 (+0200), Sebastian Benoit wrote: :i would like to make bgpd a bit more quiet. : :This type of message : : bgpd[59424]: nexthop 1.2.3.4 now valid: via 192.168.0.1 : :happens quite often depending on your upstreams. This makes it a debug :message only. : :ok? :

Re: Disable DSA_FLAG_NO_EXP_CONSTTIME, always enable constant-time behavior

Brent Cook wrote: > diff --git a/src/lib/libssl/src/crypto/dsa/dsa_key.c > b/src/lib/libssl/src/crypto/dsa/dsa_key.c > index 2968fa2..e01bacb 100644 > --- a/src/lib/libssl/src/crypto/dsa/dsa_key.c > +++ b/src/lib/libssl/src/crypto/dsa/dsa_key.c > -#endif > +#endif > \ No newline at end of file

Re: bgpd logging nexthop valid

On Sun, Jun 19, 2016 at 05:39:53PM +0200, Sebastian Benoit wrote: > i would like to make bgpd a bit more quiet. > > This type of message > > bgpd[59424]: nexthop 1.2.3.4 now valid: via 192.168.0.1 > > happens quite often depending on your upstreams. This makes it a debug > message only. > >

Re: Disable DSA_FLAG_NO_EXP_CONSTTIME, always enable constant-time behavior

On 2016/06/20 16:55, Marc Espie wrote: > The only thing I'm wondering about is if there's somebody out there who > just uses the "big integer arithmetic" part of openssl, and doesn't want > to go libgmp for licensing reasons. > > Like, if you're in it for (say) trying to break codes, having code

Re: Disable DSA_FLAG_NO_EXP_CONSTTIME, always enable constant-time behavior

The only thing I'm wondering about is if there's somebody out there who just uses the "big integer arithmetic" part of openssl, and doesn't want to go libgmp for licensing reasons. Like, if you're in it for (say) trying to break codes, having code that goes as fast as it can might be useful. Is

Re: openssl(1): fix bug loading default certificate path locations

sure.. ok On Mon, Jun 20, 2016 at 08:35:13AM -0500, Brent Cook wrote: > > This fixes a bug where the default certificate path locations would only > be loaded if the CAfile or CApath locations were succesfully loaded > first. Original patch from OpenSSL: > >

Re: Disable DSA_FLAG_NO_EXP_CONSTTIME, always enable constant-time behavior

Reads good to me, and passes the regress here, so OK from me. On Mon, Jun 20, 2016 at 04:40:25AM -0500, Brent Cook wrote: > Hi, > > This is a patch from Cesar Pereida, removing support for > DSA_FLAG_NO_EXP_CONSTTIME by making DSA always operate in constant time. > > See

openssl(1): fix bug loading default certificate path locations

This fixes a bug where the default certificate path locations would only be loaded if the CAfile or CApath locations were succesfully loaded first. Original patch from OpenSSL: https://github.com/openssl/openssl/commit/fe9b85c3cb79f1e29e61f01de105b34ce8177190 Noted here on the LibreSSL-portable

Re: af-to on pass out should be a parser error

* Mike Belopuhov [2016-06-20 00:33]: > rdr-to/nat-to are not checked on purpose. i'm not certain about > route-to/reply-to. indeed, rdr-to/nat-to in the "unnatural" direction DO work, with caveats. route-to and af-to are different. as others already pointed out the check

pool_setipl for tmpfs

PR_WAITOK implies process context, so IPL_NONE is fine. this is the same as the ufs change, but in tmpfs. ok? Index: tmpfs_vfsops.c === RCS file: /cvs/src/sys/tmpfs/tmpfs_vfsops.c,v retrieving revision 1.8 diff -u -p -r1.8

Re: set art_walk up for an mpsafe world

> On 18 Jun 2016, at 1:53 AM, Martin Pieuchot wrote: > > On 15/06/16(Wed) 11:38, David Gwynne wrote: >> this tweaks art_walk in preparation for a world where the table may >> be updated on another cpu. >> >> at the moment we're relying on the big lock to serialise updates, >>

Re: fix iwm association problems

On Mon, Jun 20, 2016 at 12:34:17PM +0200, Stefan Sperling wrote: > I found that my 8260 iwm(4) device has trouble associating to my 5 GHz AP, > which runs OpenBSD with athn(4) in hostap mode. Most of the time it won't > even get a DHCP lease. Some frames it believes it has sent are not even >

fix iwm association problems

I found that my 8260 iwm(4) device has trouble associating to my 5 GHz AP, which runs OpenBSD with athn(4) in hostap mode. Most of the time it won't even get a DHCP lease. Some frames it believes it has sent are not even visible on the air. The iwm driver still has a copy of code from Linux that

Disable DSA_FLAG_NO_EXP_CONSTTIME, always enable constant-time behavior

Hi, This is a patch from Cesar Pereida, removing support for DSA_FLAG_NO_EXP_CONSTTIME by making DSA always operate in constant time. See https://github.com/libressl-portable/openbsd/pull/61 for more details. ok? diff --git a/src/lib/libssl/src/crypto/dsa/dsa.h

iwm tx rate fixes

iwm(4) should always send multicast frames at the lowest rate. We probably got lucky and frames were still sent at a compatible rate via the LQ retry table. But it is better to have an "IS_MULTICAST" check like other drivers do. On 5GHz, iwm(4) passes the wrong rate to BPF. This is a cosmetic

Re: umb(4) man page tweaks

On Mon, 20 Jun 2016 08:50:05 +0200 Gerhard Roth wrote: > Hallo Stefan, > > danke, dass Du Dich darum kuemmerst. > > ok gerhard@ Sorry for the German. This mail was intended to go to Stefan only and not the mailing list. My mistake. Gerhard > > > On Sun, 19 Jun 2016

Re: umb(4) man page tweaks

Hallo Stefan, danke, dass Du Dich darum kuemmerst. ok gerhard@ On Sun, 19 Jun 2016 15:03:13 +0200 Stefan Sperling wrote: > Some information in the umb(4) man page seems to be outdated (IPV4 gateway > handling), or doesn't really belong in a man page ("please hack the driver >

Re: simpler audioctl

On Sun, Jun 19, 2016 at 05:56:38PM +0200, Sebastien Marie wrote: > > Just one point about the man page: > > Test if the hardware supports 24-bit encoding and 44100Hz sample rate: > >$ audioctl -f /dev/audio0 encoding=s24 rate=44100 > > "Test" is somehow incorrect as if the