[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <80A23796-B927-434A-BC10-C71AE0CAE95E@gentoo.org>
Date: Sun, 22 May 2022 20:53:06 +0100
From: Sam James <sam@...too.org>
To: oss-security@...ts.openwall.com
Subject: Re: linux-distros list policy and Linux kernel
> On 22 May 2022, at 20:46, Solar Designer <solar@...nwall.com> wrote:
>
> On Mon, May 16, 2022 at 09:12:25PM +0200, Greg KH wrote:
>> Taking this a bit further, why is the kernel "special" for something
>> like this? Why wouldn't this also apply to any other project with a
>> reasonable number of developers where you want additional review and
>> acceptance of changes before the world is notified that an issue was
>> fixed? That allows issues to be fixed, and to be in place on users
>> systems before the issue is made public.
>>
>> I would imagine that projects like Kubernetes, or Jenkins, or Docker or
>> Mozilla or Chrome or other large systems would also fall into this
>> category. Heck, smaller projects too, the size shouldn't matter, what
>> matters is that users have the ability to upgrade before security issues
>> are told to the world, ensuring that user's systems are safe.
>
> For issues commonly brought to (linux-)distros, we currently only
> encounter this sort of conflicting preferences with the Linux kernel
> community. I guess some other projects also release silent fixes that
> are only later documented to have known security relevance. Maybe our
> policy plays a role in non-reporting of such issues to distros, or maybe
> not. For example, we generally do not receive reports of
> vulnerabilities in Firefox and Chrome/ium to the distros list, but I
> don't recall anyone ever expressing any unhappiness about that - neither
> those projects nor the distros. So it's kind of fine?
>
I (and ajak) have expressed some frustration with how WebKit handles
their disclosures but that's not something you (or *-distros) is able
to control.
From what I understand of Firefox and Chromium, they both have
sufficient CI abilities and internal review to not have the same kind
of problem the kernel has (with its open development model).
>> it's your list, not mine, if
>> you are tired of running it, I totally understand.
>
> A bit tired, yes, but that's in part because of us fighting each other's
> windmills.
>
Thank you for continuing to do it.
> Alexander
best,
sam
Download attachment "signature.asc" of type "application/pgp-signature" (619 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.
