Security quotes of the week [LWN.net]

Security quotes of the week

Posted May 20, 2011 8:00 UTC (Fri) by jschrod (subscriber, #1646)
Parent article: Security quotes of the week

Well, reading the whole email thread, this Matt Mackall seems to be a very arrogant and uncooperative guy, whose touting his horn but does not the necessary steps to actually improve hg's security. After all, that would mean to educate his co-developers with his knowledge, not belittle them.

That's actually a problem with many security-focused guys, and IMHO one of the reasons why we don't get better security in our systems.

to post comments

Security quotes of the week

Posted May 20, 2011 10:22 UTC (Fri) by anselm (subscriber, #2796) [Link] (3 responses)

Well, reading the whole email thread, this Matt Mackall seems to be a very arrogant and uncooperative guy, whose touting his horn but does not the necessary steps to actually improve hg's security.

The original poster's apparent problem was that Mercurial's security was too good (so he didn't get to use symbolic links like he wanted). It's not Matt's fault that the security problems inherent in allowing symbolic links inside repositories didn't occur to the original poster.

One may reasonably disagree with Matt's tone in places, but I don't see how one can blame Matt for not improving the security of Mercurial when it is his attention to security that caused the original poster's »problem« in the first place. How exactly does allowing symbolic links in the way the original poster suggests »improve« Hg's security?

Security quotes of the week

Posted May 20, 2011 11:04 UTC (Fri) by jschrod (subscriber, #1646) [Link] (2 responses)

Obviously I expressed myself not good enough, since you misunderstood me.
I don't blame Mackall for not vetoing the proposed symlink-related change. To me it's clear that it should not have gone in; though obviously that was not the case for his fellow co-developers. I noted his attitude that he didn't see it necessary to explain *why* it's a bad idea. His style is management-by-appealing-to-authority without backing it with the (existing) facts.

In particular, he's going completely off in his later emails where he tells that he made a test hg repository that reputedly "0wnz0red" a system (his term, not mine); but refused to explain how he did so, so that the others can also learn to take such problems into account when they write or change code. Read the thread starting at http://thread.gmane.org/gmane.comp.version-control.mercur... . (I found it remarkable that this is another appeal-to-authority-style post: one has to take his word and the one-line output that the system really has been take over -- whatever that means in that context.)

Anyhow, I'm not involved in hg development and don't know anyone of these guys. I must emphasize that this is in no way an attack Mackall on a personal level; I don't know him at all. I commented on his project-related behavior shown in that email thread and just on that, because it is an exemplary incident of a greater problem.

I think the point that I actually tried to make is that this is a great example how *not* to enhance security in one's system during development. I belong to the persons that follow Bruce Schneier's thesis that security is not a state, but an ongoing improvement process. And a very important part of this process in the software development phase is developer education. Yes, Mackall prevented that this change goes in. This keeps the software system security _on the same level_ as it was before, it does _not_ improve it. But he *could* have improved the software project security process by educating his peers. Instead he chose not to do so, and that with full intent. He doesn't express it explicitly, but if I read his emails they simply tell the others "you are too stupid to learn that, go away". IMNSHO, this is *not* the way to improve security; this is eventually the opposite.

And this kind of project work and communication style I've seen with too many security "professionals"; it was one of the reasons why I left the security field some years ago.

Security quotes of the week

Posted May 20, 2011 13:18 UTC (Fri) by anselm (subscriber, #2796) [Link] (1 responses)

I noted his attitude that he didn't see it necessary to explain *why* it's a bad idea. His style is management-by-appealing-to-authority without backing it with the (existing) facts.

Matt also said that

it's not really cool for project leaders to post their own 0-day 'sploits with vulnerable clients still out there. So not yet.

which I read as an intention to explain the issue in more detail in due course.

I've been following Mercurial development, off and on, for a while (as an interested onlooker, mostly) and I have generally found Matt to be a fairly reasonable person. He could be a lot worse. He could be Dan J. Bernstein or Theo de Raadt :-)

Security quotes of the week

Posted May 20, 2011 15:02 UTC (Fri) by jschrod (subscriber, #1646) [Link]

Matt also said that
it's not really cool for project leaders to post their own 0-day 'sploits with vulnerable clients still out there. So not yet.

Well, I didn't understand that, so I ignored it. :-). The OP on the mailing list wanted to revert a change from 2007, so this is not a new introduction but the behavior of hg since 4 years. I didn't understand how there could be a newly introduced vulnerability by a change that didn't get applied.

But then, as I wrote, I don't follow hg development, so there might be some deeper insight that I'm missing. Were it not for XEmacs, I wouldn't even use it. ;-) I wanted to comment on attitude and their appeal, not on security facts. The latter are undisputed.

Security quotes of the week

Posted May 20, 2011 14:04 UTC (Fri) by Kwi (subscriber, #59584) [Link]

One should read Mackall's follow-up, which is Quote-of-the-week stuff in its own right:

The thing is, when I said no to this yesterday, I personally did NOT know an attack was possible, because even I don't have the level of expertise necessary to fully evaluate it. But I did know enough to know that there were things to be worried about.

The bar for introducing security checks is low - you just need to be a paranoid.

The bar for removing security checks is VERY high - you need to be a paranoid AND a subject-matter expert.