"generally reliable" HAHAHAHAHA
On Thu, Jul 23, 2015 at 09:31:59PM -0400, Michael McConville wrote:
> On Thu, Jul 23, 2015 at 06:49:55PM -0600, Theo de Raadt wrote:
> > > There was a great discussion about softdep recently:
> > >
> > > https://marc.info/?t=14216401691&r=1&w=2
> > >
> > >
On Thu, Jul 23, 2015 at 03:57:20PM -0600, Jérémie Courrèges-Anglas wrote:
> Stuart Henderson writes:
>
> > This avoids breaking with shell special characters. OK for the simple
> > fix? Or is there a safer way to feed in the password?
>
> OK. I only took a quick look at it, but -key seems the o
Michael McConville wrote:
> There was a great discussion about softdep recently:
>
> https://marc.info/?t=14216401691&r=1&w=2
>
> It needs extra memory, so the FAQ warns against its use on really old
> architectures.
>
> tedu@ described the two main deterrents:
>
> https://marc.
Index: daily.8
===
RCS file: /cvs/src/share/man/man8/daily.8,v
retrieving revision 1.21
diff -u -p -r1.21 daily.8
--- daily.8 16 Jul 2014 17:03:17 - 1.21
+++ daily.8 23 Jul 2015 07:27:36 -
@@ -74,9 +74,7 @@ Runs th
Index: relayd.conf.5
===
RCS file: /cvs/src/usr.sbin/relayd/relayd.conf.5,v
retrieving revision 1.163
diff -u -p -r1.163 relayd.conf.5
--- relayd.conf.5 15 May 2015 20:40:26 - 1.163
+++ relayd.conf.5 23 Jul 2015 07
On Thu, Jul 23, 2015 at 06:49:55PM -0600, Theo de Raadt wrote:
> > There was a great discussion about softdep recently:
> >
> > https://marc.info/?t=14216401691&r=1&w=2
> >
> > It needs extra memory, so the FAQ warns against its use on really
> > old architectures.
> >
> > tedu@ describe
hey maxime,
this should be fixed in src/sys/dev/pci/if_bnx.c r1.112.
thanks for the report :)
dlg
> On 21 Jul 2015, at 18:31, Maxime Villard wrote:
>
> Hi,
> I put here a bug among others:
>
> -- sys/dev/pci/if_bnx.c
>
>
There is no way this diff is going in.
When softdep is 100% reliable, then we can talk.
Enabling it prematurely is ridiculous. Considering the defects
are clearly described as lockups, disk space corruption -- with
such a suggestion I must ask --who's side are you on??
> There was a great dis
There was a great discussion about softdep recently:
https://marc.info/?t=14216401691&r=1&w=2
It needs extra memory, so the FAQ warns against its use on really old
architectures.
tedu@ described the two main deterrents:
https://marc.info/?l=openbsd-misc&m=142294185000751&w=2
On Thu, Jul 23, 2015 at 05:03:26PM +0100, Stuart Henderson wrote:
> This avoids breaking with shell special characters. OK for the simple
> fix? Or is there a safer way to feed in the password?
I'm OK with this change. It should be possible to write
the passphrase to a fd/stdin instead?
>
> I a
Stuart Henderson writes:
> This avoids breaking with shell special characters. OK for the simple
> fix? Or is there a safer way to feed in the password?
OK. I only took a quick look at it, but -key seems the only way to pass
the password, and switching this to execv(e) seems intrusive.
> I als
ping
https://marc.info/?l=openbsd-tech&m=143432732005608&w=2
https://marc.info/?l=openbsd-tech&m=143441062327954&w=2
Index: sbin/dump/dump.8
===
RCS file: /cvs/src/sbin/dump/dump.8,v
retrieving revision 1.49
diff -
Below you'll find a patch that adds vt-d support
(https://software.intel.com/en-us/blogs/2009/06/25/understanding-vt-d-intel-virtualization-technology-for-directed-io).
Being able to restrict where devices perform DMA is a pretty big security
benefit. This code works on several machines but isn't
This avoids breaking with shell special characters. OK for the simple
fix? Or is there a safer way to feed in the password?
I also noticed that ikeca.cnf doesn't get installed (the distribution:
target in ikectl/Makefile is commented out), is there a reason for
that?
Index: ikeca.c
==
On 17/07/15(Fri) 17:53, Ludovic Coues wrote:
> Following yesterday feedback, I wrote a patch merging
> usb_video_header_desc and usb_video_header_desc_all in uvideo.c .
> Current kernel compile fine with it on amd64 and video display image.
>
> At the moment, I can't test the patch on other platfo
On 2015/07/23 14:47, Theo Buehler wrote:
> Since doas.conf is a `dangerous file', it seems to make sense to monitor
> it daily(8). I don't know the policy on permissions in the /etc/mtree/*
> files. Anything between 0400 and 0644 would seem to make sense.
> /etc/sudoers used to have 0440. I sugg
Since doas.conf is a `dangerous file', it seems to make sense to monitor
it daily(8). I don't know the policy on permissions in the /etc/mtree/*
files. Anything between 0400 and 0644 would seem to make sense.
/etc/sudoers used to have 0440. I suggest 0640 so that root can edit
the file (since th
17 matches
Mail list logo
