Re: opendev and pledge: "privsep" for dumpfs(8)

2016-05-13 Thread Sebastien Marie
On Fri, May 13, 2016 at 10:52:34PM +0200, Theo Buehler wrote:
> opendev(3) should not be called by pledged processes, so the pledge of
> dumpfs(8) needs to be redone:

I agree.

> opendev is called in a loop over argv.
> 
> As dumpfs spews a whole lot of potentially untrusted data to stdout,
> fork, read the data in the child and pipe it to the pledged parent
> that writes it to stdout. pledge the child before dumping the last fs.
> Thus the common case of dumping a single fs runs almost entirely
> under pledge.

I dunno if the approch makes sense: basically you create one process
(unpledged and with full privilegies - except for last argument) that
will call opendev(3) and dumpfs(), and the pledged process will be used
to write(2) data to stdout...

the part that needs attention is the process which call dumpfs()
function. it is this one that require pledge(2). not the one that do
write(2).

I think there are two possibilities:
  - remove the capability to pass multiple fs (I dunno if it is used -
if it is, this "possibility" isn't suitable - but the man page
doesn't document this possibility).

this way, call opendev(3) unpledged, and after call pledge(2). No
need for multiples processes.

  - keep main process unpledged, fork(2) for each fs inside the loop,
and call pledge(2) after opendev(3).  so the child (which call the
sensitive dumpfs() function) will be pledged, and the parent
(unpledged) will only do write(2).

so in *all cases*, the process that proceed untrusted data is
pledged. not only if you pass one argument.

-- 
Sebastien Marie



Re: Is loss of read-only /usr permanent?

2016-05-13 Thread Theo de Raadt
> I think you are totally missing the point that Theo just made.
> Marking partitions as read-only is useful, when and only when
> appropriate.
> I have:
> /var/www/var
> /home
> /home/user1
> /home/user2
> /usr/local
> 
> all marked as read-only.
> Why, because when the power fails, no data is lost and I'm quickly back
> up with minimal fsck'ing.
> When user1 or user2 logs in, There is a big message telling them to
> mount their partition rw and right before logging out or shutting down,
> to mark as ro.
> When the lights start to flicker, Ctrl-Alt-Backspace slams you out of X
> and ro alias slams that partition safe much faster than shutdown.
> This has saved my ass twice now.
> 
> Backup your data and re-install that snapshot if you lose /usr, etc.
> Works great for me. Many times.
> You are backing up etc and root, right?

That's good Chris --

You have built a setup you like, and you handle the subtle issues
associated with that choice.

Meaning you wouldn't file a bug report.  It is your choice, and you
make the downsides of that choice work.



Re: update Mesa to 11.2.2

2016-05-13 Thread Jonathan Gray
Still looking for some tests on r600 and powerpc for this.

Note that the majors of libGL and libOSMesa are cranked due
to removed symbols.  Minors of libGLESv2 and libglapi.



Re: Is loss of read-only /usr permanent?

2016-05-13 Thread Theo de Raadt
> The report is fairly easy to reproduce.  Make the /usr filesystem
> read-only in /etc/fstab, go to single user mode and exit back to
> multi-user.  I've appended a transcript.

This does not matter.  It is your configuration.  It is not the default.

Can you make /usr readonly on 90% of other operating systems, without
downsides?  Then switch.  The reality is that you can't, since it is
your own brave configuration choice.  You own it.

> It's unfortunate that mounting /usr read-only is now a mis-configuration.

It was never a valid configuration.  Next up, you will ask for readonly
/etc.  Or readonly /var.  Or readonly something.  Or operation without
half the files that are in /etc.  Who knows.

It is your change --> you own it.



Re: Is loss of read-only /usr permanent?

2016-05-13 Thread Theo de Raadt
>I think it comes down to this. If you want read-only /etc, you'll have to
>modify /etc/rc, if you still want the mitigation.

I want to no readable files in /usr/lib!

PLEASE, the make-programs-run migitation is killing me!



Re: Is loss of read-only /usr permanent?

2016-05-13 Thread Chris Bennett
I think you are totally missing the point that Theo just made.
Marking partitions as read-only is useful, when and only when
appropriate.
I have:
/var/www/var
/home
/home/user1
/home/user2
/usr/local

all marked as read-only.
Why, because when the power fails, no data is lost and I'm quickly back
up with minimal fsck'ing.
When user1 or user2 logs in, There is a big message telling them to
mount their partition rw and right before logging out or shutting down,
to mark as ro.
When the lights start to flicker, Ctrl-Alt-Backspace slams you out of X
and ro alias slams that partition safe much faster than shutdown.
This has saved my ass twice now.

Backup your data and re-install that snapshot if you lose /usr, etc.
Works great for me. Many times.
You are backing up etc and root, right?
Chris



Re: Is loss of read-only /usr permanent?

2016-05-13 Thread Chris Cappuccio
RD Thrush [openbsd-t...@thrush.com] wrote:
> On 05/13/16 11:07, Theo de Raadt wrote:
> >> Since the anti-ROP mechanism in libc [2] was added in late April, -current 
> >> with read-only /usr produces something like the following message:
> >> re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file 
> >> system
> > 
> > Look, your statement is false.  I can install a snapshot right now,
> > and I won't see what you report.
> 
> The report is fairly easy to reproduce.  Make the /usr filesystem read-only 
> in /etc/fstab, go to single user mode and exit back to multi-user.  I've 
> appended a transcript.
> 
> > That is the result of a mis-configuration on your part.
> 
> It's unfortunate that mounting /usr read-only is now a mis-configuration.
> 

Robert, what do you suggest?

1. Say sorry, no mitigation because we want to support all possible
configurations

2. Say OK, and provide a work-around in /etc/rc that might (or might not)
work with your situation, and makes the overall situation more complicated
for everyone

3. Say sorry, the mitigation technique will not be changed. You are on your
own.

I think it comes down to this. If you want read-only /etc, you'll have to
modify /etc/rc, if you still want the mitigation.



Re: Is loss of read-only /usr permanent?

2016-05-13 Thread Edgar Pettijohn


Sent from my iPhone

> On May 13, 2016, at 4:16 PM, RD Thrush  wrote:
> 
> On 05/13/16 11:07, Theo de Raadt wrote:
>>> Since the anti-ROP mechanism in libc [2] was added in late April, -current 
>>> with read-only /usr produces something like the following message:
>>> re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file 
>>> system
>> 
>> Look, your statement is false.  I can install a snapshot right now,
>> and I won't see what you report.
> 
> The report is fairly easy to reproduce.  Make the /usr filesystem read-only 
> in /etc/fstab, go to single user mode and exit back to multi-user.  I've 
> appended a transcript.
> 
>> That is the result of a mis-configuration on your part.
> 
> It's unfortunate that mounting /usr read-only is now a mis-configuration.
> 
>>> I thought I was following best practice by mounting /usr,
>>> /usr/X11R6, and /usr/local read-only.  I submitted a bug report and a
>>> patch to fix my problem [2] but have had no response.
>> 
>> That is not best practice.  If it was, we would be heading towards
>> making it the default.
>> 
>> And why is not best practice? Because it stands directly against the
>> primary purpose of OpenBSD: A development platform, where people
>> constantly rebuild their binaries, iterating and fixing bugs.
>> 
>> What you are describing here is really just "you make a local change,
>> you own it".
> 
> # cp -p /etc/fstab /etc/fstab.orig
> # sed -e 's,/usr ffs rw,/usr ffs ro,' /etc/fstab
> # shutdown -f now
> Shutdown NOW!
> shutdown: [pid 82541]
> #
> ?*** FINAL System shutdown message from r...@obsd32.thrush.com ***?
> System going down IMMEDIATELY
> 
> 
> 
> System shutdown time has arrived
> Enter pathname of shell or RETURN for sh:
> # exit
> Fast boot: skipping disk checks.
> setting tty flags
> pfctl: pf already enabled
> machdep.allowaperture: 2 -> 2
> starting network
> DHCPREQUEST on vio0 to 255.255.255.255
> DHCPACK from 10.1.2.18 (14:da:e9:b5:84:cf)
> bound to 10.1.2.6 -- renewal in 302400 seconds.
> re-ordering libraries:install: /usr/lib/INS@73BiVBOVcW: Read-only file system
> done.
> starting early daemons: syslogd pflogd ntpd.
> starting RPC daemons:.
> savecore: no core dump
> checking quotas: done.
> clearing /tmp
> kern.securelevel: 0 -> 1
> creating runtime link editor directory cache.
> preserving editor files.
> starting network daemons: sshd smtpd sndiod.
> starting local daemons: cron.
> Fri May 13 16:30:55 EDT 2016
> 
> 
> ##
> OpenBSD 6.0-beta (GENERIC.MP) #1742: Fri May 13 08:52:53 MDT 2016
>dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> cpu0: Common 32-bit KVM processor ("GenuineIntel" 686-class) 3.41 GHz
> cpu0: 
> FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,x2APIC,HV
> real mem  = 2146844672 (2047MB)
> avail mem = 2093015040 (1996MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 06/23/99, BIOS32 rev. 0 @ 0xfd4be, SMBIOS rev. 2.8 @ 
> 0xf0cd0 (9 entries)
> bios0: vendor SeaBIOS version 
> "rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org" date 
> 04/01/2014
> bios0: QEMU Standard PC (i440FX + PIIX, 1996)
> acpi0 at bios0: rev 0
> acpi0: sleep states S3 S4 S5
> acpi0: tables DSDT FACP SSDT APIC HPET
> acpi0: wakeup devices
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 1000MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Common 32-bit KVM processor ("GenuineIntel" 686-class) 3.41 GHz
> cpu1: 
> FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,x2APIC,HV
> ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
> acpihpet0 at acpi0: 1 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpicpu0 at acpi0: C1(@1 halt!)
> acpicpu1 at acpi0: C1(@1 halt!)
> "ACPI0006" at acpi0 not configured
> "PNP0303" at acpi0 not configured
> "PNP0F13" at acpi0 not configured
> "PNP0700" at acpi0 not configured
> "PNP0501" at acpi0 not configured
> "PNP0A06" at acpi0 not configured
> "ACPI0007" at acpi0 not configured
> "ACPI0007" at acpi0 not configured
> bios0: ROM list: 0xc/0x9200 0xc9800/0xa00 0xca800/0x2400 0xed000/0x3000!
> pvbus0 at mainbus0: KVM
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
> pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
> pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 
> wired to compatibility, channel 1 wired to compatibility
> pciide0: channel 0 disabled (no drives)
> atapiscsi0 at pciide0 channel 1 drive 0
> scsibus1 at atapiscsi0: 2 targets
> cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom 
> removable
> cd0(pciide0:1:0): using PIO

Re: Is loss of read-only /usr permanent?

2016-05-13 Thread RD Thrush
On 05/13/16 11:07, Theo de Raadt wrote:
>> Since the anti-ROP mechanism in libc [2] was added in late April, -current 
>> with read-only /usr produces something like the following message:
>> re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file system
> 
> Look, your statement is false.  I can install a snapshot right now,
> and I won't see what you report.

The report is fairly easy to reproduce.  Make the /usr filesystem read-only in 
/etc/fstab, go to single user mode and exit back to multi-user.  I've appended 
a transcript.

> That is the result of a mis-configuration on your part.

It's unfortunate that mounting /usr read-only is now a mis-configuration.

>> I thought I was following best practice by mounting /usr,
>> /usr/X11R6, and /usr/local read-only.  I submitted a bug report and a
>> patch to fix my problem [2] but have had no response.
> 
> That is not best practice.  If it was, we would be heading towards
> making it the default.
> 
> And why is not best practice? Because it stands directly against the
> primary purpose of OpenBSD: A development platform, where people
> constantly rebuild their binaries, iterating and fixing bugs.
> 
> What you are describing here is really just "you make a local change,
> you own it".

# cp -p /etc/fstab /etc/fstab.orig
# sed -e 's,/usr ffs rw,/usr ffs ro,' /etc/fstab
# shutdown -f now
Shutdown NOW!
shutdown: [pid 82541]
#
?*** FINAL System shutdown message from r...@obsd32.thrush.com ***?
System going down IMMEDIATELY



System shutdown time has arrived
Enter pathname of shell or RETURN for sh:
# exit
Fast boot: skipping disk checks.
setting tty flags
pfctl: pf already enabled
machdep.allowaperture: 2 -> 2
starting network
DHCPREQUEST on vio0 to 255.255.255.255
DHCPACK from 10.1.2.18 (14:da:e9:b5:84:cf)
bound to 10.1.2.6 -- renewal in 302400 seconds.
re-ordering libraries:install: /usr/lib/INS@73BiVBOVcW: Read-only file system
 done.
starting early daemons: syslogd pflogd ntpd.
starting RPC daemons:.
savecore: no core dump
checking quotas: done.
clearing /tmp
kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
starting network daemons: sshd smtpd sndiod.
starting local daemons: cron.
Fri May 13 16:30:55 EDT 2016


##
OpenBSD 6.0-beta (GENERIC.MP) #1742: Fri May 13 08:52:53 MDT 2016
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Common 32-bit KVM processor ("GenuineIntel" 686-class) 3.41 GHz
cpu0: 
FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,x2APIC,HV
real mem  = 2146844672 (2047MB)
avail mem = 2093015040 (1996MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 06/23/99, BIOS32 rev. 0 @ 0xfd4be, SMBIOS rev. 2.8 @ 
0xf0cd0 (9 entries)
bios0: vendor SeaBIOS version 
"rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org" date 04/01/2014
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC HPET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 1000MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Common 32-bit KVM processor ("GenuineIntel" 686-class) 3.41 GHz
cpu1: 
FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,x2APIC,HV
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpihpet0 at acpi0: 1 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
"ACPI0006" at acpi0 not configured
"PNP0303" at acpi0 not configured
"PNP0F13" at acpi0 not configured
"PNP0700" at acpi0 not configured
"PNP0501" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
bios0: ROM list: 0xc/0x9200 0xc9800/0xa00 0xca800/0x2400 0xed000/0x3000!
pvbus0 at mainbus0: KVM
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 
wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11
piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0 int 9
iic0 at piixpm0
vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emula

Re: [patch] macppc.html 5.6 to 5.9

2016-05-13 Thread Theo Buehler
On Fri, May 13, 2016 at 02:06:36PM -0700, Bryan Vyhmeister wrote:
> This patch updates the boot command from 5.6 to 5.9.

fixed, thanks!



[patch] macppc.html 5.6 to 5.9

2016-05-13 Thread Bryan Vyhmeister
This patch updates the boot command from 5.6 to 5.9.

Bryan


Index: macppc.html
===
RCS file: /cvs/www/macppc.html,v
retrieving revision 1.248
diff -u -p -r1.248 macppc.html
--- macppc.html 8 Apr 2016 01:58:04 -   1.248
+++ macppc.html 13 May 2016 21:04:38 -
@@ -497,7 +497,7 @@ There are several installation media pro
   procedure.
   Alternatively, the CD can be booted at the Open Firmware prompt, with
 
-  boot cd:,ofwboot 5.6/macppc/bsd.rd
+  boot cd:,ofwboot 5.9/macppc/bsd.rd
 
   Mac OS based boot
   



opendev and pledge: "privsep" for dumpfs(8)

2016-05-13 Thread Theo Buehler
opendev(3) should not be called by pledged processes, so the pledge of
dumpfs(8) needs to be redone: opendev is called in a loop over argv.

As dumpfs spews a whole lot of potentially untrusted data to stdout,
fork, read the data in the child and pipe it to the pledged parent
that writes it to stdout. pledge the child before dumping the last fs.
Thus the common case of dumping a single fs runs almost entirely
under pledge.

The loop in printdata() is taken from raw_cat() in cat(1).

Index: sbin/dumpfs/dumpfs.c
===
RCS file: /var/cvs/src/sbin/dumpfs/dumpfs.c,v
retrieving revision 1.33
diff -u -p -r1.33 dumpfs.c
--- sbin/dumpfs/dumpfs.c23 Nov 2015 19:19:29 -  1.33
+++ sbin/dumpfs/dumpfs.c13 May 2016 20:40:08 -
@@ -40,6 +40,7 @@
 
 #include  /* DEV_BSIZE MAXBSIZE isset */
 #include 
+#include 
 
 #include 
 #include 
@@ -73,6 +74,7 @@ int   dumpcg(const char *, int, int);
 intmarshal(const char *);
 intopen_disk(const char *);
 void   pbits(void *, int);
+void   printdata(void);
 __dead voidusage(void);
 
 int
@@ -80,7 +82,9 @@ main(int argc, char *argv[])
 {
struct fstab *fs;
const char *name;
-   int ch, domarshal, eval, fd;
+   pid_t pid, wpid;
+   int p[2];
+   int ch, domarshal, eval, fd, pstat;
 
domarshal = eval = 0;
 
@@ -100,10 +104,34 @@ main(int argc, char *argv[])
if (argc < 1)
usage();
 
-   if (pledge("stdio rpath disklabel", NULL) == -1)
-   err(1, "pledge");
+   if (pipe(p) < 0)
+   err(1, "pipe");
 
-   for (; *argv != NULL; argv++) {
+   switch(pid = fork()) {
+   case -1:
+   err(1, "fork");
+
+   case 0:
+   close(p[0]);
+   dup2(p[1], STDOUT_FILENO);
+   close(p[1]);
+   break;  
+
+   default:
+   if (pledge("stdio", NULL) == -1)
+   err(1, "pledge");
+   close(p[1]);
+   dup2(p[0], STDIN_FILENO);
+   close(p[0]);
+   printdata();
+   do {
+   wpid = waitpid(pid, &pstat, 0);
+   } while (wpid == -1 && errno == EINTR);
+
+   return (wpid == -1 || WEXITSTATUS(pstat));
+   }
+
+   for (; *argv != NULL; argv++, argc--) {
if ((fs = getfsfile(*argv)) != NULL)
name = fs->fs_spec;
else
@@ -112,13 +140,19 @@ main(int argc, char *argv[])
eval |= 1;
continue;
}
+   if (argc == 1)
+   if (pledge("stdio", NULL) == -1)
+   err(1, "pledge");
if (domarshal)
eval |= marshal(name);
else
eval |= dumpfs(fd, name);
close(fd);
}
-   exit(eval);
+
+   if (fclose(stdout))
+   err(1, "fclose");
+   _exit(eval);
 }
 
 int
@@ -458,6 +492,24 @@ pbits(void *vp, int max)
printf("-%d", i);
}
printf("\n");
+}
+
+void
+printdata(void)
+{
+   int nr, nw, off;
+   char buf[1024];
+   
+   while ((nr = read(STDIN_FILENO, buf, sizeof(buf))) != -1 && nr != 0) {
+   for (off = 0; nr; nr -= nw, off += nw) {
+   if ((nw = write(STDOUT_FILENO, buf + off, nr)) == 0 ||
+   nw == -1)
+   err(1, "stdout");
+   }
+   }
+
+   if (nr < 0)
+   warn("read");
 }
 
 __dead void



Re: bioctl errx

2016-05-13 Thread Todd C. Miller
On Fri, 13 May 2016 15:00:22 -0400, "Ted Unangst" wrote:

> overzealous use of errx() hides useful information about the error.

OK millert@

 - todd



Re: bioctl errx

2016-05-13 Thread Sebastian Benoit
ok

Ted Unangst(t...@tedunangst.com) on 2016.05.13 15:00:22 -0400:
> overzealous use of errx() hides useful information about the error.
> 
> 
> Index: bioctl.c
> ===
> RCS file: /cvs/src/sbin/bioctl/bioctl.c,v
> retrieving revision 1.130
> diff -u -p -r1.130 bioctl.c
> --- bioctl.c  4 Feb 2016 08:31:26 -   1.130
> +++ bioctl.c  13 May 2016 18:59:36 -
> @@ -1299,7 +1299,7 @@ derive_key_pkcs(int rounds, u_int8_t *ke
>   } else {
>   if (readpassphrase(prompt, passphrase, sizeof(passphrase),
>   rpp_flag) == NULL)
> - errx(1, "unable to read passphrase");
> + err(1, "unable to read passphrase");
>   }
>  
>   if (verify && !password) {
> @@ -1307,7 +1307,7 @@ derive_key_pkcs(int rounds, u_int8_t *ke
>   if (readpassphrase("Re-type passphrase: ", verifybuf,
>   sizeof(verifybuf), rpp_flag) == NULL) {
>   explicit_bzero(passphrase, sizeof(passphrase));
> - errx(1, "unable to read passphrase");
> + err(1, "unable to read passphrase");
>   }
>   if ((strlen(passphrase) != strlen(verifybuf)) ||
>   (strcmp(passphrase, verifybuf) != 0)) {
> 

-- 



bioctl errx

2016-05-13 Thread Ted Unangst
overzealous use of errx() hides useful information about the error.


Index: bioctl.c
===
RCS file: /cvs/src/sbin/bioctl/bioctl.c,v
retrieving revision 1.130
diff -u -p -r1.130 bioctl.c
--- bioctl.c4 Feb 2016 08:31:26 -   1.130
+++ bioctl.c13 May 2016 18:59:36 -
@@ -1299,7 +1299,7 @@ derive_key_pkcs(int rounds, u_int8_t *ke
} else {
if (readpassphrase(prompt, passphrase, sizeof(passphrase),
rpp_flag) == NULL)
-   errx(1, "unable to read passphrase");
+   err(1, "unable to read passphrase");
}
 
if (verify && !password) {
@@ -1307,7 +1307,7 @@ derive_key_pkcs(int rounds, u_int8_t *ke
if (readpassphrase("Re-type passphrase: ", verifybuf,
sizeof(verifybuf), rpp_flag) == NULL) {
explicit_bzero(passphrase, sizeof(passphrase));
-   errx(1, "unable to read passphrase");
+   err(1, "unable to read passphrase");
}
if ((strlen(passphrase) != strlen(verifybuf)) ||
(strcmp(passphrase, verifybuf) != 0)) {



Re: 2016 customer Satisfaction Rating

2016-05-13 Thread Customer Care
View this email with images.

2016 CUSTOMER SERVICE REPORT RESULTS Call Today! 866-732-9800


WE IDENTIFY OUTSTANDING BUSINESSES

[IMAGE]


BISTRO AT THE OLD FORT INN IS BEING HONORED AS A WINNER OF THE 2016
SPECTRUM AWARD FOR SERVICE EXCELLENCE!


Congratulations are in order to you and your team at BISTRO AT THE OLD
FORT INN for winning the Spectrum Award and earning a 5 star rating!

Our mission is to support businesses that provide excellence in customer
satisfaction. We award and give voice to those exceptional companies.
Spectrum Award Winners are rated using our exclusive research and
proprietary algorithm. This allows us to provide independent ratings that
remove bias and uniquely recognize businesses providing exceptional
customer experiences.

View your 2016 Customer Satisfaction Rating online at
awards.citybeatnews.com

or

CLICK HERE

Cheers!

Frequently Asked Questions

-The City Beat News Team

[IMAGE]


[IMAGE]

SHARE the
GOOD NEWS

[IMAGE]

Start reaping the benefits of your elite, award-winning status. Refer
customers and leads to your Star Page, which provides you with the
third-party credibility you’ve earned and assures them that they are
making the right choice in you. Don't forget to share the good news on
your social media sites!

View your Star Page by clicking on the link below or copy and paste the
following URL into your 
browser:https://awards.citybeatnews.com/BISTRO-AT-THE-OLD-FORT-INN-YOUNGSTOWN-NY



UNDERSTANDING
 the SPECTRUM AWARD 

[IMAGE]

  * The  point: Your customers are highly satisfied.

  * An annual rating, not like a consumer review site

  * One easily understood rating number

  * Independently researched, unbiased report

  * Your dedication and hard word deserves recognition!




BENEFITS for AWARD WINNERS

[IMAGE]

  * Immediate third-party credibility

  * Improve Brand Recognition

  * Improve SEO

  * Reassure Customers

  * Empower Employees



ORDER YOUR AWARD MATERIALS TODAY!

[IMAGE]

When you need it most, awards can make the difference. Your team will
thank you for providing them with the tools they need to make your
business prosper.

CONTACT US TODAY AT 866-732-9800 TO LEARN MORE

WWW.CITYBEATNEWS.COM

[IMAGE][IMAGE][IMAGE]

[IMAGE]

About Us

Marketing Services

 The Stirling Alliance

About the Award

© City Beat News, Success Max, LLC, 121 W. Nepessing St., Lapeer, MI
48446
 T: 866.732.9800 | E: customerc...@citybeatnews.com

We intend to provide businesses with useful information in our emails. 
We hope you enjoy learning of your award status and how you can benefit
from it. However, if you do not wish to receive e-mail messages from City
Beat News, click unsubscribe.

Start reaping the benefits of your elite, award-winning status. Refer
customers and leads to your Star Page on our website, which provides you
with the third-party credibility you’ve earned and assures them that are
making the right choice in you. View your Star Page [insert URL here].

Start reaping the benefits of your elite, award-winning status. Refer
customers and leads to your Star Page on our website, which provides you
with the third-party credibility you’ve earned and assures them that are
making the right choice in you. View your Star Page [insert URL here].

· The Spectrum Award is to the point: your customers are highly
satisfied.

· An annual rating, not like a consumer review site

· One simple, easily understood rating number

· Independently researched, unbiased report

· The Spectrum Award is to the point: your customers are highly
satisfied.

· An annual rating, not like a consumer review site

· One simple, easily understood rating number

· Independently researched, unbiased report

· The Spectrum Award is to the point: your customers are highly
satisfied.

· An annual rating, not like a consumer review site

· One simple, easily understood rating number

· Independently researched, unbiased report

· The Spectrum Award is to the point: your customers are highly
satisfied.

· An annual rating, not like a consumer review site

· One simple, easily understood rating number

· Independently researched, unbiased report

· Immediate third-party credibility

· Improve Brand Recognition

· Improve SEO

· Reassure Customers

· Empower Employees


Re: Is loss of read-only /usr permanent?

2016-05-13 Thread Theo de Raadt
> Since the anti-ROP mechanism in libc [2] was added in late April, -current 
> with read-only /usr produces something like the following message:
> re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file system

Look, your statement is false.  I can install a snapshot right now,
and I won't see what you report.

That is the result of a mis-configuration on your part.

> I thought I was following best practice by mounting /usr,
> /usr/X11R6, and /usr/local read-only.  I submitted a bug report and a
> patch to fix my problem [2] but have had no response.

That is not best practice.  If it was, we would be heading towards
making it the default.

And why is not best practice? Because it stands directly against the
primary purpose of OpenBSD: A development platform, where people
constantly rebuild their binaries, iterating and fixing bugs.

What you are describing here is really just "you make a local change,
you own it".



Is loss of read-only /usr permanent?

2016-05-13 Thread RD Thrush
Since the anti-ROP mechanism in libc [2] was added in late April, -current with 
read-only /usr produces something like the following message:
re-ordering libraries:install: /usr/lib/INS@OPOjn7ck17: Read-only file system

I thought I was following best practice by mounting /usr, /usr/X11R6, and 
/usr/local read-only.  I submitted a bug report and a patch to fix my problem 
[2] but have had no response.

[1]
[2]



Re: remove kevent perm check

2016-05-13 Thread Luke Small
That seems a bit excessive to crash the program when all you may want to do
is track the exit of a child. Does the pledge proc flag dictate that you
can't do wait() as well?


Re: FW: Re: watchdog suport for new hardware

2016-05-13 Thread Chase Davis
Mark,

What does it mean if SEL0002 at acpi0 not configured does not show up
when you boot? I haven't tried it yet, but I don't expect that it will
print out this message.

Thanks,
Chase

On Wed, May 4, 2016 at 4:25 PM, Mark Kettenis  wrote:
>> Authentication-Results: xs4all.nl; spf=pass smtp.mailfrom=gmail.com;
>>   dkim=pass header.d=gmail.com; dmarc=pass header.from=gmail.com
>> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>> d=gmail.com; s=20120113;
>> h=mime-version:in-reply-to:references:date:message-id:subject:from:to
>>  :cc;
>> bh=qdzMoQT01IzyW8CUlpO8nUk6k9f+Av/f9v8+YsnWaOY=;
>> b=ZerIGs9e4TDbkdmaxMpZLKkdxGoeCbUZri928SVN1a/6gQ6mR8KXbkcZnPbjItj8dV
>>  Xuz20eyVF58v7gmyICDgk0vnF4QSC1jsSQd6LWl6+ONOSgFXZsg/l5RCt3JGx2E2JZPk
>>  mAgxtT8CFMk8itnXx4V+5IbTrWMZBDVhRwQLx7yZg6KGcZ4p7T8YJVsqo5/7KEgEOP4a
>>  t77aV1hx1PidQ6U+gRDHmUPMZU9bI8mPQNlF4+TRoZas+RNfakRX5EWMMSa3hDAskUM5
>>  ge2w3AVGJdXD8QdSBpd/3WiL33TvkJ+kUwyF4WoM0wiAxDrqu+mgn7jBvYcyNWH2ZcLN
>>  XO+A==
>> X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>> d=1e100.net; s=20130820;
>> h=x-gm-message-state:mime-version:in-reply-to:references:date
>>  :message-id:subject:from:to:cc;
>> bh=qdzMoQT01IzyW8CUlpO8nUk6k9f+Av/f9v8+YsnWaOY=;
>> b=N4PIuCym6oBi55KejCegHaHiQICh/Vs8GET7D+23bcH37bBVOIA9cQXiIMorpl/c+q
>>  we/J1kvLFFAiEH8Y8HDlKmDzK4iK2nLFNVRmr3DLytmBZ3aJ0ntsaVN6NgBaqadVO/Nm
>>  wAtnHgaCoXPfYpBmWmarVil14rJOPk9hFTtXONclAUSmvMrMz9ZplGKmhs4zMeZQJ6Iu
>>  b5DvZWta21Uo/Dxc3Bbs4ZRxjC5RNcIpQ856RRX1cvpNsCIQkJ4iWdfEUUXTp5y32AC4
>>  LRNVlzSJrP76/zSZWmz1vlG8ZzO68CWMpU48aOJYggM5nTFRqQvuDYMctP1x0XcOMPGZ
>>  Ti4Q==
>> X-Gm-Message-State: 
>> AOPr4FWjen4+Tr0Nl3aoO4eF8gbDP9sc8FqDtNTsrXsHl/7I+Zmd++0Vn4Kk+/9vPL+EuG9EA/DzTRMtx+nQEQ==
>> X-Received: by 10.129.161.19 with SMTP id y19mr6134393ywg.119.1462394399164;
>>  Wed, 04 May 2016 13:39:59 -0700 (PDT)
>> Date: Wed, 4 May 2016 15:39:59 -0500
>> From: Chase Davis 
>> Cc: Mike Larkin , tech@openbsd.org
>> X-XS4ALL-DNSBL-Checked: mxdrop307.xs4all.net checked 209.85.161.175 against 
>> DNS blacklists
>> X-CNFS-Analysis: v=2.2 cv=dJzko6Rb c=1 sm=0 tr=0
>>   a=eTW0FCcviAf4JPckMbNskg==:117 a=IkcTkHD0fZMA:10 a=yrkiwgmsf1kA:10
>>   a=pGLkceIS:8 a=0usQZD8xVr2ZoruZCogA:9
>> X-Virus-Scanned: by XS4ALL Virus Scanner
>> X-XS4ALL-Spam-Score: 0.0 () DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU,
>>   FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, SPF_PASS
>> X-XS4ALL-Spam: NO
>> Envelope-To: mark.kette...@xs4all.nl
>>
>> Makes perfect sense. Thanks for all the help. I will make sure that we
>> are using release. Is there any other reason you could think of why
>> match wouldn't work if SEL0002 shows up in the DSDT table?
>
> It wouldn't work on 5.9 release.  You need to be working in -current.
>
> Try booting an unmodified 5.9-current snapshot on the machine in
> question.  It should print a line like:
>
> "SEL0002" at acpi0 not configured
>
> As long as that line appears, your driver should attach when you add
> it to a -current source tree and build a new kernel.



-- 
Chase Davis