From awwaiid at thelackthereof.org  Mon Sep  4 21:56:39 2006
From: awwaiid at thelackthereof.org (Brock)
Date: Mon, 4 Sep 2006 21:56:39 -0700
Subject: [Phoenix-pm] Meeting Thursday September 7th @7:00pm
Message-ID: <20060905045639.GA19999@thelackthereof.org>

Greetings,

Sorry for the delayed announcement/confirmation. It's been a tough week
for me, which I'll tell you all about when you come to the meeting!

     Time: Thursday 7 September 2006 7:00pm-9:00pm
 Location: Counter Culture Cafe, Phoenix, AZ
           http://maps.google.com/maps?q=2330+E+McDowell+phoenix,+az
    Topic: Andy Lester at upcoming (Oct, is my guess) meeting planning
           perl -e 'print "Command line perl tricks\n"'
           Perl community / technology updates (what's new and cool)
    Other: Free wireless, bring your laptops!

Trying to hit the phoenix area a bit here, and Counter Culture worked
out really well last time.

Perhaps a somewhat random topic, but I think a great one and one that I
use on a very regular basis (command line one-offs, that is). Can also
be a lead-in to a regex discussion/tutorial.

Please RSVP!

--Brock


From andypm at exiledplanet.org  Mon Sep  4 23:32:27 2006
From: andypm at exiledplanet.org (Andrew Johnson)
Date: Mon, 4 Sep 2006 23:32:27 -0700
Subject: [Phoenix-pm] Meeting Thursday September 7th @7:00pm
In-Reply-To: <20060905045639.GA19999@thelackthereof.org>
References: <20060905045639.GA19999@thelackthereof.org>
Message-ID: <e0d2adc80609042332p57c00186p508576c28b58cff5@mail.gmail.com>

Sorry, I've got class that night.  Have fun w/o me!

[aj]

On 9/4/06, Brock <awwaiid at thelackthereof.org> wrote:
>
> Greetings,
>
> Sorry for the delayed announcement/confirmation. It's been a tough week
> for me, which I'll tell you all about when you come to the meeting!
>
>      Time: Thursday 7 September 2006 7:00pm-9:00pm
> Location: Counter Culture Cafe, Phoenix, AZ
>            http://maps.google.com/maps?q=2330+E+McDowell+phoenix,+az
>     Topic: Andy Lester at upcoming (Oct, is my guess) meeting planning
>            perl -e 'print "Command line perl tricks\n"'
>            Perl community / technology updates (what's new and cool)
>     Other: Free wireless, bring your laptops!
>
> Trying to hit the phoenix area a bit here, and Counter Culture worked
> out really well last time.
>
> Perhaps a somewhat random topic, but I think a great one and one that I
> use on a very regular basis (command line one-offs, that is). Can also
> be a lead-in to a regex discussion/tutorial.
>
> Please RSVP!
>
> --Brock
>
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/phoenix-pm/attachments/20060904/01e1539d/attachment.html 

From derek at ninth.org  Tue Sep  5 10:23:18 2006
From: derek at ninth.org (Derek Cline)
Date: Tue, 5 Sep 2006 10:23:18 -0700
Subject: [Phoenix-pm] Meeting Thursday September 7th @7:00pm
In-Reply-To: <20060905045639.GA19999@thelackthereof.org>
References: <20060905045639.GA19999@thelackthereof.org>
Message-ID: <B6CD7DFD-937D-4918-9962-8C077DFCFDC4@ninth.org>

I'll be there.

-=Derek

On Sep 4, 2006, at 9:56 PM, Brock wrote:

> Greetings,
>
> Sorry for the delayed announcement/confirmation. It's been a tough  
> week
> for me, which I'll tell you all about when you come to the meeting!
>
>      Time: Thursday 7 September 2006 7:00pm-9:00pm
>  Location: Counter Culture Cafe, Phoenix, AZ
>            http://maps.google.com/maps?q=2330+E+McDowell+phoenix,+az
>     Topic: Andy Lester at upcoming (Oct, is my guess) meeting planning
>            perl -e 'print "Command line perl tricks\n"'
>            Perl community / technology updates (what's new and cool)
>     Other: Free wireless, bring your laptops!
>
> Trying to hit the phoenix area a bit here, and Counter Culture worked
> out really well last time.
>
> Perhaps a somewhat random topic, but I think a great one and one  
> that I
> use on a very regular basis (command line one-offs, that is). Can also
> be a lead-in to a regex discussion/tutorial.
>
> Please RSVP!
>
> --Brock
>
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm


From awwaiid at thelackthereof.org  Thu Sep  7 11:09:03 2006
From: awwaiid at thelackthereof.org (Brock)
Date: Thu, 7 Sep 2006 11:09:03 -0700
Subject: [Phoenix-pm] MEETING CHANGE - Thursday September 7th @7:00pm
In-Reply-To: <B6CD7DFD-937D-4918-9962-8C077DFCFDC4@ninth.org>
References: <20060905045639.GA19999@thelackthereof.org>
	<B6CD7DFD-937D-4918-9962-8C077DFCFDC4@ninth.org>
Message-ID: <20060907180903.GI19999@thelackthereof.org>

This is the only positive RSVP that I've recieved, and I recently
learned of the topic for tonights PLUG-dev meeting and it fits in well
with the perl group.

SO! Tonight's meeting is re-located to be at the PLUG-dev meeting! Here
is the announcement:

What: PLUG Developer Meeting (And Phoenix.PM meeting!)
When: Thursday, September 7th, 2006 at 7:00 PM
Where: Adtron Corporation
4415 E. Cotton Center Blvd., Suite 100
Phoenix, AZ 85040
(Directions are available in the web site FAQ)
http://plug.phoenix.az.us/index.php?option=com_content&task=view&id=23&Itemid=25

Topic: Web Technologies on Linux - a Comparison by Paul Balyoz

A comparison of popular languages for web development - Perl,
PHP,HTML/Javascript/CSS, Ruby/Rails, Java EJB3; strengths & weaknesses,
whatto use when, etc. This will show the wide variety of
developmentchoices that Unix/Linux provides.Speaker: Paul Balyoz,
Fastech Learning Center

Paul Balyoz currently works as an instructor at the Fastech Learning
Center located in Chandler, Arizona. His past experience as Unix system
administrator, firewall engineer, and software designer during the past
18 years have fueled the fire of his passion to teach technical skills
to others. Paul has developed a number of open source software packages
including Dlint and Domtools. Fastech ( http://www.fastechLC.com/) holds
regular classes around the Phoenix area on Perl, Unix, PHP, HTML/CSS,
Javascript, and SQL - at all levels from beginning to advanced.

------

Derek, can you make it to this one? I am working downtown so I can give
you a ride if you like :)

Everyone else -- you can still RSVP!

--Brock

On 2006.09.05.10.23, Derek Cline wrote:
| I'll be there.
| 
| -=Derek
| 
| On Sep 4, 2006, at 9:56 PM, Brock wrote:
| 
| > Greetings,
| >
| > Sorry for the delayed announcement/confirmation. It's been a tough  
| > week
| > for me, which I'll tell you all about when you come to the meeting!
| >
| >      Time: Thursday 7 September 2006 7:00pm-9:00pm
| >  Location: Counter Culture Cafe, Phoenix, AZ
| >            http://maps.google.com/maps?q=2330+E+McDowell+phoenix,+az
| >     Topic: Andy Lester at upcoming (Oct, is my guess) meeting planning
| >            perl -e 'print "Command line perl tricks\n"'
| >            Perl community / technology updates (what's new and cool)
| >     Other: Free wireless, bring your laptops!
| >
| > Trying to hit the phoenix area a bit here, and Counter Culture worked
| > out really well last time.
| >
| > Perhaps a somewhat random topic, but I think a great one and one  
| > that I
| > use on a very regular basis (command line one-offs, that is). Can also
| > be a lead-in to a regex discussion/tutorial.
| >
| > Please RSVP!
| >
| > --Brock
| >
| > _______________________________________________
| > Phoenix-pm mailing list
| > Phoenix-pm at pm.org
| > http://mail.pm.org/mailman/listinfo/phoenix-pm
| 
| _______________________________________________
| Phoenix-pm mailing list
| Phoenix-pm at pm.org
| http://mail.pm.org/mailman/listinfo/phoenix-pm

From derek at ninth.org  Thu Sep  7 11:19:09 2006
From: derek at ninth.org (Derek Cline)
Date: Thu, 7 Sep 2006 11:19:09 -0700
Subject: [Phoenix-pm] MEETING CHANGE - Thursday September 7th @7:00pm
In-Reply-To: <20060907180903.GI19999@thelackthereof.org>
References: <20060905045639.GA19999@thelackthereof.org>
	<B6CD7DFD-937D-4918-9962-8C077DFCFDC4@ninth.org>
	<20060907180903.GI19999@thelackthereof.org>
Message-ID: <9B1243D5-8690-4282-825F-436DC2E215D2@ninth.org>

Yeah, I'm still down for meeting tonight. I don't mind driving since  
it'd be a trek for you to drop me off afterwards anyway, wouldn't it?

-=D


On Sep 7, 2006, at 11:09 AM, Brock wrote:

> This is the only positive RSVP that I've recieved, and I recently
> learned of the topic for tonights PLUG-dev meeting and it fits in well
> with the perl group.
>
> SO! Tonight's meeting is re-located to be at the PLUG-dev meeting!  
> Here
> is the announcement:
>
> What: PLUG Developer Meeting (And Phoenix.PM meeting!)
> When: Thursday, September 7th, 2006 at 7:00 PM
> Where: Adtron Corporation
> 4415 E. Cotton Center Blvd., Suite 100
> Phoenix, AZ 85040
> (Directions are available in the web site FAQ)
> http://plug.phoenix.az.us/index.php? 
> option=com_content&task=view&id=23&Itemid=25
>
> Topic: Web Technologies on Linux - a Comparison by Paul Balyoz
>
> A comparison of popular languages for web development - Perl,
> PHP,HTML/Javascript/CSS, Ruby/Rails, Java EJB3; strengths &  
> weaknesses,
> whatto use when, etc. This will show the wide variety of
> developmentchoices that Unix/Linux provides.Speaker: Paul Balyoz,
> Fastech Learning Center
>
> Paul Balyoz currently works as an instructor at the Fastech Learning
> Center located in Chandler, Arizona. His past experience as Unix  
> system
> administrator, firewall engineer, and software designer during the  
> past
> 18 years have fueled the fire of his passion to teach technical skills
> to others. Paul has developed a number of open source software  
> packages
> including Dlint and Domtools. Fastech ( http://www.fastechLC.com/)  
> holds
> regular classes around the Phoenix area on Perl, Unix, PHP, HTML/CSS,
> Javascript, and SQL - at all levels from beginning to advanced.
>
> ------
>
> Derek, can you make it to this one? I am working downtown so I can  
> give
> you a ride if you like :)
>
> Everyone else -- you can still RSVP!
>
> --Brock
>
> On 2006.09.05.10.23, Derek Cline wrote:
> | I'll be there.
> |
> | -=Derek
> |
> | On Sep 4, 2006, at 9:56 PM, Brock wrote:
> |
> | > Greetings,
> | >
> | > Sorry for the delayed announcement/confirmation. It's been a tough
> | > week
> | > for me, which I'll tell you all about when you come to the  
> meeting!
> | >
> | >      Time: Thursday 7 September 2006 7:00pm-9:00pm
> | >  Location: Counter Culture Cafe, Phoenix, AZ
> | >            http://maps.google.com/maps?q=2330+E+McDowell 
> +phoenix,+az
> | >     Topic: Andy Lester at upcoming (Oct, is my guess) meeting  
> planning
> | >            perl -e 'print "Command line perl tricks\n"'
> | >            Perl community / technology updates (what's new and  
> cool)
> | >     Other: Free wireless, bring your laptops!
> | >
> | > Trying to hit the phoenix area a bit here, and Counter Culture  
> worked
> | > out really well last time.
> | >
> | > Perhaps a somewhat random topic, but I think a great one and one
> | > that I
> | > use on a very regular basis (command line one-offs, that is).  
> Can also
> | > be a lead-in to a regex discussion/tutorial.
> | >
> | > Please RSVP!
> | >
> | > --Brock
> | >
> | > _______________________________________________
> | > Phoenix-pm mailing list
> | > Phoenix-pm at pm.org
> | > http://mail.pm.org/mailman/listinfo/phoenix-pm
> |
> | _______________________________________________
> | Phoenix-pm mailing list
> | Phoenix-pm at pm.org
> | http://mail.pm.org/mailman/listinfo/phoenix-pm


From awwaiid at thelackthereof.org  Thu Sep  7 11:41:13 2006
From: awwaiid at thelackthereof.org (Brock)
Date: Thu, 7 Sep 2006 11:41:13 -0700
Subject: [Phoenix-pm] MEETING CHANGE - Thursday September 7th @7:00pm
In-Reply-To: <9B1243D5-8690-4282-825F-436DC2E215D2@ninth.org>
References: <20060905045639.GA19999@thelackthereof.org>
	<B6CD7DFD-937D-4918-9962-8C077DFCFDC4@ninth.org>
	<20060907180903.GI19999@thelackthereof.org>
	<9B1243D5-8690-4282-825F-436DC2E215D2@ninth.org>
Message-ID: <20060907184112.GJ19999@thelackthereof.org>

Only a bit :)

The place was tricky for me to find the first time (though it could be
because I am not good at finding places....). I'll mail you my phone
number separately in case you get lost (if you haven't been there
before).

--Brock

On 2006.09.07.11.19, Derek Cline wrote:
| Yeah, I'm still down for meeting tonight. I don't mind driving since  
| it'd be a trek for you to drop me off afterwards anyway, wouldn't it?
| 
| -=D


From derek at ninth.org  Thu Sep  7 13:58:19 2006
From: derek at ninth.org (Derek Cline)
Date: Thu, 7 Sep 2006 13:58:19 -0700
Subject: [Phoenix-pm] MEETING CHANGE - Thursday September 7th @7:00pm
In-Reply-To: <20060907184112.GJ19999@thelackthereof.org>
References: <20060905045639.GA19999@thelackthereof.org>
	<B6CD7DFD-937D-4918-9962-8C077DFCFDC4@ninth.org>
	<20060907180903.GI19999@thelackthereof.org>
	<9B1243D5-8690-4282-825F-436DC2E215D2@ninth.org>
	<20060907184112.GJ19999@thelackthereof.org>
Message-ID: <9928DBA6-9B84-47FB-A733-59F611950ABF@ninth.org>

Cool, see you there.

-=Derek

On Sep 7, 2006, at 11:41 AM, Brock wrote:

> Only a bit :)
>
> The place was tricky for me to find the first time (though it could be
> because I am not good at finding places....). I'll mail you my phone
> number separately in case you get lost (if you haven't been there
> before).
>
> --Brock
>
> On 2006.09.07.11.19, Derek Cline wrote:
> | Yeah, I'm still down for meeting tonight. I don't mind driving since
> | it'd be a trek for you to drop me off afterwards anyway, wouldn't  
> it?
> |
> | -=D
>


From dwchandler at stilyagin.com  Thu Sep  7 16:41:50 2006
From: dwchandler at stilyagin.com (Darrin Chandler)
Date: Thu, 7 Sep 2006 16:41:50 -0700
Subject: [Phoenix-pm] MEETING CHANGE - Thursday September 7th @7:00pm
In-Reply-To: <20060907180903.GI19999@thelackthereof.org>
References: <20060905045639.GA19999@thelackthereof.org>
	<B6CD7DFD-937D-4918-9962-8C077DFCFDC4@ninth.org>
	<20060907180903.GI19999@thelackthereof.org>
Message-ID: <20060907234150.GI27121@zloy.stilyagin.com>

On Thu, Sep 07, 2006 at 11:09:03AM -0700, Brock wrote:
> This is the only positive RSVP that I've recieved, and I recently
> learned of the topic for tonights PLUG-dev meeting and it fits in well
> with the perl group.
> 
> SO! Tonight's meeting is re-located to be at the PLUG-dev meeting! Here
> is the announcement:

Cool! So I'm going to make it to my first Phoenix.pm meeting after all
this time. ;) Seems there's always some conflict with my schedule, but
not this time!

-- 
Darrin Chandler            |  Phoenix BSD Users Group
dwchandler at stilyagin.com   |  http://bsd.phoenix.az.us/
http://www.stilyagin.com/  |

From dwchandler at stilyagin.com  Thu Sep  7 16:39:27 2006
From: dwchandler at stilyagin.com (Darrin Chandler)
Date: Thu, 7 Sep 2006 16:39:27 -0700
Subject: [Phoenix-pm] MEETING CHANGE - Thursday September 7th @7:00pm
In-Reply-To: <20060907184112.GJ19999@thelackthereof.org>
References: <20060905045639.GA19999@thelackthereof.org>
	<B6CD7DFD-937D-4918-9962-8C077DFCFDC4@ninth.org>
	<20060907180903.GI19999@thelackthereof.org>
	<9B1243D5-8690-4282-825F-436DC2E215D2@ninth.org>
	<20060907184112.GJ19999@thelackthereof.org>
Message-ID: <20060907233927.GH27121@zloy.stilyagin.com>

On Thu, Sep 07, 2006 at 11:41:13AM -0700, Brock wrote:
> Only a bit :)
> 
> The place was tricky for me to find the first time (though it could be
> because I am not good at finding places....). I'll mail you my phone
> number separately in case you get lost (if you haven't been there
> before).

I had to double back and look the first time I went, too. Mapping stuff
only gets you to the vicinity. For the final steps, heed the text
directions on the PLUG site!

-- 
Darrin Chandler            |  Phoenix BSD Users Group
dwchandler at stilyagin.com   |  http://bsd.phoenix.az.us/
http://www.stilyagin.com/  |

From awwaiid at thelackthereof.org  Thu Sep  7 17:36:01 2006
From: awwaiid at thelackthereof.org (Brock)
Date: Thu, 7 Sep 2006 17:36:01 -0700
Subject: [Phoenix-pm] MEETING CHANGE - Thursday September 7th @7:00pm
In-Reply-To: <20060907233927.GH27121@zloy.stilyagin.com>
References: <20060905045639.GA19999@thelackthereof.org>
	<B6CD7DFD-937D-4918-9962-8C077DFCFDC4@ninth.org>
	<20060907180903.GI19999@thelackthereof.org>
	<9B1243D5-8690-4282-825F-436DC2E215D2@ninth.org>
	<20060907184112.GJ19999@thelackthereof.org>
	<20060907233927.GH27121@zloy.stilyagin.com>
Message-ID: <20060908003601.GQ19999@thelackthereof.org>

Actually the text tricked me too. I think the trick is to just continue
straight south from the traffic circle, and then head to the parking lot
on the right. They suggest going 3/4 of the way around the circle, but I
consider it only 1/2 way around. IIRC :)

--Brock

On 2006.09.07.16.39, Darrin Chandler wrote:
| On Thu, Sep 07, 2006 at 11:41:13AM -0700, Brock wrote:
| > Only a bit :)
| > 
| > The place was tricky for me to find the first time (though it could be
| > because I am not good at finding places....). I'll mail you my phone
| > number separately in case you get lost (if you haven't been there
| > before).
| 
| I had to double back and look the first time I went, too. Mapping stuff
| only gets you to the vicinity. For the final steps, heed the text
| directions on the PLUG site!
| 
| -- 
| Darrin Chandler            |  Phoenix BSD Users Group
| dwchandler at stilyagin.com   |  http://bsd.phoenix.az.us/
| http://www.stilyagin.com/  |

From dwchandler at stilyagin.com  Thu Sep  7 17:56:09 2006
From: dwchandler at stilyagin.com (Darrin Chandler)
Date: Thu, 7 Sep 2006 17:56:09 -0700
Subject: [Phoenix-pm] MEETING CHANGE - Thursday September 7th @7:00pm
In-Reply-To: <20060908003601.GQ19999@thelackthereof.org>
References: <20060905045639.GA19999@thelackthereof.org>
	<B6CD7DFD-937D-4918-9962-8C077DFCFDC4@ninth.org>
	<20060907180903.GI19999@thelackthereof.org>
	<9B1243D5-8690-4282-825F-436DC2E215D2@ninth.org>
	<20060907184112.GJ19999@thelackthereof.org>
	<20060907233927.GH27121@zloy.stilyagin.com>
	<20060908003601.GQ19999@thelackthereof.org>
Message-ID: <20060908005609.GL27121@zloy.stilyagin.com>

On Thu, Sep 07, 2006 at 05:36:01PM -0700, Brock wrote:
> Actually the text tricked me too. I think the trick is to just continue
> straight south from the traffic circle, and then head to the parking lot
> on the right. They suggest going 3/4 of the way around the circle, but I
> consider it only 1/2 way around. IIRC :)

Well, I enter the circle from the East, so exiting to the South is 3/4
circuit for me. Whichever way you go into the circle, South is the right
way to get to the meeting.

-- 
Darrin Chandler            |  Phoenix BSD Users Group
dwchandler at stilyagin.com   |  http://bsd.phoenix.az.us/
http://www.stilyagin.com/  |

From pm at upt.org  Thu Sep  7 18:16:43 2006
From: pm at upt.org (Lane Davis)
Date: Thu, 07 Sep 2006 18:16:43 -0700 (MST)
Subject: [Phoenix-pm] MEETING CHANGE - Thursday September 7th @7:00pm
In-Reply-To: <20060907180903.GI19999@thelackthereof.org>
Message-ID: <XFMail.20060907181643.pm@upt.org>


Sorry to top-post *and* give such a late RSVP -- count me in :-)

-Lane

On 07-Sep-2006 Brock wrote:
> This is the only positive RSVP that I've recieved, and I recently
> learned of the topic for tonights PLUG-dev meeting and it fits in well
> with the perl group.
> 
> SO! Tonight's meeting is re-located to be at the PLUG-dev meeting! Here
> is the announcement:
> 
> What: PLUG Developer Meeting (And Phoenix.PM meeting!)
> When: Thursday, September 7th, 2006 at 7:00 PM
> Where: Adtron Corporation
> 4415 E. Cotton Center Blvd., Suite 100
> Phoenix, AZ 85040
> (Directions are available in the web site FAQ)
> http://plug.phoenix.az.us/index.php?option=com_content&task=view&id=23&Itemid=
> 25
> 
> Topic: Web Technologies on Linux - a Comparison by Paul Balyoz
> 
> A comparison of popular languages for web development - Perl,
> PHP,HTML/Javascript/CSS, Ruby/Rails, Java EJB3; strengths & weaknesses,
> whatto use when, etc. This will show the wide variety of
> developmentchoices that Unix/Linux provides.Speaker: Paul Balyoz,
> Fastech Learning Center
> 
> Paul Balyoz currently works as an instructor at the Fastech Learning
> Center located in Chandler, Arizona. His past experience as Unix system
> administrator, firewall engineer, and software designer during the past
> 18 years have fueled the fire of his passion to teach technical skills
> to others. Paul has developed a number of open source software packages
> including Dlint and Domtools. Fastech ( http://www.fastechLC.com/) holds
> regular classes around the Phoenix area on Perl, Unix, PHP, HTML/CSS,
> Javascript, and SQL - at all levels from beginning to advanced.
> 
> ------
> 
> Derek, can you make it to this one? I am working downtown so I can give
> you a ride if you like :)
> 
> Everyone else -- you can still RSVP!
> 
> --Brock
> 
> On 2006.09.05.10.23, Derek Cline wrote:
>| I'll be there.
>| 
>| -=Derek
>| 
>| On Sep 4, 2006, at 9:56 PM, Brock wrote:
>| 
>| > Greetings,
>| >
>| > Sorry for the delayed announcement/confirmation. It's been a tough  
>| > week
>| > for me, which I'll tell you all about when you come to the meeting!
>| >
>| >      Time: Thursday 7 September 2006 7:00pm-9:00pm
>| >  Location: Counter Culture Cafe, Phoenix, AZ
>| >            http://maps.google.com/maps?q=2330+E+McDowell+phoenix,+az
>| >     Topic: Andy Lester at upcoming (Oct, is my guess) meeting planning
>| >            perl -e 'print "Command line perl tricks\n"'
>| >            Perl community / technology updates (what's new and cool)
>| >     Other: Free wireless, bring your laptops!
>| >
>| > Trying to hit the phoenix area a bit here, and Counter Culture worked
>| > out really well last time.
>| >
>| > Perhaps a somewhat random topic, but I think a great one and one  
>| > that I
>| > use on a very regular basis (command line one-offs, that is). Can also
>| > be a lead-in to a regex discussion/tutorial.
>| >
>| > Please RSVP!
>| >
>| > --Brock
>| >
>| > _______________________________________________
>| > Phoenix-pm mailing list
>| > Phoenix-pm at pm.org
>| > http://mail.pm.org/mailman/listinfo/phoenix-pm
>| 
>| _______________________________________________
>| Phoenix-pm mailing list
>| Phoenix-pm at pm.org
>| http://mail.pm.org/mailman/listinfo/phoenix-pm

From pm at upt.org  Thu Sep  7 21:24:44 2006
From: pm at upt.org (Lane Davis)
Date: Thu, 07 Sep 2006 21:24:44 -0700 (MST)
Subject: [Phoenix-pm] MEETING CHANGE - Thursday September 7th @7:00pm
In-Reply-To: <20060908005609.GL27121@zloy.stilyagin.com>
Message-ID: <XFMail.20060907212444.pm@upt.org>


On 08-Sep-2006 Darrin Chandler wrote:
> On Thu, Sep 07, 2006 at 05:36:01PM -0700, Brock wrote:
>> Actually the text tricked me too. I think the trick is to just continue
>> straight south from the traffic circle, and then head to the parking lot
>> on the right. They suggest going 3/4 of the way around the circle, but I
>> consider it only 1/2 way around. IIRC :)
>

Left early, couldn't indulge the extollations of HTML and the explications of
PHP.  It had its place, just was expecting some of the things promised in the
earlier PM mentions -- "Command line perl tricks\n" and regex stuff :-)

Would have liked to say "Hi" to Hans though, as I haven't seen him since the
late 90's.

Cheers & Regards to all PM's,
-Lane


From scott at   Thu Sep  7 21:45:58 2006
From: scott at  (Scott Walters)
Date: Fri, 8 Sep 2006 04:45:58 +0000
Subject: [Phoenix-pm] MEETING CHANGE - Thursday September 7th @7:00pm
In-Reply-To: <XFMail.20060907212444.pm@upt.org>
References: <20060908005609.GL27121@zloy.stilyagin.com>
	<XFMail.20060907212444.pm@upt.org>
Message-ID: <20060908044558.GN21165@straylight>

Figures.  Given a choice between a magic bullet and a hollowtip, everyone
wants the magic one.  Kind of wish I were there so I could engage in a
battle of wits with the witlings.  As they say, for every complex problem, 
there is a solution that is simple, neat, and wrong.

-scott

On  0, Lane Davis <pm at upt.org> wrote:
> 
> On 08-Sep-2006 Darrin Chandler wrote:
> > On Thu, Sep 07, 2006 at 05:36:01PM -0700, Brock wrote:
> >> Actually the text tricked me too. I think the trick is to just continue
> >> straight south from the traffic circle, and then head to the parking lot
> >> on the right. They suggest going 3/4 of the way around the circle, but I
> >> consider it only 1/2 way around. IIRC :)
> >
> 
> Left early, couldn't indulge the extollations of HTML and the explications of
> PHP.  It had its place, just was expecting some of the things promised in the
> earlier PM mentions -- "Command line perl tricks\n" and regex stuff :-)
> 
> Would have liked to say "Hi" to Hans though, as I haven't seen him since the
> late 90's.
> 
> Cheers & Regards to all PM's,
> -Lane
> 
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm

From awwaiid at thelackthereof.org  Thu Sep  7 22:13:59 2006
From: awwaiid at thelackthereof.org (Brock)
Date: Thu, 7 Sep 2006 22:13:59 -0700
Subject: [Phoenix-pm] MEETING CHANGE - Thursday September 7th @7:00pm
In-Reply-To: <XFMail.20060907212444.pm@upt.org>
References: <20060908005609.GL27121@zloy.stilyagin.com>
	<XFMail.20060907212444.pm@upt.org>
Message-ID: <20060908051359.GT19999@thelackthereof.org>

On 2006.09.07.21.24, Lane Davis wrote:
| 
| On 08-Sep-2006 Darrin Chandler wrote:
| > On Thu, Sep 07, 2006 at 05:36:01PM -0700, Brock wrote:
| >> Actually the text tricked me too. I think the trick is to just continue
| >> straight south from the traffic circle, and then head to the parking lot
| >> on the right. They suggest going 3/4 of the way around the circle, but I
| >> consider it only 1/2 way around. IIRC :)
| >
| 
| Left early, couldn't indulge the extollations of HTML and the explications of
| PHP.  It had its place, just was expecting some of the things promised in the
| earlier PM mentions -- "Command line perl tricks\n" and regex stuff :-)

We should do that next time then!

Yeah... the presentation left a bit to be desired. But it was nice
socializing afterwards.

--Brock


From bwmetz at att.com  Thu Sep  7 22:17:08 2006
From: bwmetz at att.com (Metz, Bobby W, WWCS)
Date: Fri, 8 Sep 2006 00:17:08 -0500
Subject: [Phoenix-pm] MEETING CHANGE - Thursday September 7th @7:00pm
In-Reply-To: <20060908051359.GT19999@thelackthereof.org>
Message-ID: <01D5341D04A2E64AB9B3457690473367026AA2D7@OCCLUST01EVS1.ugd.att.com>

I'm actually glad to hear the cmd line tricks wasn't done since I
couldn't make it due to work.

B

-----Original Message-----
From: phoenix-pm-bounces+bwmetz=att.com at pm.org
[mailto:phoenix-pm-bounces+bwmetz=att.com at pm.org]On Behalf Of Brock
Sent: Thursday, September 07, 2006 10:14 PM
To: Lane Davis
Cc: phoenix-pm at pm.org
Subject: Re: [Phoenix-pm] MEETING CHANGE - Thursday September 7th
@7:00pm


On 2006.09.07.21.24, Lane Davis wrote:
| 
| On 08-Sep-2006 Darrin Chandler wrote:
| > On Thu, Sep 07, 2006 at 05:36:01PM -0700, Brock wrote:
| >> Actually the text tricked me too. I think the trick is to just
continue
| >> straight south from the traffic circle, and then head to the
parking lot
| >> on the right. They suggest going 3/4 of the way around the circle,
but I
| >> consider it only 1/2 way around. IIRC :)
| >
| 
| Left early, couldn't indulge the extollations of HTML and the
explications of
| PHP.  It had its place, just was expecting some of the things promised
in the
| earlier PM mentions -- "Command line perl tricks\n" and regex stuff
:-)

We should do that next time then!

Yeah... the presentation left a bit to be desired. But it was nice
socializing afterwards.

--Brock

_______________________________________________
Phoenix-pm mailing list
Phoenix-pm at pm.org
http://mail.pm.org/mailman/listinfo/phoenix-pm

From dwchandler at stilyagin.com  Fri Sep  8 06:37:18 2006
From: dwchandler at stilyagin.com (Darrin Chandler)
Date: Fri, 8 Sep 2006 06:37:18 -0700
Subject: [Phoenix-pm] MEETING CHANGE - Thursday September 7th @7:00pm
In-Reply-To: <20060908051359.GT19999@thelackthereof.org>
References: <20060908005609.GL27121@zloy.stilyagin.com>
	<XFMail.20060907212444.pm@upt.org>
	<20060908051359.GT19999@thelackthereof.org>
Message-ID: <20060908133718.GM27121@zloy.stilyagin.com>

On Thu, Sep 07, 2006 at 10:13:59PM -0700, Brock wrote:
> | 
> | Left early, couldn't indulge the extollations of HTML and the explications of
> | PHP.  It had its place, just was expecting some of the things promised in the
> | earlier PM mentions -- "Command line perl tricks\n" and regex stuff :-)
> 
> We should do that next time then!
> 
> Yeah... the presentation left a bit to be desired. But it was nice
> socializing afterwards.

Too bad about the presentation. You'd think the guy would have realized
he was speaking to an audience of actual developers rather than people
interested in gettin started in development. Oh, well.

If anyone had known, there was time to do a 2nd, short presentation. I'd
have enjoyed some command line tricks!

Anyway, I can finally put some faces with the names I see here. :)

-- 
Darrin Chandler            |  Phoenix BSD Users Group
dwchandler at stilyagin.com   |  http://bsd.phoenix.az.us/
http://www.stilyagin.com/  |

From scott at   Sat Sep  9 00:54:42 2006
From: scott at  (Scott Walters)
Date: Sat, 9 Sep 2006 07:54:42 +0000
Subject: [Phoenix-pm] toilet simulator
Message-ID: <20060909075442.GQ21165@straylight>

Passing by the tail -f of my Web access log, I noticed a hit for the toilet simulator
from a Google search.  A friend pointed out that not only did Google score my page
highly, but it was the first hit on Google for toilet simulator.  I wanted to share
my glee.  The toilet simulator I wrote in Perl as part of a Fuzzy Logic presentation
dominates the toilet sim leaderboard!  Of course that glee is offset by the simple
fact that those times that I've urgently needed a toilet, the situation pretty well
constrained that it be a real toilet, but perhaps virtual toilet technology will
some day advance to the point that this distiction be muted.  Research marches on.

Thank you for your time.

-scott


From awwaiid at thelackthereof.org  Mon Sep 11 15:08:39 2006
From: awwaiid at thelackthereof.org (Brock)
Date: Mon, 11 Sep 2006 15:08:39 -0700
Subject: [Phoenix-pm] [Job] Web Developer
Message-ID: <20060911220839.GZ19999@thelackthereof.org>

Greetings,

SWCA Environmental Consultants is looking for an entry-level web
programmer to aid in development and customization of in-house web based
applications. The company itself is growing rapidly, with 19 offices in
10 states. This position is in the Phoenix office. (see swca.com for our
soon-to-be-replaced website)

Here are some skill keywords we are looking for:

    * Web programming
          o PHP and/or Perl
          o HTML/CSS
          o Javascript and DHTML

    * Database programming
          o SQL
          o Report building
          o Knowledge of Oracle a plus

    * General
          o Knowledge of Linux/Unix command line tools a plus
          o Revision control usage a plus

The best candidate for this position will be interested in learning and
exploring new technologies and techniques to best complete tasks. They
will be working directly with our Senior Software Engineer (me!).

Contact me directly if you are interested or want more details. I'll
post a link to the official HR posting when it comes out (and that will
be posted to places like Craig's list, I just wanted to give it a shot
here first).

--Brock
awwaiid at thelackthereof.org


From jdawgaz at cox.net  Tue Sep 12 21:44:58 2006
From: jdawgaz at cox.net (Jerry Davis)
Date: Tue, 12 Sep 2006 21:44:58 -0700
Subject: [Phoenix-pm] perl eval and the No Execute chips
Message-ID: <20060912214458.546a6d39@frodo.home.com>

I was reading an article through /. about Security, and I quote a
little from the article:

"Aitel cited the NX (No eXecute) technology being built into chips from
Intel and Advanced Micro Devices that will effectively prevent code
execution within data pages such as default heaps, stacks and memory
pools."

What if any effect will this new technology have on scripted languages
like perl?

Just wondering here.

Jerry

-- 
Happy Trails!
 
Hobbit Name: Pimpernel Loamsdown
Registered Linux User: 275424
 
Jeep Motto #2: Paved Roads Are a Fine Example of Needless Government
Spending!

From awwaiid at thelackthereof.org  Tue Sep 12 22:32:51 2006
From: awwaiid at thelackthereof.org (Brock)
Date: Tue, 12 Sep 2006 22:32:51 -0700
Subject: [Phoenix-pm] perl eval and the No Execute chips
In-Reply-To: <20060912214458.546a6d39@frodo.home.com>
References: <20060912214458.546a6d39@frodo.home.com>
Message-ID: <20060913053248.GF19999@thelackthereof.org>

Great question! Perl, as it is now, wouldn't be effected at all as far
as I know. Though it makes me wonder about loaded modules...

So here's the trick. If this is a general purpose processor that could
run an OS such as linux, then you have to allow dynamically linked
libraries. If you allow dynamically linked libraries, then you can
effectively change the program at run-time (if nothing else you can
re-compile a changed version of the program, dynamically load it, and
then transfer control).

But that's a bit of a side track. Really, let's expand the question to
this -- How does "eval" work?

I think I smell a meeting topic...

--Brock

On 2006.09.12.21.44, Jerry Davis wrote:
| I was reading an article through /. about Security, and I quote a
| little from the article:
| 
| "Aitel cited the NX (No eXecute) technology being built into chips from
| Intel and Advanced Micro Devices that will effectively prevent code
| execution within data pages such as default heaps, stacks and memory
| pools."
| 
| What if any effect will this new technology have on scripted languages
| like perl?
| 
| Just wondering here.
| 
| Jerry
| 
| -- 
| Happy Trails!
|  
| Hobbit Name: Pimpernel Loamsdown
| Registered Linux User: 275424
|  
| Jeep Motto #2: Paved Roads Are a Fine Example of Needless Government
| Spending!
| _______________________________________________
| Phoenix-pm mailing list
| Phoenix-pm at pm.org
| http://mail.pm.org/mailman/listinfo/phoenix-pm

From andypm at exiledplanet.org  Wed Sep 13 01:09:02 2006
From: andypm at exiledplanet.org (Andrew Johnson)
Date: Wed, 13 Sep 2006 01:09:02 -0700
Subject: [Phoenix-pm] perl eval and the No Execute chips
In-Reply-To: <20060913053248.GF19999@thelackthereof.org>
References: <20060912214458.546a6d39@frodo.home.com>
	<20060913053248.GF19999@thelackthereof.org>
Message-ID: <e0d2adc80609130109q103870a8s98d1202331995ade@mail.gmail.com>

On 9/12/06, Brock <awwaiid at thelackthereof.org> wrote:<snip>


>
> But that's a bit of a side track. Really, let's expand the question to
> this -- How does "eval" work?
>
>

That's easy:  it's MAGIC!!  :-)

[aj]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/phoenix-pm/attachments/20060913/9fd57c22/attachment.html 

From phx-pm-list at grueslayer.com  Wed Sep 13 08:43:54 2006
From: phx-pm-list at grueslayer.com (David A. Sinck)
Date: Wed, 13 Sep 2006 08:43:54 -0700
Subject: [Phoenix-pm] perl eval and the No Execute chips
References: <20060912214458.546a6d39@frodo.home.com>
	<20060913053248.GF19999@thelackthereof.org>
Message-ID: <17672.10042.774198.250003@magnitude.grueslayer.com>



\_ SMTP quoth Brock on 9/12/2006 22:32 as having spake thusly:
\_
\_ But that's a bit of a side track. Really, let's expand the question to
\_ this -- How does "eval" work?

Better yet, when you get a death from captured by an eval eg: 

---------------
#!/usr/bin/perl

use MIME::Lite;

eval q{
      die fladermous /* if keyboard  */
   };

print $@;
--------------
Bareword found where operator expected at (eval 10) line 2, near "* if
keyboard"
        (Missing operator before keyboard?)
Search pattern not terminated at (eval 10) line 2.
--------------

How do you know in your code which eval \d+ it is?  Sure, if it's a
simple script you can count as it's inc'd from one.  But I want to
know which eval is mine in more robust settings (hence the use in the
exapmle). 

The only way I've solved this before was adding a faulty mini eval
immediately prior to the eval I cared about and and parsing $@ from
that and guessing that it should be a single increment to get to the
eval I cared about.

David

From scott at   Wed Sep 13 09:53:28 2006
From: scott at  (Scott Walters)
Date: Wed, 13 Sep 2006 16:53:28 +0000
Subject: [Phoenix-pm] perl eval and the No Execute chips
In-Reply-To: <20060912214458.546a6d39@frodo.home.com>
References: <20060912214458.546a6d39@frodo.home.com>
Message-ID: <20060913165328.GZ21165@straylight>

Of course, the article doesn't mention that other architectures have
had that for years and years.  Slashdot has a bad habit of publishing
every lame press release that gets sent to them, no matter how innane
or physically impossible (I have a list somewhere of the various times they've
published PR releases from pump-and-dump scanm companies claiming to have
invented the single atom transistor, which makes about as much sense
as an atomic canary).

Yes.  Don't use eval.  Higher level langauges, such as Perl, and
really, anything other than C, C++, and B, aren't vulnerable to
buffer overflows (the underlying problem).  Of course, if the language is
implemented in C, the implementation of the language might have a buffer 
overflow, or off by one error on a buffer, or range error, such as
with the recent sprintf exploit for Perl.

Seriously though, you should Google up the old Phrack article, "smashing
the stack for fun and profit".  It's as good as intro into this extremely
prevailent problem that all programmers should understand.

-scott

On  0, Jerry Davis <jdawgaz at cox.net> wrote:
> I was reading an article through /. about Security, and I quote a
> little from the article:
> 
> "Aitel cited the NX (No eXecute) technology being built into chips from
> Intel and Advanced Micro Devices that will effectively prevent code
> execution within data pages such as default heaps, stacks and memory
> pools."
> 
> What if any effect will this new technology have on scripted languages
> like perl?
> 
> Just wondering here.
> 
> Jerry
> 
> -- 
> Happy Trails!
>  
> Hobbit Name: Pimpernel Loamsdown
> Registered Linux User: 275424
>  
> Jeep Motto #2: Paved Roads Are a Fine Example of Needless Government
> Spending!
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm

From scott at   Wed Sep 13 10:05:17 2006
From: scott at  (Scott Walters)
Date: Wed, 13 Sep 2006 17:05:17 +0000
Subject: [Phoenix-pm] perl eval and the No Execute chips
In-Reply-To: <20060913053248.GF19999@thelackthereof.org>
References: <20060912214458.546a6d39@frodo.home.com>
	<20060913053248.GF19999@thelackthereof.org>
Message-ID: <20060913170517.GA21165@straylight>

Brock,

Each page (usually 4k or 8k) of virtual memory (which is partially
contained in real memory) has permission bits on it.  Check out 
my Sys::Mmap for a concrete example -- processes can decide how
the bits are set when they allocate memory.  Memory can be read only,
read/write, and then there's the question of executable.  So it
isn't an all or nothing thing -- the chip supports marking pages
non-executable, that's all.  If you have a memory buffer that contains
some data that a user sent you over the network that you're trying to
process as data, and the data is broken in sneaky ways that causes 
your program to try to branch execution into the middle of it, where
malicious code instead of just malicious data lies, it's to your
advantage to be able to tell the computer to never, under any 
circumstances, execute program code (machine code -- compiled
code, binary, whatever) from that buffer.  So an attempt to return into
it, or branch into it, or otherwise transfer control of execution into
that buffer would fail and be handed to the operating system to deal with.

When ld.so tries to load a shared object, it merely doesn't request the pages 
allocated to hold that shared object be no-execute.  Stack is a bit 
harder.  The stack used to contain "springboards" for signal handles
and other small pieces of code to be executed.  That had to be redesigned and
reimplemented a bit in order to mark the memory allocated for a processes stack
non-executable.  But most buffer overflows are done on data that's on the stack,
because the stack is just brimming with fixed sized buffers, data tends to
be allocated there, it's all in a known and predictable order, etc, etc.

Here's the thing though... Perl isn't compiled to machine code.  Not even if
you use perlcc, which has just been removed from the 5.9.x branch 
(dammit!).  Perl code is just data that tells another program (the perl
interpreter) what to do.  It's unreasonable to consider the possibility
that a chip vender might make a chip that tries to prevent language
interpreters from interpreting data in buffers unless some flag is set on the
memory.  High level languages generally take care of that themselves.  
In the case of Perl, you've got Safe.pm, use ops (my personal favorite --
perldoc ops, and see http://perldesignpatterns.com/?ActiveWikiPages ),
taint, and lots of other great stuff that's far more powerful and high
level.  

-scott

On  0, Brock <awwaiid at thelackthereof.org> wrote:
> Great question! Perl, as it is now, wouldn't be effected at all as far
> as I know. Though it makes me wonder about loaded modules...
> 
> So here's the trick. If this is a general purpose processor that could
> run an OS such as linux, then you have to allow dynamically linked
> libraries. If you allow dynamically linked libraries, then you can
> effectively change the program at run-time (if nothing else you can
> re-compile a changed version of the program, dynamically load it, and
> then transfer control).
> 
> But that's a bit of a side track. Really, let's expand the question to
> this -- How does "eval" work?
> 
> I think I smell a meeting topic...
> 
> --Brock
> 
> On 2006.09.12.21.44, Jerry Davis wrote:
> | I was reading an article through /. about Security, and I quote a
> | little from the article:
> | 
> | "Aitel cited the NX (No eXecute) technology being built into chips from
> | Intel and Advanced Micro Devices that will effectively prevent code
> | execution within data pages such as default heaps, stacks and memory
> | pools."
> | 
> | What if any effect will this new technology have on scripted languages
> | like perl?
> | 
> | Just wondering here.
> | 
> | Jerry
> | 
> | -- 
> | Happy Trails!
> |  
> | Hobbit Name: Pimpernel Loamsdown
> | Registered Linux User: 275424
> |  
> | Jeep Motto #2: Paved Roads Are a Fine Example of Needless Government
> | Spending!
> | _______________________________________________
> | Phoenix-pm mailing list
> | Phoenix-pm at pm.org
> | http://mail.pm.org/mailman/listinfo/phoenix-pm
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm

From scott at   Wed Sep 13 10:37:06 2006
From: scott at  (Scott Walters)
Date: Wed, 13 Sep 2006 17:37:06 +0000
Subject: [Phoenix-pm] perl eval and the No Execute chips
In-Reply-To: <e0d2adc80609130109q103870a8s98d1202331995ade@mail.gmail.com>
References: <20060912214458.546a6d39@frodo.home.com>
	<20060913053248.GF19999@thelackthereof.org>
	<e0d2adc80609130109q103870a8s98d1202331995ade@mail.gmail.com>
Message-ID: <20060913173706.GB21165@straylight>

Stops executing, starts parsing/compiling again, and then executes the
result of that again.  I've said it before and I'll say it again...
95% of the time people eval, they really want a closure instead.

-scott

On  0, Andrew Johnson <andypm at exiledplanet.org> wrote:
> 
>    On 9/12/06, Brock <[1]awwaiid at thelackthereof.org> wrote:
>    
>    <snip>
>    
>    
>      But that's a bit of a side track. Really, let's expand the question
>      to
>      this -- How does "eval" work?
>      
>    That's easy:  it's MAGIC!!  :-)
>    [aj]
> 
> References
> 
>    1. mailto:awwaiid at thelackthereof.org

> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm

From scott at   Wed Sep 13 10:42:39 2006
From: scott at  (Scott Walters)
Date: Wed, 13 Sep 2006 17:42:39 +0000
Subject: [Phoenix-pm] perl eval and the No Execute chips
In-Reply-To: <17672.10042.774198.250003@magnitude.grueslayer.com>
References: <20060912214458.546a6d39@frodo.home.com>
	<20060913053248.GF19999@thelackthereof.org>
	<17672.10042.774198.250003@magnitude.grueslayer.com>
Message-ID: <20060913174239.GC21165@straylight>

Carp is your friend!  Get a stack trace.  Especially helpful if the
error happened while deeply nested in subroutine calls...

#!/usr/bin/perl
 
# use MIME::Lite;
use Carp 'confess';

eval q{
      die fladermous /* if keyboard  */
   };

confess $@ if $@;

On  0, "David A. Sinck" <phx-pm-list at grueslayer.com> wrote:
> 
> 
> \_ SMTP quoth Brock on 9/12/2006 22:32 as having spake thusly:
> \_
> \_ But that's a bit of a side track. Really, let's expand the question to
> \_ this -- How does "eval" work?
> 
> Better yet, when you get a death from captured by an eval eg: 
> 
> ---------------
> #!/usr/bin/perl
> 
> use MIME::Lite;
> 
> eval q{
>       die fladermous /* if keyboard  */
>    };
> 
> print $@;
> --------------
> Bareword found where operator expected at (eval 10) line 2, near "* if
> keyboard"
>         (Missing operator before keyboard?)
> Search pattern not terminated at (eval 10) line 2.
> --------------
> 
> How do you know in your code which eval \d+ it is?  Sure, if it's a
> simple script you can count as it's inc'd from one.  But I want to
> know which eval is mine in more robust settings (hence the use in the
> exapmle). 
> 
> The only way I've solved this before was adding a faulty mini eval
> immediately prior to the eval I cared about and and parsing $@ from
> that and guessing that it should be a single increment to get to the
> eval I cared about.
> 
> David
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm

From jdawgaz at cox.net  Wed Sep 13 17:20:48 2006
From: jdawgaz at cox.net (Jerry Davis)
Date: Wed, 13 Sep 2006 17:20:48 -0700
Subject: [Phoenix-pm] perl eval and the No Execute chips
In-Reply-To: <20060913173706.GB21165@straylight>
References: <20060912214458.546a6d39@frodo.home.com>
	<20060913053248.GF19999@thelackthereof.org>
	<e0d2adc80609130109q103870a8s98d1202331995ade@mail.gmail.com>
	<20060913173706.GB21165@straylight>
Message-ID: <20060913172048.2b101724@frodo.home.com>

On Wed, 13 Sep 2006 17:37:06 +0000
Scott Walters <scott@> wrote:

> Stops executing, starts parsing/compiling again, and then executes the
> result of that again.  I've said it before and I'll say it again...
> 95% of the time people eval, they really want a closure instead.

the reason I asked, is that I do make use of eval, and in what I think
is a legal way.

what I normally do in an eval, is on the command line I pass the name
of a file which is really a short perl script which is really a hash
full of static data.

sort of like:

our %h;

$h{somekey}{somesubkey} = value;
...

I then eval this file, which sets sets up my all my data, and I just
use that data in the program.

Different files hold exactly the same hash but with different values.

This has worked really really well for me, and I was just a little
alarmed over what I saw on /.

Jerry



> 
> -scott
> 
> On  0, Andrew Johnson <andypm at exiledplanet.org> wrote:
> > 
> >    On 9/12/06, Brock <[1]awwaiid at thelackthereof.org> wrote:
> >    
> >    <snip>
> >    
> >    
> >      But that's a bit of a side track. Really, let's expand the
> > question to
> >      this -- How does "eval" work?
> >      
> >    That's easy:  it's MAGIC!!  :-)
> >    [aj]
> > 
> > References
> > 
> >    1. mailto:awwaiid at thelackthereof.org
> 
> > _______________________________________________
> > Phoenix-pm mailing list
> > Phoenix-pm at pm.org
> > http://mail.pm.org/mailman/listinfo/phoenix-pm
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm


-- 
Happy Trails!
 
Hobbit Name: Pimpernel Loamsdown
Registered Linux User: 275424
 
Jeep Motto #2: Paved Roads are a Fine Example of Needless Government
Spending!

From scott at   Wed Sep 13 18:27:49 2006
From: scott at  (Scott Walters)
Date: Thu, 14 Sep 2006 01:27:49 +0000
Subject: [Phoenix-pm] perl eval and the No Execute chips
In-Reply-To: <20060913172048.2b101724@frodo.home.com>
References: <20060912214458.546a6d39@frodo.home.com>
	<20060913053248.GF19999@thelackthereof.org>
	<e0d2adc80609130109q103870a8s98d1202331995ade@mail.gmail.com>
	<20060913173706.GB21165@straylight>
	<20060913172048.2b101724@frodo.home.com>
Message-ID: <20060914012748.GE21165@straylight>

Maybe 99% was a bit dramatic.  As long as you're setting up the config files
and bad people don't have write access to them, you're fine, and that's
a legit use of eval.  Usually I 'require' or 'use' files like that (and put a 
1; on the end of them) rather than 'eval', but there isn't *that* much 
difference (the perldoc for require and use point out the other little helpful
things they do).  And of course bad people shouldn't be able to specify which file 
gets used as the config file without serious restriction on their choice.

-scott

On  0, Jerry Davis <jdawgaz at cox.net> wrote:
> On Wed, 13 Sep 2006 17:37:06 +0000
> Scott Walters <scott@> wrote:
> 
> > Stops executing, starts parsing/compiling again, and then executes the
> > result of that again.  I've said it before and I'll say it again...
> > 95% of the time people eval, they really want a closure instead.
> 
> the reason I asked, is that I do make use of eval, and in what I think
> is a legal way.
> 
> what I normally do in an eval, is on the command line I pass the name
> of a file which is really a short perl script which is really a hash
> full of static data.
> 
> sort of like:
> 
> our %h;
> 
> $h{somekey}{somesubkey} = value;
> ...
> 
> I then eval this file, which sets sets up my all my data, and I just
> use that data in the program.
> 
> Different files hold exactly the same hash but with different values.
> 
> This has worked really really well for me, and I was just a little
> alarmed over what I saw on /.
> 
> Jerry
> 
> 
> 
> > 
> > -scott
> > 
> > On  0, Andrew Johnson <andypm at exiledplanet.org> wrote:
> > > 
> > >    On 9/12/06, Brock <[1]awwaiid at thelackthereof.org> wrote:
> > >    
> > >    <snip>
> > >    
> > >    
> > >      But that's a bit of a side track. Really, let's expand the
> > > question to
> > >      this -- How does "eval" work?
> > >      
> > >    That's easy:  it's MAGIC!!  :-)
> > >    [aj]
> > > 
> > > References
> > > 
> > >    1. mailto:awwaiid at thelackthereof.org
> > 
> > > _______________________________________________
> > > Phoenix-pm mailing list
> > > Phoenix-pm at pm.org
> > > http://mail.pm.org/mailman/listinfo/phoenix-pm
> > _______________________________________________
> > Phoenix-pm mailing list
> > Phoenix-pm at pm.org
> > http://mail.pm.org/mailman/listinfo/phoenix-pm
> 
> 
> -- 
> Happy Trails!
>  
> Hobbit Name: Pimpernel Loamsdown
> Registered Linux User: 275424
>  
> Jeep Motto #2: Paved Roads are a Fine Example of Needless Government
> Spending!
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm

From paulio10 at gmail.com  Thu Sep 14 08:43:01 2006
From: paulio10 at gmail.com (Paul Balyoz)
Date: Thu, 14 Sep 2006 08:43:01 -0700
Subject: [Phoenix-pm] perl eval and the No Execute chips
In-Reply-To: <20060913172048.2b101724@frodo.home.com>
References: <20060912214458.546a6d39@frodo.home.com>
	<20060913053248.GF19999@thelackthereof.org>
	<e0d2adc80609130109q103870a8s98d1202331995ade@mail.gmail.com>
	<20060913173706.GB21165@straylight>
	<20060913172048.2b101724@frodo.home.com>
Message-ID: <bc4ba3be0609140843jdf577ecg103aacce362d2668@mail.gmail.com>

Think about how Perl "runs" any Perl code:

1. it compiles the source code, producing a binary version really really
quickly
     (this implies the executable code is placed somewhere else in memory -
     an executable block, for sure -
     it surely wouldn't be compiled back into the same memory spot where the
source code lives!)

2. execute the binary version that was just compiled.

So I don't think you have anything to worry about.

Besides, if Perl does fail on any future hardware/OS change, you can bet
that the Perl development team would release a patch for that pretty darn
quickly.  We're talkin' Open Source, here, after all.  :)

-- paul


On 9/13/06, Jerry Davis <jdawgaz at cox.net> wrote:
>
> On Wed, 13 Sep 2006 17:37:06 +0000
> Scott Walters <scott@> wrote:
>
> > Stops executing, starts parsing/compiling again, and then executes the
> > result of that again.  I've said it before and I'll say it again...
> > 95% of the time people eval, they really want a closure instead.
>
> the reason I asked, is that I do make use of eval, and in what I think
> is a legal way.
>
> what I normally do in an eval, is on the command line I pass the name
> of a file which is really a short perl script which is really a hash
> full of static data.
>
> sort of like:
>
> our %h;
>
> $h{somekey}{somesubkey} = value;
> ...
>
> I then eval this file, which sets sets up my all my data, and I just
> use that data in the program.
>
> Different files hold exactly the same hash but with different values.
>
> This has worked really really well for me, and I was just a little
> alarmed over what I saw on /.
>
> Jerry


Paul Balyoz
Fastech Learning Center
http://www.FastechLC.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/phoenix-pm/attachments/20060914/51abda97/attachment.html 

From scott at   Thu Sep 14 09:18:24 2006
From: scott at  (Scott Walters)
Date: Thu, 14 Sep 2006 16:18:24 +0000
Subject: [Phoenix-pm] perl eval and the No Execute chips
In-Reply-To: <bc4ba3be0609140843jdf577ecg103aacce362d2668@mail.gmail.com>
References: <20060912214458.546a6d39@frodo.home.com>
	<20060913053248.GF19999@thelackthereof.org>
	<e0d2adc80609130109q103870a8s98d1202331995ade@mail.gmail.com>
	<20060913173706.GB21165@straylight>
	<20060913172048.2b101724@frodo.home.com>
	<bc4ba3be0609140843jdf577ecg103aacce362d2668@mail.gmail.com>
Message-ID: <20060914161823.GF21165@straylight>

Paul,

On  0, Paul Balyoz <paulio10 at gmail.com> wrote:
> 
>    Think about how Perl "runs" any Perl code:
>    
>    1. it compiles the source code, producing a binary version really
>    really quickly

"Binary" implies "machine code", which would be incorrect in this case.
perl compiles Perl to "bytecode", which as far as the computer is concerned,
is just data.  And it is just data, really.  It's meaningless to the
computer itself, but perl understands it.  It's shorthand -- it's still
Perl source code (and can be turned back to sourcecode, minus formatting
and comments).  No-Execute protection on a page keeps the processor from
executing binary machine code in that page; it doesn't keep it from running
other programs (such as perl) that read data in that page and then do things
depending on the data read.  "Compiled" Perl is data, not x86 machine code.

>         (this implies the executable code is placed somewhere else in
>    memory -

"Executable" also has a specific meaning -- "executable by the host
processor".  Perl is not compiled to an executable. 

>         an executable block, for sure -
>    
>         it surely wouldn't be compiled back into the same memory spot
>    where the source code lives!)

What the HELL are you talking about?  

>    2. execute the binary version that was just compiled.

No, interpret, not execute.  

>    So I don't think you have anything to worry about.

You fool!  Don't pass off a weak mistranslation of actual events as a
proof of security.  The more you understand CompSci, the more you
realize security is as fleeting as a cloud formation or a ripple in
a pond -- or a fashion movement.  At no point in history have computers
been actually effectively secured in a way that they remained secure
as technology progressed, yet people insist on talking about things
in terms of "secure" and "not secure".  That's not even adequate for
a manager's understanding.  Intruders do their work by, above all else,
discovering the exact details of how each operation works.  How is
Perl compiled?  What's the bytecode look like?  What's the interpreter
look like?  Following this path, vulnerabilities in perl itself that
lead to remote comprimise can be found -- just as they were recently
found in Flash (which has a similar arrangement) and quite frequently
are found in PHP (ditto).  The worst security strategy is to look at
something, decide (arbitrary) that its "secure", and then not take other
reasonable precautions.  The fact of the matter is that Perl *programs*
are often written horribly insecure because people don't take time to
understand the nature of the various kind sof exploits that Perl 
programs often suffer from and so go on writing them.  They tell 
themselves things like "Linux is secure, Perl is secure, therefore
my site must be secure".  Bruce Schnider famously compared sticking
out one piece of security out there in hopes of protection to "sticking
a stake in the ground hoping the bad guys run into it".  No!  It takes
one bug, one buffer off by one, one timing attack, one lapse in
validation, one of any thousands of sorts of exploits, and your whole
castle crumbles.  The bad guys go around -- and they're extremely
good at doing so.  

>    Besides, if Perl does fail on any future hardware/OS change, you can
>    bet that the Perl development team would release a patch for that
>    pretty darn quickly.  We're talkin' Open Source, here, after all.  :)

This is meaningless... your logic is entirely a mystery here.

Sorry to be so gruff about this -- this is mostly for the benefit of
anyone who might have read your post and been lead astray.  While Perl
is more helpful about security than PHP (offers tools for the programmer
to avoid common problems) and itself has a better security track record,
Perl programmers, all in all, are among the *least* well educated and
as a result, historically, companies trying to use Perl have suffered
horribly at the hands of attackers.  The Perl camp as a whole has a 
wretched security track record.  So if I'm arguing aggressively, it's
because the severity of the problem.  

-scott

>    
>    
>    
>    -- paul
>    
>    
>    On 9/13/06, Jerry Davis <[1]jdawgaz at cox.net> wrote:
>    
>      On Wed, 13 Sep 2006 17:37:06 +0000
>      Scott Walters <scott@> wrote:
>      > Stops executing, starts parsing/compiling again, and then
>      executes the
>      > result of that again.  I've said it before and I'll say it
>      again...
>      > 95% of the time people eval, they really want a closure instead.
>      the reason I asked, is that I do make use of eval, and in what I
>      think
>      is a legal way.
>      what I normally do in an eval, is on the command line I pass the
>      name
>      of a file which is really a short perl script which is really a
>      hash
>      full of static data.
>      sort of like:
>      our %h;
>      $h{somekey}{somesubkey} = value;
>      ...
>      I then eval this file, which sets sets up my all my data, and I
>      just
>      use that data in the program.
>      Different files hold exactly the same hash but with different
>      values.
>      This has worked really really well for me, and I was just a little
>      alarmed over what I saw on /.
>      Jerry
>      
>     Paul BalyozFastech Learning Center[2]http://www.FastechLC.com/
> 
> References
> 
>    1. mailto:jdawgaz at cox.net
>    2. http://www.FastechLC.com/

> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm

From bwmetz at att.com  Thu Sep 14 09:47:27 2006
From: bwmetz at att.com (Metz, Bobby W, WWCS)
Date: Thu, 14 Sep 2006 11:47:27 -0500
Subject: [Phoenix-pm] perl eval and the No Execute chips
In-Reply-To: <20060914012748.GE21165@straylight>
Message-ID: <01D5341D04A2E64AB9B34576904733670273954D@OCCLUST01EVS1.ugd.att.com>

	Using eval to load static hashes...interesting, never done that
before.  It would be interesting to compare the load speed of that
method vs. the others.  I know in my own testing I've found that writing
a sub to handle hash population from a data file runs faster and takes
up less memory than when using a pre-built hash syntax using "use" or
"require".  Granted the hashes were fairly simple ones but does that
really matter?  Anyone else ever noticed similar speed/memory results?

Bobby

-----Original Message-----
From: phoenix-pm-bounces+bwmetz=att.com at pm.org
[mailto:phoenix-pm-bounces+bwmetz=att.com at pm.org]
Sent: Wednesday, September 13, 2006 6:28 PM
To: Jerry Davis
Cc: phoenix-pm at pm.org
Subject: Re: [Phoenix-pm] perl eval and the No Execute chips


Maybe 99% was a bit dramatic.  As long as you're setting up the config
files
and bad people don't have write access to them, you're fine, and that's
a legit use of eval.  Usually I 'require' or 'use' files like that (and
put a 
1; on the end of them) rather than 'eval', but there isn't *that* much 
difference (the perldoc for require and use point out the other little
helpful
things they do).  And of course bad people shouldn't be able to specify
which file 
gets used as the config file without serious restriction on their
choice.

-scott

On  0, Jerry Davis <jdawgaz at cox.net> wrote:
> On Wed, 13 Sep 2006 17:37:06 +0000
> Scott Walters <scott@> wrote:
> 
> > Stops executing, starts parsing/compiling again, and then executes
the
> > result of that again.  I've said it before and I'll say it again...
> > 95% of the time people eval, they really want a closure instead.
> 
> the reason I asked, is that I do make use of eval, and in what I think
> is a legal way.
> 
> what I normally do in an eval, is on the command line I pass the name
> of a file which is really a short perl script which is really a hash
> full of static data.
> 
> sort of like:
> 
> our %h;
> 
> $h{somekey}{somesubkey} = value;
> ...
> 
> I then eval this file, which sets sets up my all my data, and I just
> use that data in the program.
> 
> Different files hold exactly the same hash but with different values.
> 
> This has worked really really well for me, and I was just a little
> alarmed over what I saw on /.
> 
> Jerry
> 
> 
> 
> > 
> > -scott
> > 
> > On  0, Andrew Johnson <andypm at exiledplanet.org> wrote:
> > > 
> > >    On 9/12/06, Brock <[1]awwaiid at thelackthereof.org> wrote:
> > >    
> > >    <snip>
> > >    
> > >    
> > >      But that's a bit of a side track. Really, let's expand the
> > > question to
> > >      this -- How does "eval" work?
> > >      
> > >    That's easy:  it's MAGIC!!  :-)
> > >    [aj]
> > > 
> > > References
> > > 
> > >    1. mailto:awwaiid at thelackthereof.org
> > 
> > > _______________________________________________
> > > Phoenix-pm mailing list
> > > Phoenix-pm at pm.org
> > > http://mail.pm.org/mailman/listinfo/phoenix-pm
> > _______________________________________________
> > Phoenix-pm mailing list
> > Phoenix-pm at pm.org
> > http://mail.pm.org/mailman/listinfo/phoenix-pm
> 
> 
> -- 
> Happy Trails!
>  
> Hobbit Name: Pimpernel Loamsdown
> Registered Linux User: 275424
>  
> Jeep Motto #2: Paved Roads are a Fine Example of Needless Government
> Spending!
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm
_______________________________________________
Phoenix-pm mailing list
Phoenix-pm at pm.org
http://mail.pm.org/mailman/listinfo/phoenix-pm

From paulio10 at gmail.com  Thu Sep 14 10:08:25 2006
From: paulio10 at gmail.com (Paul Balyoz)
Date: Thu, 14 Sep 2006 10:08:25 -0700
Subject: [Phoenix-pm] perl eval and the No Execute chips
In-Reply-To: <20060914161823.GF21165@straylight>
References: <20060912214458.546a6d39@frodo.home.com>
	<20060913053248.GF19999@thelackthereof.org>
	<e0d2adc80609130109q103870a8s98d1202331995ade@mail.gmail.com>
	<20060913173706.GB21165@straylight>
	<20060913172048.2b101724@frodo.home.com>
	<bc4ba3be0609140843jdf577ecg103aacce362d2668@mail.gmail.com>
	<20060914161823.GF21165@straylight>
Message-ID: <bc4ba3be0609141008qce40dcdl4e6d6ff1ab2e1d61@mail.gmail.com>

On 9/14/06, Scott Walters <scott@> wrote:
> >    1. it compiles the source code, producing a binary version really
> >    really quickly
>
> "Binary" implies "machine code", which would be incorrect in this case.
> perl compiles Perl to "bytecode", which as far as the computer is concerned,
> is just data.  And it is just data, really.  It's meaningless to the
> computer itself, but perl understands it.  It's shorthand -- it's still
> Perl source code (and can be turned back to sourcecode, minus formatting
> and comments).  No-Execute protection on a page keeps the processor from
> executing binary machine code in that page; it doesn't keep it from running
> other programs (such as perl) that read data in that page and then do things
> depending on the data read.

This was a misunderstanding on my part - thank you for the
clarification.  Perl does in fact generate byte-code, not pure
executable machine code.  My bad.

> You fool!  Don't pass off a weak mistranslation of actual events as a
> proof of security.  The more you understand CompSci, the more you
> realize security is as fleeting as a cloud formation or a ripple in
> a pond -- or a fashion movement. ...

Can you find a polite way to respond to people?  I mean really, we're
a community here.  We can all learn from each other.  Be nice.

> ...At no point in history have computers
> been actually effectively secured in a way that they remained secure
> as technology progressed, yet people insist on talking about things
> in terms of "secure" and "not secure".  That's not even adequate for
> a manager's understanding.  Intruders do their work by...<long soliloqy on security>

Oh good, you understand two basic tenets of computer security:
"there is no absolute security.  there can only be more security, or
less security."
And, "all security can be defeated, it's just a matter of time."

With that said, I'd like to suggest that it sounded to me that people
were worried their exec() code was going to fail, not be "insecure".
I don't see how a No Execute flag could cause exec's to be less
secure, only that their existing perl code might fail (which is not
true, as you know).

The point of my post suggested that they don't need to worry about
code-breakage due to the use of exec(), with a No Execute flag set on
each data memory page.

Yes, there are safe and unsafe ways of exec'ing code -- in any
language.  That is a different discussion, which has been discussed
extensively on the Internet for the last 15 or so years.

-- paul

Paul Balyoz
Fastech Learning Center
http://www.fastechlc.com/

From Luke.Lackrone at gdc4s.com  Mon Sep 25 12:47:04 2006
From: Luke.Lackrone at gdc4s.com (Lackrone, Luke-P56802)
Date: Mon, 25 Sep 2006 12:47:04 -0700
Subject: [Phoenix-pm] New classrooms available to reserve in Tempe
Message-ID: <C7FCC5C93630AB4E80049ED163FFD224020CF4FC@AZ25EXM04.gddsi.com>

All,

I spotted this today:  the new North Tempe Multigenerational Center
http://www.tempe.gov/northtempe/
http://www.tempe.gov/northtempe/classrooms.htm

I know people on the list are sometimes looking for classroom
environments to reserve for meetings. 

The rooms here hold 20 people, 40 if you book two rooms and put 'em
together.  They appear to have screens, hopefully projectors, too.  Not
sure about Internet, but the facility has a computer lab w/ Internet, so
likelihood of getting it in the classroom is not bad.

Reserving them appears to be free.

Anyway, just passing on the find in case it's useful for the group or an
individual.
Luke Lackrone General Dynamics C4 Systems 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/phoenix-pm/attachments/20060925/4b11e9bb/attachment.html 

From scott at slowass.net  Fri Sep 29 12:44:56 2006
From: scott at slowass.net (Scott Walters)
Date: Fri, 29 Sep 2006 19:44:56 +0000
Subject: [Phoenix-pm] Fwd: [perl #40427] Segfault in pack
Message-ID: <20060929194456.GZ21165@straylight>


----- Forwarded message from "dgay at acm.org" <perlbug-followup at perl.org> -----

Return-Path: perl5-porters-return-116718-scott=slowass.net at perl.org
X-Original-To: scott
Delivered-To: scott at illogics.org
Received: by slowass.net (Postfix, from userid 1012)
	id D0CDC553AC; Fri, 29 Sep 2006 01:23:31 +0000 (GMT)
Received: from gmail-pop.l.google.com [66.249.83.109]
	by localhost with POP3 (fetchmail-6.2.5)
	for scott at localhost (single-drop); Fri, 29 Sep 2006 01:23:31 +0000 (GMT)
X-Gmail-Received: 55b8e566b0521769dbde980e1349a8942d7e19a4
Delivered-To: scott at slowass.net
Received: by 10.78.153.13 with SMTP id a13cs108hue;
        Thu, 28 Sep 2006 18:12:04 -0700 (PDT)
Received: by 10.65.156.10 with SMTP id i10mr2812474qbo;
        Thu, 28 Sep 2006 18:12:03 -0700 (PDT)
Received: from lists.develooper.com (x6.develooper.com [63.251.223.186])
        by mx.gmail.com with SMTP id e16si2775000qba.2006.09.28.18.12.02;
        Thu, 28 Sep 2006 18:12:03 -0700 (PDT)
Received-SPF: pass (gmail.com: domain of perl5-porters-return-116718-scott=slowass.net at perl.org designates 63.251.223.186 as permitted sender)
Received: (qmail 4966 invoked by uid 514); 29 Sep 2006 01:11:51 -0000
Mailing-List: contact perl5-porters-help at perl.org; run by ezmlm
Precedence: bulk
list-help: <mailto:perl5-porters-help at perl.org>
list-unsubscribe: <mailto:perl5-porters-unsubscribe at perl.org>
list-post: <mailto:perl5-porters at perl.org>
X-List-Archive: <http://nntp.perl.org/group/perl.perl5.porters/116718>
List-Id: <perl5-porters.perl.org>
Delivered-To: mailing list perl5-porters at perl.org
Delivered-To: moderator for perl5-porters at perl.org
Received: (qmail 17664 invoked from network); 29 Sep 2006 00:31:10 -0000
Delivered-To: perl5-porters at perl.org
X-Spam-Status: No, hits=-8.4 required=8.0
	tests=ALL_TRUSTED,BAYES_00,PERLBUG_CONF
X-Spam-Check-By: la.mx.develooper.com
Received-SPF: pass (x1.develooper.com: local policy)
Delivered-To: rt-perl5-testers at x1.develooper.com
Mail-From: perlbug-followup at perl.org  Thu Sep 28 17:31:00 2006
Delivered-To: bugs-perl5-testers at netlabs.develooper.com
Received-SPF: pass (x1.develooper.com: local policy)
Received-SPF: pass (x1.develooper.com: local policy)
From: "dgay at acm.org" <perlbug-followup at perl.org>
X-RT-NewTicket: yes
To: bugs-bitbucket at rt.perl.org
Mail-Followup-To: perl5-porters at perl.org
Reply-To: perl5-porters at perl.org
X-RT-Will-Also-CC: dgay at acm.org, 
Subject: [perl #40427] Segfault in pack 
In-Reply-To: <5.8.5_5308_1159489400 at barnowl>
References: <RT-Ticket-40427 at perl.org> <5.8.5_5308_1159489400 at barnowl>
Message-ID: <rt-3.5.HEAD-31259-1159489837-428.40427-75-0 at perl.org>
X-RT-Loop-Prevention: perl
RT-Ticket: perl #40427
Managed-by: RT 3.5.HEAD (http://www.bestpractical.com/rt/)
RT-Originator: dgay at acm.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-RT-Original-Encoding: utf-8
Date: Thu, 28 Sep 2006 17:30:37 -0700
X-Virus-Checked: Checked
X-Virus-Checked: Checked
X-Old-Spam-Check-By: la.mx.develooper.com
X-Old-Spam-Status: No, hits=-8.4 required=8.0
	tests=ALL_TRUSTED,BAYES_00,PERLBUG_CONF
Resent-To: perl5-porters at perl.org
X-Virus-Checked: Checked
X-Old-Spam-Check-By: la.mx.develooper.com
X-Old-Spam-Status: No, hits=-8.4 required=8.0
	tests=ALL_TRUSTED,BAYES_00,PERLBUG_CONF
Resent-Message-Id: <20060929012331.D0CDC553AC at slowass.net>
Resent-Date: Fri, 29 Sep 2006 01:23:31 +0000 (GMT)
Resent-From: perl5-porters-return-116718-scott=slowass.net at perl.org (Scott Walters)

# New Ticket Created by  dgay at acm.org 
# Please include the string:  [perl #40427]
# in the subject line of all future correspondence about this issue. 
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40427 >



This is a bug report for perl from dgay at acm.org,
generated with the help of perlbug 1.35 running under perl v5.8.5.


-----------------------------------------------------------------
[Please enter your report here]

The following program will cause a segfault on perl 5.8.5 and 5.9.4:
  @l = ("aa", "bb");
  $fun = pack "(A)30 N4", @l;
  print "$fun\n";

The following patch (for, and tested on, 5.9.4) fixes this:
--- pp_pack.c	2006-09-28 17:21:31.000000000 -0700
+++ pp_pack.c.new 2006-09-28 16:56:14.000000000 -0700
@@ -2630,6 +2630,7 @@
 		if (savsym.howlen == e_star && beglist == endlist)
 		    break;		/* No way to continue */
 	    }
+	    items = endlist - beglist;
 	    lookahead.flags  = symptr->flags & ~group_modifiers;
 	    goto no_change;
 	}

The problem is that the items consumed by the recursive pack are
not counted in the outer pack, so accesses to random parts of the
stack beyond the top are possible. The fix simply updates the
items local variable after the recursive packs ("make test" reports
no failures).

[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
    category=core
    severity=high
---
This perlbug was built using Perl v5.8.5 in the Red Hat build system.
It is being executed now by Perl v5.8.5 - Fri Dec 16 14:48:17 EST 2005.

Site configuration information for perl v5.8.5:

Configured by Red Hat, Inc. at Fri Dec 16 14:48:17 EST 2005.

Summary of my perl5 (revision 5 version 8 subversion 5) configuration:
  Platform:
    osname=linux, osvers=2.6.9-1.906_elsmp, archname=i386-linux-thread-multi
    uname='linux tweety.build.redhat.com 2.6.9-1.906_elsmp #1 smp sun dec 12 22:58:08 est 2004 i686 i686 i386 gnulinux '
    config_args='-des -Doptimize=-O2 -g -pipe -m32 -march=i386 -mtune=pentium4 -Dversion=5.8.5 -Dmyhostname=localhost -Dperladmin=root at localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dinc_version_list=5.8.4 5.8.3 5.8.2 5.8.1 5.8.0'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
    optimize='-O2 -g -pipe -m32 -march=i386 -mtune=pentium4',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -I/usr/include/gdbm'
    ccversion='', gccversion='3.4.4 20050721 (Red Hat 3.4.4-2)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=/lib/libc-2.3.6.so, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.3.6'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    

---
@INC for perl v5.8.5:
    /usr/lib/perl5/5.8.5/i386-linux-thread-multi
    /usr/lib/perl5/5.8.5
    /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.2/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.5
    /usr/lib/perl5/site_perl/5.8.4
    /usr/lib/perl5/site_perl/5.8.3
    /usr/lib/perl5/site_perl/5.8.2
    /usr/lib/perl5/site_perl/5.8.1
    /usr/lib/perl5/site_perl/5.8.0
    /usr/lib/perl5/site_perl
    /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.2/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.5
    /usr/lib/perl5/vendor_perl/5.8.4
    /usr/lib/perl5/vendor_perl/5.8.3
    /usr/lib/perl5/vendor_perl/5.8.2
    /usr/lib/perl5/vendor_perl/5.8.1
    /usr/lib/perl5/vendor_perl/5.8.0
    /usr/lib/perl5/vendor_perl
    .

---
Environment for perl v5.8.5:
    HOME=/home/dgay
    LANG=en_US
    LANGUAGE (unset)
    LC_COLLATE=C
    LD_LIBRARY_PATH=:/opt/msp430/lib:/opt/msp430/lib
    LOGDIR (unset)
    PATH=/home/dgay/work/ivy/cil/bin:/home/dgay/bin:/opt/IBMJava2/bin:/opt/msp430/bin:/home/dgay/work/ivy/cil/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/opt/msp430/bin:/usr/sbin:/sbin:/opt/msp430/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

----- End forwarded message -----

From scott at slowass.net  Fri Sep 29 12:53:02 2006
From: scott at slowass.net (Scott Walters)
Date: Fri, 29 Sep 2006 19:53:02 +0000
Subject: [Phoenix-pm] Fwd: [perl #40427] Segfault in pack
In-Reply-To: <20060929194456.GZ21165@straylight>
References: <20060929194456.GZ21165@straylight>
Message-ID: <20060929195302.GA21165@straylight>

Oh, didn't catch it in time, but that's an older 5.8.x branch.  Sorry...

-scott

On  0, Scott Walters <scott at slowass.net> wrote:
> 
> ----- Forwarded message from "dgay at acm.org" <perlbug-followup at perl.org> -----
> 
> Return-Path: perl5-porters-return-116718-scott=slowass.net at perl.org
> X-Original-To: scott
> Delivered-To: scott at illogics.org
> Received: by slowass.net (Postfix, from userid 1012)
> 	id D0CDC553AC; Fri, 29 Sep 2006 01:23:31 +0000 (GMT)
> Received: from gmail-pop.l.google.com [66.249.83.109]
> 	by localhost with POP3 (fetchmail-6.2.5)
> 	for scott at localhost (single-drop); Fri, 29 Sep 2006 01:23:31 +0000 (GMT)
> X-Gmail-Received: 55b8e566b0521769dbde980e1349a8942d7e19a4
> Delivered-To: scott at slowass.net
> Received: by 10.78.153.13 with SMTP id a13cs108hue;
>         Thu, 28 Sep 2006 18:12:04 -0700 (PDT)
> Received: by 10.65.156.10 with SMTP id i10mr2812474qbo;
>         Thu, 28 Sep 2006 18:12:03 -0700 (PDT)
> Received: from lists.develooper.com (x6.develooper.com [63.251.223.186])
>         by mx.gmail.com with SMTP id e16si2775000qba.2006.09.28.18.12.02;
>         Thu, 28 Sep 2006 18:12:03 -0700 (PDT)
> Received-SPF: pass (gmail.com: domain of perl5-porters-return-116718-scott=slowass.net at perl.org designates 63.251.223.186 as permitted sender)
> Received: (qmail 4966 invoked by uid 514); 29 Sep 2006 01:11:51 -0000
> Mailing-List: contact perl5-porters-help at perl.org; run by ezmlm
> Precedence: bulk
> list-help: <mailto:perl5-porters-help at perl.org>
> list-unsubscribe: <mailto:perl5-porters-unsubscribe at perl.org>
> list-post: <mailto:perl5-porters at perl.org>
> X-List-Archive: <http://nntp.perl.org/group/perl.perl5.porters/116718>
> List-Id: <perl5-porters.perl.org>
> Delivered-To: mailing list perl5-porters at perl.org
> Delivered-To: moderator for perl5-porters at perl.org
> Received: (qmail 17664 invoked from network); 29 Sep 2006 00:31:10 -0000
> Delivered-To: perl5-porters at perl.org
> X-Spam-Status: No, hits=-8.4 required=8.0
> 	tests=ALL_TRUSTED,BAYES_00,PERLBUG_CONF
> X-Spam-Check-By: la.mx.develooper.com
> Received-SPF: pass (x1.develooper.com: local policy)
> Delivered-To: rt-perl5-testers at x1.develooper.com
> Mail-From: perlbug-followup at perl.org  Thu Sep 28 17:31:00 2006
> Delivered-To: bugs-perl5-testers at netlabs.develooper.com
> Received-SPF: pass (x1.develooper.com: local policy)
> Received-SPF: pass (x1.develooper.com: local policy)
> From: "dgay at acm.org" <perlbug-followup at perl.org>
> X-RT-NewTicket: yes
> To: bugs-bitbucket at rt.perl.org
> Mail-Followup-To: perl5-porters at perl.org
> Reply-To: perl5-porters at perl.org
> X-RT-Will-Also-CC: dgay at acm.org, 
> Subject: [perl #40427] Segfault in pack 
> In-Reply-To: <5.8.5_5308_1159489400 at barnowl>
> References: <RT-Ticket-40427 at perl.org> <5.8.5_5308_1159489400 at barnowl>
> Message-ID: <rt-3.5.HEAD-31259-1159489837-428.40427-75-0 at perl.org>
> X-RT-Loop-Prevention: perl
> RT-Ticket: perl #40427
> Managed-by: RT 3.5.HEAD (http://www.bestpractical.com/rt/)
> RT-Originator: dgay at acm.org
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
> X-RT-Original-Encoding: utf-8
> Date: Thu, 28 Sep 2006 17:30:37 -0700
> X-Virus-Checked: Checked
> X-Virus-Checked: Checked
> X-Old-Spam-Check-By: la.mx.develooper.com
> X-Old-Spam-Status: No, hits=-8.4 required=8.0
> 	tests=ALL_TRUSTED,BAYES_00,PERLBUG_CONF
> Resent-To: perl5-porters at perl.org
> X-Virus-Checked: Checked
> X-Old-Spam-Check-By: la.mx.develooper.com
> X-Old-Spam-Status: No, hits=-8.4 required=8.0
> 	tests=ALL_TRUSTED,BAYES_00,PERLBUG_CONF
> Resent-Message-Id: <20060929012331.D0CDC553AC at slowass.net>
> Resent-Date: Fri, 29 Sep 2006 01:23:31 +0000 (GMT)
> Resent-From: perl5-porters-return-116718-scott=slowass.net at perl.org (Scott Walters)
> 
> # New Ticket Created by  dgay at acm.org 
> # Please include the string:  [perl #40427]
> # in the subject line of all future correspondence about this issue. 
> # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40427 >
> 
> 
> 
> This is a bug report for perl from dgay at acm.org,
> generated with the help of perlbug 1.35 running under perl v5.8.5.
> 
> 
> -----------------------------------------------------------------
> [Please enter your report here]
> 
> The following program will cause a segfault on perl 5.8.5 and 5.9.4:
>   @l = ("aa", "bb");
>   $fun = pack "(A)30 N4", @l;
>   print "$fun\n";
> 
> The following patch (for, and tested on, 5.9.4) fixes this:
> --- pp_pack.c	2006-09-28 17:21:31.000000000 -0700
> +++ pp_pack.c.new 2006-09-28 16:56:14.000000000 -0700
> @@ -2630,6 +2630,7 @@
>  		if (savsym.howlen == e_star && beglist == endlist)
>  		    break;		/* No way to continue */
>  	    }
> +	    items = endlist - beglist;
>  	    lookahead.flags  = symptr->flags & ~group_modifiers;
>  	    goto no_change;
>  	}
> 
> The problem is that the items consumed by the recursive pack are
> not counted in the outer pack, so accesses to random parts of the
> stack beyond the top are possible. The fix simply updates the
> items local variable after the recursive packs ("make test" reports
> no failures).
> 
> [Please do not change anything below this line]
> -----------------------------------------------------------------
> ---
> Flags:
>     category=core
>     severity=high
> ---
> This perlbug was built using Perl v5.8.5 in the Red Hat build system.
> It is being executed now by Perl v5.8.5 - Fri Dec 16 14:48:17 EST 2005.
> 
> Site configuration information for perl v5.8.5:
> 
> Configured by Red Hat, Inc. at Fri Dec 16 14:48:17 EST 2005.
> 
> Summary of my perl5 (revision 5 version 8 subversion 5) configuration:
>   Platform:
>     osname=linux, osvers=2.6.9-1.906_elsmp, archname=i386-linux-thread-multi
>     uname='linux tweety.build.redhat.com 2.6.9-1.906_elsmp #1 smp sun dec 12 22:58:08 est 2004 i686 i686 i386 gnulinux '
>     config_args='-des -Doptimize=-O2 -g -pipe -m32 -march=i386 -mtune=pentium4 -Dversion=5.8.5 -Dmyhostname=localhost -Dperladmin=root at localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dinc_version_list=5.8.4 5.8.3 5.8.2 5.8.1 5.8.0'
>     hint=recommended, useposix=true, d_sigaction=define
>     usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
>     useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
>     use64bitint=undef use64bitall=undef uselongdouble=undef
>     usemymalloc=n, bincompat5005=undef
>   Compiler:
>     cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
>     optimize='-O2 -g -pipe -m32 -march=i386 -mtune=pentium4',
>     cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -I/usr/include/gdbm'
>     ccversion='', gccversion='3.4.4 20050721 (Red Hat 3.4.4-2)', gccosandvers=''
>     intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
>     d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
>     ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
>     alignbytes=4, prototype=define
>   Linker and Libraries:
>     ld='gcc', ldflags =' -L/usr/local/lib'
>     libpth=/usr/local/lib /lib /usr/lib
>     libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
>     perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
>     libc=/lib/libc-2.3.6.so, so=so, useshrplib=true, libperl=libperl.so
>     gnulibc_version='2.3.6'
>   Dynamic Linking:
>     dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE'
>     cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
> 
> Locally applied patches:
>     
> 
> ---
> @INC for perl v5.8.5:
>     /usr/lib/perl5/5.8.5/i386-linux-thread-multi
>     /usr/lib/perl5/5.8.5
>     /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
>     /usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi
>     /usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi
>     /usr/lib/perl5/site_perl/5.8.2/i386-linux-thread-multi
>     /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi
>     /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
>     /usr/lib/perl5/site_perl/5.8.5
>     /usr/lib/perl5/site_perl/5.8.4
>     /usr/lib/perl5/site_perl/5.8.3
>     /usr/lib/perl5/site_perl/5.8.2
>     /usr/lib/perl5/site_perl/5.8.1
>     /usr/lib/perl5/site_perl/5.8.0
>     /usr/lib/perl5/site_perl
>     /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
>     /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi
>     /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
>     /usr/lib/perl5/vendor_perl/5.8.2/i386-linux-thread-multi
>     /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi
>     /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
>     /usr/lib/perl5/vendor_perl/5.8.5
>     /usr/lib/perl5/vendor_perl/5.8.4
>     /usr/lib/perl5/vendor_perl/5.8.3
>     /usr/lib/perl5/vendor_perl/5.8.2
>     /usr/lib/perl5/vendor_perl/5.8.1
>     /usr/lib/perl5/vendor_perl/5.8.0
>     /usr/lib/perl5/vendor_perl
>     .
> 
> ---
> Environment for perl v5.8.5:
>     HOME=/home/dgay
>     LANG=en_US
>     LANGUAGE (unset)
>     LC_COLLATE=C
>     LD_LIBRARY_PATH=:/opt/msp430/lib:/opt/msp430/lib
>     LOGDIR (unset)
>     PATH=/home/dgay/work/ivy/cil/bin:/home/dgay/bin:/opt/IBMJava2/bin:/opt/msp430/bin:/home/dgay/work/ivy/cil/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/opt/msp430/bin:/usr/sbin:/sbin:/opt/msp430/bin
>     PERL_BADLANG (unset)
>     SHELL=/bin/bash
> 
> ----- End forwarded message -----
> _______________________________________________
> Phoenix-pm mailing list
> Phoenix-pm at pm.org
> http://mail.pm.org/mailman/listinfo/phoenix-pm

From dwchandler at stilyagin.com  Sat Sep 30 10:31:37 2006
From: dwchandler at stilyagin.com (Darrin Chandler)
Date: Sat, 30 Sep 2006 10:31:37 -0700
Subject: [Phoenix-pm] October PhxBUG Meeting - Tuesday October 3rd
Message-ID: <20060930173137.GE22490@zloy.stilyagin.com>

The October meeting of the Phoenix BSD Users Group will be held this
coming Tuesday the 3rd 7:30pm at ASU Bateman Physical Sciences
building Room 566. Free parking is available after 7pm at PS2. See
directions and maps at http://bsd.phoenix.az.us/node/70

This month's presentation by Darren Spruell will be "More About PF,"
revisiting and extending our use of packet filtering, NAT, and
redirection using OpenBSD's PF, which has been ported and included in
the base distributions of at least FreeBSD and NetBSD. Darren has posted
an outline of the presentation at
http://bsd.phoenix.az.us/presentations/pf_part_2

Feel free to bring a network capable laptop so we can see the rules in
action live with actual network clients.

-- 
Darrin Chandler            |  Phoenix BSD Users Group
dwchandler at stilyagin.com   |  http://bsd.phoenix.az.us/
http://www.stilyagin.com/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.pm.org/pipermail/phoenix-pm/attachments/20060930/7316a2e4/attachment.bin