[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZOuqk2+3EMBV3pPy@1wt.eu>
Date: Sun, 27 Aug 2023 21:57:07 +0200
From: Willy Tarreau <w@....eu>
To: oss-security@...ts.openwall.com
Cc: Vegard Nossum <vegard.nossum@...cle.com>, Jiri Kosina <jkosina@...e.cz>,
Donald Buczek <buczek@...gen.mpg.de>,
Greg KH <gregkh@...uxfoundation.org>
Subject: Re: linux-distros list policy and Linux kernel, again
Hi Alexander,
On Sat, Aug 26, 2023 at 12:23:59AM +0200, Solar Designer wrote:
> In terms of (linux-)distros list policy, what can we do here? Accept up
> to 7 days since fix is ready and thus accept arbitrarily long embargoes
> and more likely have issues "requiring" such embargoes brought to the
> list? BTW, for CPU microarchitectural issues, that would probably need
> to be for the full distros list, not limited to Linux, and from what I
> know disclosure timelines for such issues may be 3 to 12+ months.
Please note that delays are not specific to hardware issues. We've had
to work maybe 3 months with a reporter on a randomness problem that
allowed to some extents to guess TCP ports and sequence numbers, and it
required us to imagine various approaches that shouldn't break TCP, and
iterate with the researchers who studied them, tested them before getting
back to us with "it still isn't sufficient". It was a long and painful
one, nobody remained idle, yet it was really needed to get to the end of
it before publishing anything. Further, the researchers asked us to keep
some details on hold for a while because they were preparing a paper, and
this is also something to keep in mind (some of them depened on this,
though we must not accept that it drags for too long).
As such I think that it's not a good solution to anything to require a
disclosure before a fix is ready. Actually there can be one exception:
when no more progress is being made. I don't think I would personally be
shocked by saying that a discussion that remained inactive for 7 days
leads to publication, it would sufficiently put the pressure on all parties
not to let it cool rot. And difficult issues generally don't stay inactive
for more than a few days.
> As to publishing PoCs/exploits, this is already mitigated by the Linux
> kernel documentation edit making it less likely (but far from
> impossible) that people would send stuff to linux-distros without being
> aware of the policy. We could further mitigate this issue by allowing
> up to 30 days (but perhaps suggesting at most 7 days?)
I don't think maintaining pressure on the reporter regarding the need
for publishing reproducers is doing any good. It should be up to the
reporter to say "please keep this confidential". We've had many of
these on s@k.o, and it's perfectly understandable. Knowing that they
must be very careful about what they share because it will be published
is a big constraint, whether it's in terms of code quality, authorization
from an employer or customer, code that was blatantly copy-pasted from
another exploit just to help with testing, etc. All of this is useful
for those trying to fix the problem and do not strictly need to be
published, so it's pointless to add pressure on the reporter regarding
this.
Just my two cents,
willy
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.
