OpenBSD::Unveil(3p) added to -current

Andrew Fresh (afresh1@) has committed OpenBSD::Unveil(3p), a Perl interface to unveil(2):

CVSROOT:	/cvs
Module name:	src
Changes by:	afresh1@cvs.openbsd.org	2019/07/09 14:41:54

Added files:
	gnu/usr.bin/perl/cpan/OpenBSD-Unveil: Unveil.xs 
	gnu/usr.bin/perl/cpan/OpenBSD-Unveil/lib/OpenBSD: Unveil.pm 
	gnu/usr.bin/perl/cpan/OpenBSD-Unveil/t: OpenBSD-Unveil.t 

Log message:
Add OpenBSD::Unveil, a perl interface to unveil(2)

OK brynet@, bluhm@

This parallels OpenBSD::Pledge(3p) / pledge(2).

aggr(4) driver added to -current

David Gwynne (dlg@) has committed to -current a dedicated Link Aggregation (EEE 802.1AX) driver, aggr(4). The main commit message explains the raison d'être:

CVSROOT:	/cvs
Module name:	src
Changes by:	dlg@cvs.openbsd.org	2019/07/04 19:35:58

Added files:
	sys/net        : if_aggr.c 

Log message:
add aggr(4), a dedicated driver that implements 802.1AX link aggregation

802.1AX (formerly known as 802.3ad) describes the Link Aggregation
Control Protocol (LACP) and how to use it in a bunch of different
state machines to control when to bundle interfaces into an
aggregation.

technically the trunk(4) driver already implements support for
802.1AX, but it had a couple of problems i struggled to deal with
as part of that driver. firstly, i couldnt easily make the output
path in trunk mpsafe without getting bogged down, and the state
machine handling had a few hard to diagnose edge cases that i couldnt
figure out.

the new driver has an mpsafe output path, and implements ifq bypass
like vlan(4) does. this means output with aggr(4) is up to twice
as fast as trunk(4). the implementation of the state machines as
per the standard means the driver behaves more correctly in edge
cases like when a physical link looks like it is up, but is logically
unidirectional.

the code has been good enough for me to use in production, but it
does need more work. that can happen in tree now instead of carrying
a large diff around.

some testing by ccardenas@, hrvoje popovski, and jmatthew@
ok deraadt@ ccardenas@ jmatthew@

OpenBSD Community goes Platinum for 2019!

Ken Westerback wrote in with some good news:

The OpenBSD Foundation is happy to announce that individual contributions from the OpenBSD community have again exceeded CDN$50,000, making the community the 1st Platinum level donor for 2019!

These smaller regular contributions are the backbone of longer term spending planning. The Foundation would like to thank all the individuals who made and continue to make regular monthly contributions.

Thanks Ken!

doas environmental security

Ted Unangst (tedu@) posted to the tech@ mailing list regarding recent changes to environment handling in doas (in -current):

[...]
After some reflection, I've been convinced that it's unlikely everybody reads
the manuals, or that the manuals are even correct or complete. So the new doas
behavior moving forward is to reset most everything to the target user's
environment.

Your action items, as we like to say in the biz, are:

1. Check existing configs for "restricted root" rules and verify that they are
run with the correct environment.

2. When updating, check for rules that intentionally use inherited environment
variables. They may need to be explicitly passing using setenv in doas.conf.

Readers are encouraged to read the entire message.

SSH gets protection against side channel attacks

Damien Miller (djm@) has just committed a new feature for SSH that should help protect against all the various memory side channel attacks that have surfaced recently.

Add protection for private keys at rest in RAM against speculation and memory sidechannel attacks like Spectre, Meltdown, Rowhammer and Rambleed. This change encrypts private keys when they are not in use with a symmetic key that is derived from a relatively large "prekey" consisting of random data (currently 16KB).

Read more…

ntpd auto time setting

Otto Moerbeek (otto@) has written an update on his recent ntpd(8) work to the tech@ mailinglist:

Hi,

I have been working on a nice feature that improves startup behaviour of ntpd.

Summary: make sure you have at least one constraint source configured and use no options. ntpd will set the clock if needed, even if you machines has no battery backed up clock and is running a DNSSEC validating resolver.

Read more…

rpki-client(8) imported into the tree

Job Snijders (job@) has imported Kristaps Dzonsons' rpki-client (discussed previously) into the tree:

And here is the commit message:

Import Kristaps Dzonsons' RPKI validator into the tree

rpki-client(1) is an implementation of the Resource Public Key
Infrastructure (RPKI), specified by RFC 6480. The client is responsible
for downloading, validating and converting Route Origin Authorisations
(ROAs) into Validated ROA Payloads (VRPs). The client's output (VRPs)
can be used by bgpd(8) to perform BGP Origin Validation (RFC 6811).

The current rpki-client(1) version depends on the CMS functions in
OpenSSL, this of course needs to be addressed urgently.

Thanks to NetNod, IIS.SE, SUNET & 6connect for supporting this effort!

OK deraadt@

On Mon, Jun 17, 2019 at 08:31:31AM -0600, Job Snijders wrote:
> CVSROOT:	/cvs
> Module name:	src
> Changes by:	job@cvs.openbsd.org	2019/06/17 08:31:31
> 
> Log message:
>     ../../../logmessage
>     
>     Status:
>     
>     Vendor Tag:	job
>     Release Tags:	job_20190617
>     
>     N src/usr.sbin/rpki-client/LICENSE.md
>     N src/usr.sbin/rpki-client/Makefile
>     N src/usr.sbin/rpki-client/README.md
>     N src/usr.sbin/rpki-client/TODO.md
>     N src/usr.sbin/rpki-client/as.c
>     N src/usr.sbin/rpki-client/cert.c
>     N src/usr.sbin/rpki-client/cms.c
>     N src/usr.sbin/rpki-client/crl.c
>     N src/usr.sbin/rpki-client/extern.h
>     N src/usr.sbin/rpki-client/io.c
>     N src/usr.sbin/rpki-client/ip.c
>     N src/usr.sbin/rpki-client/log.c
>     N src/usr.sbin/rpki-client/main.c
>     N src/usr.sbin/rpki-client/mft.c
>     N src/usr.sbin/rpki-client/roa.c
>     N src/usr.sbin/rpki-client/rpki-client.1
>     N src/usr.sbin/rpki-client/rsync.c
>     N src/usr.sbin/rpki-client/tal.c
>     N src/usr.sbin/rpki-client/test-cert.c
>     N src/usr.sbin/rpki-client/test-ip.c
>     N src/usr.sbin/rpki-client/test-mft.c
>     N src/usr.sbin/rpki-client/test-roa.c
>     N src/usr.sbin/rpki-client/test-tal.c
>     N src/usr.sbin/rpki-client/compats.c
>     N src/usr.sbin/rpki-client/configure
>     N src/usr.sbin/rpki-client/tests.c
>     N src/usr.sbin/rpki-client/output-bgpd.c
>     N src/usr.sbin/rpki-client/validate.c
>     N src/usr.sbin/rpki-client/x509.c
>     N src/usr.sbin/rpki-client/tals/afrinic.tal
>     N src/usr.sbin/rpki-client/tals/apnic.tal
>     N src/usr.sbin/rpki-client/tals/lacnic.tal
>     N src/usr.sbin/rpki-client/tals/ripe.tal
>     
>     No conflicts created by this import
> 

At the time of writing, it is not linked to the build, but work continues apace.

acme-client(1) moves to Let’s Encrypt v02 API

Florian Obser (florian@) has committed the changes required to move acme-client(1) in -current to the RFC 8555 protocol used by the Let's Encrypt v02 API:

CVSROOT:	/cvs
Module name:	src
Changes by:	florian@cvs.openbsd.org	2019/06/07 02:07:52

Modified files:
	usr.sbin/acme-client: acctproc.c acme-client.1 certproc.c 
	                      extern.h http.c http.h json.c main.c 
	                      netproc.c 

Log message:
Implement RFC 8555 "Automatic Certificate Management Environment
(ACME)" to be able to talk to the v02 Let's Encrypt API.

With this acme-client(1) will no longer be able to talk to the v01
API. Users must change the api url in /etc/acme-client.conf to
https://acme-v02.api.letsencrypt.org/directory
Existing accounts (and certs of course) stay valid and after the url
change acme-client will be able to renew certs.

Tested by Renaud Allard and benno
Input & OK benno

Let's Encrypt has already announced its "End of Life Plan for ACMEv1".