In message <200207030512.g635CMXl027835@xerxes.courtesan.com>, "Todd C. Miller"
 writes:
>I'm going to don my asbestos suit for a minute and suggest that
>what we could really use is a *BSD security list, akin to the Linux
>vendor-sec list.  I think it makes sense to have a place where we
>can discuss security issues common to all the BSDs and not worry
>about what is or is not of specific interest to ChooseYouOwnBSD.
>
>This could take one of two forms:
>
> a) A list open only to the various security officers that gets
>    advance warning of problems, CERT advisories, etc..  This allows
>    for coordinating fixes but requires that list members not forward
>    things off-list.  In the past, such lists have been leaky.
>
> b) An open list.  No advanced warning of problems would be posted.
>    The list could still be used for coordination but I don't find
>    this terribly compelling.
>

I strongly agree.  I've been mulling the following scheme for the last
few days.  Comments welcome; redistribution of this to the proper
lists in the other BSD arenas solicited.

-----


	It's in everyone's interest to secure all machines on the
	Internet -- *BSD, Linux, even Windows

	Security holes (and the relevant fixes) can be discovered by
	anyone.

	It takes a bit of time for responsible developers to create,
	test, and integrate a fix.

	It's generally advisable to keep problem information quiet
	for a *reasonable* amount of time while this is going on.
	That said, there are a few people who have to know beyond the
	security officers:

		The responsible developer who's actually going to do
		the fix.

		The release engineers, if one of the systems involved
		is going through a release cycle.

		In some cases, the folks who run the official repositories --
		a compromised distribution site could be a disaster.

	The crucial instant is when fixes (source or binary) are available via
	the public repositories.  This has to be co-ordinated.

So -- I propose creation of "BSD-CERT", to be composed of the security
officers from the different groups, plus representatives of the release
engineering teams.

	Each organization decides for itself who is best-suited to
	fix the problem, and who else should know.

	*But* -- *any* redistribution, *including* to the appropriate
	developer, is accompanied by a note to the mailing list.
	In other words, I want accountability.  Violation of this
	rule -- i.e., passing on the warning without telling the other
	members of BSD-CERT -- is grounds for immediate removal from the list.

	Existence of problems is disclosed to BSD-CERT as soon as it's
	known, to permit proper scheduling.  Yes, this might be before a
	fix is ready.

	No one makes anything public until everyone has a fix ready,
	as long as that isn't taking an "unreasonable" amount of time.
	(I decline to define "reasonable".)  But if someone is taking
	too long, there's no choice -- sitting on vulnerabilites doesn't
	work.

	The relevant mailing lists should be run by a neutral party.
	There's just too much history, bad blood, and mistrust for it
	to be hosted at FooBSD.org, etc.  (I'm afraid that that does
	exclude Wasabi Systems.)

	Membership in the mailing list should be identifiable individuals,
	and not titles like security-officer@FooBSD.org.