<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.0.9"> </HEAD> <BODY> You guys mind discussing your language flame war between each other? I'm tired of getting these messages, they're not why I signed up to the mailing list. Darrell Mozingo On Fri, 2004-04-02 at 08:08, Andreas Ericsson wrote: <BLOCKQUOTE TYPE=CITE> <PRE>Paul L. Allen wrote: >> Unions and structs are a part of ANSI. It's perfectly acceptable to >> have an array of structs containing arrays of structs with arrays of >> arrays (or whatever) in them, allowing for infinite depth arrays. > > Gosh, you have unions and structs. Ah well, that's everything you'll ever > need. > For functionality, yes. >> Hashes are convenient, but not necessary since it's perfectly possible >> for you to hop the pointer yourself. > > Hashes are not just convenient, they solve many problems that would scale > badly and run very slowly without them. If the code is written properly, scaling is not a problem. If it isn't, no language in the world will do the trick for you. > Of course, you can write your own > hash code, but good hashing code is difficult to write. Or you could find > a C library. Or you could use perl. > Enter simple mathematics. I argue that good hashing code is trivial to write as long as it has been properly implemented from the beginning. >> Bah. Some plugins should be written in C. Those that parse a lot of >> text should be written in perl, and those that rely on external >> commands for their data retrieval (like snmpget and fping) should be >> written in unix shell (it handles program execution better than perl, >> since it can fork() instead of execve()). > > And if you rely on external commands that generate a lot of text that you > have to parse? > man grep man sed man awk man cut >>> So what I'm saying is that for most cases you don't need C. Take a >>> look at the perl plugins. NONE of them make use of C-code modules that >>> I know of. >> >> The Socket module works with C-code underneath, as does SNMP and File. > > The socket module is part of the standard distribution. Perl is written > in C. Neither of those facts mean that it is sensible to rewrite perl > plugins in C just because perl is written in C. > SNMP is not, but I guess you missed that. Also, if I read Karl's comments on the perl framework correctly, it has almost grown out of its own usefulness. >>> Most competent programmers understand that programmers generate the >>> same average number of *fully* debugged lines of code a day no matter >>> which language they write in. It is left as an exercise for the reader >>> to compute the average code-density ratio of perl and C. >>> >>>> Those same functions can be called and linked from any C program >>>> without the intermittent layer and the top-level code. > > With many more lines of code needed to do so, especially if you need > text mangling. I made the point about productivity and your response > ignored it. > By reducing the intermittent code layers production times will drop. In what way did I ignore the productivity issues? >>> You can do anything from any language, if you try hard enough. >> >> My point exactly. Why try 'hard enough' to write it in perl if it >> needs C under the hood any way? > > Why work hard to code something in many lines of C that could be done in > a few lines of perl? BTW, code generated in C is just a bunch of > opcodes and data. Why write it in C when it's just opcodes under the > hood? Why not write raw machine instructions? > Now you're just being silly. >> On a serious note though; Do you know how many bugs and potential bugs >> me and the other Owl developers have fixed in perl 5.8.3? Last time I >> checked we were at patch-level 23 (each patch fixes 3 or more bugs). >> Patches have been submitted, but it's a serious load of code so I'm >> thinking it'll be a while until they're allowed in the tree. > > You're doing a good job with the patches. But, as you admit, you've > submitted patches for other things like Apache. You may have the luxury > of not running Apache until you've done a thorough audit and fixed all > the holes, most people don't. The same thing goes for perl. > Are you expecting a reply to this? >> Also, we value security above functionality, which isn't always >> functional enough for the kind of ad-hockery many perl programmers >> (read script kiddies) indulge in. > > Yeah, script kiddies like the programmers for the Swedish state pension > scheme. After the main project code went way off schedule, some of these > "script kiddies" knocked up some code in perl as an interim system. It > worked so well that the main project code was dropped and the interim > perl code upgraded to have all the functionality in the spec. The perl > code took a small fraction of the time to write that had already been > spent on the main code. > many != all Are you making this up, btw? I live and work in sweden but I've never seen this pension scheme, or any news or anything about it. >> Auditing a perl plugin makes the one-time penalty even worse, since it >> requires auditing of perl itself as well (not to mention the modules >> it uses). > > That's a fair point. But given the choice between a plugin that does > what I need written in perl or no plugin at all, I take the former. > Already discussed and agreed upon. >>> I remember mentioning to you just how much of the TCP stack is in kernel >>> space these days but I haven't seen a response. >> >> What do you want me to respond to? You weren't asking me anything if I >> remember things correctly, merely stating that it was (which is true, >> so I don't have a respond for that). > > The point is that most of the stack runs in kernel space and is therefore > a potential vulnerability. Yet another thing to audit. > Do you think I mainly spent my time working on IDE-drivers while auditing the kernel? >> Besides, perl is as vulnerable as anything to kernel bugs. > > And C isn't? Hint: perl is written in C. So if you can write something > in perl that's vulnerable to a kernel bug you can write the same thing in > C with the same vulnerability. > 'as vulnerable as anything' wasn't there for rhetorical reasons. >>> A *good* coder works around the limitations of many platforms rather >>> than coding purely for his own platform. Perl simplifies that process >>> by already knowing about many of those problems. >> >> You put too much faith in Larry Wall et al. > > The same faith I put into linux and apache. I know that they are going > to contain bugs but they are better than the alternatives. I know that > open source development means they are likely to improve. I know that > they may contain bugs, but in the end I need an OS and webserver. > And I'll be happy to provide both. Actually, it's more than just likely that some of the code you rely on was written by me, or based off of work I put into it. Fun, eh? >> Also, a false sense of security is worse than real sense of insecurity. > > I don't trust any software to be secure. Short of disconnecting servers > from the internet, there isn't much I can do to be confident I am > totally secure. Unlike you, I don't believe that your patches will > make any of these things totally secure because I don't fool myself that > I can think of every possible vulnerability or that totally new exploit > mechanisms will never be found. I don't believe they will make me totally secure. I believe they will make me more secure than I would have been without them. > >>> In practise, the only plugin I have seen that needs to run >>> an external command as another user called sudo. >> >> Which means a legitimate sudo call will exist on the stack (free fire >> zone). > > Are you advocating setuid as a safer alternative? > No, I suggest the script calling sudo shouldn't be cached. If it is then evey instance of nagios will have an easy shot at a vulnerability in its stack. >> Yes, but at what cost? Do we need to mark certain scripts as unsafe >> for the EPN, and how do we go about doing that? Config variables in >> nagior, or with shell-scripts wrapped around them? > > How about separate directories? Should work out ok. Then we'd only have to add one new variable to the main configuration file. 'perl_safe_cache_dir' or something. Code could be kept rather clean (well, not any messier than it is at least) and consistent, and everybody would be happy.</PRE> </BLOCKQUOTE> </BODY> </HTML>