cvs commit: modperl-2.0 Changes
stas2002/12/20 18:26:02
Modified:src/modules/perl modperl_cmd.c
.Changes
Log:
revert the last change, the file/linenumber of the error are already
reported by httpd
Revision ChangesPath
1.36 +2 -5 modperl-2.0/src/modules/perl/modperl_cmd.c
Index: modperl_cmd.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- modperl_cmd.c 20 Dec 2002 07:23:00 - 1.35
+++ modperl_cmd.c 21 Dec 2002 02:26:02 - 1.36
@@ -8,11 +8,8 @@
static char *modperl_cmd_too_late(cmd_parms *parms)
{
-return apr_psprintf(parms-pool,
-mod_perl is already running, too late for %s (%s:%d),
-parms-cmd-name,
-parms-directive-filename,
-parms-directive-line_num);
+return apr_pstrcat(parms-pool, mod_perl is already running,
+ too late for , parms-cmd-name, NULL);
}
char *modperl_cmd_push_handlers(MpAV **handlers, const char *name,
1.87 +0 -3 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.86
retrieving revision 1.87
diff -u -r1.86 -r1.87
--- Changes 20 Dec 2002 07:23:00 - 1.86
+++ Changes 21 Dec 2002 02:26:02 - 1.87
@@ -10,9 +10,6 @@
=item 1.99_08-dev
-when reporting too late for something, print the config file and the
-line number [Stas]
-
fix $r-read to read all the requested amount of data if possible,
adjust the test TestApache::read to verify that [Stas]
cvs commit: modperl-2.0 Changes
stas2002/12/20 19:46:07 Modified:src/modules/perl modperl_cmd.c .Changes Log: under non-threaded perl need to check whether mod_perl is running, when modperl_vhost_is_running check is done. Revision ChangesPath 1.37 +1 -1 modperl-2.0/src/modules/perl/modperl_cmd.c Index: modperl_cmd.c === RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- modperl_cmd.c 21 Dec 2002 02:26:02 - 1.36 +++ modperl_cmd.c 21 Dec 2002 03:46:07 - 1.37 @@ -61,7 +61,7 @@ return FALSE; } #else -return TRUE; +return modperl_is_running(); #endif } 1.88 +3 -0 modperl-2.0/Changes Index: Changes === RCS file: /home/cvs/modperl-2.0/Changes,v retrieving revision 1.87 retrieving revision 1.88 diff -u -r1.87 -r1.88 --- Changes 21 Dec 2002 02:26:02 - 1.87 +++ Changes 21 Dec 2002 03:46:07 - 1.88 @@ -10,6 +10,9 @@ =item 1.99_08-dev +under non-threaded perl need to check whether mod_perl is running, +when modperl_vhost_is_running check is done. [Stas] + fix $r-read to read all the requested amount of data if possible, adjust the test TestApache::read to verify that [Stas]
cvs commit: modperl-2.0/t/directive perlloadmodule3.t
stas2002/12/20 19:47:18
Modified:t/directive perlloadmodule3.t
Log:
1st subtest fails when lwp is not installed, need to investigate, make it
TODO for now
Revision ChangesPath
1.2 +2 -1 modperl-2.0/t/directive/perlloadmodule3.t
Index: perlloadmodule3.t
===
RCS file: /home/cvs/modperl-2.0/t/directive/perlloadmodule3.t,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- perlloadmodule3.t 12 Dec 2002 10:13:56 - 1.1
+++ perlloadmodule3.t 21 Dec 2002 03:47:18 - 1.2
@@ -16,7 +16,8 @@
# smaller portions of information, but requires a more elaborated
# logic.
-plan tests = 3;
+# XXX: this subtest fails when lwp is not installed, need to investigate
+plan tests = 3, todo = [1];
t_debug(connecting to $base_hostport);
{
Fw: OT - Santa uses PERL
Title: OT - Santa uses PERL This came yesterday on the httpd-users list, and I haven't seen it on the mod_perl list yet (apologies if I just happened to not notice it). I thought that people might enjoy it. I'm sure one or two of you will want to flame me for it so I'd ask those people to do it off-list to avoid *really* unnecessary traffic :-) http://www.perl.com/pub/a/2002/12/18/hohoho.html Happy Holidays to all, Issac
mod_perl 2 and problems w/ ErrorDocument Directive
I have a script that provides custom error messages that I set up using the ErrorDocument directive (ie; ErrorDocument 400 /cgi-global/error.pl?error=400useXML=1). When run under typical mod_cgi all works as planned and it outputs the proper stuff. When run under mod_perl it outputs the same but then appends the default ErrorDocument (ie; ErrorDocument 500 /error/HTTP_INTERNAL_SERVER_ERROR.html.var) output on the end so I have effectively two HTML docs on the output page. The odd part of this issue is this. When it is a 404 error The stock error doc says that Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request which makes no sense since the only log entry is File does not exist: /var/www/terradev/docs/bad-link. When you use the 500.pl example below you get Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request. despite the fact that the custom error script did work and output what it was supposed to and the error logs confirm that. The setup is plain vanilla on RH 8 and httpd2. The latest patch level of everything RH8 basically. The config of the cgi-global is: Location /cgi-global SetHandler perl-script PerlHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI /Location Output of perl -V and httpd -V are below and not that this is a vhost using named vhosts via the directive NameVirtualHost *. If you need anything else let me know since I do not have the script on my system you set up for posting bug reports. (RH did not include it) Examples can be seen at http://dev.terranovum.com/cgi-global/500.pl or http://dev.terranovum.com/bad-link Thomas Bolioli PS: Any idea if there will be a replacement for Apache::Status? #httpd -V Server version: Apache/2.0.40 Server built: Oct 9 2002 08:01:13 Server's Module Magic Number: 20020628:0 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT=/etc/httpd -D SUEXEC_BIN=/usr/sbin/suexec -D DEFAULT_PIDLOG=logs/httpd.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_LOCKFILE=logs/accept.lock -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf # perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.18-11smp, archname=i386-linux-thread-multi uname='linux daffy.perf.redhat.com 2.4.18-11smp #1 smp thu aug 15 06:41:59 edt 2002 i686 i686 i386 gnulinux ' config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dmyhostname=localhost -Dperladmin=root@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' 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 -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-O2 -march=i386 -mcpu=i686', cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -I/usr/include/gdbm' ccversion='', gccversion='3.2 20020822 (Red Hat Linux Rawhide 3.2-5)', 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=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil libc=/lib/libc-2.2.92.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.2.92' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under linux Compiled at Sep 1 2002 23:56:49
[mp1] strange build problem with request_rec structure breaks API
Hi, I have a most interesting problem. It seems as though mod_perl breaks API compatibility for apache by modifying the layout of the request_rec structure. Let me explain I maintain my own Red-Hat-based distribution of linux for my own internal use -- I take packages from Red Hat and modify them to my specifications. RPM makes deployment to multiple servers so much easier. I've modified the Red Hat apache RPM to build two copies of apache: one with mod_perl statically linked (apache-mod_perl) and the other without mod_perl (apache-vanilla). Both builds have EAPI from mod_ssl patched in. (However mod_ssl is built separately; see below.) These two apache builds start with the same source tree. I copy this source tree and then run configure and make separately in both trees. The only build difference between apache-vanilla and apache-mod_perl is two arguments on the configure script: --activate-module=src/modules/perl/libperl.a \ --libexecdir=/usr/lib/apache/modperl \ And, of course, before I run configure, I let mod_perl hack away at the apache tree as follows: CFLAGS=$RPM_OPT_FLAGS \ perl Makefile.PL \ PREFIX=$RPM_BUILD_ROOT/usr INSTALLDIRS=vendor \ APACHE_SRC=`pwd`/../src \ DO_HTTPD=1 \ USE_APACI=1 \ PREP_HTTPD=1 \ EVERYTHING=1 Everything else is *exactly* the same. After I have built apache-vanilla and apache-mod_perl, I rebuild the Red Hat mod_ssl RPM. Mod_ssl builds using apxs installed by the apache-vanilla RPM -- this apxs came from the build of apache-vanilla and NOT apache-mod_perl. The apxs from the apache-mod_perl build is never installed or used anywhere. Now here is the important part... I then use this one mod_ssl module (built with apxs from apache-vanilla) with BOTH apache-vanilla AND apache-mod_perl installations: even though it technically isn't fully matched with apache-mod_perl (because it was built using the apxs from apache-vanilla). This has worked great in the past. The abstraction caused by the API has made everything work perfectly. This worked great with: mod_perl-1.26 apache-1.3.22 (from RH 7.2 distribution) mod_ssl-2.8.5 (from RH 7.2 distribution) perl-5.6.0 (from RH 7.2 distribution) Now, I've upgraded to: mod_perl-1.27 apache-1.3.27 (from RH 7.3 distribution; rebuilt in 7.2) mod_ssl-2.8.12 (from RH 7.3 distribution; rebuilt in 7.2) perl-5.8.0 (from RH 8.0 distribution; rebuilt in 7.2) And this breaks! When I use apache-mod_perl and mod_ssl together I get a SEGFAULT. Apache-mod_perl runs fine without mod_ssl. And mod_ssl works fine with apache-vanilla. (The upgrade of apache and mod_ssl did not cause this problem. I first had problems with the older apache and mod_ssl and the newer perl and mod_perl versions. I upgraded to the latest apache and mod_ssl to try and fix things before sending this problem report.) I've used GDB and tracked down why this happens. The problem is that apache-mod_perl and mod_ssl have different ideas of the offset of r-ctx inside the request_rec structure. (r is, of course, a pointer to a request_rec structure). In GDB I've proved this to myself by evaluating ((void*)(r-ctx)) - ((void*)r): evaluates to 348 in apache-vanilla evaluates to 356 in apache-mod_perl evaluates to 348 in mod_ssl I've tracked the difference down as to where it is in the structure: all elements before and including finfo (type: struct stat) are in sync, and all elements after and including parsed_uri (type: uri_components) are 8 bytes off (extra 8 bytes in apache-mod_perl). Either finfo is eight bytes longer in apache-mod_perl, or apache-mod_perl has slipped some other element between finfo and parsed_uri. Somehow apache-mod_perl and apache-vanilla have a different ideas of the request_rec structure. Because I compile mod_ssl using apxs from apache-vanilla it works with apace-vanilla but not apache-mod_perl. I suppose you could say that I *should* build mod_ssl using the apxs from apache-mod_perl if I'm going to use it with apache-mod_perl. I thought that mod_perl didn't patch the internals of apache to the point of changing the API. If this is expected behavior and mod_perl totally breaks the API by redefining the structures, I would suggest that the MODULE_MAGIC_NUMBER be updated by mod_perl, so that incompatible modules are not linked together. If this is not normal, please help me fix this. I'd love to not have to maintain two builds of every other module I want to use. Any other information I can provide, please let me know! Thanks! David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
Re: Fw: OT - Santa uses PERL
At 11:17 AM 12/20/02 +0200, Issac Goldstand wrote: http://www.perl.com/pub/a/2002/12/18/hohoho.html>http://www.perl.com/pub/a/2002/12/18/hohoho.html That sounds a lot like Perrin's story. Didn't he save Christmas one year? -- Bill Moseley mailto:[EMAIL PROTECTED]
Re: Fw: OT - Santa uses PERL
On Fri, Dec 20, 2002 at 10:35:18AM -0800, Bill Moseley wrote: That sounds a lot like Perrin's story. Didn't he save Christmas one year? Indeed he did... and at etoys, no less... Perhaps Perrin is an elf. :) Rob
Re: Fw: OT - Santa uses PERL
Robert Landrum wrote: On Fri, Dec 20, 2002 at 10:35:18AM -0800, Bill Moseley wrote: That sounds a lot like Perrin's story. Didn't he save Christmas one year? I wouldn't go that far. There were actually a lot of warehouse problems that led to disappointed customers, but I don't dwell on that because that wasn't my area. Perhaps Perrin is an elf. :) I'll be an elf if I can jump up onto a horse like Legolas. - Perrin
libapreq-1.1 Release Candidate 2
The apreq developers are planning a maintenance release of libapreq-1.1. This version does not include support for modperl-2, but it *could* address some outstanding problems in 1.0: * OS X support [1] * perl 5.8 segfaults related to file uploads [2] Please give the tarball at http://www.apache.org/~joes/libapreq-1.1_rc2.tar.gz a try and report comments/problems/etc. to the apreq-dev list at [EMAIL PROTECTED] There are special build instructions for OS X, so be sure to have a look at http://www.apache.org/~joes/ for details on OS X support. We'll be patching the documentation based on OS X user feedback. Note: We really could use more volunteers participating in apreq-dev, especially folks with OS X experience. Even though libapreq is a small (ASF) project, there's plenty of work to be done- both in improving/supporting the libapreq-1.x codebase as well as porting apreq to modperl-2. Thanks. -- [1] - We still need volunteers who to document the OS-X install. [2] - The segfault problems with 5.8.0 are still being reported. The apreq developers need help tracking this problem down.
Shroud+ Perl obfuscator....
I extended Robert Jones' Perl Obfuscator, Shroud into what I am calling Shroud+. I
needed it to protect some rather extensive scripts I have developed for
Inventory and Image Gallery management on client web sites.
It seems to work just fine with mp2 and my source code, so I thought I would
let folks know about it here, in case they find it useful.
New stuff includes:
- Specification of input/output directories
- Writing of status info to STDOUT
- Replacement of internal subroutine names (those beginning with an
underscore _ character).
- Optionally replace public subroutine names if the input
is a perl Module (.pm file) AND if you specify that an externalmap should be
created.
- For scripts (not .pm modules ) it will optionally take an externalmap file and
use this to rename subroutine calls to be consistent with the Perl Module that
was used to create the externalmap file.
- Replacement of 'use constants' definitions with capitalized shrouded
identifiers
- Replace object-oriented attributes that take the form
'$self-{ _attr } = something;' and that are found inside a constructor (sub
new).
- removal of tabs and condensing of multiple spaces
- removal of newlines
- POD updated to reflect the above and more bugs/features/caveats noted.
It's posted on http://www.chaeron.com
Regards,
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
Re: [OT] Ideas for limiting form submissions
Check out Gimpy, which I believe is what Yahoo uses: http://www.captcha.net/captchas/gimpy/ http://www.captcha.net/ Narins, Josh wrote: Can GIMP be programmatically set up to warp/woof/weird-out an image? Yahoo's warped words works, I bet, since they use it. I'm referring to get getting an anon email account from yahoo.com -Original Message- From: Bill Moseley [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 1:13 PM To: [EMAIL PROTECTED] Subject: [OT] Ideas for limiting form submissions I've got a mod_perl feed-back form that sends mail to a specific address.. Spammers have their bots hitting the form now. The tricks I know of are: - generate a random image of numbers and make the user type in the numbers on the form. Painful for the user and spammers probably have OCR! - require an email and send a confirmation email (like a list subscription) and whitelist some email addresses. But we want to allow anonymous submissions. - limit submissions by IP number to one every X minutes. AOL users may get blocked. - md5 the submission and block duplicates (should do this anyway). BTW -- what would you recommend for caching the md5 strings. Cache::Cache or DBM? I suppose a Cache::Cache file cache would be the easiest. Any other ideas on the easy to implement side?
install apache:asp in windows
Sir, I want to run sum asp programsusing apache webserver 1.3 so i downloaded mod_perl-2.0-current.tar to have asp support on apache webserver. 1. Please tell me how to install.(in the website it is not clear) 2. Is there any change in config file. 3. then how to run an asp file. please send me reply as quick as possible. With regards, bala
RE: install apache:asp in windows
Hi - mod_perl 2.0 only works with Apache 2. You should use mod_perl 1 (current) to go with an Apache 1 server. Aloha = Beau. -Original Message-From: Karthik [mailto:[EMAIL PROTECTED]]Sent: Friday, December 20, 2002 10:20 AMTo: [EMAIL PROTECTED]Subject: install apache:asp in windows Sir, I want to run sum asp programsusing apache webserver 1.3 so i downloaded mod_perl-2.0-current.tar to have asp support on apache webserver. 1. Please tell me how to install.(in the website it is not clear) 2. Is there any change in config file. 3. then how to run an asp file. please send me reply as quick as possible. With regards, bala
Re: install apache:asp in windows
You'd need Apache 2.0.x if you want mod_perl 2 (or 1.99 etc). If you want to run Apache 1.3.x, try mod_perl 1.27 instead. Regards, .lzs On Fri, 20 Dec 2002, Karthik wrote: Sir, I want to run sum asp programs using apache webserver 1.3 so i downloaded mod_perl-2.0-current.tar to have asp support on apache webserver. 1. Please tell me how to install.(in the website it is not clear) 2. Is there any change in config file. 3. then how to run an asp file. please send me reply as quick as possible. With regards, bala
Re: install apache:asp in windows
Karthik wrote: Sir, I want to run sum asp programs using apache webserver 1.3 so i downloaded mod_perl-2.0-current.tar to have asp support on apache webserver. 1. Please tell me how to install.(in the website it is not clear) What is it not clear? Could you please be more specific? What document are you talking about? Have you read: http://perl.apache.org/docs/1.0/os/win32/install.html If not, please do it first. 2. Is there any change in config file. RTFM: http://perl.apache.org/docs/1.0/os/win32/config.html 3. then how to run an asp file. RTFM again at: http://www.apache-asp.org/ Hope that now you have enough information to figure it out on your own. Please do ask further *specific* questions, if you have any, but after you have read the documents listed in this email. Thanks. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl 2 and problems w/ ErrorDocument Directive
Terra Info wrote: I have a script that provides custom error messages that I set up using the ErrorDocument directive (ie; ErrorDocument 400 /cgi-global/error.pl?error=400useXML=1). When run under typical mod_cgi all works as planned and it outputs the proper stuff. When run under mod_perl it outputs the same but then appends the default ErrorDocument (ie; ErrorDocument 500 /error/HTTP_INTERNAL_SERVER_ERROR.html.var) output on the end so I have effectively two HTML docs on the output page. The odd part of this issue is this. When it is a 404 error The stock error doc says that Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request which makes no sense since the only log entry is File does not exist: /var/www/terradev/docs/bad-link. When you use the 500.pl example below you get Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request. despite the fact that the custom error script did work and output what it was supposed to and the error logs confirm that. Looks like ModPerl::Registry is not handling correctly the return status , hence you get the run of the default handler as well. I'll look into it. But first, does it work properly with mod_perl 1.0? Finally please attach the script that fails, preferrably removing all but the very minimal code that allows to reproduce the problem. Thanks. And if you can a test to modperl-2.0/ModPerl-Registry/t that reproduces the problem, that would be even better. If you don't know Apache::Test, you can learn more about it at: http://perl.apache.org/docs/general/testing/testing.html and looking at the existing tests. To run the registry tests you need to cd to the ModPerl-Registry dir first and run 'make test'. If it seems like too much work, I'll take care of adding the test. But it'd be cool if people who encounter problems were able to submit tests with their reports. Thanks. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Shroud+ Perl obfuscator....
Andrzej == Andrzej Jan Taramina [EMAIL PROTECTED] writes: Andrzej I extended Robert Jones' Perl Obfuscator, Shroud into what I Andrzej am calling Shroud+. I needed it to protect some rather Andrzej extensive scripts I have developed for Inventory and Image Andrzej Gallery management on client web sites. I just want to go on the record to say that I consider your action personally offensive and ethically questionable. A lot of people have worked very hard to bring you an open source platform to stand on. And now you spit in their face, by trying to pretend YOUR work is worthy of more locking up than the source code you are using to create your work. Sir, on their behalf, and my own as a contributor to the open source movement, and Perl in particular, you offend me. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
RE: Shroud+ Perl obfuscator....
Even thought I am new to the Open Source Community I agree with Randal Schwartz. I find the idea of creating AND sharing much more enriching than the way things are done in the MS world where I have spent the bulk of my career. Maybe we should come up with UnShroud+. Beau E. Cox -Original Message- From: Randal L. Schwartz [mailto:[EMAIL PROTECTED]] Sent: Friday, December 20, 2002 5:45 PM To: Andrzej Jan Taramina Cc: [EMAIL PROTECTED] Subject: Re: Shroud+ Perl obfuscator Andrzej == Andrzej Jan Taramina [EMAIL PROTECTED] writes: Andrzej I extended Robert Jones' Perl Obfuscator, Shroud into what I Andrzej am calling Shroud+. I needed it to protect some rather Andrzej extensive scripts I have developed for Inventory and Image Andrzej Gallery management on client web sites. I just want to go on the record to say that I consider your action personally offensive and ethically questionable. A lot of people have worked very hard to bring you an open source platform to stand on. And now you spit in their face, by trying to pretend YOUR work is worthy of more locking up than the source code you are using to create your work. Sir, on their behalf, and my own as a contributor to the open source movement, and Perl in particular, you offend me. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Shroud+ Perl obfuscator....
Are you for real? Or is this some lame attempt at sarcasm? Andrzej posts to the list, SHARING some code he's written in case some people actually might use it, and he gets bitchslapped with some holier-than-thou rhetoric? Puh-leaze. Take your total bullshit somewhere else because you're about as constructive as Richard-f**king-Stallman. You may not know this, but people actually use perl for things other than one-liners. Commercial projects actually use perl, and oftentimes these commercial projects are sensitive and copyrighted. And occasionally, just occasionally, these projects actually want to have some level of security, for numerous reasons that I'm sure Andrzej could explain quite easily to us if he were asked. Andrzej: thanks for sharing your code with us. Kyle Dawkins Central Park Software On Friday, Dec 20, 2002, at 22:44 US/Eastern, Randal L. Schwartz wrote: Andrzej == Andrzej Jan Taramina [EMAIL PROTECTED] writes: Andrzej I extended Robert Jones' Perl Obfuscator, Shroud into what I Andrzej am calling Shroud+. I needed it to protect some rather Andrzej extensive scripts I have developed for Inventory and Image Andrzej Gallery management on client web sites. I just want to go on the record to say that I consider your action personally offensive and ethically questionable. A lot of people have worked very hard to bring you an open source platform to stand on. And now you spit in their face, by trying to pretend YOUR work is worthy of more locking up than the source code you are using to create your work. Sir, on their behalf, and my own as a contributor to the open source movement, and Perl in particular, you offend me. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Shroud+ Perl obfuscator....
On Sat, Dec 21, 2002 at 12:53:34AM -0500, kyle dawkins wrote: Are you for real? Or is this some lame attempt at sarcasm? Andrzej posts to the list, SHARING some code he's written in case some people actually might use it, and he gets bitchslapped with some holier-than-thou rhetoric? Puh-leaze. Take your total bullshit somewhere else because you're about as constructive as Richard-f**king-Stallman. You may not know this, but people actually use perl for things other than one-liners. Commercial projects actually use perl, and oftentimes these commercial projects are sensitive and copyrighted. And occasionally, just occasionally, these projects actually want to have some level of security, for numerous reasons that I'm sure Andrzej could explain quite easily to us if he were asked. And if they do have something to protect, they should put their thinking caps on and realize that this sort of security is called obfuscation for a reason: it does not accomplish anything except to make the results hard to read. If you're giving away or selling the perl source, obfuscating it doesn't have any significant effect. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
