On 04/21/2016 10:54 AM, Jiri Slaby wrote:
> On 04/21/2016, 03:53 PM, Sasha Levin wrote:
>> I'm not trying to replace the stable trees, I'm trying to help users who don't
>> update the stable tree that often to at least receive critical fixes in between
>> those updates.
>
> And that's the point. I doubt you can separate patches to critical fixes
> and the others.
Build fixes? new device IDs? quirks? We can agree that it's not security.
We can also agree that there are commits that clearly pose no security risk, right?
From the latest 3.18 release, stuff like:
07508eb iw_cxgb3: Fix incorrectly returning error on success
983cabe iio: pressure: mpl115: fix temperature offset sign
c8d69b6 sched: Fix crash in sched_init_numa()
etc'
Obviously don't pose a security risk.
If we agree on that, then we've left with ~30% of the original tree, where the
security status is questionable. As I've mentioned, I'd be happy to discuss
the criteria for what we consider a "security" fix. Maybe it'll be all 30%, maybe less.
>> Given this, how can you tell people they should be using your stable tree
>> rather than updating the kernel as a whole? The 3.12 tree is missing a big
>> chunk of commits that are stable material even though they weren't tagged
>> as such.
>
> That's why more than one stable tree is released for every kernel. It's
> growing. If you know about any more issues, share with us, they will be
> fixed.
If this is what you expect me to do, why was your first response on this
stable-security release was "I suggest nobody uses that kernel."?
When I started working on the 3.18 stable tree, it was easy to see that there is
a problem maintaining these type of trees. Some commits were never added, some
backported incorrectly, some reverted on one tree but not the others, and so on.
Instead of bashing Greg and other maintainers that the stable tree is a dumb idea
that can never work ("how can you decide what's a real fix and what's not?") I went
to write a set of tools that was supposed to help maintainers build correct stable
trees and validate their correctness versus other stable trees (available here, for
quite a while: https://git.kernel.org/cgit/linux/kernel/git/sashal/stable-tools.git/).
I've never received a comment on it, or heard of anyone using it, even though it
could have easily caught so many issues with each tree (such as the CVEs I've
copied earlier - this is how I dug them up).
The stable tree idea was born as a result of real need by users/customers/projects.
It's implementation isn't perfect, but we're all working together on making it better:
catching bugs, improving automation and reviewing each others work.
The stable-security idea was also a result of the same need. I didn't make it up
just so I'll have more stuff to maintain, I started it because users simply weren't
following the stable tree after a certain point. I can wave my finger at them all
I want, I can even ask Greg to wave his finger at them as well, but it's not going
to change them; they still will be running months old kernel in production, being
exposed to same nasty bugs.
If you have a better way of solving this I'm all ears. I'd happily change stable-security
if you have a plan of making it work better somehow. However, if thats not the case,
can we work together or improving it? Or at least not be sending each other inflammatory
mails about missing or not missing commits?
Thanks,
Sasha
Attachment:
signature.asc
Description: OpenPGP digital signature