On Mon, Apr 24, 2017 at 01:04:12AM +0800, Michael W. Bombardieri wrote:
> Hi,
>
> When I remove uaudio_drain() on my laptop the attach/detach still
> seems to work as expected.
> I did a test with two usb soundcards. Audio files were played &
> recorded using aucat.
>
> * boot system (no audio de
On Mon, Apr 24, 2017 at 04:39 +0200, Mike Belopuhov wrote:
> AES_Setkey takes key length in bytes rather than bits which makes
> it a bit simpler.
>
The diff below will have to go right after since glxsb depends on
xform.c to do AES-192 and AES-256...
>From 25a725a4440bdac11a4860af59dae4f705a76b
Small regress test fixups.
---
regress/sys/crypto/aesctr/Makefile | 2 +-
regress/sys/crypto/aesctr/aesctr.c | 8 +++-
regress/sys/crypto/aesxts/Makefile | 2 +-
regress/sys/crypto/aesxts/aes_xts.c | 6 +++---
regress/sys/crypto/gmac/Makefile| 2 +-
regress/sys/crypto/gmac/gmac_test.c
AES_Setkey takes key length in bytes rather than bits which makes
it a bit simpler.
---
sys/crypto/cryptosoft.c | 8 +++
sys/crypto/gmac.c | 9
sys/crypto/gmac.h | 5 ++---
sys/crypto/xform.c | 55 +++--
sys/crypto/xform
Adjusts the regress test.
---
regress/sys/crypto/aes/Makefile | 2 +-
regress/sys/crypto/aes/aestest.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git regress/sys/crypto/aes/Makefile regress/sys/crypto/aes/Makefile
index 75e88b1a7a6..9120371a07d 100644
--- regress/
Hi,
This is the first diff in series to replace our table-driven AES
implementation in the crypto framework with a constant time one
authored by Thomas Pornin. I've been on the lookout for a complete
constant time implementation for several years and thanks to Thomas,
we've got a very nice one no
tech@,
There may be security implications that I'm not aware of, but would the
following be possible?
Change /dev/hotplug
cr--r- 1 root operator 82, 0 Apr 11 20:55 hotplug
This way a member of the operator group can start hotplugd from .xinitrc
and use it to launch graphical pr
On Mon, Apr 24, 2017 at 12:01:10AM +0200, Marc Espie wrote:
> On Sun, Apr 23, 2017 at 10:16:38PM +0200, Timo Buhrmester wrote:
> > > The main difference between you and Theo is that Theo knows what he's
> > > talking about.
>
> > If you want to contribute anything, point out how casting a non-nega
As reported by "orge" on #openbsd on freenode:
# sysctl kern.somaxconn=2147483648
kern.somaxconn: 128 -> -2147483648
I think there are two bugs here: first, the strtol and strtoul calls
don't properly check for integer overflow; second, kern.somaxconn should
only accept non-negative input.
Note
On Sun, Apr 23, 2017 at 10:16:38PM +0200, Timo Buhrmester wrote:
> > The main difference between you and Theo is that Theo knows what he's
> > talking about.
> If you want to contribute anything, point out how casting a non-negative
> into to size_t for comparison against another size_t could lead
> The main difference between you and Theo is that Theo knows what he's
> talking about.
If you want to contribute anything, point out how casting a non-negative
into to size_t for comparison against another size_t could lead to
"real errors later whenever the code evolves in any way". Nice straw
On Sun, Apr 23, 2017 at 05:12:16PM +0200, Timo Buhrmester wrote:
> Except if the world changes... In a way that's still POSIX-compliant.
> But why would anyone want to protect themselves from that, right?
You're full of it.
You're advocating for an unnecessary cast that can actually hide real
er
Hi Stefan,
Thanks for your help.
It seems there was a hardware problem. I was running in SSH, and that did
not work (I knew it had previously in other situations).
In the end, I had to power down completely - including removing the cables
from the PSUs!
After the reboot, it behaved as you descri
Hi,
When I remove uaudio_drain() on my laptop the attach/detach still
seems to work as expected.
I did a test with two usb soundcards. Audio files were played &
recorded using aucat.
* boot system (no audio device because I disabled azalia)
* attach device1 (Creative card)
* play wav file1 (refer
> Date: Mon, 3 Apr 2017 01:33:28 -0400
> From: Ian Sutton
>
> This patch introduces preliminary support for the display hardware
> onboard the am335x/BeagleBone Black. Included are two drivers,
> amdisplay(4) and nxptda(4), which run the LCD controller and HDMI PHY
> transmitter respectively. Thi
> well because X docs are third party, and we don't usually make local
> changes to third party docs. having said that, there are exceptions,
> and i know we have changed some docs (forget which) to mention
> xenodm. so that's why i said i'd leave it to the X folks ;)
oh. duh. maintenance burden
On Sun, Apr 23, 2017 at 10:23:14AM -0500, Scott Cheloha wrote:
>
> > On Apr 23, 2017, at 2:44 AM, Jason McIntyre wrote:
> >
> > [...] but note that all this text is doing is giving an example of a
> > window manager and, as such, it's not wrong.
>
> My thinking is that preventing stuff like
>
> Timo if you feel the need to be an asshole, please be that asshole
> elsewhere.
Pot, meet Kettle.
> On Apr 23, 2017, at 2:44 AM, Jason McIntyre wrote:
>
> [...] but note that all this text is doing is giving an example of a
> window manager and, as such, it's not wrong.
My thinking is that preventing stuff like
$ man xdm
man: No entry for xdm in the manual.
where possible
> > Otherwise, you can start enabling that option and sending a diff which
> > fixes ALL THE WARNINGS IT GIVES IN THE ENTIRE TREE.
> I think I'll pass on that. I wasn't aware of how many warnings
> a build seems to cause. This must be why NetBSD has -Werror in their
> CFLAGS.
Timo if you feel th
> > Otherwise people might fall into a habit
> > of ignoring warnings [that may point to actual problems].
>
> People might fall into the habit of ignoring a warning from an
> extension to C provided by a single compiler?
>
> I doubt it.
Doubt away. I find it more than obvious that telling peopl
> > The code is already safe.
> It is reasonably safe(*) and triggers a warning. That's a good reason
> to silence the warning.
No.
The warning is a false extension to C.
In C, int and sizeof can be compared safely in this circumstance.
> Otherwise people might fall into a habit
> of ignoring w
On Sun, Apr 23, 2017 at 02:14:51PM +0100, Andrew Grillet wrote:
> Hi
>
> I have a T2000 running OpenBSD 6.0, with five guest domains.
>
> Primary and some guests are working. I am attempting to install the OS in
> the remaining guests. In the process of installing the OS on vdisk0 of a
> guest, I
> The code is already safe.
It is reasonably safe(*) and triggers a warning. That's a good reason
to silence the warning. Otherwise people might fall into a habit
of ignoring warnings [that may point to actual problems]. I just
pointed out a safe way to silence the warning, without it
potentially
> > Well, when the world changes, that cast is suddenly wrong.
>
> I.e. instead of
> > if (ret == -1 || ret >= sizeof(buffer))
> one could use
> > if (ret < 0 || (size_t)ret >= sizeof(buffer))
>
> And be safe from a changing world.
The code is already safe.
> Well, when the world changes, that cast is suddenly wrong.
I.e. instead of
> if (ret == -1 || ret >= sizeof(buffer))
one could use
> if (ret < 0 || (size_t)ret >= sizeof(buffer))
And be safe from a changing world.
Hi
I have a T2000 running OpenBSD 6.0, with five guest domains.
Primary and some guests are working. I am attempting to install the OS in
the remaining guests. In the process of installing the OS on vdisk0 of a
guest, I wish it to boot from vdisk1, but the guest is stuck in a situation
where it c
On Sun, Apr 23, 2017 at 12:41:37PM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> I'm fine with your pfctl.c change.
>
> Although I like your brief version of manpage, wearing admin's hat, I'm
> somewhat missing line:
> > -k host | network | label | key | id
>
> so how about one small change
Hello,
I'm fine with your pfctl.c change.
Although I like your brief version of manpage, wearing admin's hat, I'm
somewhat missing line:
> -k host | network | label | key | id
so how about one small change below:
8<---8<---8<--8<
---
Hello,
On Sun, Apr 23, 2017 at 12:18:07AM +0200, Hiltjo Posthuma wrote:
> On Sat, Apr 22, 2017 at 08:14:06AM +0900, YASUOKA Masahiko wrote:
> > On Fri, 21 Apr 2017 13:52:51 +0900 (JST)
> > YASUOKA Masahiko wrote:
> > > +int
> > > +pfctl_parse_host(char *str, struct pf_rule_addr *addr)
> > > +{
>
On Sun, 23 Apr 2017 00:18:07 +0200
Hiltjo Posthuma wrote:
> On Sat, Apr 22, 2017 at 08:14:06AM +0900, YASUOKA Masahiko wrote:
>> On Fri, 21 Apr 2017 13:52:51 +0900 (JST)
>> YASUOKA Masahiko wrote:
>> > +int
>> > +pfctl_parse_host(char *str, struct pf_rule_addr *addr)
>> > +{
>> (snip)
>> > + if
On Fri, Apr 21, 2017 at 05:49:59PM -0500, Scott Cheloha wrote:
> Index: xinit.man
> ===
> RCS file: /cvs/xenocara/app/xinit/man/xinit.man,v
> retrieving revision 1.3
> diff -u -p -r1.3 xinit.man
> --- xinit.man 30 Aug 2015 13:32:02 -
32 matches
Mail list logo
