adding MIME type for XSLT
XSLT is a well-established XML-based language for stylesheets. It has been around since the late 90s; the most recent version was finalized in 2017 (see https://www.w3.org/TR/xslt-30/). The mime.types file bundled with OpenBSD 7.0 -- typically used with httpd -- doesn't include this common MIME type. May we add it? Conventionally, XSLT files use the .xsl file extension and the standard MIME type is "application/xslt+xml" (see https://datatracker.ietf.org/doc/html/rfc3023#section-8.17). A diff looks like this: diff -Naur /usr/share/misc/mime.types /usr/src/share/misc/mime.types --- /usr/share/misc/mime.types Thu Sep 30 20:01:17 2021 +++ /usr/src/share/misc/mime.types Fri Feb 11 07:36:11 2022 @@ -56,6 +56,7 @@ application/x-tcl tcl tk application/x-x509-ca-cert der pem crt application/x-xpinstallxpi +application/xslt+xmlxsl application/xhtml+xml xhtml application/zipzip Jesse
Re: more MAKEDEV cleanup
> What happened to this? I need to split this into orthogonal diffs, and also since this will expose an issue in makefs(8), I need to polish and send a fix for makefs first...
superfluous words in lib/libc/gen/statvfs.3 and sys/sys/statvfs.h
Hello,
there seem to be some superfluous words in
lib/libc/gen/statvfs.3 and sys/sys/statvfs.h .
"(unit f_frsize)" can be removed since in the man page
it is explicitely mentioned directly below:
" The fields of type fsblkcnt_t are reported in units of f_frsize. "
For sys/sys/statvs.h I left them in although IMO it is
quite obvious.
The "to" word is just a typo I think.
Alf
Index: lib/libc/gen/statvfs.3
===
RCS file: /cvs/src/lib/libc/gen/statvfs.3,v
retrieving revision 1.8
diff -u -p -r1.8 statvfs.3
--- lib/libc/gen/statvfs.3 29 Jan 2015 01:46:30 - 1.8
+++ lib/libc/gen/statvfs.3 11 Feb 2022 06:30:34 -
@@ -56,12 +56,12 @@ structure defined as follows:
struct statvfs {
unsigned long f_bsize;/* file system block size */
unsigned long f_frsize; /* fundamental file system block size */
-fsblkcnt_tf_blocks; /* number of blocks (unit f_frsize) */
+fsblkcnt_tf_blocks; /* number of blocks */
fsblkcnt_tf_bfree;/* free blocks in file system */
fsblkcnt_tf_bavail; /* free blocks for non-root */
fsfilcnt_tf_files;/* total file inodes */
fsfilcnt_tf_ffree;/* free file inodes */
-fsfilcnt_tf_favail; /* free file inodes for to non-root */
+fsfilcnt_tf_favail; /* free file inodes for non-root */
unsigned long f_fsid; /* file system id */
unsigned long f_flag; /* bit mask of f_flag values */
unsigned long f_namemax; /* maximum filename length */
Index: sys/sys/statvfs.h
===
RCS file: /cvs/src/sys/sys/statvfs.h,v
retrieving revision 1.3
diff -u -p -r1.3 statvfs.h
--- sys/sys/statvfs.h 24 Mar 2013 17:45:50 - 1.3
+++ sys/sys/statvfs.h 11 Feb 2022 07:11:35 -
@@ -29,7 +29,7 @@ struct statvfs {
fsblkcnt_t f_bavail; /* free blocks for non-root */
fsfilcnt_t f_files;/* total file inodes */
fsfilcnt_t f_ffree;/* free file inodes */
- fsfilcnt_t f_favail; /* free file inodes for to non-root */
+ fsfilcnt_t f_favail; /* free file inodes for non-root */
unsigned long f_fsid; /* file system id */
unsigned long f_flag; /* bit mask of f_flag values */
unsigned long f_namemax; /* maximum filename length */
Re: rewritten vxlan(4)
On Fri, Mar 05, 2021 at 05:09:29PM +1000, David Gwynne wrote:
> On Thu, Mar 04, 2021 at 03:36:19PM +1000, David Gwynne wrote:
> > as the subject says, this is a rewrite of vxlan(4).
> >
> > vxlan(4) relies on bridge(4) to implement learning, but i want to be
> > able to remove bridge(4) one day. while working on veb(4), i wrote
> > the guts of a learning bridge implementation that is now used by veb(4),
> > bpe(4), and nvgre(4). that learning bridge code is now also used by
> > vxlan(4).
> >
> > this means that a few of the modes that the manpage talks about are
> > different now. because vxlan doesnt need a bridge for learning, there's
> > no "multicast mode" anymore, it just does "dynamic mode" out of the box
> > when configured with a multicast destination address. there's no
> > multipoint mode now too.
> >
> > another thing that's always bothered me about vxlan(4) is how it occupies
> > the "udp namespace" and gets how it steals packets from the udp stack.
> > the new code actually creates and bind udp sockets to handle the
> > vxlan packets. this means userland can't collide with a vxlan interface,
> > and you get to see that the port is in use in things like netstat. e.g.:
> >
> > dlg@ikkaku ~$ ifconfig vxlan0
> > vxlan0: flags=8843 mtu 1500
> > lladdr fe:e1:ba:d1:17:2a
> > index 11 llprio 3
> > encap: vnetid none parent aggr0 txprio 0 rxprio outer
> > groups: vxlan
> > tunnel: inet 192.0.2.36 port 4789 --> 239.0.0.1 ttl 1 nodf
> > Addresses (max cache: 100, timeout: 240):
> > inet 100.64.1.36 netmask 0xff00 broadcast 100.64.1.255
> > dlg@ikkaku ~$ netstat -na -f inet -p udp
> > Active Internet connections (including servers)
> > Proto Recv-Q Send-Q Local Address Foreign Address
> > udp 0 0 130.102.96.36.29742129.250.35.250.123
> > udp 0 0 130.102.96.36.8965 162.159.200.123.123
> > udp 0 0 130.102.96.36.13189162.159.200.1.123
> > udp 0 0 130.102.96.36.46580220.158.215.20.123
> > udp 0 0 130.102.96.36.23109103.38.121.36.123
> > udp 0 0 239.0.0.1.4789 *.*
> > udp 0 0 192.0.2.36.4789*.*
> >
> > ive also added loop prevention, ie, sending an interfaces vxlan
> > packets over itself should fail rather than panic now.
>
> here's an updated diff with a few fixes.
>
this diff better supports vxlan p2p and multicast vxlan configs that
share a UDP listener.
Index: net/if_vxlan.c
===
RCS file: /cvs/src/sys/net/if_vxlan.c,v
retrieving revision 1.83
diff -u -p -r1.83 if_vxlan.c
--- net/if_vxlan.c 10 Jan 2022 14:07:59 - 1.83
+++ net/if_vxlan.c 11 Feb 2022 05:11:13 -
@@ -1,7 +1,7 @@
-/* $OpenBSD: if_vxlan.c,v 1.83 2022/01/10 14:07:59 jan Exp $ */
+/* $OpenBSD$ */
/*
- * Copyright (c) 2013 Reyk Floeter
+ * Copyright (c) 2021 David Gwynne
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
@@ -17,475 +17,781 @@
*/
#include "bpfilter.h"
-#include "vxlan.h"
-#include "vlan.h"
#include "pf.h"
-#include "bridge.h"
#include
#include
+#include
#include
#include
-#include
#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
#include
#include
+#include
#include
+#include
#include
-
-#if NBPFILTER > 0
-#include
-#endif
+#include
#include
#include
#include
#include
-#include
#include
-#include
#include
+#include
-#if NPF > 0
-#include
+#ifdef INET6
+#include
+#include
+#include
#endif
-#if NBRIDGE > 0
+/* for bridge stuff */
#include
+#include
+
+#if NBPFILTER > 0
+#include
#endif
-#include
+/*
+ * The protocol.
+ */
+
+#define VXLANMTU 1492
+#define VXLAN_PORT 4789
+
+struct vxlan_header {
+ uint32_tvxlan_flags;
+#define VXLAN_F_I (1U << 27)
+ uint32_tvxlan_id;
+#define VXLAN_VNI_SHIFT8
+#defineVXLAN_VNI_MASK (0xffU << VXLAN_VNI_SHIFT)
+};
+
+#define VXLAN_VNI_MAX 0x00ffU
+#define VXLAN_VNI_MIN 0xU
+
+/*
+ * The driver.
+ */
+
+union vxlan_addr {
+ struct in_addr in4;
+ struct in6_addr in6;
+};
+
+struct vxlan_softc;
+
+struct vxlan_peer {
+ RBT_ENTRY(vxlan_peer)p_entry;
+
+ struct vxlan_header p_header;
+ union vxlan_addr p_addr;
+
+ struct vxlan_softc *p_sc;
+};
+
+RBT_HEAD(vxlan_peers, vxlan_peer);
+
+struct vxlan_tep {
+ TAILQ_ENTRY(vxlan_tep) vt_entry;
+
+ sa_family_t vt_af;
+ unsigned int vt_rdomain;
+ union vxlan_addr vt_addr;
+#define
Re: more MAKEDEV cleanup
On 05/04/21(Mon) 09:25, Miod Vallat wrote:
> The following diff attempts to clean up a few loose ends in the current
> MAKEDEV files:
>
> - remove no-longer applicable device definitions (MSCP and SMD disks,
> this kind of thing).
> - makes sure all platforms use the same `ramdisk' target for
> installation media devices, rather than a mix of `ramd' and `ramdisk'.
> - moves as many `ramdisk' devices to MI land (bio, diskmap, random,
> etc).
> - reduces the number of block devices in `ramdisk' targets to only one
> per device, since the installer script will invoke MAKEDEV by itself
> for the devices it needs to use.
> - sort device names in `all' and `ramdisk' MI lists to make maintainence
> easier. This causes some ordering change in the `all' target in the
> generated MAKEDEVs.
What happened to this?
> Index: MAKEDEV.common
> ===
> RCS file: /OpenBSD/src/etc/MAKEDEV.common,v
> retrieving revision 1.113
> diff -u -p -r1.113 MAKEDEV.common
> --- MAKEDEV.common12 Feb 2021 10:26:33 - 1.113
> +++ MAKEDEV.common5 Apr 2021 09:18:49 -
> @@ -114,7 +114,7 @@ dnl make a 'disktgt' macro that automati
> dnl disktgt(rd, {-rd-})
> dnl
> dnl target(all,rd,0)
> -dnl target(ramd,rd,0)
> +dnl target(ramdisk,rd,0)
> dnl disk_q(rd)
> dnl __devitem(rd, {-rd*-}, {-rd-})dnl
> dnl
> @@ -122,62 +122,60 @@ dnl Note: not all devices are generated
> dnlits own extra list.
> dnl
> divert(1)dnl
> +target(all, acpi)dnl
> +target(all, apm)dnl
> +target(all, bio)dnl
> +target(all, bpf)dnl
> +twrget(all, com, tty0, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b)dnl
> +twrget(all, czs, cua, a, b, c, d)dnl
> +target(all, diskmap)dnl
> +target(all, dt)dnl
> twrget(all, fdesc, fd)dnl
> -target(all, st, 0, 1)dnl
> -target(all, std)dnl
> -target(all, ra, 0, 1, 2, 3)dnl
> -target(all, rx, 0, 1)dnl
> -target(all, wd, 0, 1, 2, 3)dnl
> -target(all, xd, 0, 1, 2, 3)dnl
> +target(all, fuse)dnl
> +target(all, hotplug)dnl
> +target(all, joy, 0, 1)dnl
> +target(all, kcov)dnl
> +target(all, kstat)dnl
> +target(all, local)dnl
> +target(all, lpt, 0, 1, 2)dnl
> +twrget(all, lpt, lpa, 0, 1, 2)dnl
> +target(all, par, 0)dnl
> +target(all, pci, 0, 1, 2, 3)dnl
> target(all, pctr)dnl
> target(all, pctr0)dnl
> target(all, pf)dnl
> -target(all, apm)dnl
> -target(all, acpi)dnl
> +target(all, pppac)dnl
> +target(all, pppx)dnl
> +target(all, ptm)dnl
> +target(all, pty, 0)dnl
> +target(all, pvbus, 0, 1)dnl
> +target(all, radio, 0)dnl
> +target(all, rmidi, 0, 1, 2, 3, 4, 5, 6, 7)dnl
> +twrget(all, rnd, random)dnl
> +twrget(all, speak, speaker)dnl
> +target(all, st, 0, 1)dnl
> +target(all, std)dnl
> +target(all, switch, 0, 1, 2, 3)dnl
> +target(all, tap, 0, 1, 2, 3)dnl
> twrget(all, tth, ttyh, 0, 1)dnl
> target(all, ttyA, 0, 1)dnl
> -twrget(all, mac_tty0, tty0, 0, 1)dnl
> -twrget(all, tzs, tty, a, b, c, d)dnl
> -twrget(all, czs, cua, a, b, c, d)dnl
> target(all, ttyc, 0, 1, 2, 3, 4, 5, 6, 7)dnl
> -twrget(all, com, tty0, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b)dnl
> -twrget(all, mmcl, mmclock)dnl
> -target(all, lpt, 0, 1, 2)dnl
> -twrget(all, lpt, lpa, 0, 1, 2)dnl
> -target(all, joy, 0, 1)dnl
> -twrget(all, rnd, random)dnl
> -target(all, uk, 0)dnl
> -twrget(all, vi, video, 0, 1)dnl
> -twrget(all, speak, speaker)dnl
> -target(all, asc, 0)dnl
> -target(all, radio, 0)dnl
> +target(all, tun, 0, 1, 2, 3)dnl
> target(all, tuner, 0)dnl
> -target(all, rmidi, 0, 1, 2, 3, 4, 5, 6, 7)dnl
> +twrget(all, tzs, tty, a, b, c, d)dnl
> target(all, uall)dnl
> -target(all, pci, 0, 1, 2, 3)dnl
> -twrget(all, wsmouse, wscons)dnl
> -target(all, par, 0)dnl
> -target(all, apci, 0)dnl
> -target(all, local)dnl
> -target(all, ptm)dnl
> -target(all, hotplug)dnl
> -target(all, pppx)dnl
> -target(all, pppac)dnl
> -target(all, fuse)dnl
> +target(all, uk, 0)dnl
> +twrget(all, vi, video, 0, 1)dnl
> target(all, vmm)dnl
> -target(all, pvbus, 0, 1)dnl
> -target(all, bpf)dnl
> -target(all, kcov)dnl
> -target(all, dt)dnl
> -target(all, kstat)dnl
> +target(all, vnd, 0, 1, 2, 3)dnl
> +target(all, vscsi, 0)dnl
> +target(all, wd, 0, 1, 2, 3)dnl
> +twrget(all, wsmouse, wscons)dnl
> dnl
> _mkdev(all, {-all-}, {-dnl
> show_target(all)dnl
> -})dnl
> dnl
> -dnl XXX some arches use ramd, others ramdisk - needs to be fixed eventually
> -__devitem(ramdisk, ramdisk, Ramdisk kernel devices,nothing)dnl
> -dnl
> target(usb, usb, 0, 1, 2, 3, 4, 5, 6, 7)dnl
> target(usb, uhid, 0, 1, 2, 3, 4, 5, 6, 7)dnl
> twrget(usb, fido, fido)dnl
> @@ -208,26 +206,26 @@ __devitem(ch, {-ch*-}, SCSI media change
> _mcdev(ch, ch*, ch, {-major_ch_c-}, 660, operator)dnl
> __devitem(uk, uk*, Unknown SCSI devices)dnl
> _mcdev(uk, uk*, uk, {-major_uk_c-}, 640, operator)dnl
> -dnl XXX see ramdisk above
> -__devitem(ramd, ramdisk, Ramdisk kernel devices,nothing)dnl
> dnl
> -_mkdev(ramd, ramdisk, {-dnl
> -show_target(ramd)dnl
> +__devitem(ramdisk, ramdisk, Ramdisk kernel devices,nothing)dnl
> +_mkdev(ramdisk, ramdisk, {-dnl
>
yacc(1): skeleton.c: remove outdated comment
Hi yysccsid was removed in 1.30 back in 2009. Best, Martin Index: skeleton.c === RCS file: /cvs/src/usr.bin/yacc/skeleton.c,v retrieving revision 1.40 diff -u -p -r1.40 skeleton.c --- skeleton.c 3 Feb 2021 01:10:10 - 1.40 +++ skeleton.c 10 Feb 2022 15:29:08 - @@ -35,10 +35,6 @@ #include "defs.h" -/* The definition of yysccsid in the banner should be replaced with */ -/* a #pragma ident directive if the target C compiler supports */ -/* #pragma ident directives. */ -/* */ /* If the skeleton is changed, the banner should be changed so that */ /* the altered version can be easily distinguished from the original. */ /* */
Re: wskbd_set_mixervolume
On Wed, Feb 09, 2022 at 09:13:58AM +0100, Alexandre Ratchov wrote:
> On Tue, Feb 08, 2022 at 06:59:39PM +0100, Anton Lindqvist wrote:
> > On Tue, Feb 08, 2022 at 07:32:38AM +0100, Alexandre Ratchov wrote:
> > > On Mon, Feb 07, 2022 at 06:55:21PM +0100, Anton Lindqvist wrote:
> > > > On Mon, Feb 07, 2022 at 11:21:43AM +0100, Alexandre Ratchov wrote:
> > > > > On Sun, Feb 06, 2022 at 08:40:35AM +0100, Anton Lindqvist wrote:
> > > > > >
> > > > > > Polished diff. I'm omitting a necessary refactoring commit making
> > > > > > audio_attach_mi() accept a new cookie argument.
> > > > > >
> > > > >
> > > > > I'm not sure to understand the need for the wskbd_audio structure.
> > > > > Couldn't we just store the cookie in audio and wskbd softc structures,
> > > > > then pass it in the wskbd_set_mixervolume_sc() calls ?
> > > >
> > > > Due to the device caching the data must be stored in either the audio or
> > > > wskbd softc and I don't want to expose the softc structures so I ended
> > > > up introducing wskbd_audio. Dropping the caching would probably make it
> > > > possible to only pass down the cookie to wskbd_set_mixervolume_sc() and
> > > > always do the audio device lookup.
> > > >
> > > > Is anyone in favor of this approach? I achieves the expected behavior in
> > > > my opinion.
> > >
> > > IMHO, handling the volume keys this way won't work in the general
> > > case. But for the short term we've no other options, have we?
> > >
> > > AFAICS, you're fixing a concrete use-case by tweaking what already
> > > exists, this won't make things more broken than they already are. I'm
> > > OK with it.
> >
> > Here's the complete diff including adding a cookie argument to
> > audio_attach_mi().
>
> Is the caching necessary? device_lookup() seems cheap and there are at
> most two devices in most cases. Keeping the code minimal especially on
> rare and non-performace-critical code-paths would be nice.
>
> If you choose to drop the caching, this would allow to just add a a
> new "cookie" argument to wskbd_set_mixervolume(), similarly to what
> you did for audio_attach_mi()
Sure, I ended up adding a new function after all since the
wskbd_set_mixervolume() prototype is not present in any header at this
point.
diff --git sys/arch/hppa/gsc/harmony.c sys/arch/hppa/gsc/harmony.c
index 033a3d2c356..d5748fac4b1 100644
--- sys/arch/hppa/gsc/harmony.c
+++ sys/arch/hppa/gsc/harmony.c
@@ -249,7 +249,7 @@ harmony_attach(parent, self, aux)
if ((rev & CS4215_REV_VER) >= CS4215_REV_VER_E)
sc->sc_hasulinear8 = 1;
- audio_attach_mi(_sa_hw_if, sc, >sc_dv);
+ audio_attach_mi(_sa_hw_if, sc, NULL, >sc_dv);
timeout_set(>sc_acc_tmo, harmony_acc_tmo, sc);
sc->sc_acc_num = 0xa5a5a5a5;
diff --git sys/arch/luna88k/cbus/nec86.c sys/arch/luna88k/cbus/nec86.c
index b6516cc4888..dc4e2069ddd 100644
--- sys/arch/luna88k/cbus/nec86.c
+++ sys/arch/luna88k/cbus/nec86.c
@@ -237,7 +237,7 @@ nec86_attachsubr(struct nec86_softc *sc)
if (sc->sc_attached == 0) {
printf(": %s\n", boardname[ysc->model]);
- audio_attach_mi(_hw_if, ysc, >sc_dev);
+ audio_attach_mi(_hw_if, ysc, NULL, >sc_dev);
sc->sc_attached = 1;
}
}
diff --git sys/arch/macppc/dev/aoa.c sys/arch/macppc/dev/aoa.c
index a2ca8e10a95..638da4b1669 100644
--- sys/arch/macppc/dev/aoa.c
+++ sys/arch/macppc/dev/aoa.c
@@ -134,7 +134,7 @@ aoa_defer(struct device *dev)
{
struct aoa_softc *sc = (struct aoa_softc *)dev;
- audio_attach_mi(_hw_if, sc, >sc_dev);
+ audio_attach_mi(_hw_if, sc, NULL, >sc_dev);
deq_reset(sc);
}
diff --git sys/arch/macppc/dev/awacs.c sys/arch/macppc/dev/awacs.c
index 8ea7d4869a0..adcafcf79fb 100644
--- sys/arch/macppc/dev/awacs.c
+++ sys/arch/macppc/dev/awacs.c
@@ -340,7 +340,7 @@ awacs_attach(struct device *parent, struct device *self,
void *aux)
awacs_halt_input(sc);
printf("\n");
- audio_attach_mi(_hw_if, sc, >sc_dev);
+ audio_attach_mi(_hw_if, sc, NULL, >sc_dev);
}
u_int
diff --git sys/arch/macppc/dev/daca.c sys/arch/macppc/dev/daca.c
index 070b839c99a..91b078dd254 100644
--- sys/arch/macppc/dev/daca.c
+++ sys/arch/macppc/dev/daca.c
@@ -154,7 +154,7 @@ daca_defer(struct device *dev)
/* XXX If i2c has failed to attach, what should we do? */
- audio_attach_mi(_hw_if, sc, >sc_dev);
+ audio_attach_mi(_hw_if, sc, NULL, >sc_dev);
daca_init(sc);
}
diff --git sys/arch/macppc/dev/onyx.c sys/arch/macppc/dev/onyx.c
index c279258f091..9252d1c7376 100644
--- sys/arch/macppc/dev/onyx.c
+++ sys/arch/macppc/dev/onyx.c
@@ -165,7 +165,7 @@ onyx_defer(struct device *dev)
/* XXX If i2c has failed to attach, what should we do? */
- audio_attach_mi(_hw_if, sc, >sc_dev);
+ audio_attach_mi(_hw_if, sc, NULL, >sc_dev);
deq_reset(sc);
onyx_set_volume(sc, 192, 192);
diff --git sys/arch/macppc/dev/snapper.c
Re: rpki-client print crl data
On Thu, Feb 10, 2022 at 04:20:40PM +0100, Claudio Jeker wrote: > On Thu, Feb 10, 2022 at 04:09:40PM +0100, Theo Buehler wrote: > > On Thu, Feb 10, 2022 at 03:02:15PM +0100, Claudio Jeker wrote: > > > This adds the needed bits to print CRL files. > > > Using ASN1_INTEGER_get() is probably bad at least I think there is the > > > possibility the serial number wont fit in the long. I hope tb@ has a > > > better solution :) > > > > According to RFC 5280, issuer + serialNumber must identify the cert > > uniquely so applications should be able to handle serialNumbers of > > at least 20 octets. The upper bound is 64 octets. > > > > I don't have a particularly elegant solution. The options offered > > by libcrypto that come to mind are to convert to a BIGNUM and use > > BN_print_fp() or to use a BIO and i2a_ASN1_INTEGER. Neither is > > particularly appealing. > > I would suggest we extract the code from mft.c to handle the manifest > number. The only difference is the limit of 20 vs 64 it seems. > Then we have a common function for serial numbers. Even better. I forgot we had that. It's fine to restrict to 20 for both. Certificate users MUST be able to handle serialNumber values up to 20 octets in length. Conforming CAs MUST NOT use serialNumber values longer than 20 octets. > > > I created x509_get_time() to streamline the ASN1_TIME to time_t > > > conversion and replaced a bunch of calls. mft.c uses ASN1_GENERALIZEDTIME > > > and can not be converted. > > > > We already check that the ASN.1 type is ASN1_GENERALIZEDTIME before > > calling mft_parse_time(). I'm not sure how much this being slightly > > stricter buys us. > > Can we typecast a ASN1_GENERALIZEDTIME into a ASN1_TIME? Yes. These are all just glorified ASN1_STRINGs, see /usr/inclued/openssl/openssl_typ.h
Re: rpki-client: disk space warning on btrfs
On Thu, 10 Feb 2022 09:13:25 +0100, Theo Buehler wrote: > This is purely cosmetic. I did some testing on fedora which ships with > btrfs by default. btrfs is special in that df -i and other tools always > report 0 inodes. As a consequence, each rpki-client run prints the disk > space warning, which seems a bit silly. Should we special case the 0 > inodes case? If your disk is actually that full, you'll find out quickly > enough. It might be better to check for fs.f_ffree > 0 instead. - todd
Re: rpki-client print crl data
On Thu, Feb 10, 2022 at 04:09:40PM +0100, Theo Buehler wrote:
> On Thu, Feb 10, 2022 at 03:02:15PM +0100, Claudio Jeker wrote:
> > This adds the needed bits to print CRL files.
> > Using ASN1_INTEGER_get() is probably bad at least I think there is the
> > possibility the serial number wont fit in the long. I hope tb@ has a
> > better solution :)
>
> According to RFC 5280, issuer + serialNumber must identify the cert
> uniquely so applications should be able to handle serialNumbers of
> at least 20 octets. The upper bound is 64 octets.
>
> I don't have a particularly elegant solution. The options offered
> by libcrypto that come to mind are to convert to a BIGNUM and use
> BN_print_fp() or to use a BIO and i2a_ASN1_INTEGER. Neither is
> particularly appealing.
I would suggest we extract the code from mft.c to handle the manifest
number. The only difference is the limit of 20 vs 64 it seems.
Then we have a common function for serial numbers.
> I would suggest something along these lines:
>
> const ASN1_INTEGER *serial;
> char*hex_str;
>
> serial = X509_REVOKED_get0_serialNumber(rev);
> if (serial != NULL && ASN1_STRING_length(serial) > 0)
> hex_str = hex_encode(ASN1_STRING_get0_data(serial),
> ASN1_STRING_length(serial));
> else {
> if ((hex_str = strdup("invalid")) == NULL)
> err(1, NULL);
> }
> x509_get_time(X509_REVOKED_get0_revocationDate(rev), );
> printf("Serial: %8s\tRevocation Date: %s\n", hex_str,
> time2str(t));
> free(hex_str);
>
> That is, if you can live with leading zeros and uppercase hex digits.
>
> > I created x509_get_time() to streamline the ASN1_TIME to time_t
> > conversion and replaced a bunch of calls. mft.c uses ASN1_GENERALIZEDTIME
> > and can not be converted.
>
> We already check that the ASN.1 type is ASN1_GENERALIZEDTIME before
> calling mft_parse_time(). I'm not sure how much this being slightly
> stricter buys us.
Can we typecast a ASN1_GENERALIZEDTIME into a ASN1_TIME?
> > Apart from that it seems to work.
>
> I like it. This line has a trailing tab:
>
> > + printf("Authority key identifier: %s\n", pretty_key_id(p->aki));
Fixed.
> I'm ok to land this as it is and we can bikeshed the ASN1_INTEGER
> conversion in tree.
Sure lets bikeshed in the tree :)
--
:wq Claudio
Re: rpki-client print crl data
On Thu, Feb 10, 2022 at 03:02:15PM +0100, Claudio Jeker wrote:
> This adds the needed bits to print CRL files.
> Using ASN1_INTEGER_get() is probably bad at least I think there is the
> possibility the serial number wont fit in the long. I hope tb@ has a
> better solution :)
According to RFC 5280, issuer + serialNumber must identify the cert
uniquely so applications should be able to handle serialNumbers of
at least 20 octets. The upper bound is 64 octets.
I don't have a particularly elegant solution. The options offered
by libcrypto that come to mind are to convert to a BIGNUM and use
BN_print_fp() or to use a BIO and i2a_ASN1_INTEGER. Neither is
particularly appealing.
I would suggest something along these lines:
const ASN1_INTEGER *serial;
char*hex_str;
serial = X509_REVOKED_get0_serialNumber(rev);
if (serial != NULL && ASN1_STRING_length(serial) > 0)
hex_str = hex_encode(ASN1_STRING_get0_data(serial),
ASN1_STRING_length(serial));
else {
if ((hex_str = strdup("invalid")) == NULL)
err(1, NULL);
}
x509_get_time(X509_REVOKED_get0_revocationDate(rev), );
printf("Serial: %8s\tRevocation Date: %s\n", hex_str,
time2str(t));
free(hex_str);
That is, if you can live with leading zeros and uppercase hex digits.
> I created x509_get_time() to streamline the ASN1_TIME to time_t
> conversion and replaced a bunch of calls. mft.c uses ASN1_GENERALIZEDTIME
> and can not be converted.
We already check that the ASN.1 type is ASN1_GENERALIZEDTIME before
calling mft_parse_time(). I'm not sure how much this being slightly
stricter buys us.
> Apart from that it seems to work.
I like it. This line has a trailing tab:
> + printf("Authority key identifier: %s\n", pretty_key_id(p->aki));
I'm ok to land this as it is and we can bikeshed the ASN1_INTEGER
conversion in tree.
rpki-client print crl data
This adds the needed bits to print CRL files.
Using ASN1_INTEGER_get() is probably bad at least I think there is the
possibility the serial number wont fit in the long. I hope tb@ has a
better solution :)
I created x509_get_time() to streamline the ASN1_TIME to time_t
conversion and replaced a bunch of calls. mft.c uses ASN1_GENERALIZEDTIME
and can not be converted.
Apart from that it seems to work.
--
:wq Claudio
Index: crl.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/crl.c,v
retrieving revision 1.13
diff -u -p -r1.13 crl.c
--- crl.c 8 Feb 2022 14:53:03 - 1.13
+++ crl.c 10 Feb 2022 13:27:51 -
@@ -33,7 +33,6 @@ crl_parse(const char *fn, const unsigned
{
struct crl *crl;
const ASN1_TIME *at;
- struct tmissued_tm, expires_tm;
int rc = 0;
/* just fail for empty buffers, the warning was printed elsewhere */
@@ -58,27 +57,20 @@ crl_parse(const char *fn, const unsigned
warnx("%s: X509_CRL_get0_lastUpdate failed", fn);
goto out;
}
- memset(_tm, 0, sizeof(issued_tm));
- if (ASN1_time_parse(at->data, at->length, _tm, 0) == -1) {
+ if (x509_get_time(at, >issued) == -1) {
warnx("%s: ASN1_time_parse failed", fn);
goto out;
}
- if ((crl->issued = mktime(_tm)) == -1)
- errx(1, "%s: mktime failed", fn);
- /* extract expire time for later use */
at = X509_CRL_get0_nextUpdate(crl->x509_crl);
if (at == NULL) {
warnx("%s: X509_CRL_get0_nextUpdate failed", fn);
goto out;
}
- memset(_tm, 0, sizeof(expires_tm));
- if (ASN1_time_parse(at->data, at->length, _tm, 0) == -1) {
+ if (x509_get_time(at, >expires) == -1) {
warnx("%s: ASN1_time_parse failed", fn);
goto out;
}
- if ((crl->expires = mktime(_tm)) == -1)
- errx(1, "%s: mktime failed", fn);
rc = 1;
out:
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
retrieving revision 1.118
diff -u -p -r1.118 extern.h
--- extern.h8 Feb 2022 14:53:03 - 1.118
+++ extern.h10 Feb 2022 13:27:35 -
@@ -585,13 +585,16 @@ char *x509_get_crl(X509 *, const char *
char *x509_crl_get_aki(X509_CRL *, const char *);
char *x509_get_pubkey(X509 *, const char *);
enum cert_purpose x509_get_purpose(X509 *, const char *);
+int x509_get_time(const ASN1_TIME *, time_t *);
/* printers */
-void tal_print(const struct tal *);
-void cert_print(const struct cert *);
-void mft_print(const struct mft *);
-void roa_print(const struct roa *);
-void gbr_print(const struct gbr *);
+char *time2str(time_t);
+voidtal_print(const struct tal *);
+voidcert_print(const struct cert *);
+voidcrl_print(const struct crl *);
+voidmft_print(const struct mft *);
+voidroa_print(const struct roa *);
+voidgbr_print(const struct gbr *);
/* Output! */
Index: parser.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/parser.c,v
retrieving revision 1.63
diff -u -p -r1.63 parser.c
--- parser.c8 Feb 2022 14:53:03 - 1.63
+++ parser.c10 Feb 2022 13:42:12 -
@@ -94,19 +94,6 @@ repo_add(unsigned int id, char *path, ch
errx(1, "repository already added: id %d, %s", id, path);
}
-static char *
-time2str(time_t t)
-{
- static char buf[64];
- struct tm tm;
-
- if (gmtime_r(, ) == NULL)
- return "could not convert time";
-
- strftime(buf, sizeof(buf), "%h %d %T %Y %Z", );
- return buf;
-}
-
/*
* Build access path to file based on repoid, path, location and file values.
*/
@@ -1009,6 +996,7 @@ proc_parser_file(char *file, unsigned ch
static int num;
X509 *x509 = NULL;
struct cert *cert = NULL;
+ struct crl *crl = NULL;
struct mft *mft = NULL;
struct roa *roa = NULL;
struct gbr *gbr = NULL;
@@ -1044,6 +1032,12 @@ proc_parser_file(char *file, unsigned ch
if (X509_up_ref(x509) == 0)
errx(1, "%s: X509_up_ref failed", __func__);
break;
+ case RTYPE_CRL:
+ crl = crl_parse(file, buf, len);
+ if (crl == NULL)
+ break;
+ crl_print(crl);
+ break;
case RTYPE_MFT:
mft = mft_parse(, file, buf, len);
if (mft == NULL)
@@ -1074,7 +1068,6 @@ proc_parser_file(char *file, unsigned ch
break;
tal_print(tal);
break;
-
apm -m means one of two things now
With the recent change to apm -m, reporting either the battery lifetime or the estimated time to charge (thank you), the manpage seems to have been left behind. While here, tweak some of the wording: - "in minutes" or "in percent" is not parenthetical; say it explicitly - surely -a displays the charger status, not the charger - AC is AC, not A/C, right? Jan Index: apm.8 === RCS file: /cvs/src/usr.sbin/apm/apm.8,v retrieving revision 1.44 diff -u -p -r1.44 apm.8 --- apm.8 3 Nov 2021 19:54:28 - 1.44 +++ apm.8 10 Feb 2022 13:52:38 - @@ -59,7 +59,7 @@ The options are as follows: .It Fl A Switch to automatic performance adjustment mode (the default). .It Fl a -Display the external charger (A/C status). +Display the external charger (AC) status. 0 means disconnected, 1 means connected, 2 means backup power source, and 255 means unknown. .It Fl b @@ -82,9 +82,10 @@ setting .Va hw.setperf to 0. .It Fl l -Display the estimated battery lifetime (in percent). +Display the estimated battery lifetime in percent. .It Fl m -Display the estimated battery lifetime (in minutes). +Display the estimated battery lifetime in minutes when running or battery, +or the estimated time to recharge when running on an external charger. .It Fl P Display the performance adjustment mode. 0 means manual mode.
Re: rpki-client: plug leak in http_parse_header()
On Thu, Feb 10, 2022 at 11:45:06AM +0100, Theo Buehler wrote: > > > Index: rrdp.c > > > === > > > RCS file: /cvs/src/usr.sbin/rpki-client/rrdp.c,v > > > retrieving revision 1.21 > > > diff -u -p -r1.21 rrdp.c > > > --- rrdp.c23 Jan 2022 12:09:24 - 1.21 > > > +++ rrdp.c10 Feb 2022 07:41:54 - > > > @@ -429,6 +429,7 @@ rrdp_input_handler(int fd) > > > errx(1, "%s: bad internal state", s->local); > > > > > > s->res = res; > > > + free(s->last_mod); > > > s->last_mod = last_mod; > > > s->state |= RRDP_STATE_HTTP_DONE; > > > rrdp_finished(s); > > > > > > > This one needs more thought. rrdp_finished() -> notification_done() moves > > the last_mod into nxml->current->last_mod and so you can end up with > > either a double free or use after free. > > I saw that and thought ownership was transferred to > s->nxml->current->last_mod since s->last_mod is nulled out right after > > s->task = notification_done(s->nxml, s->last_mod); > s->last_mod = NULL; > > I can't see where that's freed though. Indeed. I missed that somehow. So your diff is indeed OK. The free happens in rrdp_free() which is OK. There is only one call to notification_done() so that is fine. So your diff is indeed OK and should go in. OK claudio@ > > That code needs a proper refactor. > > That may well be... > > > I think it would be best to remove last_mod from the rrdp state and just > > pass it as char * to rrdp_finished. Still need to look when and how to > > free the value reliably. Actually that does not really work because the RRDP_HTTP_FIN could arrive before all data has been handled by rrdp_data_handler(). That is why it is in the state. As said, OK on the original diff. -- :wq Claudio
Re: rpki-client: plug leak in http_parse_header()
> > Index: rrdp.c > > === > > RCS file: /cvs/src/usr.sbin/rpki-client/rrdp.c,v > > retrieving revision 1.21 > > diff -u -p -r1.21 rrdp.c > > --- rrdp.c 23 Jan 2022 12:09:24 - 1.21 > > +++ rrdp.c 10 Feb 2022 07:41:54 - > > @@ -429,6 +429,7 @@ rrdp_input_handler(int fd) > > errx(1, "%s: bad internal state", s->local); > > > > s->res = res; > > + free(s->last_mod); > > s->last_mod = last_mod; > > s->state |= RRDP_STATE_HTTP_DONE; > > rrdp_finished(s); > > > > This one needs more thought. rrdp_finished() -> notification_done() moves > the last_mod into nxml->current->last_mod and so you can end up with > either a double free or use after free. I saw that and thought ownership was transferred to s->nxml->current->last_mod since s->last_mod is nulled out right after s->task = notification_done(s->nxml, s->last_mod); s->last_mod = NULL; I can't see where that's freed though. > That code needs a proper refactor. That may well be... > I think it would be best to remove last_mod from the rrdp state and just > pass it as char * to rrdp_finished. Still need to look when and how to > free the value reliably. Thanks.
Re: unlock mmap(2) for anonymous mappings
> Date: Thu, 10 Feb 2022 10:19:20 +
> From: Klemens Nanni
>
> On Mon, Feb 07, 2022 at 02:12:52PM +0100, Mark Kettenis wrote:
> > > Date: Mon, 7 Feb 2022 12:11:42 +
> > > From: Klemens Nanni
> > >
> > > On Mon, Feb 07, 2022 at 12:41:27PM +0100, Mark Kettenis wrote:
>
> > > > So there is the existing UVM_MAP_REQ_WRITE(). Compared to
> > > > vm_map_assert_wrlock() it checks the reference count of the map. I
> > > > think that's questionable, so these should probably be replaced by
> > > > vm_map_assert_wrlock().
> > >
> > > Yes, I'd replace the old macro with the new functions in a separate diff.
> >
> > Fair enough. This has been tested extensively and it doesn't make a
> > lot of sense to start all over again.
>
> Here's the replacement diff.
>
> OK?
If this survives a make build, I think this should be safe.
ok kettenis@
> Index: uvm_map.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_map.c,v
> retrieving revision 1.282
> diff -u -p -r1.282 uvm_map.c
> --- uvm_map.c 21 Dec 2021 22:21:32 - 1.282
> +++ uvm_map.c 10 Feb 2022 09:23:21 -
> @@ -326,16 +326,6 @@ vaddr_t uvm_maxkaddr;
> /*
> * Locking predicate.
> */
> -#define UVM_MAP_REQ_WRITE(_map)
> \
> - do {\
> - if ((_map)->ref_count > 0) {\
> - if (((_map)->flags & VM_MAP_INTRSAFE) == 0) \
> - rw_assert_wrlock(&(_map)->lock);\
> - else\
> - MUTEX_ASSERT_LOCKED(&(_map)->mtx); \
> - } \
> - } while (0)
> -
> #define vm_map_modflags(map, set, clear)
> \
> do {\
> mtx_enter(&(map)->flags_lock); \
> @@ -407,7 +397,7 @@ uvm_mapent_free_insert(struct vm_map *ma
> KDASSERT((entry->fspace & (vaddr_t)PAGE_MASK) == 0);
> KASSERT((entry->etype & UVM_ET_FREEMAPPED) == 0);
>
> - UVM_MAP_REQ_WRITE(map);
> + vm_map_assert_wrlock(map);
>
> /* Actual insert: forward to uaddr pointer. */
> if (uaddr != NULL) {
> @@ -433,7 +423,7 @@ uvm_mapent_free_remove(struct vm_map *ma
>
> KASSERT((entry->etype & UVM_ET_FREEMAPPED) != 0 || uaddr == NULL);
> KASSERT(uvm_map_uaddr_e(map, entry) == uaddr);
> - UVM_MAP_REQ_WRITE(map);
> + vm_map_assert_wrlock(map);
>
> if (uaddr != NULL) {
> fun = uaddr->uaddr_functions;
> @@ -460,7 +450,7 @@ uvm_mapent_addr_insert(struct vm_map *ma
> TRACEPOINT(uvm, map_insert,
> entry->start, entry->end, entry->protection, NULL);
>
> - UVM_MAP_REQ_WRITE(map);
> + vm_map_assert_wrlock(map);
> res = RBT_INSERT(uvm_map_addr, >addr, entry);
> if (res != NULL) {
> panic("uvm_mapent_addr_insert: map %p entry %p "
> @@ -483,7 +473,7 @@ uvm_mapent_addr_remove(struct vm_map *ma
> TRACEPOINT(uvm, map_remove,
> entry->start, entry->end, entry->protection, NULL);
>
> - UVM_MAP_REQ_WRITE(map);
> + vm_map_assert_wrlock(map);
> res = RBT_REMOVE(uvm_map_addr, >addr, entry);
> if (res != entry)
> panic("uvm_mapent_addr_remove");
>
Re: rpki-client: disk space warning on btrfs
On Thu, Feb 10, 2022 at 09:13:25AM +0100, Theo Buehler wrote:
> This is purely cosmetic. I did some testing on fedora which ships with
> btrfs by default. btrfs is special in that df -i and other tools always
> report 0 inodes. As a consequence, each rpki-client run prints the disk
> space warning, which seems a bit silly. Should we special case the 0
> inodes case? If your disk is actually that full, you'll find out quickly
> enough.
>
> On this box I see this:
>
> WARNING: rpki-client may need more than the available disk space
> on the file-system holding /usr/local/var/cache/rpki-client.
> available space: 118878020kB, suggested minimum 512000kB
> available inodes 0, suggested minimum 30
>
> Index: main.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v
> retrieving revision 1.187
> diff -u -p -r1.187 main.c
> --- main.c28 Jan 2022 15:30:23 - 1.187
> +++ main.c10 Feb 2022 08:06:29 -
> @@ -695,7 +695,8 @@ check_fs_size(int fd, const char *cached
> if (fstatvfs(fd, ) == -1)
> err(1, "statfs %s", cachedir);
>
> - if (fs.f_bavail < minsize / fs.f_frsize || fs.f_favail < minnode) {
> + if (fs.f_bavail < minsize / fs.f_frsize ||
> + (fs.f_favail > 0 && fs.f_favail < minnode)) {
> fprintf(stderr, "WARNING: rpki-client may need more than "
> "the available disk space\n"
> "on the file-system holding %s.\n", cachedir);
>
Fine with me. Rather dumb default from Linux here.
--
:wq Claudio
Re: fw_update(8): lock pkg database while running
On 2022/02/10 08:42, Marc Espie wrote:
> On Wed, Feb 09, 2022 at 07:30:46PM -0800, Andrew Hewus Fresh wrote:
> > I was reminded that fw_update(8) updates the package database without
> > locking currently. That can cause issues when running it concurrently
> > with pkg_add, for example starting `pkg_add -u` in one terminal and
> > `sysupgrade` in another.
> >
> > This diff checks to see if perl is available and if so starts a perl
> > co-process that locks the database and then kills it when exiting.
> >
> > (Figuring out how to wait for the lock to be acquired and find out the
> > pid of the co-process was a bit of a challenge, so if someone has a
> > suggestion on improving that, I'm open to suggestions)
> >
> > Comments, OK?
> >
> >
> > Index: usr.sbin/fw_update/fw_update.sh
> > ===
> > RCS file: /cvs/src/usr.sbin/fw_update/fw_update.sh,v
> > retrieving revision 1.36
> > diff -u -p -r1.36 fw_update.sh
> > --- usr.sbin/fw_update/fw_update.sh 10 Feb 2022 00:29:32 - 1.36
> > +++ usr.sbin/fw_update/fw_update.sh 10 Feb 2022 03:22:20 -
> > @@ -42,11 +42,13 @@ INSTALL=true
> > LOCALSRC=
> >
> > unset FTPPID
> > +unset LOCKPID
> > unset FWPKGTMP
> > REMOVE_LOCALSRC=false
> > cleanup() {
> > set +o errexit # ignore errors from killing ftp
> > [ "${FTPPID:-}" ] && kill -TERM -"$FTPPID" 2>/dev/null
> > + [ "${LOCKPID:-}" ] && kill -TERM -"$LOCKPID" 2>/dev/null
> > [ "${FWPKGTMP:-}" ] && rm -rf "$FWPKGTMP"
> > "$REMOVE_LOCALSRC" && rm -rf "$LOCALSRC"
> > [ -e "${CFILE}" ] && [ ! -s "$CFILE" ] && rm -f "$CFILE"
> > @@ -194,6 +196,36 @@ firmware_devicename() {
> > echo "$_d"
> > }
> >
> > +lock_db() {
> > + [ "${LOCKPID:-}" ] && return 0
> > +
> > + # The installer doesn't have perl, so we can't lock there
> > + [ -e /usr/bin/perl ] || return 0
> > +
> > + set -o monitor
> > + perl <<'EOL' |&
> > + use v5.16;
> > + use warnings;
> > + use OpenBSD::PackageInfo qw< lock_db unlock_db >;
> > + use OpenBSD::State;
> > +
> > + $|=1;
> > +
> > + lock_db(0, OpenBSD::State->new);
> > + END { unlock_db }
> > + $SIG{TERM} = sub { exit };
> > +
> > + say $$;
> > + sleep;
> > +EOL
> > + set +o monitor
> > +
> > + read -rp LOCKPID
> > +
> > + return 0
> > +}
> > +
> > +
> > installed_firmware() {
> > local _pre="$1" _match="$2" _post="$3" _firmware _fw
> > set -sA _firmware -- $(
> > @@ -401,6 +433,7 @@ set -sA devices -- "$@"
> >
> > if "$DELETE"; then
> > [ "$OPT_F" ] && echo "Cannot use -F and -d" >&2 && usage
> > + lock_db
> >
> > # Show the "Uninstall" message when just deleting not upgrading
> > ((VERBOSE)) && VERBOSE=3
> > @@ -463,6 +496,8 @@ else
> > fi
> >
> > [ "${devices[*]:-}" ] || exit
> > +
> > +lock_db
> >
> > added=''
> > updated=''
> >
> It's one of the cases where you can actually use the newer OpenBSD::BaseState
> where I explicitly split the printing and system functions.
>
> e.g.,
> use OpenBSD::BaseState;
>
> lock_db(0, 'OpenBSD::BaseState');
> should work just as well
>
That also works for me.
Re: rpki-client: plug leak in http_parse_header()
On Thu, Feb 10, 2022 at 08:44:08AM +0100, Theo Buehler wrote:
> On Thu, Feb 10, 2022 at 07:51:45AM +0100, Theo Buehler wrote:
> > At this point conn->last_modified may or may not be allocated.
> > If it is, overriting it will leak 30 bytes.
>
> rrdp_input_handler() has a leak of the same kind.
>
> Index: http.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/http.c,v
> retrieving revision 1.52
> diff -u -p -r1.52 http.c
> --- http.c23 Jan 2022 12:09:24 - 1.52
> +++ http.c10 Feb 2022 02:09:38 -
> @@ -1231,6 +1231,7 @@ http_parse_header(struct http_connection
> } else if (strncasecmp(cp, LAST_MODIFIED,
> sizeof(LAST_MODIFIED) - 1) == 0) {
> cp += sizeof(LAST_MODIFIED) - 1;
> + free(conn->last_modified);
> if ((conn->last_modified = strdup(cp)) == NULL)
> err(1, NULL);
> }
This one is OK claudio@
> Index: rrdp.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/rrdp.c,v
> retrieving revision 1.21
> diff -u -p -r1.21 rrdp.c
> --- rrdp.c23 Jan 2022 12:09:24 - 1.21
> +++ rrdp.c10 Feb 2022 07:41:54 -
> @@ -429,6 +429,7 @@ rrdp_input_handler(int fd)
> errx(1, "%s: bad internal state", s->local);
>
> s->res = res;
> + free(s->last_mod);
> s->last_mod = last_mod;
> s->state |= RRDP_STATE_HTTP_DONE;
> rrdp_finished(s);
>
This one needs more thought. rrdp_finished() -> notification_done() moves
the last_mod into nxml->current->last_mod and so you can end up with
either a double free or use after free. That code needs a proper refactor.
I think it would be best to remove last_mod from the rrdp state and just
pass it as char * to rrdp_finished. Still need to look when and how to
free the value reliably.
--
:wq Claudio
Re: fw_update(8): lock pkg database while running
On 2022/02/09 19:30, Andrew Hewus Fresh wrote:
> I was reminded that fw_update(8) updates the package database without
> locking currently. That can cause issues when running it concurrently
> with pkg_add, for example starting `pkg_add -u` in one terminal and
> `sysupgrade` in another.
>
> This diff checks to see if perl is available and if so starts a perl
> co-process that locks the database and then kills it when exiting.
>
> (Figuring out how to wait for the lock to be acquired and find out the
> pid of the co-process was a bit of a challenge, so if someone has a
> suggestion on improving that, I'm open to suggestions)
>
> Comments, OK?
Works for me, and as fw_update is using the system package database
then it does need to lock it. (Also it prints feedback, which is good
- SIGINFO is handled by the sleep or ksh process so it's normally
hard to see what's happening when fw_update is taking a long time).
FWIW OK with me.
$ doas fw_update
Package database already locked... awaiting release... done!
fw_update: added none; updated iwm; kept bwfm,intel,inteldrm,iwn,iwx,uvideo,vmm
> Index: usr.sbin/fw_update/fw_update.sh
> ===
> RCS file: /cvs/src/usr.sbin/fw_update/fw_update.sh,v
> retrieving revision 1.36
> diff -u -p -r1.36 fw_update.sh
> --- usr.sbin/fw_update/fw_update.sh 10 Feb 2022 00:29:32 - 1.36
> +++ usr.sbin/fw_update/fw_update.sh 10 Feb 2022 03:22:20 -
> @@ -42,11 +42,13 @@ INSTALL=true
> LOCALSRC=
>
> unset FTPPID
> +unset LOCKPID
> unset FWPKGTMP
> REMOVE_LOCALSRC=false
> cleanup() {
> set +o errexit # ignore errors from killing ftp
> [ "${FTPPID:-}" ] && kill -TERM -"$FTPPID" 2>/dev/null
> + [ "${LOCKPID:-}" ] && kill -TERM -"$LOCKPID" 2>/dev/null
> [ "${FWPKGTMP:-}" ] && rm -rf "$FWPKGTMP"
> "$REMOVE_LOCALSRC" && rm -rf "$LOCALSRC"
> [ -e "${CFILE}" ] && [ ! -s "$CFILE" ] && rm -f "$CFILE"
> @@ -194,6 +196,36 @@ firmware_devicename() {
> echo "$_d"
> }
>
> +lock_db() {
> + [ "${LOCKPID:-}" ] && return 0
> +
> + # The installer doesn't have perl, so we can't lock there
> + [ -e /usr/bin/perl ] || return 0
> +
> + set -o monitor
> + perl <<'EOL' |&
> + use v5.16;
> + use warnings;
> + use OpenBSD::PackageInfo qw< lock_db unlock_db >;
> + use OpenBSD::State;
> +
> + $|=1;
> +
> + lock_db(0, OpenBSD::State->new);
> + END { unlock_db }
> + $SIG{TERM} = sub { exit };
> +
> + say $$;
> + sleep;
> +EOL
> + set +o monitor
> +
> + read -rp LOCKPID
> +
> + return 0
> +}
> +
> +
> installed_firmware() {
> local _pre="$1" _match="$2" _post="$3" _firmware _fw
> set -sA _firmware -- $(
> @@ -401,6 +433,7 @@ set -sA devices -- "$@"
>
> if "$DELETE"; then
> [ "$OPT_F" ] && echo "Cannot use -F and -d" >&2 && usage
> + lock_db
>
> # Show the "Uninstall" message when just deleting not upgrading
> ((VERBOSE)) && VERBOSE=3
> @@ -463,6 +496,8 @@ else
> fi
>
> [ "${devices[*]:-}" ] || exit
> +
> +lock_db
>
> added=''
> updated=''
>
Re: unlock mmap(2) for anonymous mappings
On Mon, Feb 07, 2022 at 02:12:52PM +0100, Mark Kettenis wrote:
> > Date: Mon, 7 Feb 2022 12:11:42 +
> > From: Klemens Nanni
> >
> > On Mon, Feb 07, 2022 at 12:41:27PM +0100, Mark Kettenis wrote:
> > > So there is the existing UVM_MAP_REQ_WRITE(). Compared to
> > > vm_map_assert_wrlock() it checks the reference count of the map. I
> > > think that's questionable, so these should probably be replaced by
> > > vm_map_assert_wrlock().
> >
> > Yes, I'd replace the old macro with the new functions in a separate diff.
>
> Fair enough. This has been tested extensively and it doesn't make a
> lot of sense to start all over again.
Here's the replacement diff.
OK?
Index: uvm_map.c
===
RCS file: /cvs/src/sys/uvm/uvm_map.c,v
retrieving revision 1.282
diff -u -p -r1.282 uvm_map.c
--- uvm_map.c 21 Dec 2021 22:21:32 - 1.282
+++ uvm_map.c 10 Feb 2022 09:23:21 -
@@ -326,16 +326,6 @@ vaddr_t uvm_maxkaddr;
/*
* Locking predicate.
*/
-#define UVM_MAP_REQ_WRITE(_map)
\
- do {\
- if ((_map)->ref_count > 0) {\
- if (((_map)->flags & VM_MAP_INTRSAFE) == 0) \
- rw_assert_wrlock(&(_map)->lock);\
- else\
- MUTEX_ASSERT_LOCKED(&(_map)->mtx); \
- } \
- } while (0)
-
#definevm_map_modflags(map, set, clear)
\
do {\
mtx_enter(&(map)->flags_lock); \
@@ -407,7 +397,7 @@ uvm_mapent_free_insert(struct vm_map *ma
KDASSERT((entry->fspace & (vaddr_t)PAGE_MASK) == 0);
KASSERT((entry->etype & UVM_ET_FREEMAPPED) == 0);
- UVM_MAP_REQ_WRITE(map);
+ vm_map_assert_wrlock(map);
/* Actual insert: forward to uaddr pointer. */
if (uaddr != NULL) {
@@ -433,7 +423,7 @@ uvm_mapent_free_remove(struct vm_map *ma
KASSERT((entry->etype & UVM_ET_FREEMAPPED) != 0 || uaddr == NULL);
KASSERT(uvm_map_uaddr_e(map, entry) == uaddr);
- UVM_MAP_REQ_WRITE(map);
+ vm_map_assert_wrlock(map);
if (uaddr != NULL) {
fun = uaddr->uaddr_functions;
@@ -460,7 +450,7 @@ uvm_mapent_addr_insert(struct vm_map *ma
TRACEPOINT(uvm, map_insert,
entry->start, entry->end, entry->protection, NULL);
- UVM_MAP_REQ_WRITE(map);
+ vm_map_assert_wrlock(map);
res = RBT_INSERT(uvm_map_addr, >addr, entry);
if (res != NULL) {
panic("uvm_mapent_addr_insert: map %p entry %p "
@@ -483,7 +473,7 @@ uvm_mapent_addr_remove(struct vm_map *ma
TRACEPOINT(uvm, map_remove,
entry->start, entry->end, entry->protection, NULL);
- UVM_MAP_REQ_WRITE(map);
+ vm_map_assert_wrlock(map);
res = RBT_REMOVE(uvm_map_addr, >addr, entry);
if (res != entry)
panic("uvm_mapent_addr_remove");
Unlock getsockname(2) syscall
For inet and UNIX sockets it fills passed 'sockaddr' structure with
socket's address. For key management and route domain sockets it just
returns error.
ok?
Index: sys/kern/syscalls.master
===
RCS file: /cvs/src/sys/kern/syscalls.master,v
retrieving revision 1.222
diff -u -p -r1.222 syscalls.master
--- sys/kern/syscalls.master11 Jan 2022 08:09:14 - 1.222
+++ sys/kern/syscalls.master10 Feb 2022 08:23:45 -
@@ -99,7 +99,7 @@
socklen_t *anamelen); }
31 STD NOLOCK { int sys_getpeername(int fdes, struct sockaddr *asa, \
socklen_t *alen); }
-32 STD { int sys_getsockname(int fdes, struct sockaddr *asa, \
+32 STD NOLOCK { int sys_getsockname(int fdes, struct sockaddr *asa, \
socklen_t *alen); }
33 STD { int sys_access(const char *path, int amode); }
34 STD { int sys_chflags(const char *path, u_int flags); }
Re: rpki-client: check crl validity times
On Wed, Feb 09, 2022 at 08:14:55PM +0100, Claudio Jeker wrote:
> On Wed, Feb 09, 2022 at 02:59:41PM +0100, Theo Buehler wrote:
> > We should not use CRLs if now isn't between thisUpdate and nextUpdate.
> > This also ensures that thisUpdate <= nextUpdate. While the verifier will
> > catch all this, doing this early will often remove one of the two
> > possible choices of a CRL to use for a MFT since these are typically
> > short-lived. While there, let's simplify the exit of crl_parse().
> >
> > I was pondering whether we should mark such CRLs stale and add them to
> > the statistics as we do for MFTs, but I think it's not super
> > interesting.
>
> I'm not fully convinced by this. Mainly not returning a CRL will alter the
> error reported by X509_verify_cert() and make it more confusing
> (especially since the warnings in crl_parse are only if verbose > 1.
>
> I would not mind to do this check in parse_load_crl_from_mft().
> Another thing we should consider is that the CRL used to validate the MFT
> should also be the one used to validate the rest. This is currently not
> enforced.
>
> Will need to think about this more.
I agree. Let me drop this patch for now. I just can't shake that gut
feeling that what we're doing with CRLs and MFTs is not quite right.
Sadly, I don't have a good idea or a good reason.
>
> > Index: crl.c
> > ===
> > RCS file: /cvs/src/usr.sbin/rpki-client/crl.c,v
> > retrieving revision 1.13
> > diff -u -p -r1.13 crl.c
> > --- crl.c 8 Feb 2022 14:53:03 - 1.13
> > +++ crl.c 9 Feb 2022 06:23:30 -
> > @@ -34,7 +34,7 @@ crl_parse(const char *fn, const unsigned
> > struct crl *crl;
> > const ASN1_TIME *at;
> > struct tmissued_tm, expires_tm;
> > - int rc = 0;
> > + time_t now;
> >
> > /* just fail for empty buffers, the warning was printed elsewhere */
> > if (der == NULL)
> > @@ -66,7 +66,6 @@ crl_parse(const char *fn, const unsigned
> > if ((crl->issued = mktime(_tm)) == -1)
> > errx(1, "%s: mktime failed", fn);
> >
> > - /* extract expire time for later use */
> > at = X509_CRL_get0_nextUpdate(crl->x509_crl);
> > if (at == NULL) {
> > warnx("%s: X509_CRL_get0_nextUpdate failed", fn);
> > @@ -80,13 +79,25 @@ crl_parse(const char *fn, const unsigned
> > if ((crl->expires = mktime(_tm)) == -1)
> > errx(1, "%s: mktime failed", fn);
> >
> > - rc = 1;
> > - out:
> > - if (rc == 0) {
> > - crl_free(crl);
> > - crl = NULL;
> > + now = time(NULL);
> > + if (now < crl->issued) {
> > + if (verbose > 1)
> > + warnx("%s: crl not yet valid %s", fn,
> > + time2str(crl->issued));
> > + goto out;
> > + }
> > + if (now > crl->expires) {
> > + if (verbose > 1)
> > + warnx("%s: crl expired on %s", fn,
> > + time2str(crl->expires));
> > + goto out;
> > }
> > +
> > return crl;
> > +
> > + out:
> > + crl_free(crl);
> > + return NULL;
> > }
> >
> > static inline int
> > Index: extern.h
> > ===
> > RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
> > retrieving revision 1.118
> > diff -u -p -r1.118 extern.h
> > --- extern.h8 Feb 2022 14:53:03 - 1.118
> > +++ extern.h9 Feb 2022 06:21:49 -
> > @@ -502,6 +502,7 @@ void entity_free(struct entity *);
> > voidentity_read_req(struct ibuf *, struct entity *);
> > voidentityq_flush(struct entityq *, struct repo *);
> > voidproc_parser(int) __attribute__((noreturn));
> > +char *time2str(time_t);
> >
> > /* Rsync-specific. */
> >
> > Index: parser.c
> > ===
> > RCS file: /cvs/src/usr.sbin/rpki-client/parser.c,v
> > retrieving revision 1.63
> > diff -u -p -r1.63 parser.c
> > --- parser.c8 Feb 2022 14:53:03 - 1.63
> > +++ parser.c9 Feb 2022 06:19:40 -
> > @@ -94,7 +94,7 @@ repo_add(unsigned int id, char *path, ch
> > errx(1, "repository already added: id %d, %s", id, path);
> > }
> >
> > -static char *
> > +char *
> > time2str(time_t t)
> > {
> > static char buf[64];
> >
>
> --
> :wq Claudio
rpki-client: disk space warning on btrfs
This is purely cosmetic. I did some testing on fedora which ships with
btrfs by default. btrfs is special in that df -i and other tools always
report 0 inodes. As a consequence, each rpki-client run prints the disk
space warning, which seems a bit silly. Should we special case the 0
inodes case? If your disk is actually that full, you'll find out quickly
enough.
On this box I see this:
WARNING: rpki-client may need more than the available disk space
on the file-system holding /usr/local/var/cache/rpki-client.
available space: 118878020kB, suggested minimum 512000kB
available inodes 0, suggested minimum 30
Index: main.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v
retrieving revision 1.187
diff -u -p -r1.187 main.c
--- main.c 28 Jan 2022 15:30:23 - 1.187
+++ main.c 10 Feb 2022 08:06:29 -
@@ -695,7 +695,8 @@ check_fs_size(int fd, const char *cached
if (fstatvfs(fd, ) == -1)
err(1, "statfs %s", cachedir);
- if (fs.f_bavail < minsize / fs.f_frsize || fs.f_favail < minnode) {
+ if (fs.f_bavail < minsize / fs.f_frsize ||
+ (fs.f_favail > 0 && fs.f_favail < minnode)) {
fprintf(stderr, "WARNING: rpki-client may need more than "
"the available disk space\n"
"on the file-system holding %s.\n", cachedir);
