> No, but they can be a highly opinionated bunch of people who are
> highly dissatisfied with just about everything they haven't thought
> of or implemented themselves.
I am beginning to agree, but I was able to get the guy who claimed to
have looked at the code to be precise in his criticism. Now, below are
two examples that jumped out at him that he is using to base his
criticism of ASSP in general on. What he says SOUNDS reasonable, but
since I am not a programmer, I don't know if it has technical merit or not.
I'd like to get comments on it from anyone who understands proper
programming technique, and then I'll let this thread die.
> I simply refuse to engage in pointless arguments with them. I use
> ASSP in a 3 server production environment and am very happy with the
> solution.
Personally, I don't consider this argument/discussion pointless. I am
very interested in learning more about the s/w that I use on a daily
basis, and when someone has what *appears* to be genuine criticism, I
like to find out more.
Again, Fritz, I'm not complaining, I'm not criticising - ASSP works
great for me. I'm just curious to hear what those more knowledgable -
both with programming in general, and programming specifically in perl -
have to say about the concerns this guy took the time to be specific about.
So that said, here is what he had to say:
************************************************************
Let's go back to this fragment, found relatively early on in the code:
open(F,"<$base/assp.cfg"); local $/; (%Config)=split(/:=|\n/,<F>);
close F;
This is the sort of thing that earns someone an instant "F" on a college
programming assignment. It's completely unforgivable in a piece of
software used in a security role.
Why? Because it blithely presumes that the open() system call will
succeed. It doesn't make the slightest attempt to recognize that it
might fail, let alone try to do something sensible if it does. (And
yes, it does the same thing with the close() call, and yes, sometimes
close() calls fail.)
Any time that any program makes any system call (or subroutine call) it
should check what's called "the return value". The possible return
values are documented, and usually at least one is reserved to indicate
failure -- i.e. the call didn't work. Sometimes more than one is
reserved, and which one is returned indicates not just failure, but what
kind of failure.
So part of sound programming practice is to check the return value from
a system or subroutine call and make sure it's something indicating
success BEFORE trying to do something with it. (And if it's something
that indicates failure, then print out or log an error, try something
else, give up and exit, do something but just don't keep going on as if
nothing happened.) In this particular case, the file descriptor F is
blindly used EVEN IF IT'S GARBAGE.
Something along the lines of:
open(F,"<$base/assp.cfg") || die "cannot open ASSP configuration file
$base/assp.cfg, giving up\n";
would be at least an incremental improvement.
Now this isn't a subtle, hard-to-find, hard-to-exploit complex problem
that would take weeks to figure out. It's something I spotted on the
first read-through. Which tells me -- because this is not the first
piece of code I've ever read -- that because errors this obvious, this
egregious, this basic, have managed to survive through all the work
that's been done on the code, that it's very likely that other similar
errors, and probably worse ones as well, have also survived.
Oh look, here's another one just like it at line 1449:
if($pidfile) {open(F,">$base/$pidfile"); print F $$; close F;}
There are probably more of these -- I didn't bother looking. And that's
just open(). What about all the other system calls? All the other
subroutine calls (both to internal and external routines)?
The fact that simple things like this are horribly broken doesn't
bode well.
*************************************************************
--
Best regards,
Charles
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Assp-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/assp-user
