[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230828185350.pw5nasedkujiatvp@yuggoth.org>
Date: Mon, 28 Aug 2023 18:53:50 +0000
From: Jeremy Stanley <fungi@...goth.org>
To: oss-security@...ts.openwall.com
Subject: Re: linux-distros list policy and Linux kernel, again
On 2023-08-28 20:05:18 +0200 (+0200), Solar Designer wrote:
[...]
> So the real problem may be that (linux-)distros is misunderstood
> as permanently-private rather than temporarily-private.
> Unfortunately, I don't know how to address that reliably. Even
> with automated delayed publication, some people would initially
> have the wrong idea... maybe unless they have to pass through a
> web page with the public archives before finding the posting
> address?
[...]
I know a defect tracker is (perhaps a lot) different from a mailing
list, but on one of the larger projects where I act as a
vulnerability coordinator we have a policy which includes a maximum
embargo duration. The project uses defect trackers which have the
ability to switch reports between public and private visibility, and
on intake of any initially private report a vulnerability
coordinator calculates the date of the embargo expiration and
notifies everyone involved in that discussion what that date is (in
our case by prepending a disclaimer to the report description which
also includes policy items like reminders not to redistribute while
the embargo is in effect). Our instructions on how to report
suspected vulnerabilities also mention this policy.
While we've occasionally had to redact some report content in cases
where users unwittingly attached sensitive data, I don't think we've
encountered a case of reporters being surprised that the content of
their reports will eventually be exposed to the public. Before
putting a limit on how long reports could remain private, we had
cases of some reports sitting unfixed or even uninvestigated and
effectively ignored by developers of the affected subsystems for
years. We determined, as a project, that it was better to have a
forcing action so that the community would at least be aware of
potential defects, and could perhaps even assist in making progress
on some of them where the usual maintainers lacked time or interest
in doing so.
Maybe another significant difference is that our embargoes have an
expiration 6.5x longer than that of the linux-distros ML, and we
have (on rare occasion) granted extensions of up to a week or two in
cases where there was active work underway but thorough testing and
vetting required a little additional time. To your point though, our
vulnerability coordinators are generally the ones to notify the
linux-distros ML of upcoming publications, and our documented
process includes a reminder not to notify that list until just prior
to a scheduled disclosure (generally no more than 5 business days in
advance), in order to comply with the list's policy.
--
Jeremy Stanley
Download attachment "signature.asc" of type "application/pgp-signature" (964 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
