linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v6] EDAC/mc: Prefer strscpy or scnprintf over strcpy
@ 2021-09-03 15:05 Len Baker
  2021-09-03 17:03 ` Joe Perches
  2021-09-13  8:59 ` [PATCH] EDAC/mc: Prefer strscpy or scnprintf over strcpy, sprintf and snprintf Robert Richter
  0 siblings, 2 replies; 8+ messages in thread
From: Len Baker @ 2021-09-03 15:05 UTC (permalink / raw)
  To: Borislav Petkov, Mauro Carvalho Chehab, Tony Luck, James Morse,
	Robert Richter, Joe Perches
  Cc: Len Baker, David Laight, Kees Cook, linux-hardening, linux-edac,
	linux-kernel

strcpy() performs no bounds checking on the destination buffer. This
could result in linear overflows beyond the end of the buffer, leading
to all kinds of misbehaviors. The safe replacement is strscpy() [1].

However, to simplify and clarify the code, to concatenate labels use
the scnprintf() function. This way it is not necessary to check the
return value of strscpy (-E2BIG if the parameter count is 0 or the src
was truncated) since the scnprintf returns always the number of chars
written into the buffer. This function returns always a nul-terminated
string even if it needs to be truncated.

The main reason behind this patch is to remove all the strcpy() uses
from the kernel with the purpose to clean up the proliferation of
str*cpy() functions. Later on, the next step will be remove all the
strcpy implementations [2].

[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy
[2] https://github.com/KSPP/linux/issues/88

Co-developed-by: Joe Perches <joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Len Baker <len.baker@gmx.com>
---
Hi Joe,

I have added the "Co-developed-by: Joe Perches" tag to give you credit,
since all the code used in this patch relies heavily on your review
code snippets.

I hope there are no objections.

Thanks,
Len

Changelog v1 -> v2
- Use the strscpy() instead of scnprintf() to add labels and follow a
  code pattern more similar to the current one (advance "p" and
  decrement "left") (Robert Richter).

Changelog v2 -> v3
- Rename the "left" variable to "len" (Robert Richter).
- Use strlen(p) instead of strlen(OTHER_LABEL) to decrement "len" and
  increment "p" as otherwise "left" could underflow and p overflow
  (Robert Richter).

Changelog v3 -> v4
- Change the commit subject (Joe Perches).
- Fix broken logic (Robert Richter).
- Rebase against v5.14-rc5.

Changelog v4 -> v5
- Change the commit subject.
- Clarify why the change is being made by adding more info to the
  commit message (Borislav Petkov).
- Use scnprintf instead of strscpy (Joe Perches).
- Rebase against v5.14-rc7.

Changelog v5 -> v6
- Rebase against v5.14.
- Refactor the code to use a more common scnprintf mechanism (Joe
  Perches).

Previous versions:

v1
https://lore.kernel.org/linux-hardening/20210725162954.9861-1-len.baker@gmx.com/

v2
https://lore.kernel.org/linux-hardening/20210801143558.12674-1-len.baker@gmx.com/

v3
https://lore.kernel.org/linux-hardening/20210807155957.10069-1-len.baker@gmx.com/

v4
https://lore.kernel.org/linux-hardening/20210814075527.5999-1-len.baker@gmx.com/

v5
https://lore.kernel.org/linux-hardening/20210829161547.6069-1-len.baker@gmx.com/

 drivers/edac/edac_mc.c | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c
index f6d462d0be2d..97dff62970a5 100644
--- a/drivers/edac/edac_mc.c
+++ b/drivers/edac/edac_mc.c
@@ -1032,6 +1032,8 @@ void edac_mc_handle_error(const enum hw_event_mc_err_type type,
 	int i, n_labels = 0;
 	struct edac_raw_error_desc *e = &mci->error_desc;
 	bool any_memory = true;
+	const char *prefix = "";
+	int n = 0;

 	edac_dbg(3, "MC%d\n", mci->mc_idx);

@@ -1113,12 +1115,9 @@ void edac_mc_handle_error(const enum hw_event_mc_err_type type,
 			p = e->label;
 			*p = '\0';
 		} else {
-			if (p != e->label) {
-				strcpy(p, OTHER_LABEL);
-				p += strlen(OTHER_LABEL);
-			}
-			strcpy(p, dimm->label);
-			p += strlen(p);
+			n += scnprintf(e->label + n, sizeof(e->label) - n,
+				       "%s%s", prefix, dimm->label);
+			prefix = OTHER_LABEL;
 		}

 		/*
@@ -1140,9 +1139,9 @@ void edac_mc_handle_error(const enum hw_event_mc_err_type type,
 	}

 	if (any_memory)
-		strcpy(e->label, "any memory");
+		strscpy(e->label, "any memory", sizeof(e->label));
 	else if (!*e->label)
-		strcpy(e->label, "unknown memory");
+		strscpy(e->label, "unknown memory", sizeof(e->label));

 	edac_inc_csrow(e, row, chan);

--
2.25.1


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH v6] EDAC/mc: Prefer strscpy or scnprintf over strcpy
  2021-09-03 15:05 [PATCH v6] EDAC/mc: Prefer strscpy or scnprintf over strcpy Len Baker
@ 2021-09-03 17:03 ` Joe Perches
  2021-09-04 11:23   ` Len Baker
  2021-09-13  8:59 ` [PATCH] EDAC/mc: Prefer strscpy or scnprintf over strcpy, sprintf and snprintf Robert Richter
  1 sibling, 1 reply; 8+ messages in thread
From: Joe Perches @ 2021-09-03 17:03 UTC (permalink / raw)
  To: Len Baker
  Cc: Borislav Petkov, Mauro Carvalho Chehab, Tony Luck, James Morse,
	Robert Richter, David Laight, Kees Cook, linux-hardening,
	linux-edac, linux-kernel

On 2021-09-03 08:05, Len Baker wrote:
> strcpy() performs no bounds checking on the destination buffer. 
> len.baker@gmx.com/

[]

> @@ -1113,12 +1115,9 @@ void edac_mc_handle_error(const enum
> hw_event_mc_err_type type,
>  			p = e->label;
>  			*p = '\0';
>  		} else {
> -			if (p != e->label) {
> -				strcpy(p, OTHER_LABEL);
> -				p += strlen(OTHER_LABEL);
> -			}
> -			strcpy(p, dimm->label);
> -			p += strlen(p);
> +			n += scnprintf(e->label + n, sizeof(e->label) - n,
> +				       "%s%s", prefix, dimm->label);
> +			prefix = OTHER_LABEL;

OTHER_LABEL is a define specific to this module

IMO: Used once text macros are just obfuscating and should be removed.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v6] EDAC/mc: Prefer strscpy or scnprintf over strcpy
  2021-09-03 17:03 ` Joe Perches
@ 2021-09-04 11:23   ` Len Baker
  2021-09-04 11:36     ` Borislav Petkov
  0 siblings, 1 reply; 8+ messages in thread
From: Len Baker @ 2021-09-04 11:23 UTC (permalink / raw)
  To: Joe Perches
  Cc: Len Baker, Borislav Petkov, Mauro Carvalho Chehab, Tony Luck,
	James Morse, Robert Richter, David Laight, Kees Cook,
	linux-hardening, linux-edac, linux-kernel

Hi,

On Fri, Sep 03, 2021 at 10:03:18AM -0700, Joe Perches wrote:
> On 2021-09-03 08:05, Len Baker wrote:
> > strcpy() performs no bounds checking on the destination buffer.
> > len.baker@gmx.com/
>
> []
>
> > @@ -1113,12 +1115,9 @@ void edac_mc_handle_error(const enum
> > hw_event_mc_err_type type,
> >  			p = e->label;
> >  			*p = '\0';
> >  		} else {
> > -			if (p != e->label) {
> > -				strcpy(p, OTHER_LABEL);
> > -				p += strlen(OTHER_LABEL);
> > -			}
> > -			strcpy(p, dimm->label);
> > -			p += strlen(p);
> > +			n += scnprintf(e->label + n, sizeof(e->label) - n,
> > +				       "%s%s", prefix, dimm->label);
> > +			prefix = OTHER_LABEL;
>
> OTHER_LABEL is a define specific to this module
>
> IMO: Used once text macros are just obfuscating and should be removed.

This macro is used in "/include/linux/edac.h" as follows:

struct edac_raw_error_desc {
	[...]
	char label[(EDAC_MC_LABEL_LEN + 1 + sizeof(OTHER_LABEL)) * EDAC_MAX_LABELS];
	[...]
};

If we remove this define the size of label would be:

	char label[(EDAC_MC_LABEL_LEN + 6) * EDAC_MAX_LABELS];

So, I think now is more complicated to understand because the size is
what it is. If you prefer this option, I can remove the macro and add
a comment with some explanation.

Regards,
Len

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v6] EDAC/mc: Prefer strscpy or scnprintf over strcpy
  2021-09-04 11:23   ` Len Baker
@ 2021-09-04 11:36     ` Borislav Petkov
  2021-09-04 13:22       ` Len Baker
  0 siblings, 1 reply; 8+ messages in thread
From: Borislav Petkov @ 2021-09-04 11:36 UTC (permalink / raw)
  To: Len Baker
  Cc: Joe Perches, Mauro Carvalho Chehab, Tony Luck, James Morse,
	Robert Richter, David Laight, Kees Cook, linux-hardening,
	linux-edac, linux-kernel

On Sat, Sep 04, 2021 at 01:23:03PM +0200, Len Baker wrote:
> I can remove the macro and add a comment with some explanation.

No, please leave the macro.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v6] EDAC/mc: Prefer strscpy or scnprintf over strcpy
  2021-09-04 11:36     ` Borislav Petkov
@ 2021-09-04 13:22       ` Len Baker
  0 siblings, 0 replies; 8+ messages in thread
From: Len Baker @ 2021-09-04 13:22 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Len Baker, Joe Perches, Mauro Carvalho Chehab, Tony Luck,
	James Morse, Robert Richter, David Laight, Kees Cook,
	linux-hardening, linux-edac, linux-kernel

Hi,

On Sat, Sep 04, 2021 at 01:36:26PM +0200, Borislav Petkov wrote:
> On Sat, Sep 04, 2021 at 01:23:03PM +0200, Len Baker wrote:
> > I can remove the macro and add a comment with some explanation.
>
> No, please leave the macro.

Ok, so I leave the patch as is.

Thanks,
Len

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH] EDAC/mc: Prefer strscpy or scnprintf over strcpy, sprintf and snprintf
  2021-09-03 15:05 [PATCH v6] EDAC/mc: Prefer strscpy or scnprintf over strcpy Len Baker
  2021-09-03 17:03 ` Joe Perches
@ 2021-09-13  8:59 ` Robert Richter
  2021-09-15 11:58   ` Borislav Petkov
  2021-09-18  9:17   ` Len Baker
  1 sibling, 2 replies; 8+ messages in thread
From: Robert Richter @ 2021-09-13  8:59 UTC (permalink / raw)
  To: Len Baker
  Cc: Borislav Petkov, Mauro Carvalho Chehab, Tony Luck, James Morse,
	Joe Perches, David Laight, Kees Cook, linux-hardening,
	linux-edac, linux-kernel

Len,

On 03.09.21 17:05:39, Len Baker wrote:
> strcpy() performs no bounds checking on the destination buffer. This
> could result in linear overflows beyond the end of the buffer, leading
> to all kinds of misbehaviors. The safe replacement is strscpy() [1].
> 
> However, to simplify and clarify the code, to concatenate labels use
> the scnprintf() function. This way it is not necessary to check the
> return value of strscpy (-E2BIG if the parameter count is 0 or the src
> was truncated) since the scnprintf returns always the number of chars
> written into the buffer. This function returns always a nul-terminated
> string even if it needs to be truncated.
> 
> The main reason behind this patch is to remove all the strcpy() uses
> from the kernel with the purpose to clean up the proliferation of
> str*cpy() functions. Later on, the next step will be remove all the
> strcpy implementations [2].
> 
> [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy
> [2] https://github.com/KSPP/linux/issues/88
> 
> Co-developed-by: Joe Perches <joe@perches.com>
> Signed-off-by: Joe Perches <joe@perches.com>
> Signed-off-by: Len Baker <len.baker@gmx.com>

this patch looks good to me. I made some changes on top of it to
further ease pointer arithmetic and also fix remaining
sprintf/snprintf() users as it makes sense to have them all in a
single change. See below. Boris, please apply.

Thanks,

-Robert

From 01a3c62a533e71984dfff7189e247b3e848f1449 Mon Sep 17 00:00:00 2001
From: Len Baker <len.baker@gmx.com>
Date: Fri, 3 Sep 2021 17:05:39 +0200
Subject: [PATCH] EDAC/mc: Prefer strscpy or scnprintf over strcpy, sprintf
 and snprintf

strcpy() performs no bounds checking on the destination buffer. This
could result in linear overflows beyond the end of the buffer, leading
to all kinds of misbehaviors. The safe replacement is strscpy().
[1][2]

However, to simplify and clarify the code, to concatenate labels use
the scnprintf() function. This way it is not necessary to check the
return value of strscpy (-E2BIG if the parameter count is 0 or the src
was truncated) since the scnprintf returns always the number of chars
written into the buffer. This function returns always a nul-terminated
string even if it needs to be truncated.

While at it, fix all other broken string generation code that wrongly
interprets snprintf()'s return code or just uses sprintf(), implement
that using scnprintf() here too. Drop breaks in loops around
scnprintf() as it is safe now to loop. Moreover, the check is
needless: For the case when the buffer is exhausted, len never gets
zero because scnprintf() takes the full buffer length as input
parameter, but excludes the trailing '\0' in its return code and thus,
1 is the minimum len.

[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy
[2] https://github.com/KSPP/linux/issues/88

 [ rric: Replace snprintf() with scnprintf(), rework sprintf() user,
   drop breaks in loops around scnprintf(), introduce 'end' pointer to
   reduce pointer arithmetic, use prefix pattern for e->location,
   adjust subject and description ]

Co-developed-by: Joe Perches <joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Len Baker <len.baker@gmx.com>
Signed-off-by: Robert Richter <rrichter@amd.com>
---
 drivers/edac/edac_mc.c | 42 ++++++++++++++++++------------------------
 1 file changed, 18 insertions(+), 24 deletions(-)

diff --git a/drivers/edac/edac_mc.c b/drivers/edac/edac_mc.c
index 2c5975674723..9f82ca295353 100644
--- a/drivers/edac/edac_mc.c
+++ b/drivers/edac/edac_mc.c
@@ -66,14 +66,12 @@ unsigned int edac_dimm_info_location(struct dimm_info *dimm, char *buf,
 	char *p = buf;
 
 	for (i = 0; i < mci->n_layers; i++) {
-		n = snprintf(p, len, "%s %d ",
+		n = scnprintf(p, len, "%s %d ",
 			      edac_layer_name[mci->layers[i].type],
 			      dimm->location[i]);
 		p += n;
 		len -= n;
 		count += n;
-		if (!len)
-			break;
 	}
 
 	return count;
@@ -341,19 +339,16 @@ static int edac_mc_alloc_dimms(struct mem_ctl_info *mci)
 		 */
 		len = sizeof(dimm->label);
 		p = dimm->label;
-		n = snprintf(p, len, "mc#%u", mci->mc_idx);
+		n = scnprintf(p, len, "mc#%u", mci->mc_idx);
 		p += n;
 		len -= n;
 		for (layer = 0; layer < mci->n_layers; layer++) {
-			n = snprintf(p, len, "%s#%u",
-				     edac_layer_name[mci->layers[layer].type],
-				     pos[layer]);
+			n = scnprintf(p, len, "%s#%u",
+				      edac_layer_name[mci->layers[layer].type],
+				      pos[layer]);
 			p += n;
 			len -= n;
 			dimm->location[layer] = pos[layer];
-
-			if (len <= 0)
-				break;
 		}
 
 		/* Link it to the csrows old API data */
@@ -1027,12 +1022,13 @@ void edac_mc_handle_error(const enum hw_event_mc_err_type type,
 			  const char *other_detail)
 {
 	struct dimm_info *dimm;
-	char *p;
+	char *p, *end;
 	int row = -1, chan = -1;
 	int pos[EDAC_MAX_LAYERS] = { top_layer, mid_layer, low_layer };
 	int i, n_labels = 0;
 	struct edac_raw_error_desc *e = &mci->error_desc;
 	bool any_memory = true;
+	const char *prefix;
 
 	edac_dbg(3, "MC%d\n", mci->mc_idx);
 
@@ -1087,6 +1083,8 @@ void edac_mc_handle_error(const enum hw_event_mc_err_type type,
 	 */
 	p = e->label;
 	*p = '\0';
+	end = p + sizeof(e->label);
+	prefix = "";
 
 	mci_for_each_dimm(mci, dimm) {
 		if (top_layer >= 0 && top_layer != dimm->location[0])
@@ -1114,12 +1112,8 @@ void edac_mc_handle_error(const enum hw_event_mc_err_type type,
 			p = e->label;
 			*p = '\0';
 		} else {
-			if (p != e->label) {
-				strcpy(p, OTHER_LABEL);
-				p += strlen(OTHER_LABEL);
-			}
-			strcpy(p, dimm->label);
-			p += strlen(p);
+			p += scnprintf(p, end - p, "%s%s", prefix, dimm->label);
+			prefix = OTHER_LABEL;
 		}
 
 		/*
@@ -1141,25 +1135,25 @@ void edac_mc_handle_error(const enum hw_event_mc_err_type type,
 	}
 
 	if (any_memory)
-		strcpy(e->label, "any memory");
+		strscpy(e->label, "any memory", sizeof(e->label));
 	else if (!*e->label)
-		strcpy(e->label, "unknown memory");
+		strscpy(e->label, "unknown memory", sizeof(e->label));
 
 	edac_inc_csrow(e, row, chan);
 
 	/* Fill the RAM location data */
 	p = e->location;
+	end = p + sizeof(e->location);
+	prefix = "";
 
 	for (i = 0; i < mci->n_layers; i++) {
 		if (pos[i] < 0)
 			continue;
 
-		p += sprintf(p, "%s:%d ",
-			     edac_layer_name[mci->layers[i].type],
-			     pos[i]);
+		p += scnprintf(p, end - p, "%s%s:%d", prefix,
+			       edac_layer_name[mci->layers[i].type], pos[i]);
+		prefix = " ";
 	}
-	if (p > e->location)
-		*(p - 1) = '\0';
 
 	edac_raw_mc_handle_error(e);
 }
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] EDAC/mc: Prefer strscpy or scnprintf over strcpy, sprintf and snprintf
  2021-09-13  8:59 ` [PATCH] EDAC/mc: Prefer strscpy or scnprintf over strcpy, sprintf and snprintf Robert Richter
@ 2021-09-15 11:58   ` Borislav Petkov
  2021-09-18  9:17   ` Len Baker
  1 sibling, 0 replies; 8+ messages in thread
From: Borislav Petkov @ 2021-09-15 11:58 UTC (permalink / raw)
  To: Robert Richter
  Cc: Len Baker, Mauro Carvalho Chehab, Tony Luck, James Morse,
	Joe Perches, David Laight, Kees Cook, linux-hardening,
	linux-edac, linux-kernel

On Mon, Sep 13, 2021 at 10:59:10AM +0200, Robert Richter wrote:
> From 01a3c62a533e71984dfff7189e247b3e848f1449 Mon Sep 17 00:00:00 2001
> From: Len Baker <len.baker@gmx.com>
> Date: Fri, 3 Sep 2021 17:05:39 +0200
> Subject: [PATCH] EDAC/mc: Prefer strscpy or scnprintf over strcpy, sprintf
>  and snprintf
> 
> strcpy() performs no bounds checking on the destination buffer. This
> could result in linear overflows beyond the end of the buffer, leading
> to all kinds of misbehaviors. The safe replacement is strscpy().
> [1][2]
> 
> However, to simplify and clarify the code, to concatenate labels use
> the scnprintf() function. This way it is not necessary to check the
> return value of strscpy (-E2BIG if the parameter count is 0 or the src
> was truncated) since the scnprintf returns always the number of chars
> written into the buffer. This function returns always a nul-terminated
> string even if it needs to be truncated.
> 
> While at it, fix all other broken string generation code that wrongly
> interprets snprintf()'s return code or just uses sprintf(), implement
> that using scnprintf() here too. Drop breaks in loops around
> scnprintf() as it is safe now to loop. Moreover, the check is
> needless: For the case when the buffer is exhausted, len never gets
> zero because scnprintf() takes the full buffer length as input
> parameter, but excludes the trailing '\0' in its return code and thus,
> 1 is the minimum len.
> 
> [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy
> [2] https://github.com/KSPP/linux/issues/88
> 
>  [ rric: Replace snprintf() with scnprintf(), rework sprintf() user,
>    drop breaks in loops around scnprintf(), introduce 'end' pointer to
>    reduce pointer arithmetic, use prefix pattern for e->location,
>    adjust subject and description ]
> 
> Co-developed-by: Joe Perches <joe@perches.com>
> Signed-off-by: Joe Perches <joe@perches.com>
> Signed-off-by: Len Baker <len.baker@gmx.com>
> Signed-off-by: Robert Richter <rrichter@amd.com>
> ---
>  drivers/edac/edac_mc.c | 42 ++++++++++++++++++------------------------
>  1 file changed, 18 insertions(+), 24 deletions(-)

Applied, thanks.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] EDAC/mc: Prefer strscpy or scnprintf over strcpy, sprintf and snprintf
  2021-09-13  8:59 ` [PATCH] EDAC/mc: Prefer strscpy or scnprintf over strcpy, sprintf and snprintf Robert Richter
  2021-09-15 11:58   ` Borislav Petkov
@ 2021-09-18  9:17   ` Len Baker
  1 sibling, 0 replies; 8+ messages in thread
From: Len Baker @ 2021-09-18  9:17 UTC (permalink / raw)
  To: Robert Richter
  Cc: Len Baker, Borislav Petkov, Mauro Carvalho Chehab, Tony Luck,
	James Morse, Joe Perches, David Laight, Kees Cook,
	linux-hardening, linux-edac, linux-kernel

Hi,

On Mon, Sep 13, 2021 at 10:59:10AM +0200, Robert Richter wrote:

> this patch looks good to me. I made some changes on top of it to
> further ease pointer arithmetic and also fix remaining
> sprintf/snprintf() users as it makes sense to have them all in a
> single change. See below. Boris, please apply.

Thanks Robert for doing this.

Regards,
Len

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2021-09-18  9:17 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-03 15:05 [PATCH v6] EDAC/mc: Prefer strscpy or scnprintf over strcpy Len Baker
2021-09-03 17:03 ` Joe Perches
2021-09-04 11:23   ` Len Baker
2021-09-04 11:36     ` Borislav Petkov
2021-09-04 13:22       ` Len Baker
2021-09-13  8:59 ` [PATCH] EDAC/mc: Prefer strscpy or scnprintf over strcpy, sprintf and snprintf Robert Richter
2021-09-15 11:58   ` Borislav Petkov
2021-09-18  9:17   ` Len Baker

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).