This is a two part problem.

First, the GNATS database administrator (that's pretty much me, for now) is
responsible for looking over Confidential problem reports and making sure that
they're properly assigned, properly formatted, etc. The largest number of
Confidential PRs are malformed in some way, and placed in the the "pending"
category for the DB admin to deal with manually.

I've just completed a clean up that was at least six or nine months overdue.
Mea culpa, I got busy, and no one else took up the slack. This is what happens
when you rely on volunteer labor, alas. So, as of the writing of this PR
comment, there is only one PR in Confidential state that should not be, and
I'm going to have to nuke that one from orbit (it's the only way to be sure)
because it's giving GNATS fits for some reason.

Second, there's a mismatch between our procedures and the tools we use.

GNATS is designed to send incoming problem reports to all responsible parties,
plus other E-mail targets as configured, and it makes no distinction for
Confidential PRs (why should it? those notifications are, by design, for
"internal" consumption of whatever organization uses GNATS, and keeping
confidential PRs confidential from even the people who are supposed to fix
the problems reported is counterproductive).

The NetBSD Project, as noted, does the right thing with the GNATS DB interface
on our web server: we do not permit Confidential PRs to be visible.

Unfortunately, we do the wrong thing with the mailing list(s) to which the
PRs are sent:  we archive those mailing lists and make those archives available
to all users of the web. As the problem report complains, this exposes
Confidential PRs to the entire web.

The bias here in the way we handle our mailing list archives is to make the
project open and accountable, available for anyone to inspect. This conflicts
with the properly secure handling of "confidential" information.

There are a number of possible changes we could make:

1. no longer archive netbsd-bugs. Isn't the GNATS DB itself record enough?

2. no longer make the netbsd-bugs mailing list archive generally available.
	So far as I know, we don't have an authentication mechanism for access
	to any of our web pages right now - we'd have to ask the WWW team if
	this is something that could be relatively easily done and maintained.

3. stop sending GNATS PRs to NetBSD mailing lists.
	(ah, to live in the bliss of apparently bug-free software!)

4. hack on GNATS to not send Confidential PRs to netbsd-bugs.
	That's counterproductive, as I noted above; how are the PRs going to
	be resolved if no one knows about them? I suppose it would be a variant
	of the bliss of #3.

5. hack on GNATS to send Confidential PRs to a separate, non-archived list.

I want to say right now that I haven't hacked the internals of GNATS; I merely
maintain the database, and I have no burning desire to go whack at it, so my
preference would be #2, or #3.

	a NetBSD GNATS DB admin and
	a former NetBSD security officer,

	Erik <fair@netbsd.org>