4 ms·

> I generally have a hard time with any book list for security people that includes, for instance, _Design Patterns_. Would you please elaborate on this point?

• tptacek 12y ago
  _Design Patterns_ is one of those books that nerds of a certain vintage all have on their bookshelves. The lucky ones --- most of them! --- haven't read it carefully. It's a book about software architecture, and, more specifically, about turning C++ into Smalltalk. It has absolutely no relevance to software security, even in terms of background material about computer science. (It's actually of dubious relevance to programmers in general). It's one of a couple books on this list that give it the flavor of "I just typed up my bookshelf". It doesn't help that the summary is "Required reading for any serious programmer".
  • skue 12y ago
    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. Certainly the book is tremendously useful for ObjC programmers because Apple incorporated most of these patterns into Cocoa and Cocoa Touch. And as someone who has done code review with junior Android developers, I wish that more devs read it. When a security researcher refers to a MITM attack or SQL injection, this higher level concepts mean something and it enables clearer conversation. That's what design patterns provide to software developers.
    • tptacek 12y ago
      (To save you some explaining time:) I'm excruciatingly familiar with the GoF patterns and much of the broader pattern movement (I'm a recovering C++ programmer). So: Of the original GoF patterns, which specific ones make it easier to discuss SQL injection?
      • dllthomas 12y ago
        "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.
        • wglb 12y ago
          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. GoF will not help you with any of this.
          • dllthomas 12y ago
            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...)
    • mechanical_fish 12y ago
      Apple incorporated most of these patterns into Cocoa and Cocoa Touch. Great! That means I could just learn to work with Cocoa and Cocoa Touch and skip the tedious exposition. I would try to explain why I've never been able to pick up a patterns book without eventually throwing it against a wall, and why I prefer to encounter my patterns in the wild as I work on actual code, where I can poke and prod them and watch how they behave in practice, but it's already been throughly explained and even given a name, The Monad Tutorial Fallacy: http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ http://byorgey.wordpress.com/2009/01/12/abstraction-intuitio... Sounds to me like your junior Android developers might be learning patterns just fine: They trip over one in practice, and then they learn about it with the help of their teacher. This is how learning works. There is no royal road to geometry, and beginners don't become experts overnight just by reading the right book.
      • tptacek 12y ago
        A better way to learn the GoF patterns is through Norvig's presentation on why they aren't necessary in better programming languages. Google for [Norvig patterns] or [Norvig GoF].