[26346] in Perl-Users-Digest
Perl-Users Digest, Issue: 8521 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Oct 13 18:05:30 2005
Date: Thu, 13 Oct 2005 15: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 Thu, 13 Oct 2005 Volume: 10 Number: 8521
Today's topics:
Re: FAQ 4.43 How do I compute the difference of two arr <rvtol+news@isolution.nl>
Re: Jargons of Info Tech industry <mwm@mired.org>
Re: Jargons of Info Tech industry (Gordon Burditt)
Re: Jargons of Info Tech industry <dont@spam.me>
Re: Jargons of Info Tech industry <http://phr.cx@NOSPAM.invalid>
Re: Jargons of Info Tech industry (Gordon Burditt)
Re: Jargons of Info Tech industry <http://phr.cx@NOSPAM.invalid>
modules to detach attachments and form replies? <dm@example.org>
Re: variable question andreas a@t mrs d.t ch
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 13 Oct 2005 17:37:03 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: FAQ 4.43 How do I compute the difference of two arrays? How do I compute the intersection of two arrays?
Message-Id: <dim65d.vc.1@news.isolution.nl>
PerlFAQ Server:
> 4.43: How do I compute the difference of two arrays? How do I
> compute the intersection of two arrays?
>
> Use a hash. Here's code to do both and more. It assumes that each
> element is unique in a given array:
>
> @union = @intersection = @difference = ();
> %count = ();
> foreach $element (@array1, @array2) { $count{$element}++ }
> foreach $element (keys %count) {
> push @union, $element;
> push @{ $count{$element} > 1 ? \@intersection :
> \@difference }, $element; }
>
> Note that this is the *symmetric difference*, that is, all
> elements in either A or in B but not in both. Think of it as an
> xor operation.
I tried to convert this to "a short (less than 20-30 lines) and
*complete* program" and coded this:
#!/usr/bin/perl -w
use strict;
my @array1 = (42, 'question', 'answer', 0x01 );
my @array2 = ('ac/dc', 42, 'volts', 'answer', '"hello"' );
print '1: ', join('|', @array1), "\n";
print '2: ', join('|', @array2), "\n";
my ($element, %count, @union, @intersection, @difference);
foreach $element (@array1, @array2) { $count{$element}++ }
foreach $element (keys %count) {
push @union, $element;
push @{ $count{$element} > 1 ? \@intersection : \@difference },
$element;
}
print "\n";
print 'u: ', join('|', @union), "\n";
print 'i: ', join('|', @intersection), "\n";
print 'd: ', join('|', @difference), "\n";
-----
Because I didn't like the repetitions in the code, I changed it into
this:
#!/usr/bin/perl -w
use strict;
my @array1 = (42, 'question', 'answer', 0x01 );
my @array2 = ('ac/dc', 42, 'volts', 'answer', '"hello"' );
sub adisp($\@;$) {
my ($hdr, $aref, $fsep) = (@_, @_<3?",\t":());
print $hdr, ': (', join($fsep, @$aref), ")\n";
}
adisp('1', @array1, '|');
adisp('2', @array2, '|');
my ($element, %count, @union, @intersection, @difference);
foreach $element (@array1, @array2) { $count{$element}++ }
foreach $element (keys %count) {
push @union, $element;
push @{ $count{$element} > 1 ? \@intersection : \@difference },
$element;
}
print "\n";
adisp('u', @union);
adisp('i', @intersection);
adisp('d', @difference);
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Thu, 13 Oct 2005 11:08:24 -0400
From: Mike Meyer <mwm@mired.org>
Subject: Re: Jargons of Info Tech industry
Message-Id: <86irw1v4if.fsf@bhuda.mired.org>
Roedy Green <my_email_is_posted_on_my_website@munged.invalid> writes:
> On Thu, 13 Oct 2005 01:32:03 -0400, Mike Meyer <mwm@mired.org> wrote
> or quoted :
>>That won't prevent phishing, that will just raise the threshhold a
>>little. The first hurdle you have to get past is that most mail agents
>>want to show a human name, not some random collection of symbols that
>>map to a unique address. Even if you do that, most readers aren't
>>going to pay attention to said random collection of symbols. Given
>>that, there are *lots* of tricks that can be used to disguise the
>>signed name, most of which phishers are already using. How many people
>>do you think will really notice that mail from "John Bath, PayPal
>>Customer Service Representative" (john.barth@paypa1.com) isn't really
>>from paypal?
>
> I think it better than you imagine.
>
> First of all Mr. Phish will come in as a new communicant begging an
> audience. That is your first big clue. PayPal is already allowed in.
That's your first big clue. You've got two problems, though.
1) An as yet unspecified mechanism that magically approves everyone
that you want to talk to. That's a big lump to swallow. It's also
not an easy problem - all existing mechanisms for approving people
require constant attention. Casual users aren't going to put up
with that.
2) What makes you think your average user will realize this? It only
takes a few percent to make it worth the phishers time.
> Next if Thawte issues certs, they won't allow Phish names such as
> Paypol.com just as now for other certs.
So they'll do what their web sites do now, and sign their own certs.
> Mr. Phish is coming in on a different account.
Different from what? And how does the user get told about this, and
what will make them care?
> Next Mr. Phish had to present his passport etc when he got his Thawte
> ID. Now Interpol has a much better handle on putting him in jail.
Not if he didn't have to go to Thawte.
<mike
--
Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
------------------------------
Date: Thu, 13 Oct 2005 19:04:54 -0000
From: gordonb.g6z7y@burditt.org (Gordon Burditt)
Subject: Re: Jargons of Info Tech industry
Message-Id: <11ktbum1ira9le4@corp.supernews.com>
>Hello? I don't think that should make any difference. I should be able
>to visit absolutely any website on the Internet without any danger to my
>computer or the data stored on it. Any browser which allows otherwise
>has a bug.
Then Javascript *as a language* is a bug.
>Javascript is not inherently a virus vector. Flawed
A virus vector is not the only security problem. Leaking
information to the web site is also a problem.
>implementations might be; the language itself is not.
Does the language allow Javascript to open a new window? Does the
language allow Javascript to trigger a function when a window is
closed? I believe the answer to both questions is YES. Then it
is possible to have a page that pops up two windows whenever you
close one. This isn't theoretical: I've seen someone demonstrate
this with certain nasty porn sites. The only way to recover was
to kill off the browser and restart it. (Clicking HOME apparently
fired off a cascade of closed windows which then opened more, running
the browser out of virtual memory.) Because of this, he lost work
in progress with another web site. (Apparently he accidentally
clicked on a banner ad which lead to this booby-trapped site.)
>Similarly for
>anything else. In reality, with a properly-configured, good quality
>operating system (probably a UNIX-type system), one ought to be able to
>run full native code without any danger to one's computer or data
>(think: under the NOBODY account on Linux).
If it can reveal my email address to any web site, it's a bug. If
it can access or alter my personal files or address book, it's a
bug. If it can generate hits on web sites other than that specified
in the HTML, it's a bug. If it can open sockets, it's a bug.
If it can look at or set cookies stored on my system, it's a bug.
If it can look at or alter the list of previously visited URLs, it's
a bug.
>> Browsers don't read unsolicited web sites. Email readers do, however,
>> read unsolicited email, and email from downright hostile correspondents.
>> And I consider "web bugs" and similar tracking methods to be a danger
>> for something that's supposed to be ONLY "formatted text".
Gordon L. Burditt
------------------------------
Date: Thu, 13 Oct 2005 20:18:51 GMT
From: Brendan Guild <dont@spam.me>
Subject: Re: Jargons of Info Tech industry
Message-Id: <Xns96EE8772BFB9Fbguild31425@64.59.144.76>
Gordon Burditt wrote in
news:11ktbum1ira9le4@corp.supernews.com:
> Does the language allow Javascript to open a new window? Does the
> language allow Javascript to trigger a function when a window is
> closed? I believe the answer to both questions is YES. Then it
> is possible to have a page that pops up two windows whenever you
> close one.
This was a problem, but modern browsers implement Javascript in such a
way that it requires permission from the user before it will open a new
window.
> If it can reveal my email address to any web site, it's a bug. If
> it can access or alter my personal files or address book, it's a
> bug. If it can generate hits on web sites other than that specified
> in the HTML, it's a bug. If it can open sockets, it's a bug.
> If it can look at or set cookies stored on my system, it's a bug.
> If it can look at or alter the list of previously visited URLs, it's
> a bug.
All of those things seem like major problems except the bit about
cookies. What possible harm can reading and setting cookies do? I had
always thought they were carefully and successfully designed to be
harmless. That's not personal information in your cookies. That
information is set by websites for the sole purpose of being read by
websites. Plus, I'm pretty sure that browsers have always allowed us to
disable cookies.
------------------------------
Date: 13 Oct 2005 13:38:40 -0700
From: Paul Rubin <http://phr.cx@NOSPAM.invalid>
Subject: Re: Jargons of Info Tech industry
Message-Id: <7xk6gh6tkf.fsf@ruckus.brouhaha.com>
Brendan Guild <dont@spam.me> writes:
> This was a problem, but modern browsers implement Javascript in such a
> way that it requires permission from the user before it will open a new
> window.
Not really true, it's easy to defeat that, and also generally the
pop-up blocker only blocks window.open on load events. JS can usually
still open windows when you mouse over something.
> All of those things seem like major problems except the bit about
> cookies. What possible harm can reading and setting cookies do? I had
> always thought they were carefully and successfully designed to be
> harmless. That's not personal information in your cookies. That
> information is set by websites for the sole purpose of being read by
> websites.
If you have a cookie from site ABC on your system, that shows you
visited site ABC sometime in the past. That is personal information
all by itself, that shouldn't be revealed (including to site ABC)
without your permission. And that doesn't even begin to address web
bugs.
If the JS from site ABC can also read cookies set by unrelated site
XYZ, that's an absolute disaster. It can steal login credentials and
anything else. MSIE actually had a bug of that type a few years ago.
------------------------------
Date: Thu, 13 Oct 2005 21:39:45 -0000
From: gordonb.mrv0t@burditt.org (Gordon Burditt)
Subject: Re: Jargons of Info Tech industry
Message-Id: <11ktl11e426b41d@corp.supernews.com>
>> Does the language allow Javascript to open a new window? Does the
>> language allow Javascript to trigger a function when a window is
>> closed? I believe the answer to both questions is YES. Then it
>> is possible to have a page that pops up two windows whenever you
>> close one.
>
>This was a problem, but modern browsers implement Javascript in such a
>way that it requires permission from the user before it will open a new
>window.
An infinite loop of asking permission is *ALSO* a denial-of-service
attack. And I don't believe that the limitation applies in all
circumstances. This seems to be a feature of the *language*, not
only the implementation.
>> If it can reveal my email address to any web site, it's a bug. If
>> it can access or alter my personal files or address book, it's a
>> bug. If it can generate hits on web sites other than that specified
>> in the HTML, it's a bug. If it can open sockets, it's a bug.
>> If it can look at or set cookies stored on my system, it's a bug.
>> If it can look at or alter the list of previously visited URLs, it's
>> a bug.
>
>All of those things seem like major problems except the bit about
>cookies. What possible harm can reading and setting cookies do? I had
Javascript may be able to set cookies even if they are turned off
by the normal mechanism of setting cookies. Even if that isn't the
case, cookies are supposed to be domain-specific and a cookie from
site A (which might have a session ID for an active login session, or
login credentials for site A) should not be sent to site B. Javascript
can apparently make its own URLs and send anything it gets its hands
on to any site it wants to.
The existence of a cookie from site A shouldn't be revealed at all
to site B (or to Javascript from site B), regardless of what it
contains.
>always thought they were carefully and successfully designed to be
>harmless. That's not personal information in your cookies. That
Some websites *DO* put personal information in cookies. They don't
all just use randomized session identifiers. Some of them store
login credentials for a site (not just a currently active session,
but permanent login credentials. That might not be "personal" the
same way a SSN or credit card number is, but you could still do
damage with it). A lot of the popularity of Javascript comes from
the ability to steal information from the client computer that
normal HTML does not give access to (e.g. screen/window size, email
address, IP address as seen by the client (because of NAT and
proxies, might not be the same IP as seen by the server), MAC
address, browsing history, Windows serial number, Pentium CPU serial
number, etc.)
>information is set by websites for the sole purpose of being read by
>websites.
*BY THE WEBSITES THAT SET THEM*, not by all websites. The "domain"
parameter for setting cookies has been in there since the beginning
of the standard for cookies.
If a marketer wants a piece of information, then I don't want him
to have it, even if it's something like "I visited <page X> and
then went to <page Y>" even if there's no identification of who "I"
is.
>Plus, I'm pretty sure that browsers have always allowed us to
>disable cookies.
I'm not sure that you can disable Javascript from reading cookies
from other sites while allowing Javascript to read cookies from the
site it came from on all browsers.
Gordon L. Burditt
------------------------------
Date: 13 Oct 2005 14:45:53 -0700
From: Paul Rubin <http://phr.cx@NOSPAM.invalid>
Subject: Re: Jargons of Info Tech industry
Message-Id: <7xslv56qge.fsf@ruckus.brouhaha.com>
gordonb.mrv0t@burditt.org (Gordon Burditt) writes:
> I'm not sure that you can disable Javascript from reading cookies
> from other sites while allowing Javascript to read cookies from the
> site it came from on all browsers.
Javascript is not supposed to be able to read cross-site cookies.
It's bad but it's not THAT bad. There was an MSIE bug that allowed
reading other sites' cookies but it was correctly considered a
horrendous security breach and it was fixed quickly after discovery.
It caused a big fire drill where I was working at the time of the
incident. We had to write a special ActiveX control to protect our
cookie info until the browser patch went out.
------------------------------
Date: 13 Oct 2005 16:06:55 -0000
From: Don McLaughlin <dm@example.org>
Subject: modules to detach attachments and form replies?
Message-Id: <CQ3PAV6A38638.4631365741@anonymous.poster>
I've looked at CPAN's Mail and News sections and couldn't find what I
needed so I'd appreciate any pointers to modules or sample code.
(1) I'm sure I've seen a module somewhere for separating MIME parts of
e-mails, but I can't find it now. I want to strip away everything else
and retain just the plain text part.
(2) I want to form a reply mail/news body from an original body, in
other words turn
From: Alice ...
> Bob wrote:
>
> What's going on?
I don't know
into
Alice wrote:
>
> > Bob wrote:
> >
> > What's going on?
>
> I don't know
so I can add a reply to the end. I'm sure this is a standard thing so
I'm surprised I haven't seen anything to do it. News::AutoReply
transforms the headers into a reply but leaves the body empty. I'm
looking for something to do the body only or both the body and the
headers.
Thanks,
Don
------------------------------
Date: 13 Oct 2005 17:58:52 GMT
From: andreas a@t mrs d.t ch
Subject: Re: variable question
Message-Id: <434ea05b$0$1151$5402220f@news.sunrise.ch>
On 06 Oct 2005 20:55:44 GMT, Abigail <abigail@abigail.nl> wrote:
> M0stro (ovelozohnospam@stopspammingglasfloss.com) wrote on MMMMCDXIX
> September MCMXCIII in <URL:news:HCf1f.1314$dB4.921@newssvr12.news.prodigy.com>:
><> also, what is this character called - {
><>
><> it's not a bracket
>
>
> Opening brace, left brace, opening curly bracket, left curly bracket,
> moustache, ...
Haven't been in this newsgroup for about 3 years. But it's nice to have
a good laugh the first day I'm back.
:-)
------------------------------
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 8521
***************************************
