[25093] in Perl-Users-Digest
Perl-Users Digest, Issue: 7343 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Oct 30 09:05:34 2004
Date: Sat, 30 Oct 2004 06:05:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 30 Oct 2004 Volume: 10 Number: 7343
Today's topics:
Re: Attempting to create a C .h file to an Assembly .in <tassilo.von.parseval@rwth-aachen.de>
FAQ 9.17: How do I check a valid mail address? <comdog@panix.com>
Finding a module's $VERSION programmatically <not-for-replies@zombie.org.uk>
GD.pm install woes (Xevo)
Re: GD.pm install woes <nospam@bigpond.com>
Re: GD.pm install woes <postmaster@localhost.localdomain>
how to test the speed of rsync <xthua111@zju.edu.cn>
how to test the speed of rsync <xthua111@sohu.com>
Re: IDEs <bik.mido@tiscalinet.it>
Re: IDEs <bik.mido@tiscalinet.it>
Re: IDEs <bik.mido@tiscalinet.it>
Re: Parsing 'dirty/corrupt data'. Advice wanted burlo_stumproot@yahoo.se
Re: web hoster won't secure CGI <noreply@gunnar.cc>
Re: web hoster won't secure CGI <vilain@spamcop.net>
Re: web hoster won't secure CGI <tassilo.von.parseval@rwth-aachen.de>
Re: web hoster won't secure CGI <1usa@llenroc.ude.invalid>
Re: web hoster won't secure CGI <ioneabu@yahoo.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 30 Oct 2004 06:56:18 +0200
From: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: Attempting to create a C .h file to an Assembly .inc file
Message-Id: <slrnco67ni.r1.tassilo.von.parseval@localhost.localdomain>
Also sprach Percival:
> Tassilo v. Parseval wrote:
>
>> h2xs, the utility that creates a Perl module skeleton from a C-header,
>> is capable of parsing enums. The parsing looks like this:
>>
>> no warnings 'uninitialized';
>>
>> # Remove C and C++ comments
>> $src =~ s#/\*[^*]*\*+([^/*][^*]*\*+)*/|("(\\.|[^"\\])*"|'(\\.|[^'\\])*'|.[^/"'\\]*)#$2#gs;
>>
>> # The while loop iterates over one complete enum-block:
>> while ($src =~ /(\benum\s*([\w_]*)\s*\{\s([\s\w=,]+)\})/gsc) {
>> my ($enum_name, $enum_body) =
>> $1 =~ /enum\s*([\w_]*)\s*\{\s([\s\w=,]+)\}/gs;
>> my $val = 0;
>> for my $item (split /,/, $enum_body) {
>> my ($key, $declared_val) = $item =~ /(\w*)\s*=\s*(.*)/;
>> $val = length($declared_val) ? $declared_val : 1 + $val;
>> # $key is now the constant name, $val its value
>> }
>> }
>>
>> For that to work, it's necessary to slurp the whole header into $src. It
>> doesn't work if you try to process the file linewise. Also, C comments
>> (that may show up in enums, too) have to be stripped.
>>
>> Having a closer look at the above, I think it doesn't catch all cases.
>> Most notably, it should fail on:
>>
>> enum id { CONSTANT };
>>
>> That is: It should fail when only one key is in the enumeration.
>>
>> Tassilo
>
> Thank you very much, I'll find a way to deal with that failure case.
>
> Thanks for the program, it looks like it does what i need! Just want to
> give one last question... doesn't \w include _? So [\w_] is a waste,
> just stick with \w . But you are the expert, not me :)
That's correct, \w includes _. But looking at the big picture of h2xs,
this is really one of the minor nits. h2xs, despite being in the core,
is one of the ugliest and worst written pieces of Perl you can find. It
makes a lot of script kiddies look like decent programmers really.
That's because over the years one feature after the other was added by
different people (the above enum thing was added by me based on code I
received from another porter). But if you seek a challenge for your
refactoring skills, h2xs is the right place. It's really the Mount
Everest of refactoring (with the first ascent not having happened yet).
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Sat, 30 Oct 2004 10:03:01 +0000 (UTC)
From: PerlFAQ Server <comdog@panix.com>
Subject: FAQ 9.17: How do I check a valid mail address?
Message-Id: <clvosk$186$1@reader1.panix.com>
This message is one of several periodic postings to comp.lang.perl.misc
intended to make it easier for perl programmers to find answers to
common questions. The core of this message represents an excerpt
from the documentation provided with Perl.
--------------------------------------------------------------------
9.17: How do I check a valid mail address?
You can't, at least, not in real time. Bummer, eh?
Without sending mail to the address and seeing whether there's a human
on the other hand to answer you, you cannot determine whether a mail
address is valid. Even if you apply the mail header standard, you can
have problems, because there are deliverable addresses that aren't
RFC-822 (the mail header standard) compliant, and addresses that aren't
deliverable which are compliant.
You can use the Email::Valid or RFC::RFC822::Address which check the
format of the address, although they cannot actually tell you if it is a
deliverable address (i.e. that mail to the address will not bounce).
Modules like Mail::CheckUser and Mail::EXPN try to interact with the
domain name system or particular mail servers to learn even more, but
their methods do not work everywhere---especially for security conscious
administrators.
Many are tempted to try to eliminate many frequently-invalid mail
addresses with a simple regex, such as "/^[\w.-]+\@(?:[\w-]+\.)+\w+$/".
It's a very bad idea. However, this also throws out many valid ones, and
says nothing about potential deliverability, so it is not suggested.
Instead, see
http://www.cpan.org/authors/Tom_Christiansen/scripts/ckaddr.gz , which
actually checks against the full RFC spec (except for nested comments),
looks for addresses you may not wish to accept mail to (say, Bill
Clinton or your postmaster), and then makes sure that the hostname given
can be looked up in the DNS MX records. It's not fast, but it works for
what it tries to do.
Our best advice for verifying a person's mail address is to have them
enter their address twice, just as you normally do to change a password.
This usually weeds out typos. If both versions match, send mail to that
address with a personal message that looks somewhat like:
Dear someuser@host.com,
Please confirm the mail address you gave us Wed May 6 09:38:41
MDT 1998 by replying to this message. Include the string
"Rumpelstiltskin" in that reply, but spelled in reverse; that is,
start with "Nik...". Once this is done, your confirmed address will
be entered into our records.
If you get the message back and they've followed your directions, you
can be reasonably assured that it's real.
A related strategy that's less open to forgery is to give them a PIN
(personal ID number). Record the address and PIN (best that it be a
random one) for later processing. In the mail you send, ask them to
include the PIN in their reply. But if it bounces, or the message is
included via a ``vacation'' script, it'll be there anyway. So it's best
to ask them to mail back a slight alteration of the PIN, such as with
the characters reversed, one added or subtracted to each digit, etc.
--------------------------------------------------------------------
Documents such as this have been called "Answers to Frequently
Asked Questions" or FAQ for short. They represent an important
part of the Usenet tradition. They serve to reduce the volume of
redundant traffic on a news group by providing quality answers to
questions that keep coming up.
If you are some how irritated by seeing these postings you are free
to ignore them or add the sender to your killfile. If you find
errors or other problems with these postings please send corrections
or comments to the posting email address or to the maintainers as
directed in the perlfaq manual page.
Note that the FAQ text posted by this server may have been modified
from that distributed in the stable Perl release. It may have been
edited to reflect the additions, changes and corrections provided
by respondents, reviewers, and critics to previous postings of
these FAQ. Complete text of these FAQ are available on request.
The perlfaq manual page contains the following copyright notice.
AUTHOR AND COPYRIGHT
Copyright (c) 1997-2002 Tom Christiansen and Nathan
Torkington, and other contributors as noted. All rights
reserved.
This posting is provided in the hope that it will be useful but
does not represent a commitment or contract of any kind on the part
of the contributers, authors or their agents.
------------------------------
Date: Sat, 30 Oct 2004 12:27:43 GMT
From: Brian Greenfield <not-for-replies@zombie.org.uk>
Subject: Finding a module's $VERSION programmatically
Message-Id: <g117o0psobc64uvmbvvh6crbge8j2hlgjh@4ax.com>
I'm trying to find the version number of the CPAN modules I've
installed so I can keep my modules up to date. The following script
shows the technique I've tried:
#!/usr/bin/perl
use strict;
use warnings FATAL=>'all';
for (qw/Text::Table Class::DBI::Loader::GraphViz/)
{
print "$_: /", fetch_installed_version($_), "/\n";
}
sub fetch_installed_version
{
my $pkg = shift;
eval "require $pkg";
my $iver = eval '$'."${pkg}::VERSION";
die "VERSION is not defined in $pkg\n"
unless $iver;
return $iver;
}
The script gets the version for Text::Table but not for
Class::DBI::Loader::GraphViz:
Text::Table: /1.107/
VERSION is not defined in Class::DBI::Loader::GraphViz
This isn't a one off, about a third of the packages produce the same
error.
If I try to get the version from the command line, I get:
zippy:~/scripts$ perl -MClass::DBI::Loader::GraphViz -we \
'print $Class::DBI::Loader::GraphViz::VERSION'
Base class package "GraphViz::DBI" is empty.
(Perhaps you need to 'use' the module which defines that
package first.)
at /usr/share/perl5/Class/DBI/Loader/GraphViz.pm line 3
BEGIN failed--compilation aborted at
/usr/share/perl5/Class/DBI/Loader/GraphViz.pm line 3.
Compilation failed in require.
BEGIN failed--compilation aborted.
ISTM that my technique is flawed, so what is the best way to find a
module's $VERSION programmatically?
------------------------------
Date: 30 Oct 2004 01:00:52 -0700
From: x3v0-usenet@yahoo.com (Xevo)
Subject: GD.pm install woes
Message-Id: <359b5621.0410300000.c433a5a@posting.google.com>
I've been trying to install GD.pm for a few days now, but to no avail.
I am using Fedora Core 2 with a P4 system.
I have installed libgd 2.0.28, Free Type 2.1.9, libpng 1.2.7, and
jpeg-6b. All were installed from source. I gave each it's own
directory under /usr/local/. There were no errors during the install
of any of them. I can use the scripts that get put into the bin
directory by libgd (such as webpng) so I know libgd is working.
My problem arrises when installing GD.pm. I am attempting to install
GD.pm 2.16. I am using the following args with Makefile.PL, although I
have tried many other variations (such as without "/lib" at the end of
the paths):
perl Makefile.PL -lib_gd_path /usr/local/gd/lib -lib_png_path
/usr/local/libpng/lib -lib_jpeg_path /usr/local/jpeg/lib -lib_ft_path
/usr/local/freetype2/lib -options "GD_JPEG,GD_FREETYPE,GD_PNG,GD_GIF"
This gives me the following output:
--------------------------------------------------
Configuring for libgd version 2.0.28.
Included Features: GD_JPEG,GD_FREETYPE,GD_PNG,GD_GIF
GD library used from: /usr/local/gd/lib
FreeType library used from: /usr/local/freetype2/lib
PNG library used from: /usr/local/libpng/lib
JPEG library used from: /usr/local/jpeg/lib
If you experience compile problems, please check the @INC, @LIBPATH
and @LIBS
arrays defined in Makefile.PL and manually adjust, if necessary.
Writing Makefile for GD
--------------------------------------------------
Ok, so far so good! I then run make...
--------------------------------------------------
gcc -c -I/usr/local/jpeg/lib/include -I/usr/local/libpng/lib/include
-I/usr/local/freetype2/lib/include -I/usr/local/include -D_REENTRANT
-D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/include/gdbm -O2 -g -pipe -march=i386 -mcpu=i686
-DVERSION=\"2.16\" -DXS_VERSION=\"2.16\" -fPIC
"-I/usr/lib/perl5/5.8.3/i386-linux-thread-multi/CORE" -DHAVE_JPEG
-DHAVE_FT -DHAVE_GIF GD.c
Running Mkbootstrap for GD ()
chmod 644 GD.bs
rm -f blib/arch/auto/GD/GD.so
gcc -shared -L/usr/local/lib GD.o -o blib/arch/auto/GD/GD.so
-L/usr/local/freetype2/lib -L/usr/local/libpng/lib
-L/usr/local/jpeg/lib -L/usr/local/lib -ljpeg -lfreetype -lpng -lz -lm
-lgd
chmod 755 blib/arch/auto/GD/GD.so
cp GD.bs blib/arch/auto/GD/GD.bs
chmod 644 blib/arch/auto/GD/GD.bs
Manifying blib/man3/GD::Polyline.3pm
Manifying blib/man3/GD.3pm
--------------------------------------------------
Still no problems that I can see. However, make test blows up...
--------------------------------------------------
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e"
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/GD..........Can't load './blib/arch/auto/GD/GD.so' for module GD:
[libgd.so.2: cannot open shared object file: No such file or directory
at /usr/lib/perl5/5.8.3/i386-linux-thread-multi/DynaLoader.pm line
229.
] at t/GD.t line 13
Compilation failed in require at t/GD.t line 13.
BEGIN failed--compilation aborted at t/GD.t line 13.
t/GD..........dubious
Test returned status 255 (wstat 65280, 0xff00)
Scalar found where operator expected at (eval 152) line 1, near "'int'
$__val"
(Missing operator before $__val?)
DIED. FAILED tests 1-10
Failed 10/10 tests, 0.00% okay
t/Polyline....Can't load
'/home/x3v0/gt/install/GD-2.16/blib/arch/auto/GD/GD.so' for module GD:
[libgd.so.2: cannot open shared object file: No such file or directory
at /usr/lib/perl5/5.8.3/i386-linux-thread-multi/DynaLoader.pm line
229.
] at /home/x3v0/gt/install/GD-2.16/blib/lib/GD/Polyline.pm line 49
Compilation failed in require at
/home/x3v0/gt/install/GD-2.16/blib/lib/GD/Polyline.pm line 49.
BEGIN failed--compilation aborted at
/home/x3v0/gt/install/GD-2.16/blib/lib/GD/Polyline.pm line 49.
Compilation failed in require at t/Polyline.t line 10.
BEGIN failed--compilation aborted at t/Polyline.t line 10.
t/Polyline....dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/GD.t 255 65280 10 19 190.00% 1-10
t/Polyline.t 255 65280 1 2 200.00% 1
Failed 2/2 test scripts, 0.00% okay. 11/11 subtests failed, 0.00%
okay.
make: *** [test_dynamic] Error 255
--------------------------------------------------
I'm not sure exactly what is wrong, but it looks like it can't find
libgd.so.2. Any ideas on what is going on and how to fix this error?
Thanks,
Xevo
------------------------------
Date: Sat, 30 Oct 2004 18:55:16 +1000
From: Gregory Toomey <nospam@bigpond.com>
Subject: Re: GD.pm install woes
Message-Id: <2uh37kF271vrhU2@uni-berlin.de>
Xevo wrote:
> I've been trying to install GD.pm for a few days now, but to no avail.
>
> I am using Fedora Core 2 with a P4 system.
>
> I have installed libgd 2.0.28, Free Type 2.1.9, libpng 1.2.7, and
> jpeg-6b. All were installed from source. I gave each it's own
> directory under /usr/local/. There were no errors during the install
> of any of them. I can use the scripts that get put into the bin
> directory by libgd (such as webpng) so I know libgd is working.
>
I've had problem before too. Try an earlier version. 1.18 has gif suport.
gtoomey
------------------------------
Date: Sat, 30 Oct 2004 10:52:13 +0100
From: bengee <postmaster@localhost.localdomain>
Subject: Re: GD.pm install woes
Message-Id: <4183642c$0$4000$ed2619ec@ptn-nntp-reader01.plus.net>
Xevo wrote:
> I've been trying to install GD.pm for a few days now, but to no avail.
>
> I am using Fedora Core 2 with a P4 system.
>
> I have installed libgd 2.0.28, Free Type 2.1.9, libpng 1.2.7, and
> jpeg-6b. All were installed from source. I gave each it's own
> directory under /usr/local/. There were no errors during the install
> of any of them. I can use the scripts that get put into the bin
> directory by libgd (such as webpng) so I know libgd is working.
I've had problems like this when libgd, libpng and jpeg we're not
installed in their default directory, i.e. i specified --prefix as
/usr/local/whatever. When i re-compiled the above 3 and let the system
put them in their default dir, the problems went away.
Ben
------------------------------
Date: Sat, 30 Oct 2004 13:56:39 +0800
From: kenneth <xthua111@zju.edu.cn>
Subject: how to test the speed of rsync
Message-Id: <clvahk$1m6b$1@mail.cn99.com>
hi everyone.i 'd like to make a mirror of fedora rpms in rsync.and i get
a list of rsync sites. what puzzled me is which site to used . i'd like
to get the higher speed. any advises? thank you!
------------------------------
Date: Sat, 30 Oct 2004 13:57:31 +0800
From: xthua <xthua111@sohu.com>
Subject: how to test the speed of rsync
Message-Id: <clvajl$6om$1@news.yaako.com>
hi everyone.i 'd like to make a mirror of fedora rpms in rsync.and i get
a list of rsync sites. what puzzled me is which site to used . i'd like
to get the higher speed. any advises? thank you!
------------------------------
Date: Sat, 30 Oct 2004 09:06:50 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: IDEs
Message-Id: <sie6o0h685bvp673h0tevtok8e9p3tdfud@4ax.com>
On Fri, 29 Oct 2004 13:49:13 -0400, "daniel kaplan"
<nospam@nospam.com> wrote:
>as for the perldoc, still...no grep (is there a dos equiv?) and doing a
>search on the email address itself produced nothing
There are Windos/DOS ports of grep. But then there's Perl:
perl -lne "print if /what_i_want/" <file(s)>
Unfortunately, at least under Windows98, since the perldoc executable
that comes with AS Perl is a .bat file, you can't pipe its output into
a cmd like the above. OTOH I've set 'less' as my pager and use its
handy search facility. So if you have a favourite pager that allows
you to do searches, then use it instead of 'more'.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 30 Oct 2004 09:06:51 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: IDEs
Message-Id: <tee6o0l9oekr41rq3d2sq04msavqgbj83e@4ax.com>
On Fri, 29 Oct 2004 12:16:09 -0400, "daniel kaplan"
<nospam@nospam.com> wrote:
>in a nutshell, the debugger of OpenPerlIDE complained on just loadin the USE
>statements. it became too much of a headache. so komodo is slow running,
As a side note, there's not such a thing as a "USE statement". In fact
Perl is case sensitive. You may use quotes instead, or even better
C<use>, if you want to stress that you're referring to a code
fragment.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 30 Oct 2004 13:18:16 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: IDEs
Message-Id: <i2u6o0lc6cogld8ctbdo7ajo7h2u3ksc3h@4ax.com>
On Fri, 29 Oct 2004 14:47:20 -0500, Michael Carman
<mjcarman@mchsi.com> wrote:
>Free is good, but I don't mind paying for quality software. At $35, UE
>is a bargain. (Great support, too.)
I think it is reasonable to pay for commercial sw that one actually
uses fruitfully. But there are just so many free and high quality text
editors...
Happily using jed,
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Sat, 30 Oct 2004 12:51:50 GMT
From: burlo_stumproot@yahoo.se
Subject: Re: Parsing 'dirty/corrupt data'. Advice wanted
Message-Id: <ufz3wxtaz.fsf@notvalid.se>
anno4000@lublin.zrz.tu-berlin.de (Anno Siegel) writes:
> <burlo_stumproot@yahoo.se> wrote in comp.lang.perl.misc:
> >
> >
> > I'm finding myself in a position where I have to extract data from a
> > file possibly filled with a lot of other junk of unknown length and
> > format.
<snip>
> > My problem is that the data can at any point contain one or more lines
> > with junk/data I dont want. It looks like the data is collected from
> > an output device that listens to more than one application. (And I
> > cant do anything about that). Some (or most) of the junk can be easily
> > identified as such and can be removed but how to deal with the rest?
>
> Are you sure that only complete lines can intervene? In general,
> one process can overwrite parts of what another process writes to
> the same file.
No, but as yet I have not found any junk inside a line. And if I later
find lines like that I'm going report it in the app and suggest a manual
edit of the file. I have to draw the line somwhere and my line is that
I have to trust my lines :-)
> > Im not looking for code examples but rather advice on how to solve a
> > problem like this in a robust and secure way.
>
> That makes it a non-perl question.
>
> There is no such way. The intervening junk could happen to look exactly
> like a valid line of data. If you don't have means to check the validity
> of a data block you (think you) received, you'll never know.
I can make "some" validity checks on the data. If it's varies too much
from erlier and later data I can report it as questionable.
> If you can't control the output, reasonable data processing is impossible
> in that environment.
And yet I have to. I suppose it depends on your value of "reasonable" :-)
As I wrote above I'm doing exstencive look-ahead in the file for the missing
data lines. If I dont find a line that matches[1] (I stop looking when I
find another block header) I mark the datablock as invalid. This happens
very rarly, most of the time the lookahead works.
What I wanted to know was if anyone had a better idea or suggestion for
improvment to this strategy.
[1]
The regexp for valid lines are very simple but varies between the lines
in a block.
line 1 in block matches regexp_A
line 2 in block matches regexp_B
line 3 in block matches regexp_A
line 4 in block matches regexp_C
...
/PM
From adress valid but rarly read.
------------------------------
Date: Sat, 30 Oct 2004 07:33:29 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: web hoster won't secure CGI
Message-Id: <2ugo1qF2a4hj4U1@uni-berlin.de>
A. Sinan Unur wrote:
> Now, Gunnar, before you interject and say "it is OK not to use CGI
> for such and such reasons", let me point out that it is not OK for
> this particular poster to do that before actually learning Perl.
:)
For some reason, both you and Eric mentioned me in this thread. Let me
explain (again): I have a relaxed relation to Perl modules, and I use
modules when I find it suitable to do so. I often use CGI.pm, and I
normally advise others to use it for parsing CGI data. At the same time,
to me it's not a gathering catastrophe each time somebody considers to
use some other code.
Personally I pay more heed to CGI security, and it's satisfying to
notice that the OP knew that CGI.pm does not protect against DoS attacks
by default, despite several posts here that have given the opposite
impression. As others have pointed out, the CGI docs describe
alternative methods to enable such protection.
Michael's schizophrenic post didn't even address the OP's question, and
I had no intention to comment on it.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Fri, 29 Oct 2004 23:25:50 -0700
From: "Michael Vilain <vilain@spamcop.net>"
Subject: Re: web hoster won't secure CGI
Message-Id: <vilain-39D608.23255029102004@news.giganews.com>
In article <2ugo1qF2a4hj4U1@uni-berlin.de>,
Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
> A. Sinan Unur wrote:
>
> Michael's schizophrenic post didn't even address the OP's question, and
> I had no intention to comment on it.
You're only jealous because the voices are talking to _me_ instead of
you. ;)p
--
DeeDee, don't press that button! DeeDee! NO! Dee...
------------------------------
Date: Sat, 30 Oct 2004 08:33:37 +0200
From: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: web hoster won't secure CGI
Message-Id: <slrnco6de1.1r5.tassilo.von.parseval@localhost.localdomain>
Also sprach wana:
> According to Lincoln Stein's book on CGI.pm, to make CGI safe, you
> have to make configuration changes at the beginning of the CGI.pm
> file.
You don't have to alter CGI.pm's sourcecode, though. These changes
happen through package variables that are accessible from outside the
module.
> I asked my web hosting company if they had made these changes
> to protect me from multi-megabyte uploads or large entries in
> textfields and they told me that they make no changes to Perl modules
> and I have no access to it myself.
>
> Is there another way to provide this protection?
By setting $CGI::POST_MAX or even $CGI::DISABLE_UPLOADS to some sane
value after use()ing the module. See "Avoiding Denial of Service
Attacks" near the end of CGI.pm's perldocs.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: 30 Oct 2004 12:24:16 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: web hoster won't secure CGI
Message-Id: <Xns9592557F628F8asu1cornelledu@132.236.56.8>
Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in news:2ugo1qF2a4hj4U1@uni-
berlin.de:
> A. Sinan Unur wrote:
>> Now, Gunnar, before you interject and say "it is OK not to use CGI
>> for such and such reasons", let me point out that it is not OK for
>> this particular poster to do that before actually learning Perl.
>
>:)
>
> For some reason, both you and Eric mentioned me in this thread.
I forgot to put a smiley at the end ... It was meant in good humor,
especially because you and I had an exchange related to some other home-
cooked CGI parsing routine.
> I have a relaxed relation to Perl modules, and I use modules when I find
> it suitable to do so.
And I tend to go look for a module first and only rarely give them up (for
example, File::Copy in response to Abigail's comments).
> to me it's not a gathering catastrophe each time somebody considers to
> use some other code.
True, but you have to condition that statement on the OP's identity.
> it's satisfying to notice that the OP knew that CGI.pm does not protect
> against DoS attacks by default, despite several posts here that have
> given the opposite impression.
On the other hand, it is prejudicial against the OP that he did not, upon
uncovering this, go and read the CGI.pm docs first. Instead, he went to his
hosting company, and wanted them to change the site CGI.pm to suit his and
his needs only. While we agree that it is useful to put a limit on POST
data size, it is far from clear that that limit ought to be the same for
every script.
Sinan.
--
A. Sinan Unur
1usa@llenroc.ude.invalid
(remove '.invalid' and reverse each component for email address)
------------------------------
Date: Sat, 30 Oct 2004 08:38:50 -0400
From: wana <ioneabu@yahoo.com>
Subject: Re: web hoster won't secure CGI
Message-Id: <10o730vo1kreh2b@news.supernews.com>
Gunnar Hjalmarsson wrote:
> A. Sinan Unur wrote:
>> Now, Gunnar, before you interject and say "it is OK not to use CGI
>> for such and such reasons", let me point out that it is not OK for
>> this particular poster to do that before actually learning Perl.
>
> :)
>
> For some reason, both you and Eric mentioned me in this thread. Let me
> explain (again): I have a relaxed relation to Perl modules, and I use
> modules when I find it suitable to do so. I often use CGI.pm, and I
> normally advise others to use it for parsing CGI data. At the same time,
> to me it's not a gathering catastrophe each time somebody considers to
> use some other code.
>
> Personally I pay more heed to CGI security, and it's satisfying to
> notice that the OP knew that CGI.pm does not protect against DoS attacks
> by default, despite several posts here that have given the opposite
> impression. As others have pointed out, the CGI docs describe
> alternative methods to enable such protection.
>
> Michael's schizophrenic post didn't even address the OP's question, and
> I had no intention to comment on it.
>
Thanks, I read the CGI docs and the book chapter and it does explain how to
protect scripts globally (change CGI.pm file) or on a script-by-script
basis. The book words it a little differently and emphasizes the changing
of the CGI.pm file more. The script-by-script method is mentioned as a way
to override the changes you made to CGI.pm so individual scripts may open
themselves up to larger downloads if they want, although, on second
reading, it is clear you can do it either way.
It seems to me that a web hosting service would probably want to set the
defaults in such a way to prevent attacks:
$CGI::POST_MAX=1024 * 100; # max 100K posts
$CGI::DISABLE_UPLOADS = 1; # no uploads
Then individual scripts still have the option to override.
I don't mean to put down my web provider. They have given me incredible
service for the small price I pay. It is like a home away from home. I
didn't even know what Perl was when I signed up 2 years ago. Now that I am
learning, I find that they have hundreds of modules installed and I have
had no problems running some cool programs there. They just have a policy
of not modifying any modules, which makes sense.
By the way, the book 'MySQL and Perl for the Web' by Paul Dubois clued me in
on the importance of security in CGI scripts and the complete lack of
security that html forms provide.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 7343
***************************************
