OpenBSD src changes summary for 2017-04-19 ==========================================
distrib/sets lib/libpcap regress/sbin regress/sys sbin/dhclient sbin/disklabel sbin/ipsecctl share/termtypes sys/net sys/netinet sys/netinet6 sys/ufs/ufs usr.bin/make usr.bin/mandoc usr.bin/tmux usr.sbin/arp usr.sbin/dhcpd usr.sbin/dhcrelay usr.sbin/dhcrelay6 usr.sbin/hostapd usr.sbin/mopd usr.sbin/npppd usr.sbin/rarpd usr.sbin/rbootd usr.sbin/relayd usr.sbin/tcpdump usr.sbin/vmctl usr.sbin/vmd == distrib =========================================================== 01/08 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib sets ~ lists/base/mi > sync (deraadt@) == lib =============================================================== 02/08 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib libpcap ~ pcap-bpf.c > Switch base tools from /dev/bpf0 to /dev/bpf. Now that /dev/bpf has been > around for two releases, it should be safe to do so. > ok bluhm deraadt sthen tb yasuoka (natano@) == regress =========================================================== 03/08 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/regress sbin ~ ipsecctl/sa25.ok ~ ipsecctl/sa26.ok ~ ipsecctl/sa27.ok > SA group has been renamed to bundle. Adapt test. (bluhm@) sys ~ net/pf_table/Makefile > Make the test pass when an obj directory exists. (bluhm@) == sbin ============================================================== 04/08 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin dhclient ~ bpf.c > Switch base tools from /dev/bpf0 to /dev/bpf. Now that /dev/bpf has been > around for two releases, it should be safe to do so. > ok bluhm deraadt sthen tb yasuoka (natano@) disklabel ~ Makefile ~ editor.c > enlarge obj to satisfy new world order that has *big* compilers and > remove condition for static linking; ok tb@ (otto@) ~ disklabel.8 > Bump numbers for /usr/obj allocation with *big* compilers. > ok otto (tb@) ipsecctl ~ ipsecctl.c ~ ipsecctl.h ~ parse.y ~ pfkdump.c ~ pfkey.c > Rename all SA groups to bundles consistently. The first kernel > commit in 2000 that introduced the features already called them SA > bundles. The word group is taken by Diffie-Hellman, reusing it > causes confusion. > OK hshoexer@ (bluhm@) == share ============================================================= 05/08 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/share termtypes ~ termtypes.master > Update to terminfo.src 2017-04-01. (nicm@) == sys =============================================================== 06/08 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys net ~ if_loop.c ~ route.c ~ rtsock.c > Use the rt_rmx defines that hide the struct rt_kmetrics indirection. > No binary change. > OK mpi@ (bluhm@) netinet ~ ip_icmp.c ~ ip_input.c ~ ip_output.c ~ tcp_input.c ~ tcp_subr.c ~ tcp_timer.c > Use the rt_rmx defines that hide the struct rt_kmetrics indirection. > No binary change. > OK mpi@ (bluhm@) netinet6 ~ icmp6.c ~ ip6_output.c > Use the rt_rmx defines that hide the struct rt_kmetrics indirection. > No binary change. > OK mpi@ (bluhm@) ~ icmp6.c ~ raw_ip6.c > icmp6_rip6_input() was mostly duplicated code from rip6_input(). > Merge these functions together and remove icmp6_rip6_input(). > OK mpi@ (bluhm@) ufs/ufs ~ ufs_vnops.c > Add size to free() > ok deraadt@ visa@ (dhill@) ~ ufs_dirhash.c > Add sizes to free() > ok deraadt@ visa@ (dhill@) == usr.bin =========================================================== 07/08 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin make ~ make.1 > spelling fixes from michael w. bombardieri (jmc@) mandoc ~ cgi.c > More thoroughly reject direct access to unintended files, such that > URIs like http://man.openbsd.org/OpenBSD-current/mandoc.db and > http://man.openbsd.org/OpenBSD-current/man1/ do not cause display > of garbage. (schwarze@) tmux ~ format.c ~ server-client.c ~ tmux.1 ~ tmux.h ~ tty.c > When the data we have buffered to write to a terminal grows beyond a > reasonable amount (currently width * height * 8 bytes), discard all > output to the terminal and start trying to redraw periodically > instead. Continue with this until the amount of data we are trying to > write falls to a low level again. > This helps to prevent tmux sitting on a huge buffer of data when there > are processes with fast output running inside tmux but the outside > terminal is slow. > A new client_discarded format holds the amount of data that has been > discarded due to this mechanism. > The three variables (when to start this, when to stop, and how often to > redraw) are basically "works for me" at the moment, this is going in to > see how it goes and if it causes problems for anyone else. (nicm@) ~ cmd-command-prompt.c ~ grid.c ~ tmux.c > Style nits and a missing cast. (nicm@) ~ cmd-detach-client.c ~ server-client.c ~ tmux.h > Add a suspend helper function, and do not allow detaching or suspending > while already doing so. (nicm@) ~ cmd-source-file.c > load_cfg returns < 0 on error, not != 0. Problem reported by Kaushal Modi. > (nicm@) == usr.sbin ========================================================== 08/08 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin arp ~ arp.c > Switch base tools from /dev/bpf0 to /dev/bpf. Now that /dev/bpf has been > around for two releases, it should be safe to do so. > ok bluhm deraadt sthen tb yasuoka (natano@) dhcpd ~ bpf.c > Switch base tools from /dev/bpf0 to /dev/bpf. Now that /dev/bpf has been > around for two releases, it should be safe to do so. > ok bluhm deraadt sthen tb yasuoka (natano@) dhcrelay ~ bpf.c > Switch base tools from /dev/bpf0 to /dev/bpf. Now that /dev/bpf has been > around for two releases, it should be safe to do so. > ok bluhm deraadt sthen tb yasuoka (natano@) dhcrelay6 ~ bpf.c > Switch base tools from /dev/bpf0 to /dev/bpf. Now that /dev/bpf has been > around for two releases, it should be safe to do so. > ok bluhm deraadt sthen tb yasuoka (natano@) hostapd ~ hostapd.c > Switch base tools from /dev/bpf0 to /dev/bpf. Now that /dev/bpf has been > around for two releases, it should be safe to do so. > ok bluhm deraadt sthen tb yasuoka (natano@) mopd ~ common/pf.c > Switch base tools from /dev/bpf0 to /dev/bpf. Now that /dev/bpf has been > around for two releases, it should be safe to do so. > ok bluhm deraadt sthen tb yasuoka (natano@) npppd ~ npppd/privsep.c ~ pppoe/pppoed.c > Switch base tools from /dev/bpf0 to /dev/bpf. Now that /dev/bpf has been > around for two releases, it should be safe to do so. > ok bluhm deraadt sthen tb yasuoka (natano@) rarpd ~ rarpd.c > Switch base tools from /dev/bpf0 to /dev/bpf. Now that /dev/bpf has been > around for two releases, it should be safe to do so. > ok bluhm deraadt sthen tb yasuoka (natano@) rbootd ~ bpf.c ~ rbootd.8 > Switch base tools from /dev/bpf0 to /dev/bpf. Now that /dev/bpf has been > around for two releases, it should be safe to do so. > ok bluhm deraadt sthen tb yasuoka (natano@) relayd ~ relayd.conf.5 > better example; from hiltjo posthuma > ok sthen (jmc@) tcpdump ~ privsep_pcap.c ~ tcpdump.8 > Switch base tools from /dev/bpf0 to /dev/bpf. Now that /dev/bpf has been > around for two releases, it should be safe to do so. > ok bluhm deraadt sthen tb yasuoka (natano@) vmctl ~ main.c ~ vmctl.8 ~ vmctl.c > Add support for dynamic "NAT" interfaces (-L/local interface). > When a local interface is configured, vmd configures a /31 address on > the tap(4) interface of the host and provides another IP in the same > subnet via DHCP (BOOTP) to the VM. vmd runs an internal BOOTP server > that replies with IP, gateway, and DNS addresses to the VM. The > built-in server only ever responds to the VM on the inside and cannot > leak its DHCP responses to the outside. > Thanks to Uwe Werler, Josh Grosse, and some others for testing! > OK deraadt@ (reyk@) vmd ~ Makefile ~ parse.y ~ priv.c ~ virtio.c ~ virtio.h ~ vm.c ~ vm.conf.5 ~ vmd.c ~ vmd.h + dhcp.c + dhcp.h + packet.c > Add support for dynamic "NAT" interfaces (-L/local interface). > When a local interface is configured, vmd configures a /31 address on > the tap(4) interface of the host and provides another IP in the same > subnet via DHCP (BOOTP) to the VM. vmd runs an internal BOOTP server > that replies with IP, gateway, and DNS addresses to the VM. The > built-in server only ever responds to the VM on the inside and cannot > leak its DHCP responses to the outside. > Thanks to Uwe Werler, Josh Grosse, and some others for testing! > OK deraadt@ (reyk@) =============================================================================== _______________________________________________ odc mailing list [email protected] http://www.squish.net/mailman/listinfo/odc
