On 04/21/2016, 03:53 PM, Sasha Levin wrote: >> Pardom my ignorance, how can you actually be sure? > > I'm not, same way you can't be sure about your stable patch selection either. I repeat I am not doing any selection. Patches are not included iff they do not apply and I am not confident enough to backport them. In that case, a FAILED message is sent to the authors. And when the authors don't care about that, the patch is not included. > A commit that may not look to you like stable material might turn out to be one, > so how is this different for stable-security? I do not select. > "immediately" is a strong word. Right now they won't update at all, so even > if they take a month to update that's better than the current state. > > 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. >>> So I've also ended up auditing the 3.12 for missing CVE fixes and these >>> ones ended up being at the top of the list. Could you explain why they >>> are not in the 3.12 stable tree (and as a result can't get to users of >>> the corresponding stable-security tree)? >> >> Sure. They didn't apply or were not marked as stable. In both cases it >> is the code maintainer responsibility to take care of those. At least by >> pinging the stable list with SHAs. > > 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. > Those commits fix real bugs and by not shipping them users are given a false > sense of security by just updating the stable tree rather than the entire > kernel tree. Updating versions is painful, because new features and code refactoring introduce bugs. We do not backport those. That's the difference. >>> (CVE-2015-7513) 0185604 KVM: x86: Reload pit counters for all channels when restoring state >> >> This was not evaluated for SLE12 yet. > > This is an almost half a year old vulnerability that allows guests to crash > KVM hosts; something I'd consider quite critical these days. > > This sort of thing is something that might encourage users not to follow the > stable tree at all. If updating the stable tree won't fix these sort of critical > issues, then why bother at all? Well, if that's so critical, why is there no trace on the stable list about it to be applied to all trees? I indeed committed it into 3.12 already. > I'd be happy to set clearer guidelines for what I consider a security > fix if that's the concern here? Yes, please. >> Fourth, naturally, there is a lot of patches missing in the net flowing >> in the large sea of patches. But given your count of patches, you have ~ >> 2 times higher chance to miss something important. > > I do? Per the definition of stable-security, I only have to select them > from the ones you already selected. So while I have to look through ~50 > commits per version you need to look at hundreds. But yet, you missed some important fixes in a single release. > You're way more likely than me to miss a commit that was supposed to be > in stable, Naturally, see above. I am not doing filtering though. I include everything which fixes a bug and I am aware of. > than me missing something that had to go into stable-security. Doing any filtering on patches that somebody proposed to be in stable is anything but -security. If people feel that's too much updates, they should run some sort of BSD or something. Anyway, it's nonsense to review all the patches and pretend to understand the code well enough to decide whether the patches are OK or not. It's bullshit. That's the very reason why any selection won't ever work. And provided we run stable trees on all our products with no dedicated people to stable patches (except me collecting 3.12 and randomly applying stable patches) and we saw only little bugs introduced by stable over the past decade, I do not believe they chose the right approach. Stable really pays off as it stays even though the process could be improved in many ways as was discussed many times, of course. thanks, -- js suse labs
Attachment:
signature.asc
Description: OpenPGP digital signature