ftp.openbsd.org currently unreachable

Hello all, I'm writing to provide a heads up that ftp.openbsd.org appears to currently be unreachable. For example, `curl -O https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.6.3.tar.gz` is currently producing: curl: (28) Failed to connect to ftp.openbsd.org port 443 after 129852 ms: Connec

Re: avoid truncation of filtered smtpd data lines

On Tue, 20 Jun 2023 21:38:49 +0200, Omar Polo wrote: > Then I realized that we don't need to copy the line at all. We're > already using strtoull to parse the number and the payload is the last > field of the received line, so we can just advance the pointer. The > drawback is that we now need t

Re: rpki-client: disallow empty RFC 3779 extensions

On Tue, Jun 20, 2023 at 10:10:43PM +0200, Theo Buehler wrote: > The first warning cannot be hit because the X509v3_asid_is_canonical() > errors on empty asIdsOrRanges sequences. This is not the case for > IPAddrBlocks... > > There is some ambiguity in RFC 6487, 4.8.10 whether empty > ipAddressesOr

rpki-client: disallow empty RFC 3779 extensions

The first warning cannot be hit because the X509v3_asid_is_canonical() errors on empty asIdsOrRanges sequences. This is not the case for IPAddrBlocks... There is some ambiguity in RFC 6487, 4.8.10 whether empty ipAddressesOrRanges are allowed or not. I opted for the stricter interpretation matchin

avoid truncation of filtered smtpd data lines

hello tech@, this was reported some time ago on the OpenSMTPD-portable repository[0] [0]: https://github.com/OpenSMTPD/OpenSMTPD/pull/1192 Filters can register to the data-line event to alter the mail content. smtpd, when parsing the filter' output it first copies the received line in a temporar

Re: rpki-client: better handling of X509_get_ext_d2i() errors

On Tue, Jun 20, 2023 at 07:50:19PM +0200, Theo Buehler wrote: > X509_get_ext_d2i() is one of those very special OpenSSL interfaces... > > It can return NULL for various reasons. If it returns NULL and crit is > not -1, something bad happened. If crit is -2, multiple extensions with > the same OID

Re: rpki-client: warn on duplicate X509v3 extensions

On Tue, Jun 20, 2023 at 08:58:23PM +0200, Theo Buehler wrote: > For some reason libcrypto doesn't check this part of RFC 5280, 4.2: A > certificate MUST NOT include more than one instance of a particular > extension. > > With the badCertSIA2x.cer from Ties's test artefacts, I get this > warning: >

rpki-client: warn on duplicate X509v3 extensions

For some reason libcrypto doesn't check this part of RFC 5280, 4.2: A certificate MUST NOT include more than one instance of a particular extension. With the badCertSIA2x.cer from Ties's test artefacts, I get this warning: rpki-client: badCertSIA2x.cer: RFC 5280 section 4.2: duplicate subjectInf

rpki-client: better handling of X509_get_ext_d2i() errors

X509_get_ext_d2i() is one of those very special OpenSSL interfaces... It can return NULL for various reasons. If it returns NULL and crit is not -1, something bad happened. If crit is -2, multiple extensions with the same OID as the one corresponding to the nid were found (this is not allowed per

Re: open_memstream cleanup

On Tue, 20 Jun 2023 17:49:46 +0200, Claudio Jeker wrote: > In open_memstream() the code does a bzero() of the new memory even though > recallocarray() used which does this already. > > In open_wmemstream() the code does the same but is still using > reallocarray(). So adjust that code to be like o

Re: more relayd cleanup

> On 20 Jun 2023, at 18:16, Claudio Jeker wrote: > > On Tue, Jun 20, 2023 at 03:35:11PM +0200, Theo Buehler wrote: >>> On Tue, Jun 20, 2023 at 02:17:06PM +0200, Claudio Jeker wrote: >>> Ok, this went overboard. I just wanted to clean up a bit more in >>> check_tcp.c but noticed check_send_expe

Re: ospfd use new ibuf functions

On Tue, Jun 20, 2023 at 06:29:59PM +0200, Claudio Jeker wrote: > On Tue, Jun 20, 2023 at 02:47:41PM +0200, Claudio Jeker wrote: > > This diff updates ospfd to use the new ibuf API. > > > > It mainly removes the use of ibuf_seek() and replaces these calls with > > ibuf_set(). > > > > Regress still

[s...@spacehopper.org: ospf6d fib reload [Re: bgpd fix for possible crash in SE]]

This hasn't blown up yet... any interest? - Forwarded message from Stuart Henderson - From: Stuart Henderson Date: Fri, 26 May 2023 14:40:45 +0100 To: tech@openbsd.org Subject: ospf6d fib reload [Re: bgpd fix for possible crash in SE] Mail-Followup-To: tech@openbsd.org On 2023/05/26 13

Re: ospfd use new ibuf functions

On Tue, Jun 20, 2023 at 02:47:41PM +0200, Claudio Jeker wrote: > This diff updates ospfd to use the new ibuf API. > > It mainly removes the use of ibuf_seek() and replaces these calls with > ibuf_set(). > > Regress still passes with this diff in. Here the same diff for ospf6d. -- :wq Claudio I

Re: more relayd cleanup

On Tue, Jun 20, 2023 at 03:35:11PM +0200, Theo Buehler wrote: > On Tue, Jun 20, 2023 at 02:17:06PM +0200, Claudio Jeker wrote: > > Ok, this went overboard. I just wanted to clean up a bit more in > > check_tcp.c but noticed check_send_expect and CHECK_BINSEND_EXPECT. > > > > This code is not very

Re: open_memstream cleanup

On Tue, Jun 20, 2023 at 05:49:46PM +0200, Claudio Jeker wrote: > In open_memstream() the code does a bzero() of the new memory even though > recallocarray() used which does this already. > > In open_wmemstream() the code does the same but is still using > reallocarray(). So adjust that code to be

Re: uvm_meter: improve periodic execution logic for uvm_loadav()

On Tue, Jun 20, 2023 at 10:25:02AM -0500, Scott Cheloha wrote: > On Tue, Jun 20, 2023 at 11:47:10AM +0200, Claudio Jeker wrote: > > On Mon, Jun 19, 2023 at 04:45:03PM -0500, Scott Cheloha wrote: > > > > [...] > > > > > Index: uvm/uvm_meter.c > > > =

open_memstream cleanup

In open_memstream() the code does a bzero() of the new memory even though recallocarray() used which does this already. In open_wmemstream() the code does the same but is still using reallocarray(). So adjust that code to be like open_memstream(). -- :wq Claudio Index: open_memstream.c

Re: uvm_meter: improve periodic execution logic for uvm_loadav()

On Tue, Jun 20, 2023 at 11:47:10AM +0200, Claudio Jeker wrote: > On Mon, Jun 19, 2023 at 04:45:03PM -0500, Scott Cheloha wrote: > > [...] > > > Index: uvm/uvm_meter.c > > === > > RCS file: /cvs/src/sys/uvm/uvm_meter.c,v > > retrievin

Re: ospfd use new ibuf functions

On Tue, Jun 20, 2023 at 03:46:23PM +0200, Theo Buehler wrote: > On Tue, Jun 20, 2023 at 02:47:41PM +0200, Claudio Jeker wrote: > > This diff updates ospfd to use the new ibuf API. > > > > It mainly removes the use of ibuf_seek() and replaces these calls with > > ibuf_set(). > > > > Regress still

Re: profclock, gmonclock: new callbacks for profil(2)/GPROF statclock() code

Claudio Jeker wrote: > On Mon, Jun 19, 2023 at 06:41:14PM -0500, Scott Cheloha wrote: > > > On Jun 19, 2023, at 18:07, Theo de Raadt wrote: > > > > > > Make sure to STOP all kernel profiling before attempting to > > >suspend or hibernate your machine. Otherwise I expect it > >

Re: rpki-client use new ibuf API

On Tue, Jun 20, 2023 at 03:44:56PM +0200, Claudio Jeker wrote: > Use the ibuf_fd_*() API for file descriptor passing and also ibuf_set() > instead of ibuf_seek(). ok tb

Re: ospfd use new ibuf functions

On Tue, Jun 20, 2023 at 02:47:41PM +0200, Claudio Jeker wrote: > This diff updates ospfd to use the new ibuf API. > > It mainly removes the use of ibuf_seek() and replaces these calls with > ibuf_set(). > > Regress still passes with this diff in. There's a function vs fatal mismatch in orig_rtr_

rpki-client use new ibuf API

Use the ibuf_fd_*() API for file descriptor passing and also ibuf_set() instead of ibuf_seek(). -- :wq Claudio Index: http.c === RCS file: /cvs/src/usr.sbin/rpki-client/http.c,v retrieving revision 1.76 diff -u -p -r1.76 http.c ---

Re: more relayd cleanup

On Tue, Jun 20, 2023 at 02:17:06PM +0200, Claudio Jeker wrote: > Ok, this went overboard. I just wanted to clean up a bit more in > check_tcp.c but noticed check_send_expect and CHECK_BINSEND_EXPECT. > > This code is not very consitent in the differnt ways the strings are > encoded. Especially che

ospfd use new ibuf functions

This diff updates ospfd to use the new ibuf API. It mainly removes the use of ibuf_seek() and replaces these calls with ibuf_set(). Regress still passes with this diff in. -- :wq Claudio Index: auth.c === RCS file: /cvs/src/usr.sbi

more relayd cleanup

Ok, this went overboard. I just wanted to clean up a bit more in check_tcp.c but noticed check_send_expect and CHECK_BINSEND_EXPECT. This code is not very consitent in the differnt ways the strings are encoded. Especially check_send_expect() is a bit of a mess because of that. While there I notic

Re: uvm_meter: improve periodic execution logic for uvm_loadav()

On Mon, Jun 19, 2023 at 04:45:03PM -0500, Scott Cheloha wrote: > On Mon, Jun 19, 2023 at 10:22:56AM +0200, Claudio Jeker wrote: > > On Sun, Jun 18, 2023 at 12:43:18PM -0500, Scott Cheloha wrote: > > > On Sun, Jun 18, 2023 at 12:36:07PM -0500, Scott Cheloha wrote: > > > > On Sun, Jun 18, 2023 at 07:

Re: convert relayd to use new ibuf function

On Tue, Jun 20, 2023 at 11:34:22AM +0200, Claudio Jeker wrote: > Instead of ibuf_reserve() just use ibuf_add_zero(buf, 1) to add a > NUL byte to the buffer. ok tb

convert relayd to use new ibuf function

Instead of ibuf_reserve() just use ibuf_add_zero(buf, 1) to add a NUL byte to the buffer. There is more needed in here but lets start small. -- :wq Claudio Index: check_tcp.c === RCS file: /cvs/src/usr.sbin/relayd/check_tcp.c,v retr

tr(1): don't use indirect variable, supplement comment

Hello, I suggest this simplification in the "tr [-Ccs] string1 string2" section of main. It makes it easier to understand what's happening in the -C case. Luka diff --git a/usr.bin/tr/tr.c b/usr.bin/tr/tr.c index ab78898a986..a47fb409f34 100644 --- a/usr.bin/tr/tr.c +++ b/usr.bin/tr/tr.c @@ -167

Re: uvm_meter: improve periodic execution logic for uvm_loadav()

On Tue, Jun 20, 2023 at 08:36:58AM +0200, Claudio Jeker wrote: > On Mon, Jun 19, 2023 at 04:45:03PM -0500, Scott Cheloha wrote: > > On Mon, Jun 19, 2023 at 10:22:56AM +0200, Claudio Jeker wrote: > > > On Sun, Jun 18, 2023 at 12:43:18PM -0500, Scott Cheloha wrote: > > > > On Sun, Jun 18, 2023 at 12: