Re: userdel: remove login group for =uid
On 2023/05/24 20:00, Omar Polo wrote: > On 2023/05/19 10:24:58 -0600, Todd C. Miller wrote: > > If /etc/usermgmt.conf has a line like: > > > > group =uid > > > > where a new user's group ID in the passwd file is the same as their > > user ID, remove that group when the user is removed. The group is > > only removed if it matches the login name, has a gid that matches > > the user's uid, and has no other members. > > > > This makes our userdel(8) behave more like the version on other > > systems. > > > > Opinions? This is something that has always bothered me and can > > result in uid/gid mismatches if you remove a user, then re-add them > > without removing the login group first. > > I have been bitten by this too and later been (pleasently) surprised > when found that on other systems removing a users removes the group > too. It makes sense to me. > > > Thoughts or strong opinions? > > fwiw i like the change, ok for me. +1 > As Aisha pointed out, pkg_delete hints could be updated too. If that is done, pkg_delete would need to check whether the group will actually get removed i.e. make sure that no other user has been added to the group.
Re: pfioctl: drop net lock from SIOC{S,G}LIMIT
On Thu, May 25, 2023 at 03:20:04AM +, Klemens Nanni wrote:
> pfsync_in_bus() looks like the only place where the static array
> pf_pool_limits[] is accessed without the pf lock, so grab it there.
>
> Limits themselves are protected by the pf lock and pool(9)s are never
> destroyed and have builtint per-pool locks, so the net lock is not
> needed.
>
> (pf_pool_limits[] access in DIOCXCOMMIT remains under pf *and net* lock
> until the rest in there gets pulled out of the net lock.)
>
> Feedback? OK?
Correct diff without typo and with missing locking comment.
Index: pf_ioctl.c
===
RCS file: /cvs/src/sys/net/pf_ioctl.c,v
retrieving revision 1.404
diff -u -p -r1.404 pf_ioctl.c
--- pf_ioctl.c 11 May 2023 12:36:22 - 1.404
+++ pf_ioctl.c 24 May 2023 13:48:52 -
@@ -2094,44 +2094,37 @@ pfioctl(dev_t dev, u_long cmd, caddr_t a
error = EINVAL;
goto fail;
}
- NET_LOCK();
PF_LOCK();
pl->limit = pf_pool_limits[pl->index].limit;
PF_UNLOCK();
- NET_UNLOCK();
break;
}
case DIOCSETLIMIT: {
struct pfioc_limit *pl = (struct pfioc_limit *)addr;
- NET_LOCK();
PF_LOCK();
if (pl->index < 0 || pl->index >= PF_LIMIT_MAX) {
error = EINVAL;
PF_UNLOCK();
- NET_UNLOCK();
goto fail;
}
if (((struct pool *)pf_pool_limits[pl->index].pp)->pr_nout >
pl->limit) {
error = EBUSY;
PF_UNLOCK();
- NET_UNLOCK();
goto fail;
}
/* Fragments reference mbuf clusters. */
if (pl->index == PF_LIMIT_FRAGS && pl->limit > nmbclust) {
error = EINVAL;
PF_UNLOCK();
- NET_UNLOCK();
goto fail;
}
pf_pool_limits[pl->index].limit_new = pl->limit;
pl->limit = pf_pool_limits[pl->index].limit;
PF_UNLOCK();
- NET_UNLOCK();
break;
}
Index: if_pfsync.c
===
RCS file: /cvs/src/sys/net/if_pfsync.c,v
retrieving revision 1.315
diff -u -p -r1.315 if_pfsync.c
--- if_pfsync.c 18 May 2023 12:10:04 - 1.315
+++ if_pfsync.c 25 May 2023 03:27:29 -
@@ -1009,10 +1009,12 @@ pfsync_in_bus(caddr_t buf, int len, int
switch (bus->status) {
case PFSYNC_BUS_START:
+ PF_LOCK();
timeout_add(>sc_bulkfail_tmo, 4 * hz +
pf_pool_limits[PF_LIMIT_STATES].limit /
((sc->sc_if.if_mtu - PFSYNC_MINPKT) /
sizeof(struct pfsync_state)));
+ PF_UNLOCK();
DPFPRINTF(LOG_INFO, "received bulk update start");
break;
@@ -2037,10 +2039,12 @@ pfsync_request_full_update(struct pfsync
#endif
pfsync_sync_ok = 0;
DPFPRINTF(LOG_INFO, "requesting bulk update");
+ PF_LOCK();
timeout_add(>sc_bulkfail_tmo, 4 * hz +
pf_pool_limits[PF_LIMIT_STATES].limit /
((sc->sc_if.if_mtu - PFSYNC_MINPKT) /
sizeof(struct pfsync_state)));
+ PF_UNLOCK();
pfsync_request_update(0, 0);
}
}
pfioctl: drop net lock from SIOC{S,G}LIMIT
pfsync_in_bus() looks like the only place where the static array
pf_pool_limits[] is accessed without the pf lock, so grab it there.
Limits themselves are protected by the pf lock and pool(9)s are never
destroyed and have builtint per-pool locks, so the net lock is not
needed.
(pf_pool_limits[] access in DIOCXCOMMIT remains under pf *and net* lock
until the rest in there gets pulled out of the net lock.)
Feedback? OK?
Index: if_pfsync.c
===
RCS file: /cvs/src/sys/net/if_pfsync.c,v
retrieving revision 1.315
diff -u -p -r1.315 if_pfsync.c
--- if_pfsync.c 18 May 2023 12:10:04 - 1.315
+++ if_pfsync.c 18 May 2023 13:49:34 -
@@ -1009,10 +1009,12 @@ pfsync_in_bus(caddr_t buf, int len, int
switch (bus->status) {
case PFSYNC_BUS_START:
+ PF_LOCK();
timeout_add(>sc_bulkfail_tmo, 4 * hz +
pf_pool_limits[PF_LIMIT_STATES].limit /
((sc->sc_if.if_mtu - PFSYNC_MINPKT) /
sizeof(struct pfsync_state)));
+ PF_LOCK();
DPFPRINTF(LOG_INFO, "received bulk update start");
break;
@@ -2037,10 +2039,12 @@ pfsync_request_full_update(struct pfsync
#endif
pfsync_sync_ok = 0;
DPFPRINTF(LOG_INFO, "requesting bulk update");
+ PF_LOCK();
timeout_add(>sc_bulkfail_tmo, 4 * hz +
pf_pool_limits[PF_LIMIT_STATES].limit /
((sc->sc_if.if_mtu - PFSYNC_MINPKT) /
sizeof(struct pfsync_state)));
+ PF_UNLOCK();
pfsync_request_update(0, 0);
}
}
Index: pf_ioctl.c
===
RCS file: /cvs/src/sys/net/pf_ioctl.c,v
retrieving revision 1.404
diff -u -p -r1.404 pf_ioctl.c
--- pf_ioctl.c 11 May 2023 12:36:22 - 1.404
+++ pf_ioctl.c 24 May 2023 13:48:52 -
@@ -2094,44 +2094,37 @@ pfioctl(dev_t dev, u_long cmd, caddr_t a
error = EINVAL;
goto fail;
}
- NET_LOCK();
PF_LOCK();
pl->limit = pf_pool_limits[pl->index].limit;
PF_UNLOCK();
- NET_UNLOCK();
break;
}
case DIOCSETLIMIT: {
struct pfioc_limit *pl = (struct pfioc_limit *)addr;
- NET_LOCK();
PF_LOCK();
if (pl->index < 0 || pl->index >= PF_LIMIT_MAX) {
error = EINVAL;
PF_UNLOCK();
- NET_UNLOCK();
goto fail;
}
if (((struct pool *)pf_pool_limits[pl->index].pp)->pr_nout >
pl->limit) {
error = EBUSY;
PF_UNLOCK();
- NET_UNLOCK();
goto fail;
}
/* Fragments reference mbuf clusters. */
if (pl->index == PF_LIMIT_FRAGS && pl->limit > nmbclust) {
error = EINVAL;
PF_UNLOCK();
- NET_UNLOCK();
goto fail;
}
pf_pool_limits[pl->index].limit_new = pl->limit;
pl->limit = pf_pool_limits[pl->index].limit;
PF_UNLOCK();
- NET_UNLOCK();
break;
}
Re: ifconfig description for wireguard peers
On 23.5.2023. 21:13, Klemens Nanni wrote: > On Sat, Jan 14, 2023 at 02:28:27PM +, Stuart Henderson wrote: >> On 2023/01/12 04:49, Mikolaj Kucharski wrote: >>> Hi, >>> >>> Is there anything else which I can do, to help this diff reviwed and >>> increase the chance of getting in? >>> >>> Thread at https://marc.info/?t=16347829861=1=2 >>> >>> Last version of the diff at >>> https://marc.info/?l=openbsd-tech=167185582521873=mbox >> Inlining that for a few comments, otherwise it's ok sthen > wgdescr[iption] would be consistent with the existing descr[iption]. > At least my keep typing the trailing "r"... > > Then '-wgdescr' and 'wgdescr ""' work and are implemented exactly like > te inteface description equivalents. > > I could use this now in a new VPN setup, so here's a polished diff, > with the above, missing ifconfig.8 bits written and other nits inline. > > As Theo suggested, I'd drop the wg.4 and leave it to ifconfig.8 proper. > > Feedback? > > Either way, net/wireguard-tools needs a bump/rebuild. > Hi, this would be nice features when having wg server with lots of wgpeers. I've tried this diff ans it's working as expected. Thank you Mikolaj and kn@
Re: patch: make CRYPTO_get_ex_new_index not return 0
On Wed, May 24, 2023 at 2:16 PM Theo Buehler wrote:
> On Tue, May 23, 2023 at 12:40:40PM -0400, Marc Aldorasi wrote:
> > The man page for CRYPTO_get_ex_new_index says that "the value 0 is
> > reserved for the legacy "app_data" APIs", but the function can still
> > return 0, which can cause issues for programs that use both APIs. The
> > attached patch causes the returned indices to start at 1 instead.
> >
> > See also the corresponding OpenSSL bug report:
> > https://marc.info/?l=openssl-dev=142421750627504=2
>
> Thanks for the diff. This makes some sense, but I need to look closer to
> understand the full ramifications. Unfortunately, OpenSSL's rt is now
> lost to the Internet Dark Ages, so information is a bit lacking.
>
> What made you write this patch? Is there a real-world issue you ran
> into? If so, could you point me at it?
>
> Thanks.
The issue is that I have an application that uses SSL_get_ex_data and
SSL_set_ex_data, but also uses a library (Boost Asio) that uses
SSL_get_app_data and SSL_set_app_data. When using OpenSSL this works
fine; SSL_get_ex_new_index returns 1, so the main program uses index 1,
the library uses index 0, and there's no conflict. With LibreSSL,
SSL_get_ex_new_index returns 0, so both the main program and the library
use index 0 and conflict with each other. Specifically, Boost Asio is
trying to call a virtual function on the data that my application set,
which fails because my data has the wrong type. The application is
proprietary, but here's a reduced example that exhibits the problem:
#include
#include
using namespace boost::asio;
int new_data(void *, void *, CRYPTO_EX_DATA *cd, int idx, long, void *)
{
CRYPTO_set_ex_data(cd, idx, strdup("some custom data"));
return 0;
}
int main()
{
int custom_data_index = SSL_get_ex_new_index(0, nullptr,
new_data, nullptr, nullptr);
io_context ctx;
ssl::context ssl_ctx(ssl::context::tls);
ssl::stream ssl_sock(ctx, ssl_ctx);
}
When ssl_sock is destroyed, boost calls SSL_get_app_data, interprets the
non-null return to mean that it had previously set that data, and so
calls delete on it, which tries to read the object's destructor out of
its vtable. Since the data is actually a string set by new_data and not
an object with a vtable, this causes a segfault.
> > diff --git a/src/lib/libcrypto/ex_data.c b/src/lib/libcrypto/ex_data.c
> > index b1e391366..d9c39b2c4 100644
> > --- a/src/lib/libcrypto/ex_data.c
> > +++ b/src/lib/libcrypto/ex_data.c
> > @@ -320,7 +320,7 @@ def_get_class(int class_index)
> > gen = malloc(sizeof(EX_CLASS_ITEM));
> > if (gen) {
> > gen->class_index = class_index;
> > - gen->meth_num = 0;
> > + gen->meth_num = 1;
> > gen->meth = sk_CRYPTO_EX_DATA_FUNCS_new_null();
> > if (!gen->meth)
> > free(gen);
>
Re: Virtio fix for testing
I forgot to mention that no stress test is necessary. If it boots and
the virtio devices work at all, that should be enough.
Cheers,
Stefan
Am 20.05.23 um 15:00 schrieb Stefan Fritsch:
Hi,
with help from Aaron Mason, I have found the problem responsible for the
vioscsi panic on oracle cloud and windows qemu. Basically before using any
virt-queues, the guest must set the DRIVER_OK status bit, or the host may
not process the queues. This affects vioscsi(4) and viogpu(4) in openbsd,
but I have changed the code in all virtio drivers to work the same.
This seems to be a common bug in guests and qemu has workarounds in some
code paths, but not in others. I think that is the reason why I could not
reproduce the issue on my own qemu/linux system.
I have only tested this on amd64 / qemu. I would be interested in test
results on other systems, especially on top of vmd and on arm64 with
viogpu.
Aaron, can you please also test with the updated diff?
Thanks in advance.
Cheers,
Stefan
commit d3209e34d77ab7353973efb2a57303f636fff4f4
Author: Stefan Fritsch
Date: Sat May 20 14:18:57 2023 +0200
virtio: Set DRIVER_OK earlier
The DRIVER_OK must be set before using any virt-queues. To allow virtio
device drivers to use the virt-queues in their attach functions, set the
bit there and not in the virtio transport attach function. Only vioscsi
and viogpu really need this, but let's only have one standard way to do
this .
Noticed because of hangs with vioscsi on qemu/windows and in the Oracle
cloud. With much debugging help by Aaron Mason .
Also revert vioscsi.c 1.31 "Temporarily workaround double calls into
vioscsi_req_done()"
diff --git a/sys/dev/fdt/virtio_mmio.c b/sys/dev/fdt/virtio_mmio.c
index 12f5a6cdeb6..682cbd304a1 100644
--- a/sys/dev/fdt/virtio_mmio.c
+++ b/sys/dev/fdt/virtio_mmio.c
@@ -293,7 +293,6 @@ virtio_mmio_attach(struct device *parent, struct device
*self, void *aux)
goto fail_2;
}
- virtio_set_status(vsc, VIRTIO_CONFIG_DEVICE_STATUS_DRIVER_OK);
return;
fail_2:
diff --git a/sys/dev/pci/virtio_pci.c b/sys/dev/pci/virtio_pci.c
index 236120cf5a6..747101b8382 100644
--- a/sys/dev/pci/virtio_pci.c
+++ b/sys/dev/pci/virtio_pci.c
@@ -651,7 +651,6 @@ virtio_pci_attach(struct device *parent, struct device
*self, void *aux)
}
printf("%s: %s\n", vsc->sc_dev.dv_xname, intrstr);
- virtio_set_status(vsc, VIRTIO_CONFIG_DEVICE_STATUS_DRIVER_OK);
return;
fail_2:
diff --git a/sys/dev/pv/if_vio.c b/sys/dev/pv/if_vio.c
index be53ccaf7c3..5d1ca8d0030 100644
--- a/sys/dev/pv/if_vio.c
+++ b/sys/dev/pv/if_vio.c
@@ -600,6 +600,7 @@ vio_attach(struct device *parent, struct device *self, void
*aux)
timeout_set(>sc_txtick, vio_txtick, >sc_vq[VQTX]);
timeout_set(>sc_rxtick, vio_rxtick, >sc_vq[VQRX]);
+ virtio_set_status(vsc, VIRTIO_CONFIG_DEVICE_STATUS_DRIVER_OK);
if_attach(ifp);
ether_ifattach(ifp);
diff --git a/sys/dev/pv/vioblk.c b/sys/dev/pv/vioblk.c
index 093ce9b5a58..9f8a10e0fa2 100644
--- a/sys/dev/pv/vioblk.c
+++ b/sys/dev/pv/vioblk.c
@@ -251,6 +251,7 @@ vioblk_attach(struct device *parent, struct device *self,
void *aux)
saa.saa_quirks = 0;
saa.saa_wwpn = saa.saa_wwnn = 0;
+ virtio_set_status(vsc, VIRTIO_CONFIG_DEVICE_STATUS_DRIVER_OK);
config_found(self, , scsiprint);
return;
diff --git a/sys/dev/pv/viocon.c b/sys/dev/pv/viocon.c
index bd96467c810..882f0961ada 100644
--- a/sys/dev/pv/viocon.c
+++ b/sys/dev/pv/viocon.c
@@ -203,6 +203,7 @@ viocon_attach(struct device *parent, struct device *self,
void *aux)
goto err;
}
viocon_rx_fill(sc->sc_ports[0]);
+ virtio_set_status(vsc, VIRTIO_CONFIG_DEVICE_STATUS_DRIVER_OK);
return;
err:
diff --git a/sys/dev/pv/viogpu.c b/sys/dev/pv/viogpu.c
index e8a91c34310..06f4388a7b0 100644
--- a/sys/dev/pv/viogpu.c
+++ b/sys/dev/pv/viogpu.c
@@ -235,6 +235,8 @@ viogpu_attach(struct device *parent, struct device *self,
void *aux)
sc->sc_fb_dma_kva, sc->sc_fb_dma_size, NULL, BUS_DMA_NOWAIT) != 0)
goto fb_unmap;
+ virtio_set_status(vsc, VIRTIO_CONFIG_DEVICE_STATUS_DRIVER_OK);
+
if (viogpu_create_2d(sc, 1, sc->sc_fb_width, sc->sc_fb_height) != 0)
goto fb_unmap;
diff --git a/sys/dev/pv/viomb.c b/sys/dev/pv/viomb.c
index 8169770553e..a8d408e7392 100644
--- a/sys/dev/pv/viomb.c
+++ b/sys/dev/pv/viomb.c
@@ -220,6 +220,7 @@ viomb_attach(struct device *parent, struct device *self,
void *aux)
sensordev_install(>sc_sensdev);
printf("\n");
+ virtio_set_status(vsc, VIRTIO_CONFIG_DEVICE_STATUS_DRIVER_OK);
return;
err_dmamap:
bus_dmamap_destroy(vsc->sc_dmat, sc->sc_req.bl_dmamap);
diff --git a/sys/dev/pv/viornd.c b/sys/dev/pv/viornd.c
index 39442bc8391..490e823173b 100644
--- a/sys/dev/pv/viornd.c
+++ b/sys/dev/pv/viornd.c
@@ -138,6
Re: patch: make CRYPTO_get_ex_new_index not return 0
On Tue, May 23, 2023 at 12:40:40PM -0400, Marc Aldorasi wrote:
> The man page for CRYPTO_get_ex_new_index says that "the value 0 is
> reserved for the legacy "app_data" APIs", but the function can still
> return 0, which can cause issues for programs that use both APIs. The
> attached patch causes the returned indices to start at 1 instead.
>
> See also the corresponding OpenSSL bug report:
> https://marc.info/?l=openssl-dev=142421750627504=2
Thanks for the diff. This makes some sense, but I need to look closer to
understand the full ramifications. Unfortunately, OpenSSL's rt is now
lost to the Internet Dark Ages, so information is a bit lacking.
What made you write this patch? Is there a real-world issue you ran
into? If so, could you point me at it?
Thanks.
> diff --git a/src/lib/libcrypto/ex_data.c b/src/lib/libcrypto/ex_data.c
> index b1e391366..d9c39b2c4 100644
> --- a/src/lib/libcrypto/ex_data.c
> +++ b/src/lib/libcrypto/ex_data.c
> @@ -320,7 +320,7 @@ def_get_class(int class_index)
> gen = malloc(sizeof(EX_CLASS_ITEM));
> if (gen) {
> gen->class_index = class_index;
> - gen->meth_num = 0;
> + gen->meth_num = 1;
> gen->meth = sk_CRYPTO_EX_DATA_FUNCS_new_null();
> if (!gen->meth)
> free(gen);
Re: userdel: remove login group for =uid
On 2023/05/19 10:24:58 -0600, Todd C. Miller wrote:
> If /etc/usermgmt.conf has a line like:
>
> group =uid
>
> where a new user's group ID in the passwd file is the same as their
> user ID, remove that group when the user is removed. The group is
> only removed if it matches the login name, has a gid that matches
> the user's uid, and has no other members.
>
> This makes our userdel(8) behave more like the version on other
> systems.
>
> Opinions? This is something that has always bothered me and can
> result in uid/gid mismatches if you remove a user, then re-add them
> without removing the login group first.
I have been bitten by this too and later been (pleasently) surprised
when found that on other systems removing a users removes the group
too. It makes sense to me.
> Thoughts or strong opinions?
fwiw i like the change, ok for me.
However I never did anything "crazy" with usermgmt.conf(5) so don't
know if this could break existing setups, althought I highly doubt:
the worst could be getting some errors from groupdel(8) due to an
already deleted group.
As Aisha pointed out, pkg_delete hints could be updated too.
one minor style nit below, hope you'll excuse my nitpicking.
> [...]
> @@ -1366,6 +1366,15 @@ rm_user_from_groups(char *login_name)
> warnx("Malformed entry `%s'. Skipping", buf);
> continue;
> }
> + if (rm_login_group && strncmp(buf, login_name, login_len) == 0
> + && buf[login_len] == ':') {
> + /* remove login group if empty or user is only member */
> + if (*cp == '\n')
> + continue;
> + if (strncmp(cp, login_name, login_len) == 0 &&
> + cp [login_len] == '\n')
extra space
> + continue;
> + }
Re: Installer: use $(
On Tue, 23 May 2023 23:41:32 +0200, Christian Weisgerber wrote:
> This replaces "$(cat file)" with the ksh construct "$( Admittedly cosmetic.
>
> I have left the line
>
> local _sec=$(cat $HTTP_SEC 2>/dev/null)
>
> unchanged, since it would require
>
> { local var=$(<$HTTP_SEC); } 2>/dev/null
>
> which is sufficiently opaque that I'm not sure it's an improvement.
OK millert@
- todd
Re: rpki-client: prime file modification times to optimize failover from RRDP to RSYNC
Dear all,
Claudio made some suggestions to pass the desired modification times
around in a different way, below is an updated patch proposal.
I also added some instrumentation to also adjust GBRs and TAKs.
RIPE & APNIC informally indicated some interest in this hack.
Kind regards,
Job
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
retrieving revision 1.181
diff -u -p -r1.181 extern.h
--- extern.h9 May 2023 10:34:32 - 1.181
+++ extern.h24 May 2023 16:11:15 -
@@ -348,6 +348,7 @@ struct gbr {
time_t notbefore; /* EE cert's Not Before */
time_t notafter; /* Not After of the GBR EE */
time_t expires; /* when the signature path expires */
+ int talid; /* TAL the GBR is chained up to */
};
struct aspa_provider {
@@ -755,7 +756,7 @@ void proc_http(char *, int) __attribut
voidproc_rrdp(int) __attribute__((noreturn));
/* Repository handling */
-int filepath_add(struct filepath_tree *, char *);
+int filepath_add(struct filepath_tree *, char *, time_t);
voidrrdp_clear(unsigned int);
voidrrdp_save_state(unsigned int, struct rrdp_session *);
int rrdp_handle_file(unsigned int, enum publish_type, char *,
Index: filemode.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/filemode.c,v
retrieving revision 1.31
diff -u -p -r1.31 filemode.c
--- filemode.c 3 May 2023 10:22:30 - 1.31
+++ filemode.c 24 May 2023 16:11:15 -
@@ -586,6 +586,7 @@ parse_file(struct entityq *q, struct msg
struct entity *entp;
struct ibuf *b;
struct tal *tal;
+ time_t dummy = 0;
while ((entp = TAILQ_FIRST(q)) != NULL) {
TAILQ_REMOVE(q, entp, entries);
@@ -612,6 +613,7 @@ parse_file(struct entityq *q, struct msg
io_simple_buffer(b, >repoid, sizeof(entp->repoid));
io_simple_buffer(b, >talid, sizeof(entp->talid));
io_str_buffer(b, entp->file);
+ io_simple_buffer(b, , sizeof(dummy));
io_close_buffer(msgq, b);
entity_free(entp);
}
Index: main.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v
retrieving revision 1.236
diff -u -p -r1.236 main.c
--- main.c 27 Apr 2023 08:37:53 - 1.236
+++ main.c 24 May 2023 16:11:15 -
@@ -551,6 +551,7 @@ entity_process(struct ibuf *b, struct st
struct aspa *aspa;
struct repo *rp;
char*file;
+ time_t mtime;
unsigned int id;
int talid;
int c;
@@ -565,12 +566,13 @@ entity_process(struct ibuf *b, struct st
io_read_buf(b, , sizeof(id));
io_read_buf(b, , sizeof(talid));
io_read_str(b, );
+ io_read_buf(b, , sizeof(mtime));
/* in filemode messages can be ignored, only the accounting matters */
if (filemode)
goto done;
- if (filepath_add(, file) == 0) {
+ if (filepath_add(, file, mtime) == 0) {
warnx("%s: File already visited", file);
goto done;
}
Index: parser.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/parser.c,v
retrieving revision 1.94
diff -u -p -r1.94 parser.c
--- parser.c11 May 2023 20:13:30 - 1.94
+++ parser.c24 May 2023 16:11:15 -
@@ -485,7 +485,7 @@ proc_parser_root_cert(char *file, const
/*
* Parse a ghostbuster record
*/
-static void
+static struct gbr *
proc_parser_gbr(char *file, const unsigned char *der, size_t len,
const char *mftaki)
{
@@ -496,17 +496,23 @@ proc_parser_gbr(char *file, const unsign
const char *errstr;
if ((gbr = gbr_parse(, file, der, len)) == NULL)
- return;
+ return NULL;
a = valid_ski_aki(file, , gbr->ski, gbr->aki, mftaki);
crl = crl_get(, a);
/* return value can be ignored since nothing happens here */
- if (!valid_x509(file, ctx, x509, a, crl, ))
+ if (!valid_x509(file, ctx, x509, a, crl, )) {
warnx("%s: %s", file, errstr);
-
+ X509_free(x509);
+ gbr_free(gbr);
+ return NULL;
+ }
X509_free(x509);
- gbr_free(gbr);
+
+ gbr->talid = a->cert->talid;
+
+ return gbr;
}
/*
@@ -615,8 +621,11 @@ parse_entity(struct entityq *q, struct m
struct mft *mft;
struct roa *roa;
struct aspa *aspa;
+ struct gbr *gbr;
+ struct tak *tak;
struct ibuf *b;
unsigned char *f;
+ time_t mtime = 0;
Re: ix(4): LRO forwarding
On Tue, May 23, 2023 at 02:14:57PM +0200, Jan Klemkow wrote:
> Hi,
>
> This diff sets needed offloading flags and the calculated mss to LRO
> mbufs in ix(4). Thus, we can forward this packets and process them via
> tcp_if_output_tso(). This diff also uses tcp_if_output_tso() in
> ip6_forward().
>
> I tested the ip6_forward path via the address family transition in pf:
>
> pass in inet from 192.168.1.1 to 192.168.13.2 af-to \
> inet6 from fc00:13::1 to fc00:13::2
>
> ok?
crashes during my tests with lro turned on. Looks like devision
by zero.
START ssh_perform@lt13_iperf3_-c10.3.46.36_-P10_-t10 2023-05-24T13:33:54Z
Timeout, server ot14 not responding.
login: [-- MARK -- Wed May 24 15:30:00 2023]
kerkneel:rker nn el:e l : in t e g e r d i v inite dg e e
fr a ul t t r a p, c o d e =0
Stopped at ixgbe_encap+0x177: divl%ecx,%eax
ddb{2}> trace
ixgbe_encap(801241b0,fd80b80db400) at ixgbe_encap+0x177
ixgbe_start(80121800) at ixgbe_start+0xcf
ifq_serialize(80121800,801218e0) at ifq_serialize+0xfd
taskq_thread(8002f000) at taskq_thread+0x100
end trace frame: 0x0, count: -4
ddb{2}> ps
PID TID PPIDUID S FLAGS WAIT COMMAND
99854 209089 9079 0 30x100082 kqreadssh
15809 442526 1 0 30x100080 kqreadssh
97949 86242 1 0 30x100080 kqreadssh
9079 146443 53981 0 30x82 piperdperl
53981 227769 5893 0 30x10008a sigsusp ksh
5893 451861 1468 0 30x9a kqreadsshd
94168 490141 1 0 30x100083 ttyin getty
75652 427583 1 0 30x100098 kqreadcron
39299 237287 1 99 3 0x1100090 kqreadsndiod
47108 360525 1110 30x100090 kqreadsndiod
38566 177187 19960 95 3 0x1100092 kqreadsmtpd
23522 195537 19960103 3 0x1100092 kqreadsmtpd
80420 195512 19960 95 3 0x1100092 kqreadsmtpd
2367 42113 19960 95 30x100092 kqreadsmtpd
7393 283209 19960 95 3 0x1100092 kqreadsmtpd
7653 297707 19960 95 3 0x1100092 kqreadsmtpd
19960 437487 1 0 30x100080 kqreadsmtpd
71374 338452 30627 89 3 0x1100092 kqreadrelayd
16907 408885 30627 89 3 0x1100092 kqreadrelayd
35081 284379 30627 89 3 0x1100092 kqreadrelayd
25277 284381 30627 89 3 0x1100092 kqreadrelayd
30678 463036 30627 89 3 0x1100092 kqreadrelayd
83004 265034 30627 89 3 0x1100092 kqreadrelayd
95286 431522 30627 89 3 0x1100092 kqreadrelayd
59217 310908 30627 89 3 0x1100092 kqreadrelayd
30627 478072 1 0 30x80 kqreadrelayd
11795 299233 20858 91 30x92 kqreadsnmpd_metrics
20858 85096 1 0 30x100080 kqreadsnmpd
37930 377730 1 91 3 0x1100092 kqreadsnmpd
1468 62101 1 0 30x88 kqreadsshd
24611 87454 0 0 3 0x14280 nfsidlnfsio
65040 198675 0 0 3 0x14280 nfsidlnfsio
24289 234081 0 0 3 0x14280 nfsidlnfsio
8301 276844 0 0 3 0x14280 nfsidlnfsio
93209 90851 1 0 30x100080 kqreadntpd
61881 51205 99207 83 30x100092 kqreadntpd
99207 296079 1 83 3 0x1100092 kqreadntpd
19281 369312 38531 74 3 0x1100092 bpf pflogd
38531 252705 1 0 30x80 netio pflogd
42140 503330 9467 73 3 0x1100090 kqreadsyslogd
9467 506976 1 0 30x100082 netio syslogd
86346 356807 1 0 30x100080 kqreadresolvd
8248 456268 86437 77 30x100092 kqreaddhcpleased
81843 247582 86437 77 30x100092 kqreaddhcpleased
86437 362320 1 0 30x80 kqreaddhcpleased
52151 379618 4048115 30x100092 kqreadslaacd
61436 14534 4048115 30x100092 kqreadslaacd
4048 130235 1 0 30x100080 kqreadslaacd
20154 61454 0 0 3 0x14200 bored smr
91942 510513 0 0 3 0x14200 pgzerozerothread
42079 231044 0 0 3 0x14200 aiodoned aiodoned
91303 99546 0 0 3 0x14200 syncerupdate
2249 13527 0 0 3 0x14200 cleaner cleaner
84329 74364 0 0 3 0x14200 reaperreaper
16246 208290 0 0 3 0x14200 pgdaemon pagedaemon
87196 379876 0 0 3 0x14200 usbtskusbtask
79540 107697 0
Re: sticky(8): mark S_ISVTX as Dv
On Wed, 24 May 2023 16:04:13 +0200, Omar Polo wrote: > It makes `man -k any=S_ISVTX' slightly more useful by pointing at > sticky(8) too other than strmode(3); may help if someone (like me :-) > forgot about sticky(8) files. OK millert@ - todd
Re: Installer: use $(
24 мая 2023 г. 18:05:29 Todd C. Miller :
> On Tue, 23 May 2023 22:22:04 -, Klemens Nanni wrote:
>
>> I'm pointing this out because the error message we'd get provides less
>> information with your diff:
>>
>> $ echo $(cat /nope) 2>/dev/null
>> cat: /nope: No such file or directory
>> vs.
>> echo $(< /nope) 2>/dev/null
>> ksh: /nope: cannot open $(<) input
>>
>> But given the constraint environment, I'm fine with turning those four
>> $(cat ...) instances into $(< ...) like the exising seven onces with
>> the intial example being the only outlier.
>
> Here's the error output from bash, zsh and ksh93:
>
> $bash echo $(< /nope)
> bash: /nope: No such file or directory
>
> $zsh echo $(< /nope)
> zsh: no such file or directory: /nope
>
> $ksh93 echo $(< /nope)
> ksh93: /nope: cannot open [No such file or directory]
>
> Maybe we should just adjust ksh to display the more useful message?
> With diff:
>
> $ echo $(< /nope)
> ksh: /nope: No such file or directory
>
> - todd
>
> diff -u -p -u -r1.66 eval.c
> --- bin/ksh/eval.c 13 Sep 2020 15:39:09 - 1.66
> +++ bin/ksh/eval.c 24 May 2023 14:03:41 -
> @@ -8,6 +8,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -909,7 +910,7 @@ comsub(Expand *xp, char *cp)
> SHF_MAPHI|SHF_CLEXEC);
> if (shf == NULL)
> warningf(!Flag(FTALKING),
> - "%s: cannot open $(<) input", name);
> + "%s: %s", name, strerror(errno));
> xp->split = 0; /* no waitlast() */
> } else {
> int ofd1, pv[2];
OK kn
Re: Installer: use $(
makes sense to me, OK florian fwiw
On 2023-05-24 08:05 -06, Todd C. Miller wrote:
> On Tue, 23 May 2023 22:22:04 -, Klemens Nanni wrote:
>
>> I'm pointing this out because the error message we'd get provides less
>> information with your diff:
>>
>> $ echo $(cat /nope) 2>/dev/null
>> cat: /nope: No such file or directory
>> vs.
>> echo $(< /nope) 2>/dev/null
>> ksh: /nope: cannot open $(<) input
>>
>> But given the constraint environment, I'm fine with turning those four
>> $(cat ...) instances into $(< ...) like the exising seven onces with
>> the intial example being the only outlier.
>
> Here's the error output from bash, zsh and ksh93:
>
> $bash echo $(< /nope)
> bash: /nope: No such file or directory
>
> $zsh echo $(< /nope)
> zsh: no such file or directory: /nope
>
> $ksh93 echo $(< /nope)
> ksh93: /nope: cannot open [No such file or directory]
>
> Maybe we should just adjust ksh to display the more useful message?
> With diff:
>
> $ echo $(< /nope)
> ksh: /nope: No such file or directory
>
> - todd
>
> diff -u -p -u -r1.66 eval.c
> --- bin/ksh/eval.c13 Sep 2020 15:39:09 - 1.66
> +++ bin/ksh/eval.c24 May 2023 14:03:41 -
> @@ -8,6 +8,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -909,7 +910,7 @@ comsub(Expand *xp, char *cp)
> SHF_MAPHI|SHF_CLEXEC);
> if (shf == NULL)
> warningf(!Flag(FTALKING),
> - "%s: cannot open $(<) input", name);
> + "%s: %s", name, strerror(errno));
> xp->split = 0; /* no waitlast() */
> } else {
> int ofd1, pv[2];
>
--
In my defence, I have been left unsupervised.
Re: Installer: use $(
On Tue, 23 May 2023 22:22:04 -, Klemens Nanni wrote:
> I'm pointing this out because the error message we'd get provides less
> information with your diff:
>
> $ echo $(cat /nope) 2>/dev/null
> cat: /nope: No such file or directory
> vs.
> echo $(< /nope) 2>/dev/null
> ksh: /nope: cannot open $(<) input
>
> But given the constraint environment, I'm fine with turning those four
> $(cat ...) instances into $(< ...) like the exising seven onces with
> the intial example being the only outlier.
Here's the error output from bash, zsh and ksh93:
$bash echo $(< /nope)
bash: /nope: No such file or directory
$zsh echo $(< /nope)
zsh: no such file or directory: /nope
$ksh93 echo $(< /nope)
ksh93: /nope: cannot open [No such file or directory]
Maybe we should just adjust ksh to display the more useful message?
With diff:
$ echo $(< /nope)
ksh: /nope: No such file or directory
- todd
diff -u -p -u -r1.66 eval.c
--- bin/ksh/eval.c 13 Sep 2020 15:39:09 - 1.66
+++ bin/ksh/eval.c 24 May 2023 14:03:41 -
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
#include
#include
@@ -909,7 +910,7 @@ comsub(Expand *xp, char *cp)
SHF_MAPHI|SHF_CLEXEC);
if (shf == NULL)
warningf(!Flag(FTALKING),
- "%s: cannot open $(<) input", name);
+ "%s: %s", name, strerror(errno));
xp->split = 0; /* no waitlast() */
} else {
int ofd1, pv[2];
sticky(8): mark S_ISVTX as Dv
It makes `man -k any=S_ISVTX' slightly more useful by pointing at sticky(8) too other than strmode(3); may help if someone (like me :-) forgot about sticky(8) files. ok? diff /usr/src commit - beb1c6c70ae1e2a18abd99274d326b36106135ad path + /usr/src blob - 5577ca04b51f728d40b28bafa2d8de891d2fdac0 file + share/man/man8/sticky.8 --- share/man/man8/sticky.8 +++ share/man/man8/sticky.8 @@ -39,7 +39,7 @@ A special file mode, called the .Sh DESCRIPTION A special file mode, called the .Em sticky bit -(mode S_ISVTX), +.Pq mode Dv S_ISVTX , is used to indicate special treatment for files and directories. See .Xr chmod 2
