"Of the original GoF patterns, which specific ones make it easier to discuss SQL injection?"
That doesn't seem to be the claim made in the parent comment. I read it as a far weaker, "In much the same way that security researchers label antipatterns that enable attacks and that makes it easier to talk about security, the GOF label patterns that make it easier to talk about design."
I don't know that the parent comment makes a good case for relevance of this claim, though, since - as you've been more focused on - this list is supposed to be more specifically for (FTA) "topics within computer security, digital forensics, incident response, malware analysis, and reverse engineering." I suppose if the system you're reverse engineering made substantial use of GoF design patterns, familiarity with them would probably help, but that seems a little bit of a stretch.
> I don't know that the parent comment makes a good case for relevance of this claim, though, since
The parent comment is responding to @tptacek's original comment:
> (It's actually of dubious relevance to programmers in general).
Where 'it' is the Design Patterns book. That's a more broad statement than just whether or not security researchers needs to read the book. The parent to your post replied to that:
> I agree that _Design Patterns_ has little to do with security, but I think you are being a bit hard on it from a programming perspective.
So, in summary:
tptacek: Design Patterns has no relevance to security. It also
has dubious relevance to all other programming.
skue: It doesn't have relevance to security, but I feel that it
does have relevance to programming in general.
From an security professional's point of view, the idea is to find flaws in software, developers thinking, or corporate culture that make vulnerabilities for attack.
GoF doesn't really help with any of the above. What GoF helps with is shoring up weak languages that don't have the proper stuff to begin with. It talks about abstractions and how to build them.
What is useful from a security professional's point of view is to learn how to puncture abstractions. Finding flaws such as information leakage between abstractions. This is a hard mind-set to come to.
Did you just want to voice your opinion and find my comment relevant enough to serve as a place to hang it, or did you mean that as a response to what I wrote? I don't think I substantively disagree, although I think Norvig's claim is often read (not sure if intended) slightly stronger than is merited. I would also note that the list does not seem to be restricted to "security professionals", but to all those interested in learning about the topics in the list I quoted above. I broadly agree with the thesis that Design Patterns doesn't fit that mold particularly well.
(In general, I find it a recurring problem on HN - and to some degree similar fora - that I am not sure what conversational role a poster intended their comment to serve; I wonder if there is a good way to address that...)
I was chiming in on support of I suppose if the system you're reverse engineering made substantial use of GoF design patterns, familiarity with them would probably help, but that seems a little bit of a stretch and to clarify my opinion about the 'tptacek comment pointing out a common vulnerability (sql injection) and how GoF doesn't really addresss it.
And we could discuss I think Norvig's claim is often read (not sure if intended) slightly stronger than is merited quite a bit. I might go the other way, as I think Norvig is really quite gentle in making his points.
So not disagreeing with your comment, and perhaps I did hang my comment on the wrong post.
Regarding GoF, I think having more well-known constructs to reference can provide some value even when those constructs are motivated by overcoming limitations that may not be present in a given context. Picking more broadly useful constructs will provide more value, but you may or may not be able to get there from here, and certainly (perhaps unfortunately) enough people still find themselves coding in contexts where GoF patterns can be directly useful.
That doesn't seem to be the claim made in the parent comment. I read it as a far weaker, "In much the same way that security researchers label antipatterns that enable attacks and that makes it easier to talk about security, the GOF label patterns that make it easier to talk about design."
I don't know that the parent comment makes a good case for relevance of this claim, though, since - as you've been more focused on - this list is supposed to be more specifically for (FTA) "topics within computer security, digital forensics, incident response, malware analysis, and reverse engineering." I suppose if the system you're reverse engineering made substantial use of GoF design patterns, familiarity with them would probably help, but that seems a little bit of a stretch.