Of third party products, code reviews and module installation...(discussion)

[tinman]

Earlier this week, I was given the task of installing a shopping cart script for my organization... The reason this particular commercial product was picked was because a higher-up and seen it and liked the interface... being written in Perl, (and since I'm the only Perl person in the company), I got to find out the nitty gritty details of installing this script..

Upon looking at the source, I was amazed to see code that violated a couple of practices that I consider essential to CGI programming: taint checks were not turned on, and CGI.pm was not used. At that time, I solicited the opinion of my fellow monks on what to do (I didn't think I would be taken seriously by management.. have you ever seen a glint in the eye of senior management when they're championing a product ? I saw it in my manager's eyes :o).. Thanks to WebHick, virtualsue and TStanley (these are just the people I remember, there were quite a few more), I wrote a CYA email to a few people outlining some of the problems that I saw in the script (namely, the two I mentioned above)..

Now, the point of this rambling meditation (finally, you say :o)... Another possible problem that I discovered is that this script sends email, but uses raw sockets and SMTP commands in the script rather than modules from CPAN (Net:: and Mail:: modules)... Now I personally think that this is another coding practice as bad as not using CGI.pm or enabling taint checks.. but I can see the point of view of the developer (I think I've seen other Perl products that also has the same philosophy of not using modules because then it runs "out of the box" on any Perl installation).. My question really is.. do you think writing products that don't use CPAN modules is bad coding practice ? Were you to write a product that would be publicly distributed (commercially or otherwise), which approach would you take ? and why ?

[Masem]

This ties in nicely with something on /. today: while the GPL is good, it *is* viral in the sence that anything that uses a GPL component must be GPL itself.

Not wanting to get into a agrument over GPL vs other open source licenses, there's probably good reason to stick to handmade code over CPAN offerings if the CPAN module has a license that you cannot live with. Given that you said this particular instance was commercial, it could *possibly* be that the CPAN modules of interest were not usable without removing the commercializability of the software. (Of course, dollars to donuts that in this case, the developers didn't know about CPAN or just wanted to reinvent said wheel).

---

Dr. Michael K. Neylon - [e-mail] || "You've left the lens cap of your mind on again, Pinky" - The Brain

[buckaduck]

Aren't most CPAN modules distributed either "freely" or "under the same terms as Perl itself"? I don't see how using a module would create any more licensing problems than would already exist. Unless, as you say, the modules in question have different terms.

But after a quick check of some Net:: and Mail:: modules, I don't see that this is a big issue...

buckaduck

[mikfire]

There have been a few times when I have had to eschew the help of the Net:: or Mail:: modules because I was trying to do things that the modules ... ummmm ... were not really designed to do ( no, really, I was forging mail headers in the cause of good - namely, so the whining users couldn't reply to my email ). I likely could have dug deep into the documentation and figured out how to get the module to jump through the hoops I needed, but it was ( in that case alone ) honestly easier for me to write my own little nasty function to do the work.

I have also been on a few projects where the idea was to ship a module such that it could run on any perl. However, we developed the habit ( if they were pure perl modules ) of either including them in the distro or ( horror ) embedding them directly into the file we distributed ( again, please believe me that the original authors were given full credit and no attempt was made to imply I was smart enough to write all the code ).

There are a few excuses for not using CPAN. They are very few though, and CGI.pm is simply not one of them. That has been part of the core since at least 5.003.

mikfire

[toma]

The lack of taint checking is interesting.

I would turn taint checking on, and then see if the module runs. In my experience, if the module is developed without taint checking, chances are it won't pass when you add the check. Even experienced programmers often miss something. Check for the idioms that are used to untaint variables and protect IFS, etc.

If it passes, then someone probably developed with taint checking and turned it off for the shipping code. Some people feel that taint checking causes a performance hit. I have heard that any performance hit is very small, but others may not know this, or I may have bad info. When I heard the claim that the performance hit is 1-2% or less, many in the audience were surprised.

In my opinion, if the module fails the taint check then it is likely insecure. You might even be able to find an exploit of such a hole, perhaps a simple one that just lists the contents of a directory.

One of the benefits to using CGI.pm is that it does a lot of advanced things and it works well with taint checking.

Another benefit to using CPAN modules is that, in general, you have access to the developers of the code. Try calling up the vendor and ask to talk to the developer of the module. Ask the developer your same CPAN and taint questions. If you can't get relatively easy access to the developer, you have another valid reason to prefer a CPAN approach.

I have often argued that the support of perl modules is vastly superior to commercial software because of developer support and quick fixes. Commercial software bug fixes often languish is a release cycle that takes six months or more. I would ask how quickly they could get you a version that has taint checking. Chances are they would charge a hefty fee for this, or they won't be in business very long. The commercial software business is tough :-).

It should work perfectly the first time! - toma

[cforde]

do you think writing products that don't use CPAN modules is bad coding practice ?

Depends. If there is a module that does exactly what is needed and the developer can live with the license then it should be used. Most modules on CPAN use the GPL or Artistic license so that shouldn't be a problem. Now if there is a module that doesn't quite fit the bill, but can be modified to do so, the situation changes. The reason and nature of the modification might be something the vendor considers a competitive advantage and not want to distribute. So the GPL and Artistic licenses could be stumbling blocks here. Rather than be in a grey area, the safe thing to do is custom development. This should be a last resort because it takes developer time that could be used for other features or fixes.

btw, the "runs out of the box..." excuse is just that. A lame excuse. The installation documentation should specify the pre-requisites. The installation routine should verify them. If pre-requisites are a concern, it's always nice to include them...

Have fun,
Carl Forde

[John M. Dlugosz]

Six years ago I didn't use CGI.pm because it wasn't mature. Today, I would not try and do protocal stuff without the CPAN modules.

As for running out of the box, why not just supply all the modules, too? They can be found in a local path so the script gets the version it was built with, or the installer can install the dependant parts, too.

For distributing a simple script around the office, having it complain about missing modules is a pain. For a major commercial product, I think there should be an installer or a checklist to go by.