* Breaking UAPI change?
@ 2021-03-24 15:30 Richard Weinberger
2021-03-24 19:01 ` Kurt Van Dijck
0 siblings, 1 reply; 8+ messages in thread
From: Richard Weinberger @ 2021-03-24 15:30 UTC (permalink / raw)
To: linux-can
Hi!
commit f5223e9eee65 ("can: extend sockaddr_can to include j1939 members") increased the size of
struct sockaddr_can.
This is a problem for applications which use recvfrom() with addrlen being sizeof(struct sockaddr_can)
or sizeof(struct sockaddr).
If such an application was built before the change it will no longer function correctly on newer kernels.
In fact I ran into such a scenario and found the said commit later that day.
Is this a known issue?
Or is this allowed and application must not use sizeof(struct sockaddr_can) as addrlen?
If so, what is the proposed way to avoid future breakage?
Thanks,
//richard
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Breaking UAPI change? 2021-03-24 15:30 Breaking UAPI change? Richard Weinberger @ 2021-03-24 19:01 ` Kurt Van Dijck 2021-03-24 19:21 ` Richard Weinberger 0 siblings, 1 reply; 8+ messages in thread From: Kurt Van Dijck @ 2021-03-24 19:01 UTC (permalink / raw) To: Richard Weinberger; +Cc: linux-can Hello, On Wed, 24 Mar 2021 16:30:58 +0100, Richard Weinberger wrote: > Hi! > > commit f5223e9eee65 ("can: extend sockaddr_can to include j1939 members") increased the size of > struct sockaddr_can. > This is a problem for applications which use recvfrom() with addrlen being sizeof(struct sockaddr_can) > or sizeof(struct sockaddr). > If such an application was built before the change it will no longer function correctly on newer kernels. This scenario was identified, and explicitely dealt with. This requires a tiny bit different code, i.e. net/can/raw.c should use REQUIRED_SIZE() instead of sizeof() for testing the size of the address structure. > In fact I ran into such a scenario and found the said commit later that day. Looking to the v5.10 kernel (which I happen to have checked out), your claim indeed seems true, the raw_recvmsg does not (raw_bind and raw_sendmsg work correct, but that's not important for your problem). > > Is this a known issue? It wasn't, until you found it :-) > Or is this allowed and application must not use sizeof(struct sockaddr_can) as addrlen? sizeof(struct sockaddr_can). As you already mentioned, applications may have been built before the size increase, and so they should not be recompiled. > If so, what is the proposed way to avoid future breakage? Your application should not change. Kernel must be fixed. Kurt ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Breaking UAPI change? 2021-03-24 19:01 ` Kurt Van Dijck @ 2021-03-24 19:21 ` Richard Weinberger 2021-03-24 19:27 ` PATCH: " Kurt Van Dijck 0 siblings, 1 reply; 8+ messages in thread From: Richard Weinberger @ 2021-03-24 19:21 UTC (permalink / raw) To: Kurt Van Dijck; +Cc: linux-can Kurt, ----- Ursprüngliche Mail ----- >> commit f5223e9eee65 ("can: extend sockaddr_can to include j1939 members") >> increased the size of >> struct sockaddr_can. >> This is a problem for applications which use recvfrom() with addrlen being >> sizeof(struct sockaddr_can) >> or sizeof(struct sockaddr). >> If such an application was built before the change it will no longer function >> correctly on newer kernels. > > This scenario was identified, and explicitely dealt with. > This requires a tiny bit different code, i.e. net/can/raw.c should use > REQUIRED_SIZE() instead of sizeof() for testing the size of the address > structure. > >> In fact I ran into such a scenario and found the said commit later that day. > > Looking to the v5.10 kernel (which I happen to have checked out), > your claim indeed seems true, the raw_recvmsg does not (raw_bind and > raw_sendmsg work correct, but that's not important for your problem). > >> >> Is this a known issue? > > It wasn't, until you found it :-) Thanks for the prompt reply! >> Or is this allowed and application must not use sizeof(struct sockaddr_can) as >> addrlen? > > sizeof(struct sockaddr_can). As you already mentioned, applications may have > been built > before the size increase, and so they should not be recompiled. > > >> If so, what is the proposed way to avoid future breakage? > > Your application should not change. Kernel must be fixed. Feel free to CC me when you submit a patch, I'll happily test it. Thanks, //richard ^ permalink raw reply [flat|nested] 8+ messages in thread
* PATCH: Breaking UAPI change? 2021-03-24 19:21 ` Richard Weinberger @ 2021-03-24 19:27 ` Kurt Van Dijck 2021-03-24 19:47 ` Richard Weinberger 2021-03-24 20:26 ` Oliver Hartkopp 0 siblings, 2 replies; 8+ messages in thread From: Kurt Van Dijck @ 2021-03-24 19:27 UTC (permalink / raw) To: Richard Weinberger; +Cc: linux-can > ----- Ursprüngliche Mail ----- > >> commit f5223e9eee65 ("can: extend sockaddr_can to include j1939 members") > >> increased the size of > >> struct sockaddr_can. > >> This is a problem for applications which use recvfrom() with addrlen being > >> sizeof(struct sockaddr_can) > >> or sizeof(struct sockaddr). > >> If such an application was built before the change it will no longer function > >> correctly on newer kernels. > > > > This scenario was identified, and explicitely dealt with. > > This requires a tiny bit different code, i.e. net/can/raw.c should use > > REQUIRED_SIZE() instead of sizeof() for testing the size of the address > > structure. > > > >> In fact I ran into such a scenario and found the said commit later that day. > > > > Looking to the v5.10 kernel (which I happen to have checked out), > > your claim indeed seems true, the raw_recvmsg does not (raw_bind and > > raw_sendmsg work correct, but that's not important for your problem). > > > >> > >> Is this a known issue? > > > > It wasn't, until you found it :-) > > Thanks for the prompt reply! > > >> Or is this allowed and application must not use sizeof(struct sockaddr_can) as > >> addrlen? > > > > sizeof(struct sockaddr_can). As you already mentioned, applications may have > > been built > > before the size increase, and so they should not be recompiled. > > > > > >> If so, what is the proposed way to avoid future breakage? > > > > Your application should not change. Kernel must be fixed. > > Feel free to CC me when you submit a patch, I'll happily test it. Here it goes. Even not compile tested :-( on my v5.10, at this hour. I spotted a similar problem in getsockname/getpeername calls. The patch will test for minimum required size before touching anything, later on, the maximum size will be evaluated. Happy testing? commit 124900109ca88d29382ef2e2b848d3a2f9d67b98 Author: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> Date: Wed Mar 24 20:08:50 2021 can raw: don't increase provided name length The length of the buffer is known by the application, not the kernel. Kernel is supposed to return only the size of used bytes. There is a minimum required size for the struct sockaddr_can to be usefull for can_raw, so errors are returned when the provided size is lower Signed-off-by: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> diff --git a/net/can/raw.c b/net/can/raw.c index 6ec8aa1d0da4..00d352ae221e 100644 --- a/net/can/raw.c +++ b/net/can/raw.c @@ -475,7 +475,7 @@ static int raw_getname(struct socket *sock, struct sockaddr *uaddr, if (peer) return -EOPNOTSUPP; - memset(addr, 0, sizeof(*addr)); + memset(addr, 0, CAN_REQUIRED_SIZE(*addr, ifindex)); addr->can_family = AF_CAN; addr->can_ifindex = ro->ifindex; @@ -806,6 +806,10 @@ static int raw_recvmsg(struct socket *sock, struct msghdr *msg, size_t size, return sock_recv_errqueue(sk, msg, size, SOL_CAN_RAW, SCM_CAN_RAW_ERRQUEUE); + if (msg->name && msg->msg_namelen < + CAN_REQUIRED_SIZE(struct sockaddr_can, ifindex)) + return -EINVAL; + skb = skb_recv_datagram(sk, flags, noblock, &err); if (!skb) return err; @@ -825,7 +829,8 @@ static int raw_recvmsg(struct socket *sock, struct msghdr *msg, size_t size, if (msg->msg_name) { __sockaddr_check_size(sizeof(struct sockaddr_can)); - msg->msg_namelen = sizeof(struct sockaddr_can); + if (msg->msg_namelen > sizeof(struct sockaddr_can)) + msg->msg_namelen = sizeof(struct sockaddr_can); memcpy(msg->msg_name, skb->cb, msg->msg_namelen); } ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: PATCH: Breaking UAPI change? 2021-03-24 19:27 ` PATCH: " Kurt Van Dijck @ 2021-03-24 19:47 ` Richard Weinberger 2021-03-24 20:26 ` Oliver Hartkopp 1 sibling, 0 replies; 8+ messages in thread From: Richard Weinberger @ 2021-03-24 19:47 UTC (permalink / raw) To: Kurt Van Dijck; +Cc: linux-can Kurt, ----- Ursprüngliche Mail ----- > Happy testing? ;-) > commit 124900109ca88d29382ef2e2b848d3a2f9d67b98 > Author: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> > Date: Wed Mar 24 20:08:50 2021 > > can raw: don't increase provided name length > > The length of the buffer is known by the application, > not the kernel. Kernel is supposed to return only the > size of used bytes. > There is a minimum required size for the struct sockaddr_can > to be usefull for can_raw, so errors are returned when > the provided size is lower > > Signed-off-by: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> > > diff --git a/net/can/raw.c b/net/can/raw.c > index 6ec8aa1d0da4..00d352ae221e 100644 > --- a/net/can/raw.c > +++ b/net/can/raw.c > @@ -475,7 +475,7 @@ static int raw_getname(struct socket *sock, struct sockaddr > *uaddr, > if (peer) > return -EOPNOTSUPP; > > - memset(addr, 0, sizeof(*addr)); > + memset(addr, 0, CAN_REQUIRED_SIZE(*addr, ifindex)); can_ifindex? > addr->can_family = AF_CAN; > addr->can_ifindex = ro->ifindex; > > @@ -806,6 +806,10 @@ static int raw_recvmsg(struct socket *sock, struct msghdr > *msg, size_t size, > return sock_recv_errqueue(sk, msg, size, > SOL_CAN_RAW, SCM_CAN_RAW_ERRQUEUE); > > + if (msg->name && msg->msg_namelen < msg->msg_name? > + CAN_REQUIRED_SIZE(struct sockaddr_can, ifindex)) > + return -EINVAL; > + With the above changes this -EINVAL always triggers. msg->msg_namelen is 0 in my case. The application does: socklen_t addrlen = sizeof(struct sockaddr_can); recvfrom(s, &frame, sizeof(struct can_frame), 0, (struct sockaddr *)&addr, &addrlen); Thanks, //richard ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PATCH: Breaking UAPI change? 2021-03-24 19:27 ` PATCH: " Kurt Van Dijck 2021-03-24 19:47 ` Richard Weinberger @ 2021-03-24 20:26 ` Oliver Hartkopp 2021-03-24 21:59 ` Oliver Hartkopp 2021-03-25 8:01 ` Kurt Van Dijck 1 sibling, 2 replies; 8+ messages in thread From: Oliver Hartkopp @ 2021-03-24 20:26 UTC (permalink / raw) To: Richard Weinberger, linux-can On 24.03.21 20:27, Kurt Van Dijck wrote: >> ----- Ursprüngliche Mail ----- >>>> commit f5223e9eee65 ("can: extend sockaddr_can to include j1939 members") >>>> increased the size of >>>> struct sockaddr_can. >>>> This is a problem for applications which use recvfrom() with addrlen being >>>> sizeof(struct sockaddr_can) >>>> or sizeof(struct sockaddr). >>>> If such an application was built before the change it will no longer function >>>> correctly on newer kernels. >>> >>> This scenario was identified, and explicitely dealt with. >>> This requires a tiny bit different code, i.e. net/can/raw.c should use >>> REQUIRED_SIZE() instead of sizeof() for testing the size of the address >>> structure. >>> >>>> In fact I ran into such a scenario and found the said commit later that day. >>> >>> Looking to the v5.10 kernel (which I happen to have checked out), >>> your claim indeed seems true, the raw_recvmsg does not (raw_bind and >>> raw_sendmsg work correct, but that's not important for your problem). >>> >>>> >>>> Is this a known issue? >>> >>> It wasn't, until you found it :-) >> >> Thanks for the prompt reply! >> >>>> Or is this allowed and application must not use sizeof(struct sockaddr_can) as >>>> addrlen? >>> >>> sizeof(struct sockaddr_can). As you already mentioned, applications may have >>> been built >>> before the size increase, and so they should not be recompiled. >>> >>> >>>> If so, what is the proposed way to avoid future breakage? >>> >>> Your application should not change. Kernel must be fixed. >> >> Feel free to CC me when you submit a patch, I'll happily test it. > > Here it goes. > Even not compile tested :-( on my v5.10, at this hour. > I spotted a similar problem in getsockname/getpeername calls. > > The patch will test for minimum required size before touching anything, > later on, the maximum size will be evaluated. > > Happy testing? > > commit 124900109ca88d29382ef2e2b848d3a2f9d67b98 > Author: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> > Date: Wed Mar 24 20:08:50 2021 > > can raw: don't increase provided name length > > The length of the buffer is known by the application, > not the kernel. Kernel is supposed to return only the > size of used bytes. > There is a minimum required size for the struct sockaddr_can > to be usefull for can_raw, so errors are returned when > the provided size is lower > > Signed-off-by: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> > > diff --git a/net/can/raw.c b/net/can/raw.c > index 6ec8aa1d0da4..00d352ae221e 100644 > --- a/net/can/raw.c > +++ b/net/can/raw.c > @@ -475,7 +475,7 @@ static int raw_getname(struct socket *sock, struct sockaddr *uaddr, > if (peer) > return -EOPNOTSUPP; > > - memset(addr, 0, sizeof(*addr)); > + memset(addr, 0, CAN_REQUIRED_SIZE(*addr, ifindex)); > addr->can_family = AF_CAN; > addr->can_ifindex = ro->ifindex; > Is there no need to adapt the return value then? - return sizeof(*addr); + return CAN_REQUIRED_SIZE(*addr, ifindex); Regards, Oliver ps. If so, I need to go through isotp_getname() too ... > @@ -806,6 +806,10 @@ static int raw_recvmsg(struct socket *sock, struct msghdr *msg, size_t size, > return sock_recv_errqueue(sk, msg, size, > SOL_CAN_RAW, SCM_CAN_RAW_ERRQUEUE); > > + if (msg->name && msg->msg_namelen < > + CAN_REQUIRED_SIZE(struct sockaddr_can, ifindex)) > + return -EINVAL; > + > skb = skb_recv_datagram(sk, flags, noblock, &err); > if (!skb) > return err; > @@ -825,7 +829,8 @@ static int raw_recvmsg(struct socket *sock, struct msghdr *msg, size_t size, > > if (msg->msg_name) { > __sockaddr_check_size(sizeof(struct sockaddr_can)); > - msg->msg_namelen = sizeof(struct sockaddr_can); > + if (msg->msg_namelen > sizeof(struct sockaddr_can)) > + msg->msg_namelen = sizeof(struct sockaddr_can); > memcpy(msg->msg_name, skb->cb, msg->msg_namelen); > } > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PATCH: Breaking UAPI change? 2021-03-24 20:26 ` Oliver Hartkopp @ 2021-03-24 21:59 ` Oliver Hartkopp 2021-03-25 8:01 ` Kurt Van Dijck 1 sibling, 0 replies; 8+ messages in thread From: Oliver Hartkopp @ 2021-03-24 21:59 UTC (permalink / raw) To: Kurt Van Dijck, Richard Weinberger; +Cc: linux-can Hi Kurt, I sent a patch which addresses the msg_name issue in all missing CAN protocols. https://lore.kernel.org/linux-can/20210324215442.44537-1-socketcan@hartkopp.net/T/#u Can you please check, if we should go for this approach? @Richard: Can you please test this patch if it fixes your issue? Regards, Oliver On 24.03.21 21:26, Oliver Hartkopp wrote: > > > On 24.03.21 20:27, Kurt Van Dijck wrote: >>> ----- Ursprüngliche Mail ----- >>>>> commit f5223e9eee65 ("can: extend sockaddr_can to include j1939 >>>>> members") >>>>> increased the size of >>>>> struct sockaddr_can. >>>>> This is a problem for applications which use recvfrom() with >>>>> addrlen being >>>>> sizeof(struct sockaddr_can) >>>>> or sizeof(struct sockaddr). >>>>> If such an application was built before the change it will no >>>>> longer function >>>>> correctly on newer kernels. >>>> >>>> This scenario was identified, and explicitely dealt with. >>>> This requires a tiny bit different code, i.e. net/can/raw.c should use >>>> REQUIRED_SIZE() instead of sizeof() for testing the size of the address >>>> structure. >>>> >>>>> In fact I ran into such a scenario and found the said commit later >>>>> that day. >>>> >>>> Looking to the v5.10 kernel (which I happen to have checked out), >>>> your claim indeed seems true, the raw_recvmsg does not (raw_bind and >>>> raw_sendmsg work correct, but that's not important for your problem). >>>> >>>>> >>>>> Is this a known issue? >>>> >>>> It wasn't, until you found it :-) >>> >>> Thanks for the prompt reply! >>>>> Or is this allowed and application must not use sizeof(struct >>>>> sockaddr_can) as >>>>> addrlen? >>>> >>>> sizeof(struct sockaddr_can). As you already mentioned, applications >>>> may have >>>> been built >>>> before the size increase, and so they should not be recompiled. >>>> >>>> >>>>> If so, what is the proposed way to avoid future breakage? >>>> >>>> Your application should not change. Kernel must be fixed. >>> >>> Feel free to CC me when you submit a patch, I'll happily test it. >> >> Here it goes. >> Even not compile tested :-( on my v5.10, at this hour. >> I spotted a similar problem in getsockname/getpeername calls. >> >> The patch will test for minimum required size before touching anything, >> later on, the maximum size will be evaluated. >> >> Happy testing? >> >> commit 124900109ca88d29382ef2e2b848d3a2f9d67b98 >> Author: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> >> Date: Wed Mar 24 20:08:50 2021 >> >> can raw: don't increase provided name length >> The length of the buffer is known by the application, >> not the kernel. Kernel is supposed to return only the >> size of used bytes. >> There is a minimum required size for the struct sockaddr_can >> to be usefull for can_raw, so errors are returned when >> the provided size is lower >> Signed-off-by: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> >> >> diff --git a/net/can/raw.c b/net/can/raw.c >> index 6ec8aa1d0da4..00d352ae221e 100644 >> --- a/net/can/raw.c >> +++ b/net/can/raw.c >> @@ -475,7 +475,7 @@ static int raw_getname(struct socket *sock, struct >> sockaddr *uaddr, >> if (peer) >> return -EOPNOTSUPP; >> - memset(addr, 0, sizeof(*addr)); >> + memset(addr, 0, CAN_REQUIRED_SIZE(*addr, ifindex)); >> addr->can_family = AF_CAN; >> addr->can_ifindex = ro->ifindex; > > Is there no need to adapt the return value then? > > - return sizeof(*addr); > + return CAN_REQUIRED_SIZE(*addr, ifindex); > > Regards, > Oliver > > ps. If so, I need to go through isotp_getname() too ... > > >> @@ -806,6 +806,10 @@ static int raw_recvmsg(struct socket *sock, >> struct msghdr *msg, size_t size, >> return sock_recv_errqueue(sk, msg, size, >> SOL_CAN_RAW, SCM_CAN_RAW_ERRQUEUE); >> + if (msg->name && msg->msg_namelen < >> + CAN_REQUIRED_SIZE(struct sockaddr_can, ifindex)) >> + return -EINVAL; >> + >> skb = skb_recv_datagram(sk, flags, noblock, &err); >> if (!skb) >> return err; >> @@ -825,7 +829,8 @@ static int raw_recvmsg(struct socket *sock, struct >> msghdr *msg, size_t size, >> if (msg->msg_name) { >> __sockaddr_check_size(sizeof(struct sockaddr_can)); >> - msg->msg_namelen = sizeof(struct sockaddr_can); >> + if (msg->msg_namelen > sizeof(struct sockaddr_can)) >> + msg->msg_namelen = sizeof(struct sockaddr_can); >> memcpy(msg->msg_name, skb->cb, msg->msg_namelen); >> } >> ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PATCH: Breaking UAPI change? 2021-03-24 20:26 ` Oliver Hartkopp 2021-03-24 21:59 ` Oliver Hartkopp @ 2021-03-25 8:01 ` Kurt Van Dijck 1 sibling, 0 replies; 8+ messages in thread From: Kurt Van Dijck @ 2021-03-25 8:01 UTC (permalink / raw) To: Oliver Hartkopp; +Cc: Richard Weinberger, linux-can On Wed, 24 Mar 2021 21:26:19 +0100, Oliver Hartkopp wrote: > On 24.03.21 20:27, Kurt Van Dijck wrote: > >>----- Ursprüngliche Mail ----- > >>>>commit f5223e9eee65 ("can: extend sockaddr_can to include j1939 members") > >commit 124900109ca88d29382ef2e2b848d3a2f9d67b98 > >Author: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> > >Date: Wed Mar 24 20:08:50 2021 > > > > can raw: don't increase provided name length > > The length of the buffer is known by the application, > > not the kernel. Kernel is supposed to return only the > > size of used bytes. > > There is a minimum required size for the struct sockaddr_can > > to be usefull for can_raw, so errors are returned when > > the provided size is lower > > Signed-off-by: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> > > > >diff --git a/net/can/raw.c b/net/can/raw.c > >index 6ec8aa1d0da4..00d352ae221e 100644 > >--- a/net/can/raw.c > >+++ b/net/can/raw.c > >@@ -475,7 +475,7 @@ static int raw_getname(struct socket *sock, struct sockaddr *uaddr, > > if (peer) > > return -EOPNOTSUPP; > >- memset(addr, 0, sizeof(*addr)); > >+ memset(addr, 0, CAN_REQUIRED_SIZE(*addr, ifindex)); > > addr->can_family = AF_CAN; > > addr->can_ifindex = ro->ifindex; > > Is there no need to adapt the return value then? > > - return sizeof(*addr); > + return CAN_REQUIRED_SIZE(*addr, ifindex); indeed. I have missed that one. I was looking for a function parameter, and then forgot somehow ... > > Regards, > Oliver > > ps. If so, I need to go through isotp_getname() too ... > > > >@@ -806,6 +806,10 @@ static int raw_recvmsg(struct socket *sock, struct msghdr *msg, size_t size, > > return sock_recv_errqueue(sk, msg, size, > > SOL_CAN_RAW, SCM_CAN_RAW_ERRQUEUE); > >+ if (msg->name && msg->msg_namelen < > >+ CAN_REQUIRED_SIZE(struct sockaddr_can, ifindex)) > >+ return -EINVAL; > >+ > > skb = skb_recv_datagram(sk, flags, noblock, &err); > > if (!skb) > > return err; > >@@ -825,7 +829,8 @@ static int raw_recvmsg(struct socket *sock, struct msghdr *msg, size_t size, > > if (msg->msg_name) { > > __sockaddr_check_size(sizeof(struct sockaddr_can)); > >- msg->msg_namelen = sizeof(struct sockaddr_can); > >+ if (msg->msg_namelen > sizeof(struct sockaddr_can)) > >+ msg->msg_namelen = sizeof(struct sockaddr_can); > > memcpy(msg->msg_name, skb->cb, msg->msg_namelen); > > } > > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-03-25 8:02 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-24 15:30 Breaking UAPI change? Richard Weinberger 2021-03-24 19:01 ` Kurt Van Dijck 2021-03-24 19:21 ` Richard Weinberger 2021-03-24 19:27 ` PATCH: " Kurt Van Dijck 2021-03-24 19:47 ` Richard Weinberger 2021-03-24 20:26 ` Oliver Hartkopp 2021-03-24 21:59 ` Oliver Hartkopp 2021-03-25 8:01 ` Kurt Van Dijck
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.