Re: signify xr sysupgrade.8

[Claudio Jeker]

On Fri, Apr 26, 2019 at 02:49:57PM -0600, Theo de Raadt wrote:
> Ted Unangst  wrote:
> 
> > Simplify examples section. The magic recipe is contained in sysupgrade, so 
> > we
> > can omit it, and instead add a .xr to sysupgrade.8.
> > 
> > 
> > Index: signify.1
> > ===
> > RCS file: /home/cvs/src/usr.bin/signify/signify.1,v
> > retrieving revision 1.46
> > diff -u -p -r1.46 signify.1
> > --- signify.1   23 Mar 2019 07:10:06 -  1.46
> > +++ signify.1   26 Apr 2019 20:32:24 -
> > @@ -166,18 +166,6 @@ Sign a file, specifying a signature name
> >  Verify a signature, using the default signature name:
> >  .Dl $ signify -V -p key.pub -m generalsorders.txt
> >  .Pp
> > -Verify a release directory containing
> > -.Pa SHA256.sig
> > -and a full set of release files:
> > -.Bd -literal -offset indent -compact
> > -$ signify -C -p /etc/signify/openbsd-66-base.pub -x SHA256.sig
> > -.Ed
> > -.Pp
> > -Verify a bsd.rd before an upgrade:
> > -.Bd -literal -offset indent -compact
> > -$ signify -C -p /etc/signify/openbsd-66-base.pub -x SHA256.sig bsd.rd
> > -.Ed
> > -.Pp
> >  Sign a gzip archive:
> >  .Bd -literal -offset indent -compact
> >  $ signify -Sz -s key-arc.sec -m in.tgz -x out.tgz
> 
> Please do not delete those chunks.
> 
> I use them every 6 months to verify I have constructed correct release
> directories.
> 
> I am not going to read the internals of sysupgrade to determine this.  I
> am not going to use sysupgrade to verify my release directories are
> correct, since they directories are not yet flowing to mirrors and
> are hiding on some darknet.
> 
> I know this recipe is in this manual page, so I use it.
> 
> Removing it and saying "Oh some code somewhere does it", is irresponsible,
> it forces peoplt to use just that specific chunk of code.  Now everyone
> has to use sysupgrade?  What if someone wants to do it manually?  Oh I get
> it, they'll skip the verification step.
> 

I concur, I find this examples very helpful

-- 
:wq Claudio

Re: signify xr sysupgrade.8

[Theo de Raadt]

Ted Unangst  wrote:

> Simplify examples section. The magic recipe is contained in sysupgrade, so we
> can omit it, and instead add a .xr to sysupgrade.8.
> 
> 
> Index: signify.1
> ===
> RCS file: /home/cvs/src/usr.bin/signify/signify.1,v
> retrieving revision 1.46
> diff -u -p -r1.46 signify.1
> --- signify.1 23 Mar 2019 07:10:06 -  1.46
> +++ signify.1 26 Apr 2019 20:32:24 -
> @@ -166,18 +166,6 @@ Sign a file, specifying a signature name
>  Verify a signature, using the default signature name:
>  .Dl $ signify -V -p key.pub -m generalsorders.txt
>  .Pp
> -Verify a release directory containing
> -.Pa SHA256.sig
> -and a full set of release files:
> -.Bd -literal -offset indent -compact
> -$ signify -C -p /etc/signify/openbsd-66-base.pub -x SHA256.sig
> -.Ed
> -.Pp
> -Verify a bsd.rd before an upgrade:
> -.Bd -literal -offset indent -compact
> -$ signify -C -p /etc/signify/openbsd-66-base.pub -x SHA256.sig bsd.rd
> -.Ed
> -.Pp
>  Sign a gzip archive:
>  .Bd -literal -offset indent -compact
>  $ signify -Sz -s key-arc.sec -m in.tgz -x out.tgz

Please do not delete those chunks.

I use them every 6 months to verify I have constructed correct release
directories.

I am not going to read the internals of sysupgrade to determine this.  I
am not going to use sysupgrade to verify my release directories are
correct, since they directories are not yet flowing to mirrors and
are hiding on some darknet.

I know this recipe is in this manual page, so I use it.

Removing it and saying "Oh some code somewhere does it", is irresponsible,
it forces peoplt to use just that specific chunk of code.  Now everyone
has to use sysupgrade?  What if someone wants to do it manually?  Oh I get
it, they'll skip the verification step.

signify xr sysupgrade.8

[Ted Unangst]

Simplify examples section. The magic recipe is contained in sysupgrade, so we
can omit it, and instead add a .xr to sysupgrade.8.


Index: signify.1
===
RCS file: /home/cvs/src/usr.bin/signify/signify.1,v
retrieving revision 1.46
diff -u -p -r1.46 signify.1
--- signify.1   23 Mar 2019 07:10:06 -  1.46
+++ signify.1   26 Apr 2019 20:32:24 -
@@ -166,18 +166,6 @@ Sign a file, specifying a signature name
 Verify a signature, using the default signature name:
 .Dl $ signify -V -p key.pub -m generalsorders.txt
 .Pp
-Verify a release directory containing
-.Pa SHA256.sig
-and a full set of release files:
-.Bd -literal -offset indent -compact
-$ signify -C -p /etc/signify/openbsd-66-base.pub -x SHA256.sig
-.Ed
-.Pp
-Verify a bsd.rd before an upgrade:
-.Bd -literal -offset indent -compact
-$ signify -C -p /etc/signify/openbsd-66-base.pub -x SHA256.sig bsd.rd
-.Ed
-.Pp
 Sign a gzip archive:
 .Bd -literal -offset indent -compact
 $ signify -Sz -s key-arc.sec -m in.tgz -x out.tgz
@@ -191,7 +179,8 @@ $ ftp url | signify -Vz -t arc | tar ztf
 .Xr fw_update 1 ,
 .Xr gzip 1 ,
 .Xr pkg_add 1 ,
-.Xr sha256 1
+.Xr sha256 1 ,
+.Xr sysupgrade 8
 .Sh HISTORY
 The
 .Nm

Re: OpenBSD 6.5 released -- Apr 24 2019

[Landry Breuil]

On Fri, Apr 26, 2019 at 07:48:26PM +0100, Andrew Grillet wrote:
> Install was very quick on my Sun V100. Congratulations to all involved.
> 
> Any news on if/when there will be packages for Sparc64?

When they're done, still at least 3 weeks.

Re: OpenBSD 6.5 released -- Apr 24 2019

[Andrew Grillet]

Install was very quick on my Sun V100. Congratulations to all involved.

Any news on if/when there will be packages for Sparc64?

On Wed, 24 Apr 2019 at 14:46, Theo de Raadt  wrote:

> OpenBSD 6.5 builds finished a week early, so the May 1 dated code can
> go out the door 1 week early.
>
> 
> - OpenBSD 6.5 RELEASED -
>
> May 1, 2019.
>
> We are pleased to announce the official release of OpenBSD 6.5.
> This is our 46th release.  We remain proud of OpenBSD's record of more
> than twenty years with only two remote holes in the default install.
>
> As in our previous releases, 6.5 provides significant improvements,
> including new features, in nearly all areas of the system:
>
>  - Improved hardware support, including:
> o clang(1) is now provided on mips64.
> o The default linker has been switched from the binutils bfd-based
>   linker to lld on amd64 and i386.
> o octeon: Now the system automatically detects the number of
>   available cores. However, manual setting of the numcores, or
>   coremask, boot parameter is still needed to enable secondary
>   cores.
> o octeon: It is now possible to use the root disk's DUID as the
>   value of the rootdev boot parameter.
> o New octgpio(4) driver for the OCTEON GPIO controller.
> o New pvclock(4) driver for KVM paravirtual clock.
> o New ixl(4) driver for Intel Ethernet 700 series controller
>   devices.
> o New abcrtc(4) driver for Abracon AB1805 real-time clock.
> o New imxsrc(4) driver for i.MX system reset controller.
> o New uxrcom(4) driver for Exar XR21V1410 USB serial adapters.
> o New mvgicp(4) driver for Marvell ARMADA 7K/8K GICP controller.
> o Support for QCA AR816x/AR817x in alc(4).
> o Support for isochronous transfers in xhci(4).
> o uaudio(4) has been replaced by a new driver which supports USB
>   audio class v2.0.
> o Improved support for nmea(4) devices, providing altitude and
>   ground speed values as sensors.
>
>  - IEEE 802.11 wireless stack improvements:
> o Reduced usage of RTS frames improves overall throughput and
>   latency.
> o Improved transmit rate selection in the iwm(4) driver.
> o Improved radio hardware calibration in the athn(4) driver.
> o The bwfm(4) driver now provides more accurate device configuration
>   information to userland.
> o Added new routing socket message RTM_80211INFO to provide details
>   of 802.11 interface state changes to dhclient(8) and route(8).
> o If an auto-join list is configured, wireless interfaces will no
>   longer connect to unknown open networks by default. This behaviour
>   must now be explicitly enabled by adding the empty network name to
>   the auto-join list, e.g. ifconfig iwm0 join "", or join "" in
>   hostname.if files.
> o The iwn(4) and iwm(4) drivers will now automatically try to
>   connect to a network if the radio kill switch is toggled to allow
>   radio transmissions while the interface is marked UP.
>
>  - Generic network stack improvements:
> o New bpe(4) Backbone Provider Edge pseudo-device.
> o New mpip(4) MPLS IP layer 2 pseudowire driver.
> o MPLS encapsulation interfaces support configuration of alternative
>   MPLS route domains.
> o The vlan(4) driver bypasses queue processing and outputs directly
>   to the parent interface.
> o New per SAD counters visible via ipsecctl(8).
> o The bpf(4) filter drop mechanism has been extended to allow
>   dropping without capturing packets, and use of the mechanism with
>   tcpdump(8) as a filtering mechanism early in the device receive
>   path.
> o ifconfig(8) gains txprio for controlling the encoding of priority
>   in tunnel headers, and support in drivers including vlan(4),
>   gre(4), gif(4), and etherip(4).
>
>  - Installer improvements:
> o rdsetroot(8) (a build-time tool) is now available for general use.
> o During upgrades, some components of old releases are deleted.
>
>  - Security improvements:
> o unveil(2) has been improved to understand and find covering unveil
>   matches above the working directory of the running process for
>   relative path accesses. As a result many programs now can use
>   unveil in broad ways such as unveil("/", "r").
> o unveil(2) no longer silently allows stat(2) and access(2) to work
>   on any unveiled path component.
> o Now using unveil(2) in ospfd(8), ospf6d(8), rebound(8),
>   getconf(1), kvm_mkdb(8), bdftopcf(1), Xserver(1), passwd(1),
>   spamlogd(8), spamd(8), sensorsd(8), snmpd(8), htpasswd(1),
>   ifstated(8). Some pledge(2) changes were required to accommodate
>   unveil.
> o ROP mitigations in clang(1) have been improved, resulting in a
>   significant decrease in the number of polymorphic 

Re: new USB audio class v2.0 driver

[Alexandre Ratchov]

On Thu, Apr 25, 2019 at 02:49:35AM -0700, alexh wrote:
> Hi,
> 
> 
> Alexandre Ratchov-2 wrote
> > If you have an audio device that is class compliant (aka vendor claims 
> > it's "driverless" on MacOS) *and* one of the above host/hub/device 
> > combinations then I'd be very interested in test reports. Especially 
> > I'd like to know about possible regressions. 
> 
> I tested with a Focusrite Scarlett 2i4 which should be a class compliant
> v2.0 device, but I get "only one AC iface allowed".
> 
> Here is my dmesg:
> 

Could you install the sysutils/usbutils package and send me the output
of "lsusb -vv" please?

Thanks.

Re: route(4) manual and sockaddrs; ROUNDUP()

[Claudio Jeker]

On Fri, Apr 26, 2019 at 01:55:52PM +0300, Vadim Penzin wrote:
> Greetings,
> 
> 
> 1. The manual of route(4) explains the structure of its messages thus:
> 
> `Messages are formed by a header followed by a small number of
> sockaddr structures (which are variable length), interpreted by
> position, and delimited by the length entry in the sockaddr.'
> 
> (That phrase is quite unfortunate in itself: `sa_len' is supposed to
> /determine/ the length of a structure.  To me, the word `delimited'
> implies the presence of a memory object between two adjacent
> structures, which certainly was not the intent of the author.)

Yes this is not quite right since the lenght is rounded to the next long
word to ensure that structures are properly aligned on strict align
architectures.
 
> Armed with that knowledge, I wrote a parser the other day.  I very
> much enjoyed OpenBSD until my program fatally stumbled on a peculiar
> structure that does not fit the above description:
> 
> 05 00 00 00 ff 00 00 00
> 
> (The value of `sa_len' of that `sockaddr' is nothing that I am
> familiar with, the address family is `AF_UNSPEC', and the most
> disturbing: `sa_len' does not match the physical size of this
> structure. These eight bytes were immediately followed by a perfectly
> valid `sockaddr_in'.)

This is a probably a netmask which are special in many senses from the old
time of the radix routing tree. For AF_UNSPEC it defines how many bytes
are used to store the netmask. It is wierd I agree.
 
> It took me some time to figure out that, apparently, I am looking at
> the combined effect of in_socktrim() (see src/sys/netinet/in.c) and
> ROUNDUP() (see src/sys/net/rtsock.c) applied to the netmask of
> 0xff00 that was stored as sockaddr_in'.
> 
> I believe that manuals should be more merciful.  In the absence of
> proper documentation, the part of my program that handles this case looks
> like a mysterious ritual; it should not be that way.
 
Please send suggestions to better documentation to this list.
route(4) is not perfect for sure and could use some work.
 
> 2. The definition of ROUNDUP() somewhat surprised me: it silently handles
> zero. The macro is local to the compilation unit; it is used
> this way:
> 
> if (rtinfo == NULL || (sa = rtinfo->rti_info[i]) == NULL)
>   continue;
>   rtinfo->rti_addrs |= (1 << i);
>   dlen = ROUNDUP(sa->sa_len);
> 
> and this way:
> 
>   if ((sa = rtinfo->rti_info[i]) == NULL)
> continue;
>   rtinfo->rti_addrs |= (1 << i);
>   dlen = ROUNDUP(sa->sa_len);

What code are you talking about?
 
> (In the second case, the programmer does not check `rtinfo' for being
> NULL.  I only hope that there exists a good explanation to that.)
> 
> Since `sa_len' describes the size of a `sockaddr' (or one of its
> derivatives) /including/ `sa_len' (maybe I am wrong, but this is my
> interpretation of the comment `total length' that appears near the
> definition of `struct sockaddr' in ), `sa_len' just
> cannot be zero.

Yes, it can not be zero.
 
> The current definition of ROUNDUP() might hide a bug.  In addition, on
> some machines, it disturbs the pipeline of the CPU by introducing a
> branch (for no real reason, as it seems, while I might be
> nitpicking). At very least, it looks confusing.


-- 
:wq Claudio

Re: new USB audio class v2.0 driver

[alexh]

Hi,


Alexandre Ratchov-2 wrote
> If you have an audio device that is class compliant (aka vendor claims 
> it's "driverless" on MacOS) *and* one of the above host/hub/device 
> combinations then I'd be very interested in test reports. Especially 
> I'd like to know about possible regressions. 

I tested with a Focusrite Scarlett 2i4 which should be a class compliant
v2.0 device, but I get "only one AC iface allowed".

Here is my dmesg:





--
Sent from: 
http://openbsd-archive.7691.n7.nabble.com/openbsd-dev-tech-f151936.html

Re: ifconfig: add carriage return when printing transceiver

[Sebastian Benoit]

ok

Denis Fondras(open...@ledeuns.net) on 2019.04.26 11:46:58 +0200:
> When transceiver is unknown (among others), a carriage return is missing.
> 
> Before :
> [root@er6p:~] ifconfig cnmac0 sff   
> cnmac0: flags=8802 mtu 1500
> lladdr 18:e8:29:b6:d4:a9
> index 1 priority 0 llprio 3
> media: Ethernet autoselect (none)
> status: no carrier
> transceiver: Unknown [root@er6p:~] 
> 
> After :
> [root@er6p:/usr/src/sbin/ifconfig] ifconfig cnmac0 sff 
> cnmac0: flags=8802 mtu 1500
> lladdr 18:e8:29:b6:d4:a9
> index 1 priority 0 llprio 3
> media: Ethernet autoselect (none)
> status: no carrier
> transceiver: Unknown 
> [root@er6p:/usr/src/sbin/ifconfig]
> 
> 
> Index: sff.c
> ===
> RCS file: /cvs/src/sbin/ifconfig/sff.c,v
> retrieving revision 1.11
> diff -u -p -r1.11 sff.c
> --- sff.c 16 Apr 2019 09:32:06 -  1.11
> +++ sff.c 26 Apr 2019 09:36:01 -
> @@ -361,6 +361,9 @@ if_sff_info(int s, const char *ifname, i
>   case SFF8024_ID_QSFP28:
>   error = if_sff8636(s, ifname, dump, );
>   break;
> + default:
> + putchar('\n');
> + break;
>   }
>  
>   return (error);
> 

Threadripper 2950 and slow softraid encryption

[Bryan Everly]

Hi tech@

I had previously posted about slow boot times and was correctly pointed to it 
being poor read performance from disk to load the kernel. I wondered if it had 
anything to do with the performance of my encrypted disk (I reported this from 
my standard install where I use softraid to encrypt the disk) so I wiped and 
reinstalled with no encryption.

Boot time went from over five minutes to insanely fast.

What information can I gather to help troubleshoot this issue?  Thanks in 
advance.

- Bryan

Get Outlook for iOS

route(4) manual and sockaddrs; ROUNDUP()

[Vadim Penzin]

Greetings,


1. The manual of route(4) explains the structure of its messages thus:

`Messages are formed by a header followed by a small number of
sockaddr structures (which are variable length), interpreted by
position, and delimited by the length entry in the sockaddr.'

(That phrase is quite unfortunate in itself: `sa_len' is supposed to
/determine/ the length of a structure.  To me, the word `delimited'
implies the presence of a memory object between two adjacent
structures, which certainly was not the intent of the author.)

Armed with that knowledge, I wrote a parser the other day.  I very
much enjoyed OpenBSD until my program fatally stumbled on a peculiar
structure that does not fit the above description:

05 00 00 00 ff 00 00 00

(The value of `sa_len' of that `sockaddr' is nothing that I am
familiar with, the address family is `AF_UNSPEC', and the most
disturbing: `sa_len' does not match the physical size of this
structure. These eight bytes were immediately followed by a perfectly
valid `sockaddr_in'.)

It took me some time to figure out that, apparently, I am looking at
the combined effect of in_socktrim() (see src/sys/netinet/in.c) and
ROUNDUP() (see src/sys/net/rtsock.c) applied to the netmask of
0xff00 that was stored as sockaddr_in'.

I believe that manuals should be more merciful.  In the absence of
proper documentation, the part of my program that handles this case 
looks like a mysterious ritual; it should not be that way.



2. The definition of ROUNDUP() somewhat surprised me: it silently 
handles zero. The macro is local to the compilation unit; it is used

this way:

if (rtinfo == NULL || (sa = rtinfo->rti_info[i]) == NULL)
continue;
rtinfo->rti_addrs |= (1 << i);
dlen = ROUNDUP(sa->sa_len);

and this way:

if ((sa = rtinfo->rti_info[i]) == NULL)
continue;
rtinfo->rti_addrs |= (1 << i);
dlen = ROUNDUP(sa->sa_len);

(In the second case, the programmer does not check `rtinfo' for being
NULL.  I only hope that there exists a good explanation to that.)

Since `sa_len' describes the size of a `sockaddr' (or one of its
derivatives) /including/ `sa_len' (maybe I am wrong, but this is my
interpretation of the comment `total length' that appears near the
definition of `struct sockaddr' in ), `sa_len' just
cannot be zero.

The current definition of ROUNDUP() might hide a bug.  In addition, on
some machines, it disturbs the pipeline of the CPU by introducing a
branch (for no real reason, as it seems, while I might be
nitpicking). At very least, it looks confusing.


Thank you for your time,
-- Vadim

ifconfig: add carriage return when printing transceiver

[Denis Fondras]

When transceiver is unknown (among others), a carriage return is missing.

Before :
[root@er6p:~] ifconfig cnmac0 sff   
cnmac0: flags=8802 mtu 1500
lladdr 18:e8:29:b6:d4:a9
index 1 priority 0 llprio 3
media: Ethernet autoselect (none)
status: no carrier
transceiver: Unknown [root@er6p:~] 

After :
[root@er6p:/usr/src/sbin/ifconfig] ifconfig cnmac0 sff 
cnmac0: flags=8802 mtu 1500
lladdr 18:e8:29:b6:d4:a9
index 1 priority 0 llprio 3
media: Ethernet autoselect (none)
status: no carrier
transceiver: Unknown 
[root@er6p:/usr/src/sbin/ifconfig]


Index: sff.c
===
RCS file: /cvs/src/sbin/ifconfig/sff.c,v
retrieving revision 1.11
diff -u -p -r1.11 sff.c
--- sff.c   16 Apr 2019 09:32:06 -  1.11
+++ sff.c   26 Apr 2019 09:36:01 -
@@ -361,6 +361,9 @@ if_sff_info(int s, const char *ifname, i
case SFF8024_ID_QSFP28:
error = if_sff8636(s, ifname, dump, );
break;
+   default:
+   putchar('\n');
+   break;
}
 
return (error);