<< Got a bounce on this ... please ignore if duplicate ... >> Even though this thread has gone on way to long ... On Mon, 25 Jun 2001 02:58:45 -0700 Ben Ford <Ben Ford <bfordat_private>> wrote: > >>lots of people, especially beginners just happen to write CGI programs in > >>perl and since they are not yet capable programmers, they write insecure > >>code. beginners don't write CGI programs in C++ because it is outside the > >>capability of beginners to do so. a skilled programmer will write quality > >>code with either language. > > <snip comment> > You are saying that Perl is insecure because it is easier to write for > and there are more newbies using it . . . No! I believe Glenn's comment was *not* saying perl is insecure, but that there exist a large supply of vulnerable programs due to the ease of learning perl and the number of people that do end up starting with it. > . . . so why don't these newbies ever learn? Who says they don't? But who says they go back and fix all their old buggy code they previously released? > If Perl is easier, it should be easier to master, right? I think it's naive to assume that learning curves are linear. > And if you've mastered the language, you should be able to program > securely, right? Not if you're not thinking about security. > So if Perl is easier to learn, then it should be more secure. However . . . http://everything2.com/index.pl?node=3DLogical+Fallacy > . . . C is harder to learn, so it stands to reason that more people will > make mistakes writing it, and therefore pump out insecure programs by > the bushel. But not compared to Perl! This (referring to the "harder to learn" and "not compared to") is difficult to quantify when taking into account each language's life span, architectural span, typing, scoping, standard usage, general integratration, types of problems each lend themselves to, etc. Since it's unquantified even with the rawest of numbers (as of yet), I'll ignore it. There's a big difference between language and programmer. While one may argue that a given language "promotes" one behavior or another on the part of the programmer, or likewise "discourages" some other behavior, the onus is still on the programmer. The quality of the programmer shouldn't be used as the sole judge of the language, if judging the language. And, the quality of the language shouldn't be used as the sole judge of the programmer, if judging the programmer. Yes, the two are inter-related and will certainly affect the evolution of each other, but they shouldn't be confused. That said, I do agree that some PL's help the programmer write more securely, but more for their immediate properties, not what they reflect. E.g., throw Ada into Crispin's typing discussion, and you've got something very resistant to type mismatches. Hell, it's even difficult to purposely make it marshal data between between types (compartively speaking). Move more runtime checking (type, bounds) into the PL and you get more resilency. Use well defined and enforced name spaces. Lexical OR dynamic scoping. Narrow, well-defined interfaces. As I believe someone else pointed out, using OOB signalling in a PL can improve security - control can't be confused for data and vice versa. That's all off the top of my head right now.... > Since real life is not what is shown by a simple logics experiment, > there must be other factors that are not taken into account. Namely, > that Perl is cheesecloth when it comes to security. > > -b I think you're trying to justify your conclusion, not conclude with justification. -Barclay
This archive was generated by hypermail 2b30 : Tue Jun 26 2001 - 17:53:59 PDT