Re: dhcpleased, slaacd, unwind: Pass arguments to shutdown(2) in the right order

2023-02-14 Thread Florian Obser
Oopsie.

OK florian


On 2023-02-14 17:30 -05, Josiah Frentsos  wrote:
> Index: dhcpleased/dhcpleased.c
> ===
> RCS file: /cvs/src/sbin/dhcpleased/dhcpleased.c,v
> retrieving revision 1.28
> diff -u -p -r1.28 dhcpleased.c
> --- dhcpleased/dhcpleased.c   11 Dec 2022 10:47:37 -  1.28
> +++ dhcpleased/dhcpleased.c   14 Feb 2023 22:19:42 -
> @@ -255,7 +255,7 @@ main(int argc, char *argv[])
>   if ((routesock = socket(AF_ROUTE, SOCK_RAW | SOCK_CLOEXEC |
>   SOCK_NONBLOCK, AF_INET)) == -1)
>   fatal("route socket");
> - shutdown(SHUT_RD, routesock);
> + shutdown(routesock, SHUT_RD);
>  
>   event_init();
>  
> Index: slaacd/slaacd.c
> ===
> RCS file: /cvs/src/sbin/slaacd/slaacd.c,v
> retrieving revision 1.67
> diff -u -p -r1.67 slaacd.c
> --- slaacd/slaacd.c   27 Nov 2022 15:19:38 -  1.67
> +++ slaacd/slaacd.c   14 Feb 2023 22:19:43 -
> @@ -213,7 +213,7 @@ main(int argc, char *argv[])
>   if ((routesock = socket(AF_ROUTE, SOCK_RAW | SOCK_CLOEXEC |
>   SOCK_NONBLOCK, AF_INET6)) == -1)
>   fatal("route socket");
> - shutdown(SHUT_RD, routesock);
> + shutdown(routesock, SHUT_RD);
>  
>   event_init();
>  
> Index: unwind/unwind.c
> ===
> RCS file: /cvs/src/sbin/unwind/unwind.c,v
> retrieving revision 1.67
> diff -u -p -r1.67 unwind.c
> --- unwind/unwind.c   18 Dec 2021 10:34:19 -  1.67
> +++ unwind/unwind.c   14 Feb 2023 22:19:43 -
> @@ -278,7 +278,7 @@ main(int argc, char *argv[])
>   if ((routesock = socket(AF_ROUTE, SOCK_RAW | SOCK_CLOEXEC |
>   SOCK_NONBLOCK, 0)) == -1)
>   fatal("route socket");
> - shutdown(SHUT_RD, routesock);
> + shutdown(routesock, SHUT_RD);
>  
>   if ((ta_fd = open(TRUST_ANCHOR_FILE, O_RDWR | O_CREAT, 0644)) == -1)
>   log_warn("%s", TRUST_ANCHOR_FILE);
>

-- 
I'm not entirely sure you are real.



Update share/locale/ctype/en_US.UTF-8.src to Unicode 14.0.0

2023-02-14 Thread Andrew Hewus Fresh
With the perl update, we get a new version of unicode available to
update this file as well.  This was just running the script with the new
perl version.

OK?

Index: share/locale/ctype/en_US.UTF-8.src
===
RCS file: /cvs/src/share/locale/ctype/en_US.UTF-8.src,v
retrieving revision 1.12
diff -u -p -r1.12 en_US.UTF-8.src
--- share/locale/ctype/en_US.UTF-8.src  16 May 2021 22:48:05 -  1.12
+++ share/locale/ctype/en_US.UTF-8.src  15 Feb 2023 00:47:03 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: en_US.UTF-8.src,v 1.12 2021/05/16 22:48:05 afresh1 Exp $  
*/
+/* $OpenBSD$   */
 
 /*
  * COPYRIGHT AND PERMISSION NOTICE
@@ -40,7 +40,7 @@
 ENCODING"UTF8"
 VARIABLECODESET=UTF-8
 
-/* Unicode Version 13.0.0 */
+/* Unicode Version 14.0.0 */
 
 /*
  * U+ - U+007F : Basic Latin
@@ -906,14 +906,14 @@ ALPHA 0x06d5 - 0x06dc  0x06e1 - 0x06
 ALPHA 0x06ff
 CONTROL   0x061c
 DIGIT 0x0660 - 0x0669  0x06f0 - 0x06f9
-GRAPH 0x0600 - 0x061c  0x061e - 0x06ff
-PUNCT 0x0606 - 0x060f  0x061b  0x061e - 0x061f  0x066a - 0x066d  0x06d4
+GRAPH 0x0600 - 0x06ff
+PUNCT 0x0606 - 0x060f  0x061b  0x061d - 0x061f  0x066a - 0x066d  0x06d4
 PUNCT 0x06de  0x06e9  0x06fd - 0x06fe
-PRINT 0x0600 - 0x061c  0x061e - 0x06ff
+PRINT 0x0600 - 0x06ff
 SPECIAL   0x0600 - 0x0605  0x0658  0x06dd  0x06df - 0x06e0  0x06ea - 0x06ec
 SWIDTH0   0x0600 - 0x0605  0x0610 - 0x061a  0x061c  0x064b - 0x065f  0x0670
 SWIDTH0   0x06d6 - 0x06dd  0x06df - 0x06e4  0x06e7 - 0x06e8  0x06ea - 0x06ed
-SWIDTH1   0x0606 - 0x060f  0x061b  0x061e - 0x064a  0x0660 - 0x066f
+SWIDTH1   0x0606 - 0x060f  0x061b  0x061d - 0x064a  0x0660 - 0x066f
 SWIDTH1   0x0671 - 0x06d5  0x06de  0x06e5 - 0x06e6  0x06e9  0x06ee - 0x06ff
 
 TODIGIT   < 0x0660 - 0x0669 : 0x >
@@ -1005,21 +1005,28 @@ SWIDTH1   0x0860 - 0x086a
 
 
 /*
- * U+0870 - U+089F : No_Block
+ * U+0870 - U+089F : Arabic Extended-B
  */
 
+ALPHA 0x0870 - 0x0887  0x0889 - 0x088e
+GRAPH 0x0870 - 0x088e  0x0890 - 0x0891  0x0898 - 0x089f
+PUNCT 0x0888
+PRINT 0x0870 - 0x088e  0x0890 - 0x0891  0x0898 - 0x089f
+SPECIAL   0x0890 - 0x0891  0x0898 - 0x089f
+SWIDTH0   0x0890 - 0x0891  0x0898 - 0x089f
+SWIDTH1   0x0870 - 0x088e
+
 
 /*
  * U+08A0 - U+08FF : Arabic Extended-A
  */
 
-ALPHA 0x08a0 - 0x08b4  0x08b6 - 0x08c7  0x08d4 - 0x08df  0x08e3 - 0x08e9
-ALPHA 0x08f0 - 0x08ff
-GRAPH 0x08a0 - 0x08b4  0x08b6 - 0x08c7  0x08d3 - 0x08ff
-PRINT 0x08a0 - 0x08b4  0x08b6 - 0x08c7  0x08d3 - 0x08ff
-SPECIAL   0x08d3  0x08e0 - 0x08e2  0x08ea - 0x08ef
-SWIDTH0   0x08d3 - 0x08ff
-SWIDTH1   0x08a0 - 0x08b4  0x08b6 - 0x08c7
+ALPHA 0x08a0 - 0x08c9  0x08d4 - 0x08df  0x08e3 - 0x08e9  0x08f0 - 0x08ff
+GRAPH 0x08a0 - 0x08ff
+PRINT 0x08a0 - 0x08ff
+SPECIAL   0x08ca - 0x08d3  0x08e0 - 0x08e2  0x08ea - 0x08ef
+SWIDTH0   0x08ca - 0x08ff
+SWIDTH1   0x08a0 - 0x08c9
 
 
 /*
@@ -1187,20 +1194,22 @@ TODIGIT   < 0x0bf2 1000 >
 
 ALPHA 0x0c00 - 0x0c03  0x0c05 - 0x0c0c  0x0c0e - 0x0c10  0x0c12 - 0x0c28
 ALPHA 0x0c2a - 0x0c39  0x0c3d - 0x0c44  0x0c46 - 0x0c48  0x0c4a - 0x0c4c
-ALPHA 0x0c55 - 0x0c56  0x0c58 - 0x0c5a  0x0c60 - 0x0c63
+ALPHA 0x0c55 - 0x0c56  0x0c58 - 0x0c5a  0x0c5d  0x0c60 - 0x0c63
 DIGIT 0x0c66 - 0x0c6f
 GRAPH 0x0c00 - 0x0c0c  0x0c0e - 0x0c10  0x0c12 - 0x0c28  0x0c2a - 0x0c39
-GRAPH 0x0c3d - 0x0c44  0x0c46 - 0x0c48  0x0c4a - 0x0c4d  0x0c55 - 0x0c56
-GRAPH 0x0c58 - 0x0c5a  0x0c60 - 0x0c63  0x0c66 - 0x0c6f  0x0c77 - 0x0c7f
+GRAPH 0x0c3c - 0x0c44  0x0c46 - 0x0c48  0x0c4a - 0x0c4d  0x0c55 - 0x0c56
+GRAPH 0x0c58 - 0x0c5a  0x0c5d  0x0c60 - 0x0c63  0x0c66 - 0x0c6f
+GRAPH 0x0c77 - 0x0c7f
 PUNCT 0x0c77  0x0c7f
 PRINT 0x0c00 - 0x0c0c  0x0c0e - 0x0c10  0x0c12 - 0x0c28  0x0c2a - 0x0c39
-PRINT 0x0c3d - 0x0c44  0x0c46 - 0x0c48  0x0c4a - 0x0c4d  0x0c55 - 0x0c56
-PRINT 0x0c58 - 0x0c5a  0x0c60 - 0x0c63  0x0c66 - 0x0c6f  0x0c77 - 0x0c7f
-SPECIAL   0x0c04  0x0c4d  0x0c78 - 0x0c7e
-SWIDTH0   0x0c00  0x0c04  0x0c3e - 0x0c40  0x0c46 - 0x0c48  0x0c4a - 0x0c4d
-SWIDTH0   0x0c55 - 0x0c56  0x0c62 - 0x0c63
+PRINT 0x0c3c - 0x0c44  0x0c46 - 0x0c48  0x0c4a - 0x0c4d  0x0c55 - 0x0c56
+PRINT 0x0c58 - 0x0c5a  0x0c5d  0x0c60 - 0x0c63  0x0c66 - 0x0c6f
+PRINT 0x0c77 - 0x0c7f
+SPECIAL   0x0c04  0x0c3c  0x0c4d  0x0c78 - 0x0c7e
+SWIDTH0   0x0c00  0x0c04  0x0c3c  0x0c3e - 0x0c40  0x0c46 - 0x0c48
+SWIDTH0   0x0c4a - 0x0c4d  0x0c55 - 0x0c56  0x0c62 - 0x0c63
 SWIDTH1   0x0c01 - 0x0c03  0x0c05 - 0x0c0c  0x0c0e - 0x0c10  0x0c12 - 0x0c28
-SWIDTH1   0x0c2a - 0x0c39  0x0c3d  0x0c41 - 0x0c44  0x0c58 - 0x0c5a
+SWIDTH1   0x0c2a - 0x0c39  0x0c3d  0x0c41 - 0x0c44  0x0c58 - 0x0c5a  0x0c5d
 SWIDTH1   0x0c60 - 0x0c61  0x0c66 - 0x0c6f  0x0c77 - 0x0c7f
 
 TODIGIT   < 0x0c66 - 0x0c6f : 0x >
@@ -1213,23 +1222,23 @@ TODIGIT   < 0x0c7c - 0x0c7e : 1 >
 
 ALPHA 0x0c80 - 0x0c83  0x0c85 - 0x0c8c  0x0c8e - 0x0c90  0x0c92 - 0x0ca8
 ALPHA 0x0caa - 0x0cb3  0x0cb5 - 0x0cb9 

match 'Intel Atom(R)' in fw_update(8)

2023-02-14 Thread Jonathan Gray
patrick mentioned a machine with:
cpu0: Intel Atom(R) x6425RE Processor @ 1.90GHz, 1895.90 MHz, 06-96-01
isn't matched by fw_update

that is different to what we've seen in the past, such as
cpu0: Intel(R) Pentium(R) M processor 1.60GHz ("GenuineIntel" 686-class) 1.60 
GHz, 06-0d-06
cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.61 MHz, 06-3d-04
cpu0: Intel(R) Atom(TM) Processor E3940 @ 1.60GHz, 1596.81 MHz, 06-5c-09
cpu0: 12th Gen Intel(R) Core(TM) i7-1260P, 1995.55 MHz, 06-9a-03
cpu0: Genuine Intel(R) CPU @ 1.00GHz, 1000.13 MHz, 06-26-01

Index: patterns.c
===
RCS file: /cvs/src/usr.sbin/fw_update/patterns.c,v
retrieving revision 1.7
diff -u -p -r1.7 patterns.c
--- patterns.c  24 Jan 2023 01:40:22 -  1.7
+++ patterns.c  14 Feb 2023 22:23:36 -
@@ -98,7 +98,7 @@ main(void)
printf("%s\n", "bwfm");
printf("%s\n", "bwi");
printf("%s\n", "intel");
-   printf("%s\n", "intel ^cpu0:*Intel(R)");
+   printf("%s\n", "intel ^cpu0:*Intel");
printf("%s\n", "inteldrm");
print_devices("inteldrm", i915_devices, nitems(i915_devices));
printf("%s\n", "ipw");



Re: fix NULL pointer dereference in pfsync_bulk_update()

2023-02-14 Thread Alexandr Nedvedicky
Hello,

On Tue, Feb 14, 2023 at 01:23:16AM +0100, Alexander Bluhm wrote:
> On Mon, Feb 13, 2023 at 08:39:39AM +0100, Alexandr Nedvedicky wrote:
> > this bug has been found and reported by Hrvoje@ [1].
> > I took my chance and asked Hrvoje to test a small diff [2].
> > I would like to ask for OK to commit this fix which makes
> > Hrvoje's test box happy. Diff below is same to one found
> > at bugs@. The thing is that pfsync_bulk_update() function
> > must check first if there is anything to update, otherwise
> > we may day due to NULL pointer dereference.
> 
> Your check makes sense, OK bluhm@
> 
> But who is protecting write access to sc->sc_bulk_next ?
> 
> I think it is exclusive netlock.  This works as pfsync_input() is
> a protocol input function which is still not running in parallel.

yes, NET_LOCK() is still exclusive lock. so it should provide
sufficient protection.

> 
> rw_enter_read(&pf_state_list.pfs_rwl) does not protect sc->sc_bulk_next
> it is a read lock.  mtx_enter(&pf_state_list.pfs_mtx) is not taken
> for all writers to sc->sc_bulk_next.
> 
> Do you have plans to relax this code from exclusive to shared
> netlock?

dlg@ has a new code for pfsync. I've seen his code back in ?December?
last year. support for bulk transfers was missing piece.

I think option we have here in pfsync(4) is to introduce a new rw-lock
private to if_pfsync and remove NET_LOCK() here completely.

sashan



dhcpleased, slaacd, unwind: Pass arguments to shutdown(2) in the right order

2023-02-14 Thread Josiah Frentsos
Index: dhcpleased/dhcpleased.c
===
RCS file: /cvs/src/sbin/dhcpleased/dhcpleased.c,v
retrieving revision 1.28
diff -u -p -r1.28 dhcpleased.c
--- dhcpleased/dhcpleased.c 11 Dec 2022 10:47:37 -  1.28
+++ dhcpleased/dhcpleased.c 14 Feb 2023 22:19:42 -
@@ -255,7 +255,7 @@ main(int argc, char *argv[])
if ((routesock = socket(AF_ROUTE, SOCK_RAW | SOCK_CLOEXEC |
SOCK_NONBLOCK, AF_INET)) == -1)
fatal("route socket");
-   shutdown(SHUT_RD, routesock);
+   shutdown(routesock, SHUT_RD);
 
event_init();
 
Index: slaacd/slaacd.c
===
RCS file: /cvs/src/sbin/slaacd/slaacd.c,v
retrieving revision 1.67
diff -u -p -r1.67 slaacd.c
--- slaacd/slaacd.c 27 Nov 2022 15:19:38 -  1.67
+++ slaacd/slaacd.c 14 Feb 2023 22:19:43 -
@@ -213,7 +213,7 @@ main(int argc, char *argv[])
if ((routesock = socket(AF_ROUTE, SOCK_RAW | SOCK_CLOEXEC |
SOCK_NONBLOCK, AF_INET6)) == -1)
fatal("route socket");
-   shutdown(SHUT_RD, routesock);
+   shutdown(routesock, SHUT_RD);
 
event_init();
 
Index: unwind/unwind.c
===
RCS file: /cvs/src/sbin/unwind/unwind.c,v
retrieving revision 1.67
diff -u -p -r1.67 unwind.c
--- unwind/unwind.c 18 Dec 2021 10:34:19 -  1.67
+++ unwind/unwind.c 14 Feb 2023 22:19:43 -
@@ -278,7 +278,7 @@ main(int argc, char *argv[])
if ((routesock = socket(AF_ROUTE, SOCK_RAW | SOCK_CLOEXEC |
SOCK_NONBLOCK, 0)) == -1)
fatal("route socket");
-   shutdown(SHUT_RD, routesock);
+   shutdown(routesock, SHUT_RD);
 
if ((ta_fd = open(TRUST_ANCHOR_FILE, O_RDWR | O_CREAT, 0644)) == -1)
log_warn("%s", TRUST_ANCHOR_FILE);



Re: openrsync: fix handling of port numbers in rsync:// urls

2023-02-14 Thread Job Snijders
Hi Theo,

Thanks for the feedback, good catch on 'len'! Following your suggestions
- how about the below?

Kind regards,

Job

Index: main.c
===
RCS file: /cvs/src/usr.bin/rsync/main.c,v
retrieving revision 1.65
diff -u -p -r1.65 main.c
--- main.c  2 Aug 2022 20:01:12 -   1.65
+++ main.c  14 Feb 2023 16:55:43 -
@@ -231,17 +231,21 @@ fargs_parse(size_t argc, char *argv[], s
j = strlen(cp);
if (f->remote &&
strncasecmp(cp, "rsync://", 8) == 0) {
-   /* rsync://path */
+   /* rsync://host[:port]/path */
+   size_t module_offset = len;
cp += 8;
-   if ((ccp = strchr(cp, ':')))/* skip :port */
+   /* skip :port */
+   if ((ccp = strchr(cp, ':')) != NULL) {
*ccp = '\0';
+   module_offset += strcspn(ccp + 1, "/") + 1;
+   }
if (strncmp(cp, f->host, len) ||
(cp[len] != '/' && cp[len] != '\0'))
errx(ERR_SYNTAX, "different remote host: %s",
f->sources[i]);
memmove(f->sources[i],
-   f->sources[i] + len + 8 + 1,
-   j - len - 8);
+   f->sources[i] + module_offset + 8 + 1,
+   j - module_offset - 8);
} else if (f->remote && strncmp(cp, "::", 2) == 0) {
/* ::path */
memmove(f->sources[i],



Re: bgpd better startup behaviour

2023-02-14 Thread Theo Buehler
On Tue, Feb 14, 2023 at 01:05:36PM +0100, Claudio Jeker wrote:
> bgpd does not really synchronize the start of sessions with
> the config reload of the RDE. This is fine but there is one gotcha.
> When loading big configs including RTR tables the delay between the SE
> finishing the config reload (RECONF_DONE) and the RDE finally getting
> RECONF_DONE is so long that on startup many sessions come up manage to
> feed data to the RDE before the initial config gets active.  This is not
> great.
> 
> So this diff tries to reduce this window a bit by
> a) issue RECONF_DONE for the RTR and RDE together (there is no dependecy
> between the two and the ROA/ASPA reloads can happen on the side).
> b) introduce a small timeout before bringing new sessions up.
> 
> For the second diff I had to fix a bug in the neighbor state handler which
> has been there for a long time. The "reinit due?" case only triggers when
> init_peer() also triggers and so this code makes no sense and can simply
> be removed. We should never restart a session because of a config reload.

This all makes sense, as usual.

ok tb



bgpd better startup behaviour

2023-02-14 Thread Claudio Jeker
bgpd does not really synchronize the start of sessions with
the config reload of the RDE. This is fine but there is one gotcha.
When loading big configs including RTR tables the delay between the SE
finishing the config reload (RECONF_DONE) and the RDE finally getting
RECONF_DONE is so long that on startup many sessions come up manage to
feed data to the RDE before the initial config gets active.  This is not
great.

So this diff tries to reduce this window a bit by
a) issue RECONF_DONE for the RTR and RDE together (there is no dependecy
between the two and the ROA/ASPA reloads can happen on the side).
b) introduce a small timeout before bringing new sessions up.

For the second diff I had to fix a bug in the neighbor state handler which
has been there for a long time. The "reinit due?" case only triggers when
init_peer() also triggers and so this code makes no sense and can simply
be removed. We should never restart a session because of a config reload.
 
-- 
:wq Claudio

Index: bgpd.c
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.c,v
retrieving revision 1.256
diff -u -p -r1.256 bgpd.c
--- bgpd.c  20 Jan 2023 10:30:41 -  1.256
+++ bgpd.c  14 Feb 2023 10:57:15 -
@@ -984,9 +984,9 @@ dispatch_imsg(struct imsgbuf *ibuf, int 
break;
}
if (idx == PFD_PIPE_SESSION) {
+   /* RDE and RTR engine can reload concurrently */
imsg_compose(ibuf_rtr, IMSG_RECONF_DONE, 0,
0, -1, NULL, 0);
-   } else if (idx == PFD_PIPE_RTR) {
imsg_compose(ibuf_rde, IMSG_RECONF_DONE, 0,
0, -1, NULL, 0);
 
Index: session.c
===
RCS file: /cvs/src/usr.sbin/bgpd/session.c,v
retrieving revision 1.440
diff -u -p -r1.440 session.c
--- session.c   9 Feb 2023 13:43:23 -   1.440
+++ session.c   14 Feb 2023 11:36:38 -
@@ -259,14 +259,6 @@ session_main(int debug, int verbose)
if (p->state == STATE_NONE)
init_peer(p);
 
-   /* reinit due? */
-   if (p->reconf_action == RECONF_REINIT) {
-   session_stop(p, ERR_CEASE_ADMIN_RESET);
-   if (!p->conf.down)
-   timer_set(&p->timers,
-   Timer_IdleHold, 0);
-   }
-
/* deletion due? */
if (p->reconf_action == RECONF_DELETE) {
if (p->demoted)
@@ -580,7 +572,7 @@ init_peer(struct peer *p)
if (p->conf.down)
timer_stop(&p->timers, Timer_IdleHold); /* no autostart */
else
-   timer_set(&p->timers, Timer_IdleHold, 0); /* start ASAP */
+   timer_set(&p->timers, Timer_IdleHold, SESSION_CLEAR_DELAY);
 
p->stats.last_updown = getmonotime();
 



Re: route(8) allow route monitor -mpls

2023-02-14 Thread Theo Buehler
On Tue, Feb 14, 2023 at 11:38:20AM +0100, Claudio Jeker wrote:
> Currently route monitor only accepts -inet and -inet6 as address family
> but -mpls is also a valid option. It is the 3 routing tables we support.
> 
> OK?

ok

> -- 
> :wq Claudio
> 
> Index: route.c
> ===
> RCS file: /cvs/src/sbin/route/route.c,v
> retrieving revision 1.261
> diff -u -p -r1.261 route.c
> --- route.c   22 Dec 2022 19:53:22 -  1.261
> +++ route.c   14 Feb 2023 09:23:23 -
> @@ -221,6 +221,9 @@ main(int argc, char **argv)
>   case K_INET6:
>   af = AF_INET6;
>   break;
> + case K_MPLS:
> + af = AF_MPLS;
> + break;
>   case K_IFACE:
>   case K_INTERFACE:
>   filter = ROUTE_FILTER(RTM_IFINFO) |
> 



Re: openrsync: fix handling of port numbers in rsync:// urls

2023-02-14 Thread Theo Buehler
On Sun, Feb 12, 2023 at 09:16:58PM +, Job Snijders wrote:
> I noticed there is an issue in openrsync when a port is specified in the
> rsync:// URL, the port number ends up becoming part of the path:
> 
> $ openrsync -r rsync://rsync.roa.tohunet.com:3873/repo/ /tmp/r
> rsync: [sender] change_dir "/3873/repo" (in repo) failed: No such file or 
> directory (2)
> 
> The below changeset seems to improve the situation, but might not be the
> best way to fix it. I found fargs_parse() a bit hard to understand.

No kidding...

> OK? Suggestions?
> 
> Kind regards,
> 
> Job
> 
> Index: main.c
> ===
> RCS file: /cvs/src/usr.bin/rsync/main.c,v
> retrieving revision 1.65
> diff -u -p -r1.65 main.c
> --- main.c2 Aug 2022 20:01:12 -   1.65
> +++ main.c12 Feb 2023 21:06:00 -
> @@ -233,8 +233,12 @@ fargs_parse(size_t argc, char *argv[], s
>   strncasecmp(cp, "rsync://", 8) == 0) {
>   /* rsync://path */
>   cp += 8;
> - if ((ccp = strchr(cp, ':')))/* skip :port */
> + /* skip :port */
> + if ((ccp = strchr(cp, ':')) != NULL) {
>   *ccp = '\0';
> + while (cp[len] != '/' && len < j)
> + len++;
> + }

There are various issues here. First, you don't know that cp[len] is in
any way related to the location of ':' in the string since the strncmp()
only happens later.

This is equivalent to your while loop but starting at what we know to be
after the colon:

len += strcspn(ccp + 1, "/") + 1;

This brings me to the next problem: we must not modify len, as it is
the length of f->host. If there are multiple sources, len my grow and
eventually cp[len] could access out of bounds.

While it is not super clean, the easiest fix for this would be to do

/* rsync://path[:host] */
size_t save_len = len;

after the strncasecmp() above, then after the memmove() at the end of the
scope reset the length to what it originally was:

len = save_len;

A bit cleaner would be to replace uses of len with

/* rsync://path[:host] */
size_t module_offset = len;

...

module_offset += strcspn(ccp + 1, "/") + 1;

then replace all uses of len in this scope *after* the strncmp below with
module_offset.

>   if (strncmp(cp, f->host, len) ||
>   (cp[len] != '/' && cp[len] != '\0'))
>   errx(ERR_SYNTAX, "different remote host: %s",
> 



www: Move horizontal rule and update year

2023-02-14 Thread Martin Vahlensieck
Hi

Going back a few versions, it seems this hr was used to separate the
past from the future.  So put it back in the right place.  While here
also correct the year for future events, or should that be replaced by
"None currently scheduled"?

Best,

Martin

diff --git a/events.html b/events.html
index a10a3e50a..1d3f0fd65 100644
--- a/events.html
+++ b/events.html
@@ -40,7 +40,9 @@ like-minded people.
 
 Future events:
 
-2022
+2023
+
+
 
 Past events:
 
@@ -94,8 +96,6 @@ Sep 15-18, 2022, Vienna, Austria
 
 
 
-
-
 
 
 



route(8) allow route monitor -mpls

2023-02-14 Thread Claudio Jeker
Currently route monitor only accepts -inet and -inet6 as address family
but -mpls is also a valid option. It is the 3 routing tables we support.

OK?
-- 
:wq Claudio

Index: route.c
===
RCS file: /cvs/src/sbin/route/route.c,v
retrieving revision 1.261
diff -u -p -r1.261 route.c
--- route.c 22 Dec 2022 19:53:22 -  1.261
+++ route.c 14 Feb 2023 09:23:23 -
@@ -221,6 +221,9 @@ main(int argc, char **argv)
case K_INET6:
af = AF_INET6;
break;
+   case K_MPLS:
+   af = AF_MPLS;
+   break;
case K_IFACE:
case K_INTERFACE:
filter = ROUTE_FILTER(RTM_IFINFO) |