Quotes of the week

Posted Jun 12, 2011 12:18 UTC (Sun) by nix (subscriber, #2304) [Link]

To compound your mistake you also insult almost everyone who happens to disagree with you.

This is particularly foolish, because it goes directly against his primary goal, which is to get developers writing code with security in mind (well, OK, his *other* primary goal is to get credit come what may, but that is endemic in the security field so can be disregarded).

Unfortunately he is so unpleasant when doing it that virtually everyone who might benefit from his instruction is so turned off by his supercilious and venomous interaction style that they rapidly disregard everything he says, if they don't just killfile him and leave it at that.

I'm not a security person, just someone writing low-level userspace code some of which is network-exposed, i.e. just the sort of person he might be interested in educating, you'd think. When he started posting here I had no idea who he was. Within about fifty posts I'd realised that he obviously knew his stuff, but his interaction style was so unpleasant and so predicated on never admitting error and never giving anyone the benefit of the doubt that by that point I wouldn't believe him if he said the sky was blue. And I don't think I'm particularly unusual.

Even people who can cope with the... robust interactions on the l-k list get turned off by the spender style: the vast number of good developers who don't go near l-k because it's too unpleasant are not even going to consider paying attention to spender, because listening to his security lessons is like wading through acid. Nobody wants their lessons interspersed with commentary on how stupid and foolish they are, and how they are engaging in coverups against the public good (though that last is more PaXTeam's shtick). There's a reason decent teachers don't attack their students.

I have an aunt who communicates in a similar style to spender. Or she would, if she could -- nobody talks to her. Nobody wants to.

Posted Jun 12, 2011 12:54 UTC (Sun) by mingo (subscriber, #31122) [Link]

I'll note that bug fixers tend to only look back a short while when considering -stable fixes (if you look at the number of changesets in the various long-term and -stable supported kernels, you will see that they tend to get a lot of fixes initially, but that the rate of fixes tapers off fairly rapidly)

Well, that's an expected curve: current empirical studies show that the distribution / time evolution of software defects goes along a Simon-Yule distribution - which goes down sharper than a bell curve as time goes on.

It's also roughly what you get if you use a simple bug fixing model: take the set of bugs still unfixed, and let bug fixers (developers) random walk the code, then there's a fixed probability to find a bug, with every man-hour spent on looking at the code.

As time goes on, the probability increases that a bug will be found, with a 1-1/t probability, where 't' is the time spent on the code. It will be like a bell-curve for a given difficulty of bug. The 'difficulty' of bugs is a constant parameter, so the combined bug metric would show the integral of 1-d/t ('d': difficulty, 't': time), integrated over 'd' and 't', which would still roughly be a bell curve in practice.

Thus older kernels seeing fewer fixes is natural and expected and is not in itself a sign of less attention.

There's also another aspect: the Cc: stable tag does not typically limit how far a fix is getting ported back - that is decided by the -stable maintainers. They will generally port is back as far as it will still cherry-pick cleanly - and they'll notify the patch submitter if there's a conflict with older stable kernels.

But yes, the older a stable kernel is, the higher the chance that a bug is missed and is not backported - this is a classic trade-off.

Posted Jun 11, 2011 18:34 UTC (Sat) by mingo (subscriber, #31122) [Link]

It's your opinion that he's right.

That the static vsyscall page is not a security vulnerability in itself is not just my opinion, it is a rather common-sense statement and it is our editor's opinion as well:

One useful point from that discussion is that the static vsyscall page is not, in fact, a security vulnerability; it's simply a resource which can make it easier for an attacker to exploit a vulnerability elsewhere in the system.

So could you guys please stop attacking people just because they disagree with you?

Posted Jun 11, 2011 20:23 UTC (Sat) by Julie (✭ supporter ✭, #66693) [Link]

he didn't consider the other side of the coin, the same person who chooses not to read configuration help and enables/disables options based on their config name alone, doesn't disable this feature...

If he didn't consider this maybe it was because he thought anyone config'ing their own kernel without checking the ---help--- is being at least a little silly.

I always build my own kernels and when I config one I feel it's only common sense to be expected to take some responsibility for the outcome myself, which means being able to work out (if I don't know) what does what, which implies checking the config help for new or unfamiliar features and not just making assumptions based on the name of the feature about what it is or does.
So I always check new config options, and if I didn't do this and I ended up disabling something I was relying on using or having some other unpleasant experience resulting from it well, that would be my own fault, wouldn't it. Because I shouldn't be messing with it in the first place. A really useful lesson in humility, at least...

I'm pretty sure distro and kernel maintainers and other users who have more at stake than me, or more of a measure of responsibility, check new configs too - isn't it just sensible?

CONFIG_UNSAFE_VSYSCALLS as a config name does seem rather histrionic though.