Document the sendsyslog2(2) system call

2016-02-18 Thread Rafael Neves
Hi,

The the inlined patch aims to document the new sendsyslog2 system call,
and add the corresponding MLINKS entry. Note that I do not put
"syslog(3) logopt LOG_CONS" or "syslog(3) LOG_CONS flag" because
actually in syslog(3) it says that it redirects to "/dev/console", so I
thought that could be misleading as sendsyslog2(2) does not open the
device, it is a direct channel.

Comments?


Regards,
Rafael Neves


Patch:

Index: lib/libc/sys/Makefile.inc
===
RCS file: /cvs/src/lib/libc/sys/Makefile.inc,v
retrieving revision 1.137
diff -u -p -r1.137 Makefile.inc
--- lib/libc/sys/Makefile.inc   25 Nov 2015 00:01:21 -  1.137
+++ lib/libc/sys/Makefile.inc   18 Feb 2016 21:31:31 -
@@ -224,6 +224,7 @@ MLINKS+=select.2 pselect.2
 MLINKS+=select.2 FD_ISSET.3 select.2 FD_ZERO.3
 MLINKS+=select.2 FD_SET.3 select.2 FD_CLR.3
 MLINKS+=send.2 sendmsg.2 send.2 sendto.2
+MLINKS+=sendsyslog.2 sendsyslog2.2
 MLINKS+=setpgid.2 setpgrp.2
 MLINKS+=setresuid.2 getresgid.2 setresuid.2 getresuid.2
 MLINKS+=setresuid.2 setresgid.2
Index: lib/libc/sys/sendsyslog.2
===
RCS file: /cvs/src/lib/libc/sys/sendsyslog.2,v
retrieving revision 1.4
diff -u -p -r1.4 sendsyslog.2
--- lib/libc/sys/sendsyslog.2   10 Sep 2015 17:55:21 -  1.4
+++ lib/libc/sys/sendsyslog.2   18 Feb 2016 21:31:31 -
@@ -18,19 +18,40 @@
 .Dt SENDSYSLOG 2
 .Os
 .Sh NAME
-.Nm sendsyslog
+.Nm sendsyslog ,
+.Nm sendsyslog2
 .Nd send a message to syslogd
 .Sh SYNOPSIS
+.In sys/syslog.h
 .In sys/types.h
 .Ft int
 .Fn sendsyslog "const void *msg" "size_t len"
+.Ft int
+.Fn sendsyslog2 "const void *msg" "size_t len" "int flags"
 .Sh DESCRIPTION
+.Pp
+The
 .Fn sendsyslog
-is used to transmit a
+and
+.Fn sendsyslog2
+functions are used to transmit a
 .Xr syslog 3
 formatted message direct to
 .Xr syslogd 8
 without requiring the allocation of a socket.
+.Pp
+The
+.Fa flags
+argument of
+.Fn sendsyslog2
+accepts the
+.Dv LOG_CONS
+flag. If 
+.Dv LOG_CONS
+is specified, and
+.Xr syslogd 8
+is not accepting messages, the message will be sent directly to the
+console.
 This is used internally by
 .Xr syslog_r 3 ,
 so that messages can be sent during difficult situations.
@@ -41,7 +62,9 @@ so that messages can be sent during diff
 can fail if:
 .Bl -tag -width Er
 .It Bq Er ENOTCONN
-The message cannot be sent, likely because
+The message cannot be sent to 
+.Xr syslogd(8) ,
+likely because
 .Xr syslogd 8
 is not running.
 .El
@@ -53,3 +76,7 @@ The
 .Fn sendsyslog
 function call appeared in
 .Ox 5.6 .
+The
+.Fn sendsyslog2
+function call appeared in
+.Ox 5.9 .



Re: Remove TMPDIR support from sendbug(1) and newfs(8) manpages

2016-02-18 Thread Jason McIntyre
On Thu, Feb 18, 2016 at 03:11:16PM -0700, Rafael Neves wrote:
> Hi,
> 
> The TMPDIR enviroment support was removed from sendbug(1) and newfs(8),
> but the manpages still document them. The inlined patches remove these
> leftovers.
> 
> Regards,
> Rafael Neves
> 

fixed, thanks.
jmc

> 
> Patch:
> 
> Index: sbin/newfs/newfs.8
> ===
> RCS file: /cvs/src/sbin/newfs/newfs.8,v
> retrieving revision 1.71
> diff -u -p -r1.71 newfs.8
> --- sbin/newfs/newfs.829 Aug 2014 12:09:04 -  1.71
> +++ sbin/newfs/newfs.818 Feb 2016 20:57:39 -
> @@ -301,14 +301,6 @@ If the
>  .Fl P Ar file
>  option is not used, the owner and mode of the created mfs file
>  system will be the same as the owner and mode of the mount point.
> -.Sh ENVIRONMENT
> -.Bl -tag -width TMPDIR
> -.It Ev TMPDIR
> -Directory in which to create temporary mount points for use by
> -.Nm mount_mfs Fl P
> -instead of
> -.Pa /tmp .
> -.El
>  .Sh SEE ALSO
>  .Xr disktab 5 ,
>  .Xr fs 5 ,
> Index: usr.bin/sendbug/sendbug.1
> ===
> RCS file: /cvs/src/usr.bin/sendbug/sendbug.1,v
> retrieving revision 1.26
> diff -u -p -r1.26 sendbug.1
> --- usr.bin/sendbug/sendbug.1 11 Oct 2015 21:23:15 -  1.26
> +++ usr.bin/sendbug/sendbug.1 18 Feb 2016 20:57:48 -
> @@ -103,10 +103,6 @@ the default is
>  Filename of PR form to use instead of using the built-in form.
>  Such a PR form can be partially pre-completed to make the
>  process faster.
> -.It Ev TMPDIR
> -Specifies a directory for temporary files to be created.
> -The default is
> -.Pa /tmp .
>  .El
>  .Sh FILES
>  .Bl -tag -width "/tmp/p.XX" -compact
> 



Remove TMPDIR support from sendbug(1) and newfs(8) manpages

2016-02-18 Thread Rafael Neves
Hi,

The TMPDIR enviroment support was removed from sendbug(1) and newfs(8),
but the manpages still document them. The inlined patches remove these
leftovers.

Regards,
Rafael Neves


Patch:

Index: sbin/newfs/newfs.8
===
RCS file: /cvs/src/sbin/newfs/newfs.8,v
retrieving revision 1.71
diff -u -p -r1.71 newfs.8
--- sbin/newfs/newfs.8  29 Aug 2014 12:09:04 -  1.71
+++ sbin/newfs/newfs.8  18 Feb 2016 20:57:39 -
@@ -301,14 +301,6 @@ If the
 .Fl P Ar file
 option is not used, the owner and mode of the created mfs file
 system will be the same as the owner and mode of the mount point.
-.Sh ENVIRONMENT
-.Bl -tag -width TMPDIR
-.It Ev TMPDIR
-Directory in which to create temporary mount points for use by
-.Nm mount_mfs Fl P
-instead of
-.Pa /tmp .
-.El
 .Sh SEE ALSO
 .Xr disktab 5 ,
 .Xr fs 5 ,
Index: usr.bin/sendbug/sendbug.1
===
RCS file: /cvs/src/usr.bin/sendbug/sendbug.1,v
retrieving revision 1.26
diff -u -p -r1.26 sendbug.1
--- usr.bin/sendbug/sendbug.1   11 Oct 2015 21:23:15 -  1.26
+++ usr.bin/sendbug/sendbug.1   18 Feb 2016 20:57:48 -
@@ -103,10 +103,6 @@ the default is
 Filename of PR form to use instead of using the built-in form.
 Such a PR form can be partially pre-completed to make the
 process faster.
-.It Ev TMPDIR
-Specifies a directory for temporary files to be created.
-The default is
-.Pa /tmp .
 .El
 .Sh FILES
 .Bl -tag -width "/tmp/p.XX" -compact



Re: undefined behaviour in add_entropy_words()

2016-02-18 Thread Stefan Kempf
Martin Natano wrote:
> Hi,
> 
> The add_entropy_words() function performs a right shift by
> (32 - entropy_input_rotate) bits, with entropy_input_rotate being an
> integer between [0..31]. This can lead to a shift of 32 on a 32 bit
> value, which is undefined behaviour in C. The standard says this: "If
> the value of the right operand is negative or is greater than or equal
> to the width of the promoted left operand, the behaviour is undefined."
> In our case the value is 32 and the width of the promoted left operand
> is 32 too, thus the behaviour is undefined.
> 
> As a matter of fact the expression doesn't yield the (probably) expected
> result of 0 on i386 and amd64 machines. The reason being, that the shift
> exponent is truncated to 5 bits on x86.
> 
> natano@obsd:~$ uname -a
> OpenBSD obsd.my.domain 5.9 GENERIC.MP#1862 amd64
> natano@obsd:~$ cat test.c
> #include 
> 
> int
> main(void)
> {
> unsigned int x = 0x;
> printf("x >> 32: 0x%x\n", x >> 32);
> return 0;
> }
> natano@obsd:~$ cc test.c
> test.c: In function 'main':
> test.c:7: warning: right shift count >= width of type
> natano@obsd:~$ ./a.out
> x >> 32: 0x
> natano@obsd:~$
> 
> On the other hand ppc truncates the shift exponent to 6 bits. (I didn't
> try it, but
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
> says so).
> 
> In the specific instance below, the differing behaviour between x86 and
> pcc doesn't matter, because of the equality (x | x) == (x | 0) == x.
> 
> However, I think it might be still worth fixing this, because we can't
> rely on future versions of gcc and other compilers retaining this
> behaviour. The behaviour is undefined, so the compiler can do whatever
> it wants (insert obligatory reference to nasal demons here).
 
I think we don't mix declarations and code.
Would this be an option?

diff --git a/dev/rnd.c b/dev/rnd.c
index 819ce0d..0f57b1b 100644
--- a/dev/rnd.c
+++ b/dev/rnd.c
@@ -421,7 +421,7 @@ add_entropy_words(const u_int32_t *buf, u_int n)
 
for (; n--; buf++) {
u_int32_t w = (*buf << entropy_input_rotate) |
-   (*buf >> (32 - entropy_input_rotate));
+   (*buf >> ((32 - entropy_input_rotate) & 31));
u_int i = entropy_add_ptr =
(entropy_add_ptr - 1) & POOLMASK;
/*
 
> Index: dev/rnd.c
> ===
> RCS file: /cvs/src/sys/dev/rnd.c,v
> retrieving revision 1.178
> diff -u -p -u -r1.178 rnd.c
> --- dev/rnd.c 8 Jan 2016 07:54:02 -   1.178
> +++ dev/rnd.c 31 Jan 2016 10:11:17 -
> @@ -420,8 +420,9 @@ add_entropy_words(const u_int32_t *buf, 
>   };
>  
>   for (; n--; buf++) {
> - u_int32_t w = (*buf << entropy_input_rotate) |
> - (*buf >> (32 - entropy_input_rotate));
> + u_int32_t w = *buf << entropy_input_rotate;
> + if (entropy_input_rotate > 0)
> + w |= *buf >> (32 - entropy_input_rotate);
>   u_int i = entropy_add_ptr =
>   (entropy_add_ptr - 1) & POOLMASK;
>   /*
> 
> cheers,
> natano
> 



Re: Harmful casts in ufs

2016-02-18 Thread Stefan Kempf
Todd C. Miller wrote:
> On Wed, 17 Feb 2016 10:22:04 +0100, Martin Natano wrote:
> 
> > Casting the result of ext2fs_size() and DIP(ip, size) to int potentially
> > truncates the result. Issue found by Stefan Kempf, see
> > https://marc.info/?l=openbsd-tech&m=145495905416536 .
> > 
> > While there I also removed the cast in the ext2fs_chmod() call, because
> > the function expects a mode_t argument anyway.
> 
> There is currently code that checks for mnt_maxsymlinklen <= 0.
> Removing the cast will cause other problems for ffs if the maxsymlinklen
> value is negative.  I don't think it is safe to make this change
> unless mnt_maxsymlinklen is made unsigned in struct mount and a
> check is added to the assignment of mnt_maxsymlinklen from
> fs_maxsymlinklen in ufs/ffs/ffs_vfsops.c to avoid assigning a
> negative value.

That makes sense. Those <= 0 checks look whether the FFS is in the
"old" format. When creating an old format FFS, newfs creates a superblock
with fs_maxsymlinklen of 0. A negative fs_maxsymlinklen should never
happen except for bogus superblocks. So checking for this when mounting
the filesystem looks reasonable.

>  - todd
> 



Re: [patch] Fix carp(4) with balancing ip / ip-stealth

2016-02-18 Thread Florian Riehm
On 02/16/16 11:23, Martin Pieuchot wrote:
> On 12/02/16(Fri) 16:33, Florian Riehm wrote:
>> Hi Tech,
>>
>> I have noticed that CARP IP-Balancing is broken, so I am testing and
>> fixing it.
>>
>> The first problem came in with this commit:
>> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/if_ethersubr.c.diff?r1=1.176&r2=1.177
>> It enforces that outgoing packets use the src mac of the carp interface 
>> instead
>> the mac of its carpdev. That's a good idea for failover carp but it breaks
>> balancing ip(-stealth), because the same source MAC is seen by multiple
>> switchports now. That leads to continues MAC flapping at switches.
>> My attached patch fixes the problem. Thanks Martin's refactoring, we can
>> enforce the right MAC on a central place in carp_start() now.
> 
> Can't you completely get rid of the else chunk then?  It looks like a
> bad refactoring.

I was also thinking about deleting the else chunk. At the end I decided to keep
it, because I wasn't sure about its purpose.
My intention was:
Fix the more or less obviously broken balancing case and don't change the
behavior of other CARP modes.
I will remove the else chunk and do some more testing to determine if it's
really unnecessary.

> I'm also wondering can't we use "sc_realmac" here?

I have not know "sc_realmac" until now. As far as I understand the intention of
the sc_realmac flag is, to indicate that the user has overwritten the mac
address of the carp interface with the mac of its parent. I have never had a
use case to do this. Without overwriting the mac by hand sc_realmac is 0 for
carp with balancing ip/ip-stealth AND carp without balancing.

I don't see how sc_realmac could help us by this problem?!
Can you give me a hint please?

> 
>> A second problem was introduced two weeks ago. Since we always check the
>> destination MAC address of received unicast packets, not only when in
>> promiscuous mode, carp balancing ip is always broken, not only when in
>> promiscuous mode. The new check collides with "Clear mcast if received on a
>> carp IP balanced address." in carp_input().
> 
> Could you describe the problem?  Which Destination MAC the packet
> contains and why it doesn't match the interface?  I still don't grok why
> a carp(4) interface in balancing mode cannot have the right MAC
> configured...  Do you know?  But if what you want is the parent's MAC,
> then I'd rather go with the symmetric of your other change:  modify
> carp_input() to overwrite ``ether_dhost''.

If using carp balancing, incoming packets contain the destination mac address
of the carp interface, let's say: 01:00:5e:00:01:01.
The MCAST-Bit is set here!

carp_input() removes the MCAST-Bit:
/*
 * Clear mcast if received on a carp IP balanced address.
 */
if (sc->sc_balancing == CARP_BAL_IP &&
ETHER_IS_MULTICAST(eh->ether_dhost))
*(eh->ether_dhost) &= ~0x01;

Then we run into ether_input() and 
memcmp(ac->ac_enaddr, eh->ether_dhost, ETHER_ADDR_LEN)
evaluates to false because 
ac->ac_enaddr (01:00:5e:00:01:01) != eh->ether_dhost (00:00:5e:00:01:01)




Re: Fix overflow check in sys/netinet6/in6.c

2016-02-18 Thread Martin Pieuchot
On 17/02/16(Wed) 20:38, Stefan Kempf wrote:
> Martin Pieuchot wrote:
> > On 13/02/16(Sat) 18:51, Stefan Kempf wrote:
> > > Some thoughts about this:
> > > 
> > > If this particular type of undefined behavior is really a concern: maybe
> > > looking for bounds/overflow checks that are incorrect besides undefined
> > > behavior first is a better approach. A good way of fixing those will
> > > be found, which could then be applied to the "just undefined behavior"
> > > cases.
> > > 
> > > Details below.
> > > 
> > > Michael McConville wrote:
> > > > time_second is a time_t, which we define as int64_t. The other operands
> > > > used are of type uint32_t. Therefore, these checks get promoted to
> > > > int64_t and the overflow being tested is undefined because it uses
> > > > signed arithmetic.
> > > > 
> > > > I think that the below diff fixes the overflow check. However, I'm
> > > > pretty tired at the moment and this is hard to do right, so review is
> > > > appreciated.
> > >  
> > > If you know that lt->ia6t_[pv]time will stay an uint32_t forever,
> > > then isn't checking for (time_second > INT64_MAX - lt->ia6t_vltime)
> > > enough? The right side of the comparison will always be > 0 then.
> > > If we somehow had time_second < 0, then your sanity check would still
> > > work without checking for time_second > 0.
> > > Don't think we ever have time_second < 0 though, since it's the
> > > seconds since the Epoch.
> > 
> > Does your reasoning also apply to time_uptime?  Because it might make
> > sense to first convert this code to use time_uptime first to avoid leaps
> > that might be triggered by clock_settime(2) or settimeofday(2) for example.
> 
> I think it holds. time_uptime and time_second are both updated in
> tc_windup(), and as far as I can tell after a quick read of
> the code, time_uptime is only added to, as is reasonable to expect :-)
> 
> > Such work as been done in NetBSD as far as I know.
> 
> The netinet/in6.c of NetBSD uses time_uptime. Some other things I noted
> while looking at NetBSD below. Can't judge how these findings
> apply to our tree though.
> 
> But mentioning lifetimes and expire times, your time_yptime suggestion
> sounds reasonable to me in this context.
> 
> It looks like NetBSD removed the SIOCSIFALIFETIME_IN6 ioctl a long time
> ago, along with the overflow checks, saying that this ioctl could never
> have worked:
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/netinet6/in6.c?rev=1.132&content-type=text/x-cvsweb-markup&only_with_tag=MAIN

Indeed we should remove it as well.



Re: faq11 typo

2016-02-18 Thread Theo Buehler
On Thu, Feb 18, 2016 at 01:14:03PM +0100, Jan Stary wrote:
> --- faq11.html.orig   Thu Feb 18 11:11:41 2016
> +++ faq11.htmlThu Feb 18 11:12:14 2016
> @@ -97,7 +97,7 @@ Some X applications are very lean; others will seeming
>  all the processor and RAM you can give them.
>  Of course, some users just like to use X to provide a large number of
>  http://www.openbsd.org/cgi-bin/man.cgi?query=xterm";>xterm(1)
> -windowss, which can be done on very modest hardware.
> +windows, which can be done on very modest hardware.
>  
>  11.1.2 - Can I have any kind of graphics without X?

committed, thanks



faq11 typo

2016-02-18 Thread Jan Stary
--- faq11.html.orig Thu Feb 18 11:11:41 2016
+++ faq11.html  Thu Feb 18 11:12:14 2016
@@ -97,7 +97,7 @@ Some X applications are very lean; others will seeming
 all the processor and RAM you can give them.
 Of course, some users just like to use X to provide a large number of
 http://www.openbsd.org/cgi-bin/man.cgi?query=xterm";>xterm(1)
-windowss, which can be done on very modest hardware.
+windows, which can be done on very modest hardware.
 
 11.1.2 - Can I have any kind of graphics without X?
 



Re: LPRng removed, how can I get a copy of last port before removal?

2016-02-18 Thread Stuart Henderson
On 2016/02/17 22:30, Chris Bennett wrote:
> Last version from author was 3.8.35 done at end of 2010.
> Appears that many useful features are present, many other problems like
> Kerberos need removal.
> Author said that IPP would start at 4.x.x versions, which have never
> been done.
> Is using Artistic license.
> 
> Has SSL support, which would need to be updated, by someone else. I'm a
> USA citizen.
> 
> Documentation is moderately OK, but poorly organized and has a lot of
> sections which show some examples: "I haven't used but you can see what
> you get out of it."
> 
> Fixing all the problems and then trying to get IPP support going might
> be a good answer to lpd problems.
> 
> Chris Bennett
> 

cvs get -P -D 2013/03/17 ports/sysutils/LPRng

*however*...

1) if you read the commit log to the ports Makefile, there have been
a number of security problems over the time it was in ports. Have a look
at upstream commits: have they done anything to improve things?
Commit logs with mention of problems found by static analyzers/fuzzing
tools/etc would be a good sign.

2) there have been no substantial changes to the port since 2003 or so.
It is rarely a good idea to base things on such an old port, there have
been many changes in ports infrastructure since then - it's usually
better to start from a recent Makefile.template and work from there
as a new port, possibly referencing the old one if you get stuck.
But think carefully about 1) first though.



/usr/X11/README typo

2016-02-18 Thread Jan Stary
THere seems to be a typo in macppc's /usr/X11/README

Jan


--- README.orig Thu Feb 18 11:14:56 2016
+++ README  Thu Feb 18 11:15:25 2016
@@ -12,7 +12,7 @@ hardware.  If your hardware is not properly autodetect
 or not supported as you wish, you will have to create a configuration
 file.
 
-The 'r128 and 'ati' drivers are currently known to work on the
+The 'r128' and 'ati' drivers are currently known to work on the
 machines with ATI Rage 128 or Radeon cards. The 'nv' driver works for
 machines with nVidia cards, although some modes may experience
 problems.



Re: Optimize pledge-related notes in 59.html

2016-02-18 Thread Alexey Suslikov
Theo de Raadt  openbsd.org> writes:

> so thanks for your suggestion.  have you ever noticed how suggestions
> are taken less seriously when they are not formatted as a diff?

--- 59.html.origThu Feb 18 11:45:24 2016
+++ 59.html Thu Feb 18 12:03:29 2016
@@ -100,21 +100,21 @@
 http://www.openbsd.org/cgi-bin/man.cgi?
query=dhclient&sektion=8">dhclient(8) no longer exits if a desired 
route cannot be added. It now just reports the fact.
 http://www.openbsd.org/cgi-bin/man.cgi?
query=dhclient&sektion=8">dhclient(8) now takes a much more careful 
approach to received packets to ensure only received data is used to process 
the packet. Packets with incorrect length information or lacking appropriate 
header information are now dropped.
 http://www.openbsd.org/cgi-bin/man.cgi?
query=dhclient&sektion=8">dhclient(8) again disables pending 
timeouts if the interface link is lost, preventing endless retries at 
obtaining a lease.
-http://www.openbsd.org/cgi-bin/man.cgi?
query=dhclient&sektion=8">dhclient(8) was pledged.
 http://www.openbsd.org/cgi-bin/man.cgi?
query=dhcpd&sektion=8">dhcpd(8) again properly utilizes default-
lease-time, max-lease-time and bootp-lease-time options.
-http://www.openbsd.org/cgi-bin/man.cgi?
query=dhcpd&sektion=8">dhcpd(8) was pledged.
 ...
 
 
 
 Security improvements:
 
-...
+http://www.openbsd.org/cgi-bin/man.cgi/?
query=pledge">pledge(2), a new subsystem for restricting operations in 
programs, was added.
+More than 200 daemons and programs was pledged, among them: http://www.openbsd.org/cgi-bin/man.cgi?
query=dhclient&sektion=8">dhclient(8), http://www.openbsd.org/cgi-bin/man.cgi?
query=dhcpd&sektion=8">dhcpd(8), http://www.openbsd.org/cgi-
bin/man.cgi?query=fdisk&sektion=8">fdisk(8), http://www.openbsd.org/cgi-bin/man.cgi/?
query=pdisk§ion=8&arch=macppc">pdisk(8).
 Support for looking up hosts via YP has been removed from libc.
   The 'yp' lookup method in
   http://www.openbsd.org/cgi-bin/man.cgi?
query=resolv.conf&sektion=5">resolv.conf
   is no longer available.
 Support for the HOSTALIASES environment variable has been removed 
from libc.
+   ...
 
 
 
@@ -123,7 +123,7 @@
 doas is a little friendlier to use
 Updated flex
 Updated and improved less
-http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man8/macppc/pdisk.8?query=pdisk">pdisk(8) was largely rewritten 
and pledged.
+http://www.openbsd.org/cgi-bin/man.cgi/?
query=pdisk§ion=8&arch=macppc">pdisk(8) was largely rewritten.
 Renaming files in the root directory of a MSDOS filesystem was 
fixed.
 Many obsolete http://www.openbsd.org/cgi-
bin/man.cgi/OpenBSD-current/man5/disktab.5?query=disktab">disktab(5) 
attributes and entries were removed.
 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man4/softraid.4?query=softraid">softraid(4) volumes now 
correctly look for the disklabel in the first OpenBSD disk partition, not 
the last.
@@ -132,7 +132,6 @@
 http://www.openbsd.org/cgi-bin/man.cgi?
query=fdisk&sektion=8">fdisk(8) now has a '-b' flag that specifies 
the size of the EFI System partition to create.
 http://www.openbsd.org/cgi-bin/man.cgi?
query=fdisk&sektion=8">fdisk(8) now has a '-v' flag that causes a 
verbose display of both MBR and GPT information.
 http://www.openbsd.org/cgi-bin/man.cgi?
query=fdisk&sektion=8">fdisk(8) now provides full interactive GPT 
editing.
-http://www.openbsd.org/cgi-bin/man.cgi?
query=fdisk&sektion=8">fdisk(8) was pledged.
 Disks with sector sizes other than 512 bytes can now be partitioned 
with a GPT.
 The GPT kernel option was removed and GPT support is part of all 
GENERIC and GENERIC derived kernels.
 Many improvements were made to the GPT kernel support to ensure 
safe and reliable operation of GPT and MBR processing.