[19808] in Perl-Users-Digest
Perl-Users Digest, Issue: 2003 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Oct 25 03:05:33 2001
Date: Thu, 25 Oct 2001 00:05:14 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <1003993513-v10-i2003@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Thu, 25 Oct 2001 Volume: 10 Number: 2003
Today's topics:
Re: beginner: leading zerro function <pne-news-20011025@newton.digitalspace.net>
Re: capture image <goldbb2@earthlink.net>
Re: executing a perl script (David Efflandt)
How to loop through a hash (was Re: Perl and SNMP) <goldbb2@earthlink.net>
Re: IO::Wrap (Douglas Wilson)
Re: lookingglass.pl (Mark Jason Dominus)
Re: lookingglass.pl <goldbb2@earthlink.net>
Re: lookingglass.pl <mgjv@tradingpost.com.au>
Re: Perl Vs. Java (Logan Shaw)
Re: Perl Vs. Java <Tassilo.Parseval@post.rwth-aachen.de>
Re: PF_INET vs. AF_INET (Clinton A. Pierce)
Re: PF_INET vs. AF_INET (Garry Williams)
Re: PF_INET vs. AF_INET <joe+usenet@sunstarsys.com>
Re: Plaintext to passwd file? <darkon@one.net>
Re: Plaintext to passwd file? (Mark Jason Dominus)
Re: Plaintext to passwd file? (Logan Shaw)
Re: Problems with B::CC <kalinabears@hdc.com.au>
Re: Regexp help needed Part 2 <dot@dot.dot>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 25 Oct 2001 09:02:25 +0200
From: Philip Newton <pne-news-20011025@newton.digitalspace.net>
Subject: Re: beginner: leading zerro function
Message-Id: <mrdfttk8r0dr7s67hbp8s57uc8ccqg3cq3@4ax.com>
On Wed, 24 Oct 2001 22:32:01 GMT, Tim Hammerquist <tim@vegeta.ath.cx>
wrote:
> $ perl -
^
Don't really need that.
(And I like typing __END__ to finish off rather than ^D. Personal
preference, I suppose, and partly because I test on Win98 and it doesn't
always seem to like ^Z for end-of-file.)
Cheers,
Philip
--
Philip Newton <nospam.newton@gmx.li>
That really is my address; no need to remove anything to reply.
If you're not part of the solution, you're part of the precipitate.
------------------------------
Date: Thu, 25 Oct 2001 02:38:03 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: capture image
Message-Id: <3BD7B34B.B76044B5@earthlink.net>
huan wrote:
>
> hi,
>
> i want to know how to capture an image from internet using perl, i
> have some codes below, but it seem not work:-
>
> #!/usr/bin/perl -w
> use LWP::Simple;
>
> print "Content-Type: image/gif\n\n";
> $content = get("http://xxx.com/xxx.jpg");
> print $content;
> exit;
#!/usr/bin/perl -w
use LWP::Simple;
print "Content-type: image/jepg\n\n"; # jpeg, not gif.
binmode STDOUT; # important.
getprint("http://xxx.com/xxx.jpg");
exit;
--
Klein bottle for rent - inquire within.
------------------------------
Date: Thu, 25 Oct 2001 01:46:26 +0000 (UTC)
From: efflandt@xnet.com (David Efflandt)
Subject: Re: executing a perl script
Message-Id: <slrn9terni.s8n.efflandt@typhoon.xnet.com>
On Wed, 24 Oct 2001 01:51:16 +0000 (UTC), L S <loudawg98@hotmail.com> wrote:
> Hi
> I am a newbie at this and I was trying to configure squirrelMail and I needed
> to run a conf.pl and I had no idea how to do this. Can someone please help.
What OS? Usually in any Unix or Linux see if conf.pl has read and execute
permission (and if the first line points to Perl on your system). If it
does, you should be able to run it as ./conf.pl from that dir (current dir
'.' is not necessarily in your PATH).
If not, it would probably still run as 'perl conf.pl' (even on Windows, if
you have Perl installed).
--
David Efflandt - All spam is ignored - http://www.de-srv.com/
http://www.autox.chicago.il.us/ http://www.berniesfloral.net/
http://cgi-help.virtualave.net/ http://hammer.prohosting.com/~cgi-wiz/
------------------------------
Date: Thu, 25 Oct 2001 02:30:24 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: How to loop through a hash (was Re: Perl and SNMP)
Message-Id: <3BD7B180.F81C01F6@earthlink.net>
P wrote:
>
> Hi
>
> I have the following bit of code..
[snip]
> if (!defined($userid = $session->get_table($oid))) {
> printf("ERROR: is %s.\n", $session->error);
[snip]
> print "$userid->{$oid1}\n";
> print "$userid->{$oid2}\n";
[snip]
> Now what I want to do is simply loop through all values that have been
> assigned to $userid by the get_table function. Is there some easy way
> to do this? I'm not so good on the OO stuff.
Your problem has nothing to do with OO. $userid is a reference to a
hash. You loop through it just as you would if "userid" were an
ordinary hash, except that there's a "$" between the "%" and "userid" :
while( my ($key, $value) = each %$userid ) {
print "key: $key; value $value\n";
}
--
Klein bottle for rent - inquire within.
------------------------------
Date: Thu, 25 Oct 2001 06:38:36 GMT
From: dwilson@gtemail.net (Douglas Wilson)
Subject: Re: IO::Wrap
Message-Id: <3bd7ab5a.7109531@news>
On Mon, 22 Oct 2001 11:18:28 -0400, Lou Moran <lmoran@wtsg.com> wrote:
>>use IO::Wrap; $output = wraphandle($output);
>
>In a recent thread someone (BG) was kind enough to write out some code
>for me and it has the above line in it.
>
>What module is this a part of, or is it it's own module? Trying to
>find this via PPM with no luck
It's part of the IO-stringy bundle and can be found here:
http://velocity.activestate.com/code/cpan/e/er/ERYQ.author.html
You can always find existing modules through CPAN (http://search.cpan.org)
and at least find out what bundle they're in.
If they are not on ActiveState's site, and if they don't need to be compiled
(and you don't have a compiler), you can install them yourself without PPM by
just copying the *.pm files, though if they are PPM'd it
makes life a little easier for ActiveState users :-)
-Douglas Wilson
------------------------------
Date: Thu, 25 Oct 2001 02:59:54 GMT
From: mjd@plover.com (Mark Jason Dominus)
Subject: Re: lookingglass.pl
Message-Id: <3bd78029.16da$25a@news.op.net>
In article <slrn9tel15.6ff.mgjv@verbruggen.comdyn.com.au>,
Martien Verbruggen <mgjv@tradingpost.com.au> wrote:
>> I think I'm going to add $#array to my 'Program Repair Shop and Red
>> Flags' class as a red flag: Whenever you see $#array, you should stop
>> and see whether you have an opportunity to write clearer code
>> involving @array instead.
>
>I think that would be going a bit too far.
Stopping to see whether you have an opportunity to write clearer
code is 'going a bit too far'? Gosh, you *are* cautious!
Let's by all means not take any drastic and irreversible steps like
stopping to see whether we might have an opportunity to write clearer
code. That would be madness.
Madness, I say!
--
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
------------------------------
Date: Thu, 25 Oct 2001 01:56:27 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: lookingglass.pl
Message-Id: <3BD7A98B.2B1BCDB6@earthlink.net>
Mark Jason Dominus wrote:
[snip]
> Here, on the other hand, is a counterexample (from someone who should
> have known better):
>
> Subject: Re: non repeating random numbers
> Message-Id: <8zneh8a3.fsf@pobox.com>
>
> # create an array of indices into the list of questions
> @q_index = (0 .. @questions-1);
> # scramble it, using the method outlined in perlfaq4
> fisher_yates_shuffle( \@q_index );
> # then ask the questions in the shuffled order we just created
> ask_question($questions[$_]) foreach @q_index;
>
> @questions-1 should evidently have been $#questions.
ISTM that the code above could have been better done as:
@q_shuffled = @questions;
fisher_yates_shuffle( \@q_shuffled );
ask_question($_) foreach @q_shuffled;
The only significant difference between this and the original code is
that before, within ask_question, $_[0] was an alias into the @questions
array, such that changing it would result in a change to that element in
@questions, and in my code it isn't such an alias.
--
Klein bottle for rent - inquire within.
------------------------------
Date: Thu, 25 Oct 2001 06:43:20 GMT
From: Martien Verbruggen <mgjv@tradingpost.com.au>
Subject: Re: lookingglass.pl
Message-Id: <slrn9tfd49.3r3.mgjv@verbruggen.comdyn.com.au>
On Thu, 25 Oct 2001 02:59:54 GMT,
Mark Jason Dominus <mjd@plover.com> wrote:
> In article <slrn9tel15.6ff.mgjv@verbruggen.comdyn.com.au>,
> Martien Verbruggen <mgjv@tradingpost.com.au> wrote:
>>> I think I'm going to add $#array to my 'Program Repair Shop and Red
>>> Flags' class as a red flag: Whenever you see $#array, you should stop
>>> and see whether you have an opportunity to write clearer code
>>> involving @array instead.
>>
>>I think that would be going a bit too far.
>
> Stopping to see whether you have an opportunity to write clearer
> code is 'going a bit too far'? Gosh, you *are* cautious!
No.
Adding the use of $#array as a red flag is going a bit too far. I
don't see any reason to view every occurrence of $#array as a reason
to stop and see whether there is an opportunity to write clearer code.
You might as well say that every occurrence of map or for should make
you do that, or every occurrence of a literal string quoted with
single or double quotes.
> Let's by all means not take any drastic and irreversible steps like
> stopping to see whether we might have an opportunity to write clearer
> code. That would be madness.
Sarcasm noted.
Misunderstanding of what was said is also noted.
Did you read any of the other stuff I wrote in that same post? Might
have helped a bit in understanding what that last remark was about.
> Madness, I say!
uhuh.
Martien
--
Martien Verbruggen |
Interactive Media Division | "In a world without fences,
Commercial Dynamics Pty. Ltd. | who needs Gates?"
NSW, Australia |
------------------------------
Date: 24 Oct 2001 20:54:13 -0500
From: logan@cs.utexas.edu (Logan Shaw)
Subject: Re: Perl Vs. Java
Message-Id: <9r7rc5$gi8$1@charity.cs.utexas.edu>
In article <slrn9td4rm.3i7.tim@vegeta.ath.cx>,
Tim Hammerquist <timmy@cpan.org> wrote:
>This _better_ informed opinion backs yours up. Java _is_ painful...at
>least on my fingers. *lugs out Java manual [1]* The Welcome.java example
>(a glorified "Hello World") is 6+ lines. Christ! 6 lines to print 2
>words?!
Java is verbose, especially compared to Perl, but the reason that
"Hello, world" is 6 lines in Java is that Java forces you to do
everything in an object-oriented fashion. So almost all of that extra
stuff is there because you are creating a class, which you wouldn't
normally do for a program as trivial as "Hello, world".
>The OP mentioned that some others in his org. insisted on Java for
>text-processing...well, if it's not XML _and_ it doesn't have to scale real
>high, I'd use Perl anyway. If it's XML _and/or_ needs to scale well,
>I'd use Python. Both Perl and Python beat out Java for power,
>development speed, and execution speed.
If you mean for text-processing, then I agree that Perl definitely wins
out over Java for power and development speed. Just a few weeks ago, I
found myself trying to find all IMG tags' URLs in an HTML document
using Java, and I was really hating life. I kept thinking, "If this
were Perl, I'd just write
@urls = $html =~ /<\s+IMG[^>]+SRC\s+=\s+"([^"]+)"/ig;
and I'd be done." Sure, it's not actually correct, but it's a lot
closer to correct than what I wrote in Java (it wasn't even
case-insensitive!), and that took me something like 50 lines and half
an hour.
But execution speed is a different story. There may very well be cases
when Perl is faster (probably when doing text processing, which after
all is Perl's forte). But in general, Java wins hands down.
As a little test, I wrote a Sieve of Eratostenes program in each
language. The programs are almost identical. Here's the Java
version:
class Sieve
{
public static void main (String args[])
{
int max;
max = Integer.parseInt(args[0]);
boolean[] prime = new boolean[max + 1];
for (int i = 2; i <= max; i++)
{
prime[i] = true;
}
for (int i = 2; i * i <= max; i++)
{
for (int j = 2 * i; j <= max; j += i)
{
prime[j] = false;
}
}
int count = 0;
for (int i = 2; i <= max; i++)
{
if (prime[i])
{
count++;
}
}
System.out.println ("There are " + count
+ " primes in the interval [2,"
+ max + "].");
}
}
The Perl version is slightly shorter, even though I didn't
go to any real effort to make it short:
#! /usr/local/bin/perl
use strict;
my $max = $ARGV[0];
my @prime;
for (my $i = 2; $i <= $max; $i++)
{
$prime[$i] = 1;
}
for (my $i = 2; $i * $i <= $max; $i++)
{
for (my $j = 2 * $i; $j <= $max; $j += $i)
{
$prime[$j] = 0;
}
}
my $count = 0;
for (my $i = 2; $i <= $max; $i++)
{
if ($prime[$i])
{
$count++;
}
}
print "There are $count primes in the interval [2,$max].\n";
And now, for the fun part: timing them.
$ time perl Sieve.pl 2000000
There are 148933 primes in the interval [2,2000000].
real 0m35.99s
user 0m35.36s
sys 0m0.34s
$ time java Sieve 2000000
There are 148933 primes in the interval [2,2000000].
real 0m2.02s
user 0m1.84s
sys 0m0.14s
Oh my, the Java seems to be almost 20 times as fast as the Perl one!
Now, I love Perl, but that's a pretty significant speed difference.
Just for grins, I wrote a C++ version (I'll not post the
source code -- the important bits are character-for-character
identical to the Java code anyway) and compiled it with gcc
with optimization turned on. The results?
$ time ./Sieve 2000000
There are 148933 primes in the interval [2,2000000].
real 0m1.43s
user 0m1.39s
sys 0m0.03s
The optimized C++ code runs only about 33% faster than the Java code!
Here are the versions I used:
$ perl -version | grep 'This is perl'
This is perl, v5.6.0 built for i86pc-solaris
$ java -version
java version "1.3.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)
$ g++ --version
2.95.3
Now, I know that the Sieve of Eratostenes is not the ultimate in
accurate benchmarks. I may ultimately be testing my computer's memory
latency by trying to find the primes that lie in an interval of two
million integers. And I know that not all code is made up of tight
loops doing simple integer arithmetic.
But the point is that, at least in certain circumstances, Java's
performance can really be quite good.
- Logan
--
"In order to be prepared to hope in what does not deceive,
we must first lose hope in everything that deceives."
Georges Bernanos
------------------------------
Date: Thu, 25 Oct 2001 06:44:43 +0200
From: Tassilo von Parseval <Tassilo.Parseval@post.rwth-aachen.de>
Subject: Re: Perl Vs. Java
Message-Id: <3BD798BB.7040605@post.rwth-aachen.de>
Logan Shaw wrote:
[programs etc snipped]
> And now, for the fun part: timing them.
>
> $ time perl Sieve.pl 2000000
> There are 148933 primes in the interval [2,2000000].
>
> real 0m35.99s
> user 0m35.36s
> sys 0m0.34s
>
> $ time java Sieve 2000000
> There are 148933 primes in the interval [2,2000000].
>
> real 0m2.02s
> user 0m1.84s
> sys 0m0.14s
>
> Oh my, the Java seems to be almost 20 times as fast as the Perl one!
> Now, I love Perl, but that's a pretty significant speed difference.
It only seems to be. First you did not tell us which platform you are
using. Java on a native Sun-machine is something quite different than on
a PC running Win or Linux.
Secondly, you neglected memory consumption. Java is known to consume a
lot of that.
Thirdly, this was hardly a real life example. Let the programs do some
I/O for instance, or perhaps add a GUI to it and things wont be that
bright any longer for Java.
Fourthly:
http://www.ubka.uni-karlsruhe.de/cgi-bin/psview?document=/ira/2000/5
This is a lengthy comparison between C, C++, Java, Perl, Python, REXX
and TCL. The tests were made back at 1998 so the JDK used was not
up-to-date. Yet I doubt that a recent Java would have changed the
results that significantly. The tendency would have been roughly the
same (extravagant memory-consumption, rather poor runtime-performance).
Tassilo
--
$a=[(74,116)];$b=[($a->[1]-1,$a->[1]++,0x20)];$c=[(97,110)];$d=[($c->
[1]+1,$b->[1],"her")];for(@{[$a,$b,$c,$d]}){for(@{$_}){$_=~/\d+/?print
(chr($_)):print;}}$c=sub{$l=shift;[(0x20+$l-1,0x50,0x65,0x73-0x01,108
),(0x20,0x68,0x61,)]};print(map{chr($_)}@{($c->(1))});$h={a=>33*3,b=>
10**2+7,c=>"1"."0"."1",d=>0162};@h=sort(keys(%$h));for(@h){print(chr(
ord(chr($h->{$_}))))};
------------------------------
Date: Thu, 25 Oct 2001 01:08:12 GMT
From: clintp@geeksalad.org (Clinton A. Pierce)
Subject: Re: PF_INET vs. AF_INET
Message-Id: <0CJB7.199166$K6.96152465@news2>
[Posted and mailed]
In article <3BD76EFF.700B7ED1@monmouth.com>,
Richard Trahan <rtrahan@monmouth.com> writes:
> What's the difference?
>
> The Socket module and Wall p. 144 use PF_INET, but I cannot find any
> description of this value in Linux man pages or 3rd party socket
> tutorials.
Assuming you have the full Linux man pages installed:
man socket
To start with.
--
Clinton A. Pierce Teach Yourself Perl in 24 Hours *and*
clintp@geeksalad.org Perl Developer's Dictionary
"If you rush a Miracle Man, for details, see http://geeksalad.org
you get rotten Miracles." --Miracle Max, The Princess Bride
------------------------------
Date: Thu, 25 Oct 2001 01:32:27 GMT
From: garry@ifr.zvolve.net (Garry Williams)
Subject: Re: PF_INET vs. AF_INET
Message-Id: <slrn9teqtb.q7a.garry@zfw.zvolve.net>
On Wed, 24 Oct 2001 18:46:39 -0700, Richard Trahan <rtrahan@monmouth.com> wrote:
> What's the difference?
>
> The Socket module and Wall p. 144 use PF_INET, but I cannot find any
> description of this value in Linux man pages or 3rd party socket
> tutorials.
I don't have a Linux system handy, but this might help from a Solaris
system:
$ grep PF_INET /usr/include/sys/socket.h
#define PF_INET AF_INET
#define PF_INET6 AF_INET6
$
--
Garry Williams
------------------------------
Date: 24 Oct 2001 22:16:08 -0400
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: Re: PF_INET vs. AF_INET
Message-Id: <m3wv1k4g7r.fsf@mumonkan.sunstarsys.com>
Richard Trahan <rtrahan@monmouth.com> writes:
> What's the difference?
>
> The Socket module and Wall p. 144 use PF_INET, but I cannot find any
> description of this value in Linux man pages or 3rd party socket
> tutorials.
When in doubt, always add "Richard Stevens" to the search terms:
google( "Richard Stevens" PF_INET AF_INET ) =>
http://www.kohala.com/start/lanciani.96apr10.txt
--
Joe Schaefer "Only presidents, editors and people with tapeworm have the
right to use the editorial 'we'."
-- Mark Twain
------------------------------
Date: Thu, 25 Oct 2001 02:50:00 GMT
From: "David K. Wall" <darkon@one.net>
Subject: Re: Plaintext to passwd file?
Message-Id: <Xns9144E8852CDDEdarkononenet@24.2.68.108>
logan@cs.utexas.edu (Logan Shaw) wrote:
> So the point of enumerating salts instead of picking them at random is
> to ensure that there are no duplicate salts, which would make the
> attacker's job easier.
The docs say the Perl crypt is the same as the crypt(3) function in the C
library, for which the man pages say
By taking the lowest 7 bit of each character of the key, a 56-bit key
is obtained. This 56-bit key is used to encrypt repeatedly a constant
string (usually a string consisting of all zeros). The returned value
points to the encrypted password, a series of 13 printable ASCII
characters (the first two characters represent the salt itself).
I don't see how picking different salts each time makes things any more
difficult, since anyone will know what the salt is by picking off the first
two characters of the encrypted string. Or am I missing something?
> As an aside, I'll point out that while random really isn't that bad,
> it's not that good either. The chances of having a duplicate salt are
> pretty high, even with only a small number of passwords stored in the
> file. On the other hand, the chances of having all of the salts
> exactly the same are really quite small...
The docs in perlfunc for crypt() recommend a random salt, which may be
where Steffen got the idea.
--
David Wall - darkon@one.net
"Of course, the best way to get accurate information on Usenet is to post
something wrong and wait for corrections." -- Matthew Austern
<austern@research.att.com> 10 Oct 2001 in rec.arts.sf.written
------------------------------
Date: Thu, 25 Oct 2001 03:28:57 GMT
From: mjd@plover.com (Mark Jason Dominus)
Subject: Re: Plaintext to passwd file?
Message-Id: <3bd786f8.1773$2e9@news.op.net>
In article <Xns9144E8852CDDEdarkononenet@24.2.68.108>,
David K. Wall <darkon@one.net> wrote:
>I don't see how picking different salts each time makes things any more
>difficult, since anyone will know what the salt is by picking off the first
>two characters of the encrypted string. Or am I missing something?
It doesn't make it any more difficult to attack a single password. if
I want to guess the password for user X, I can do what you suggested:
I can look up the user X's salt, since it's right there, encrypt the
dictionary with that salt, and see if I get any matches. If so, I win
and user X loses.
The salt is to protect from dictionary attacks against the *entire*
password file.
Without the salt, I encrypt the dictionary and look to see if any of
the results match *any* of the passwords in the file. If any does, I
win and you lose.
With the salt, I encrypt the dictionary with salt "AA" and then I look
for matches. But I won't have any matches unless some of the
passwords were also encrypted with salt "AA". If my dictionary
contains the word "gandalf", and I encrypt "gandalf" with "AA", and
one user has the password "gandalf" but it is encrypted with salt
"AB", I don't get a match and I am no wiser than before. To attack
the entire password file, I have to encrypt my dictionary 4096 times.
Each dictionary is useful for only 1/4096th of the entire password
file, on average.
If there are 10,000 passwords in the file, some salts will be more
used and some will be less used. If one salt is used by 10 passwords
and another salt is only used by one password, I can get time times as
much mileage out of my dictionary attack by attacking the most
commonly-used salt. So ideally, you want to make the number of
appearances of each salt as nearly equal as possible. For 10,000
passwords, this means that optimally, 2288 salts will be used twice
each and the other 1808 will be used three times each. The best the
attacker can do is to choose one of the three-times-used salts and
encrypt the dictionary with that salt.
>The docs in perlfunc for crypt() recommend a random salt, which may be
>where Steffen got the idea.
The very best strategy when encrypting a single new password is to
look through the password file for a salt that has not yet been used,
or one which is among the least-used. Since this is a lot of trouble,
people take the easy way out and pick a salt at random. The random
strategy is almost as good and it's a lot less work.
Since the original poster happens to have a whole lot of passwords to
encrypt all at once, we can do better with no extra cost.
--
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
------------------------------
Date: 24 Oct 2001 22:47:31 -0500
From: logan@cs.utexas.edu (Logan Shaw)
Subject: Re: Plaintext to passwd file?
Message-Id: <9r820j$hd6$1@charity.cs.utexas.edu>
In article <Xns9144E8852CDDEdarkononenet@24.2.68.108>,
David K. Wall <darkon@one.net> wrote:
>The docs say the Perl crypt is the same as the crypt(3) function in the C
>library, for which the man pages say
In addition to saying that the password is used as a key for
encryption, the (Linux) manual page also says this:
salt is a two-character string chosen from the set
[a-zA-Z0-9./]. This string is used to perturb the algorithm
in one of 4096 different ways.
It's not clear, exactly, how the algorithm is perturbed, but it's not
terribly important. The important thing is that using two different
salts with the same plaintext password will yield two different
encrypted passwords:
$ perl -le 'print crypt("yippie!", "AA");'
AA5JrXfgPz9Nc
$ perl -le 'print crypt("yippie!", "AB");'
AB/01hWzR8v/c
>I don't see how picking different salts each time makes things any more
>difficult, since anyone will know what the salt is by picking off the first
>two characters of the encrypted string. Or am I missing something?
It's not that the attacker has to guess the salt. He knows the salt,
but it still makes the attacker's life more difficult.
Maybe an example will help. Let's say you have three users with three
different passwords:
user password
---- --------
medeski organ
martin drums
wood bass
and you know that these guys are some sort of musicians, so you decide
to try the passwords "funk" and "bass". How long will it take you?
First let's see what happens if they all use different salts.
user password w/ salt
---- ----------------
medeski AAfxwbqSuVegg
martin ABaI090PbjAaA
wood ACK9fzz1c2N/M
So, you've got to go through the following steps:
1. Compute crypt("funk", "AA"); compare against medeski's password.
2. Compute crypt("funk", "AB"); compare against martin's password.
3. Compute crypt("funk", "AC"); compare against wood's password.
4. Compute crypt("bass", "AA"); compare against medeski's password.
5. Compute crypt("bass", "AB"); compare against martin's password.
6. Compute crypt("bass", "AC"); compare against wood's password.
Now let's assume instead that they all use the same salt.
user password w/ salt
---- ----------------
medeski AAfxwbqSuVegg
martin AAQRHjAWsxKco
wood AAS/UXbsZToOc
Now let's be naive and do the same steps again:
1. Compute crypt("funk", "AA"); compare against medeski's password.
2. Compute crypt("funk", "AA"); compare against martin's password.
3. Compute crypt("funk", "AA"); compare against wood's password.
4. Compute crypt("bass", "AA"); compare against medeski's password.
5. Compute crypt("bass", "AA"); compare against martin's password.
6. Compute crypt("bass", "AA"); compare against wood's password.
But wait -- we are computing crypt("funk", "AA") and
crypt("bass", "AA") three times each. As a consequence of
the fact that everyone has chosen the same salt, we can turn
that into this:
1. Compute crypt("funk", "AA"); see if that matches medeski's,
martin's, or wood's password.
2. Compute crypt("bass", "AA"); see if that matches medeski's,
martin's, or wood's password.
This is a big win because crypt() is sort of expensive to compute and
we've divided the number of times that we must run crypt() by the total
number of users in our password file. A secondary gain is that
comparing is easier too because we don't have to compare one string to
another three times. Instead, we just have to see if one string
matches any in a list of three, and that can be done in constant time
using a hash.
>The docs in perlfunc for crypt() recommend a random salt, which may be
>where Steffen got the idea.
Yeah. It's not a bad strategy. With random choices of salt, you still
will have lots of passwords that have different salts, and that will
still make the attacker's job difficult. It's just not optimal.
- Logan
--
"In order to be prepared to hope in what does not deceive,
we must first lose hope in everything that deceives."
Georges Bernanos
------------------------------
Date: Thu, 25 Oct 2001 13:32:46 +1000
From: "Sisyphus" <kalinabears@hdc.com.au>
Subject: Re: Problems with B::CC
Message-Id: <1003980656.33118@webmail.origin.net.au>
"Eric McDaniel" <ericm@vertical.com> wrote in message
news:3bd74786$0$6202$4c41069e@reader1.ash.ops.us.uu.net...
>
> I am trying to compile a very simple program into a Win32 executable:
>
> print "Hello world!\n";
>
> I've run my hello.pl source file through perlcc (I've also tried a
straight
> "perl -MO=CC" with the same end result). It generates the expected hello.c
> file, which I can then compile into a hello.exe using MSVC 6.0 with no
> warnings or errors. So far so good.
>
> However, when I try to run hello.exe, I get an access violation at the
> following line in perl_init():
>
> av_store(CvPADLIST(PL_main_cv),0,SvREFCNT_inc((AV*)&sv_list[0]));
>
>
> I realize this is a long shot, but... from the information given, can
anyone
> see what I'm doing wrong? My perl distribution is ActivePerl v5.6.1 build
> 629.
Try 'perlcc -o hello.exe hello.pl'
For me that builds 'hello.exe' quite ok.
Btw, I'm on 2k, build 626 (5.6.1) VC++ 6.0
However, if 'hello.pl' is simply 'print "Hello";' then it works , but
produces an application error pop-up, which is possibly related to the
problem you are facing.
In general, I find that if the script exits, it produces the pop-up, but if
it does not exit it works perfectly.
So, my 'hello.pl' contains:
print "Hello\n";
while (1) { <STDIN> }
I then have to hit Ctrl-C to kill it.
It's the only workaround I know.
One other limitation that I haven't been able to get past is that the
application can't "use" any of the perl extensions, though I've had success
with applications that "use" pure perl modules.
Hth.
Cheers,
Rob
------------------------------
Date: Thu, 25 Oct 2001 14:40:38 +0800
From: "DIAMOND Mark R." <dot@dot.dot>
Subject: Re: Regexp help needed Part 2
Message-Id: <9r8c59$h27$1@enyo.uwa.edu.au>
I am back. Sorry.
The solution given to me by Bernard El-Hagin works wonderfully, but I
realise I made two omissions which complicate things although, in a list of
over 1000 references, the problem only arises about 15 times ... certainly
easy enough to correct manually. But here is the problem anyhow.
Initials, strange as it may seem, are not ALWAYS uppercase. One occasionally
gets an Authorship like "von Erich von Holst and David Mittelstaedt" where
the whole reference then becomes
\item von Holst, v. E., & Mittelstaedt, D. (1954). Also I did not include
the title stuff that appears on the rest of the. Journal Name and other
stuff.
So, is there a way of making the processing stop for a line at the
appearance of the parenthesised year. One can then replace the [A-Z] with
[a-zA-Z] and get the correct result? The complication then seems to be that
one can't use the very useful "global"
Cheers,
Mark
------------------------------
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.
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 2003
***************************************
