| |||||||||||||
fixed in v2.6.31.1fixed in v2.6.31.1Posted Sep 26, 2009 10:45 UTC (Sat) by mingo (subscriber, #31122)In reply to: fixed in v2.6.31.1 by PaXTeam Parent article: Kernel release status
notice that anonymous contributions are explicitly not allowed (those words were actually added because of a patch of mine a few years ago). so there is the answer to your accusation. I don't question your honesty, but FYI, your level of paranoia is reaching clinical levels. If you don't trust others to know your real name, why do you expect millions of others to trust your anonymous word that the code you have contributed is indeed yours, with no legal strings attached? (such as an employer you work for currently and who thus does not know (and cannot know, due to the pseudonym) that you contribute in corporate time, etc.) As far as it being added to the SOB requirements based on your case - that might simply be because in 99.99% of the cases people are actually proud of being mentioned in the Linux kernel source (it's even a good point for your career so generally considered stupid if you forfeit it), so this situation was simply not contemplated before? Nevertheless i do always look at your fix patches and accept them (for subsystems i maintain) if they are good. I add my own signoff so i take responsibility for your patches, and credit you for the fix. I do think you are genuinely interested in (and worried about) Linux security, you are competent and capable, and I think you are doing good fixes. As an example look at this upstream fix that you wrote:
e003208: x86: fix stackprotector canary updates during context switches So there's absolutely no impediment to you contributing fixes to the Linux kernel, if you chose to do so. All it takes is to find someone with a real name who trusts you enough to take fixes from you. (bigger patches are still a problem of course.) the so-called 'stable' series (apparently that implies neither timely nor honest). Do you have proof of (or even an indication of) that -stable is dishonest? I don't have such an indication, and i take honesty and security seriously. Have you considered alternative possibilities, such as honest mistakes or lack of information? Or the possibility of maintainers being genuinely worried about and interested in a far wider spectrum of system stability than the important but (technically) narrow sub-set of security related bugs?
(Log in to post comments)
fixed in v2.6.31.1 Posted Sep 27, 2009 10:34 UTC (Sun) by nix (subscriber, #2304) [Link]
We've had this flamewar before. From those past flamewars, 'dishonest' in
PaXspeak appears to mean 'does not research every single patch to determine if it fixes an exploitable hole, then pause the release while a CVE is assigned and rewrite the changelog to include the CVE number and exploit'. If a single hole lacks a CVE we get flames on LWN (why pick on LWN, which is just reporting them? Search me. Maybe he wants as many people as possible to dislike him. LWN used to have a pleasant collegial comment atmosphere before these PaXTeam and Brad Spengler came along. Now it often feels like alt.flame: I certainly want a killfile again.)
So we have PaXTeam on one side damning the stable team for not doing all
fixed in v2.6.31.1 Posted Sep 27, 2009 10:35 UTC (Sun) by nix (subscriber, #2304) [Link]
Allow me to thank Greg et al for continuing with stable maintenance
despite getting 'thanks' and accusations of incompetence, lying, and malice with virtually every release. I know I'd have given up long ago and told these horrible people to do the releases themselves if they cared so much about them. Greg is more mature than that thankfully. :)
|
|||||||||||||