Re: linux-distros list policy and Linux kernel

[Sam James <sam () gentoo org>]

> On 22 May 2022, at 20:19, Solar Designer <solar () openwall com> wrote:
>
> Hi,
>
> Thank you all for the helpful replies in this thread.  Here's my summary
> of what was said so far:
>
> As seen from replies by Jason and Greg, I didn't make the distinction
> between my suggested options 0 and 2 clear enough.  They were:
>
> > 0. Do nothing specific - let things work or fail on their own.
>
> > 2. Strictly enforce the policy as it is - and be in conflict with Linux
> > kernel security team, and handle fewer issues via linux-distros.
>
> Let me clarify.  As I wrote, after the disagreement in February, "the
> handling was hectic - indeed, people felt discouraged from enforcing the
> policy."  So by option 0 I referred to the loose (non-)enforcement we've
> had since February until now, and by option 2 to enforcement at least as
> strict as we had before February.
>
> Although I wouldn't necessarily have the list's future decided by a
> majority vote, I counted something like 4.5 votes for relaxing the list
> policy to accommodate (at least) Linux kernel community's workflow:

I've been watching as I was hesitant to muddy the waters as we've
had this discussion many times before and didn't want to be noisy, but
my support is for Greg's suggestion.

We're trying to get the best possible outcome within practical means
and I think it'll serve that aim.

> Igor Seletskiy
> > My vote would be for #1
>
> Anthony Liguori
> > make this policy specific to changes under security () vger kernel org embargo
>
> Greg KH
> > So if you all could just modify the rules to be something like,
> > "embargos are not broken when changes are posted in public, or accepted
> > into public trees, unless the changes or discussions around them turn
> > out to disclose the security related issue."

What I ask is that the kernel folks are proactive in reaching out to us if they
think people start to suspect, too.

I'd also like to ask that the final commit messages please reference any
relevant CVEs or at least the security impact. There've been a fair number
of incidents where such information is stripped and it makes tracking
issues *really* hard.

This would make a big difference to us in distributions. I hope this can
be considered.

> [snip]

best,
sam

Attachment: signature.asc
Description: Message signed with OpenPGP