On November 5, 2002 at 16:58, Gunnar Hjalmarsson wrote:
* The initial BEGIN block is probably not needed. Fatal messages
should be sent a log file to avoid any potential sensitive
information showing up in someone's browser. Error messages the user
see should not be some Perl error message, IMHO.
Please note that the script is intended to be password protected in some
way, and the "user" can be assumed to have at least FTP access. (I made
a change, so that the 'fatalsToBrowser' routine is not imported when
running the refresh() routine, which anybody can do.)
I have tried to make the installation easy, and error messages in the
browser is undoubtedly convenient when you are installing a CGI script.
I could of course import the 'carpout' routine instead of
'fatalsToBrowser', or do something similar, but I don't understand the
reason for your concern.
All this sounds reasonable. I was just considering the case where
something was misconfigured, so errors could happen before any
password checks were performed. This could allow someone else to
see error messages from the CGI.
I do not think it is anything major. Maybe for a later version of
your script, you could have an option that allows errors to the browser
or to a log file.
True. I didn't use password protection here, since I wanted to make a
simple pipe from for instance a .forward file possible.
I'd then make it configurable. By default, password check is done,
but then a configuration variable can be set for those that want
to bypass it.
Generally, try to go with the more secure approach, but allow
configurability for those who are willing, and conscience, to take
the risk.
This appears to allow someone to do a DoS against the the popserver
($pophost)
Not sure what you mean by that.
DoS = Denial of Service.
A malicious hacker could pound the CGI script with archive update
request. This would then cause alot of traffic to the POP server,
which could cause denial of service problems and disable any archive
updates.
You may think I'm naive, but to some extent I simply rely on
hackers/crackers/whatever having more exciting things to do than causing
some minor inconvenience for somebody who maintains a mailing list
archive. ;-)
This is a common mistake made by everyone (including myself). Most
people think they are not worth hacking, but it happens all the time.
You may not care about your archives, but someone else using your
script may.
There are alot of script kiddies out there that like to screw with
stuff, just cuz.
* The updatembox() could be written to prevent a large amount of
memory getting used. At a mimimum, store the passed in message data
into a single scalar
...
Note, an array containing each line of a message takes up more
memory than a single scalar containing the entire message text.
So far I understand, and now STDIN is stored in a scalar. But I haven't
used the code you suggested in this respect, since I'm not comfortable
with references in Perl, and I avoid using code I don't understand.
If you can explain what the point would be, I'd be happy to do some
reading. :)
The main reason is to reduce memory usage by not storing the complete
data in memory and references could be used to avoid unnecessay copying
of data (references are also required for complex data structures
like an array of hashes or a hash of arrays). Reference usage could
also protect from a DoS where a hacker uploads megabytes of data
to the script. You may want to consider adding a max upload size
parameter to check against CONTENT_LENGTH, and abort the request if
CONTENT_LENGTH is too large (I'd add this feature independent of
using references or not).
References in Perl are not that complicated. They are much better
than dealing with pointers in C, since in C, you can really screw
yourself. If you have time, read the perlreftut and perlref
manpages. They should help you in getting started with references.
* In the shell() routine, you may want to use shellwords.pl. ... I'm
not sure if anyone has bothered to make a module out of it.
Did that. I found Text::Shellwords in CPAN, but it seems totally
redundant to me, since shellwords.pl only includes one subroutine. On
the other hand, it was Lincoln Stein who wrote it, so I guess there is a
sensible reason for its existence...
My guess is that Text::Shellwords would replace shellwords.pl
at sometime. However, Text::Shellwords is not included with the
standard Perl distribution while shellwords.pl is. I do know
why Lincoln didn't just copy the shellwords.pl implementation
in Text::Shellwords.
I'm slowly working on v2.6.0 of MHonArc. When I think I am getting
near a release date, I will post a message to the dev list. You can
then remind me about your mhastart.pl and insure I get the latest
copy before the release is made.
I recommend that you run pod2html on your script and make the
output available on your site. This way, people can read the docs
before downloading to see how it works.
--ewh
---------------------------------------------------------------------
To sign-off this list, send email to majordomo(_at_)mhonarc(_dot_)org with the
message text UNSUBSCRIBE MHONARC-DEV
