OT run ticker source code

[Fairlight]

>From inside the gravity well of a singularity, Howie shouted:
> Once everything is in the proper place, with the proper permissions you 
> start it by running:

You speak of proper permissions?  From runticker.bat:

umask 0

Insecure, 'nuff said.

>From tick.pl...why are you doing CGI parsing by hand when there's a module
that does it properly already?  perldoc CGI

For that matter, I'm lost on the $qual=$value line.  That makes no
sense.  You go to the trouble of parsing and urldecoding every name=value
pair in $QUERY_STRING, then you just seem to assume the last value
present will correlate to a value you can use for 'qual'.  A wholly
unfounded assumption, I might add.  If that were the case, you could have
skipped 11 lines of code and altered one and just assumed you could split
qual=whatever.

To top it off, there's absolutely zero sanitation of $qual, and you just
spit it back out in tick.pl.  That's the only place it seems to be used in
any sort of logic or output, despite appearing in ticker.pl, tickref.pl,
and tick.pl.  Actually, you do the full QUERY_STRING parse in all three,
despite the fact you never seem to actually -use- what you're trying to
get.

I have zero idea what you're using it for, but boy, this is not pretty code
in general.  Considering the lack of sanitisation, I'm -glad- for you that
$qual isn't actually used anywhere important in this.

> Once you understand how it all works you can modify it to display any type 
> of information you want.  At Aljex the original version was created to 
> display all shipments waiting to be dispatched.  The qual= variable (not 
> used in runticker) was for passing the user's qualifier name to filepro.

Ah, well, that's what I get for answering inline.  However...if it's not
used, why is it there?  If it's used with the same lack of sanitation and
the same assumptions about being the last value that you have here, but in
your other programs...you have some security issues that want addressing.
The umask is just plain inexcusable in any area.  I suggest a look at
either cgiwrap or suEXEC so you can get out of this mindset (present since
fpWeb, from what I've seen on people's systems) that you must let
everything be 0777 to work with files between apache and filePro.  I'm
surprised this approach hasn't been modified in the years since you were
made aware that it's an inherently bad practise.

> PS: I made some last minute changes to clean up the code and scripts and 
> hope I have not introduced any bugs.

It's just needlessly bloated.

The JS stuff was a bit informational, at least.  I'm not sure how much I
trust it as a "good example" after seeing it directly associated with some
of the worst CGI I've seen coming from outside the Ukraine, but it was
informational nonetheless, thanks.  (Actually, considering what it did to
Firefox's main window, I would hazard there are some bad assumptions being
made in the JS as well.  In fact, I'd state it as probable.)

I'm sorry.  I mean...I sincerely believe you want to share something neat
with the community, and I applaud that.  But this stuff is just...I mean if
you say you cleaned it up, and it's in that state, I have to question your
definition of "clean" CGI.  It's nothing I would personally put -near- a
web server on a public network.

http://www.fairlite.com/fc/articles/

I'd suggest reading both the one on basic CGI security, and the one on
*nix filesystem permissions.

mark->