[PHP-DEV] FOSDEM
Hello mates, I wanted to know who is going to be in Brussels on february 16-17 for FOSDEM ? Can we plan something ? Sterling ? hellekin --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.320 / Virus Database: 179 - Release Date: 2002-01-30 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #14950: __sleep() and __wakeup() fail
From: [EMAIL PROTECTED] Operating system: Debian SID PHP version: 4.0CVS-2002-01-09 PHP Bug Type: Session related Bug description: __sleep() and __wakeup() fail Passing objects using the magic __sleep() and __wakeup() methods through sessions fail. In the best case the script fails without error. In the worst, an integer in session turns into the value of the PHP session ID and the object is not registered. Yasuo Ohgaki guesses it's a serialize/unserialize problem. Make log : /usr/src/web/php/php4/ext/standard/var_unserializer.re: In function `php_var_unserialize': /usr/src/web/php/php4/ext/standard/var_unserializer.re:304: warning: comparison is always false due to limited range of data type Tests : http://php.hellekin.com/test/session/ PHPInfo() : http://php.hellekin.com/info.php -- Edit bug report at: http://bugs.php.net/?id=14950edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14950 Updated: __sleep() and __wakeup() fail
ID: 14950 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Debian SID PHP Version: 4.0CVS-2002-01-09 New Comment: Forgot to tell : asking for .phps will show you the source in the /test/session/ directory. Previous Comments: [2002-01-09 10:36:08] [EMAIL PROTECTED] Passing objects using the magic __sleep() and __wakeup() methods through sessions fail. In the best case the script fails without error. In the worst, an integer in session turns into the value of the PHP session ID and the object is not registered. Yasuo Ohgaki guesses it's a serialize/unserialize problem. Make log : /usr/src/web/php/php4/ext/standard/var_unserializer.re: In function `php_var_unserialize': /usr/src/web/php/php4/ext/standard/var_unserializer.re:304: warning: comparison is always false due to limited range of data type Tests : http://php.hellekin.com/test/session/ PHPInfo() : http://php.hellekin.com/info.php Edit this bug report at http://bugs.php.net/?id=14950edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: RC3
At 16:31 05/10/2001 +0900, Yasuo Ohgaki wrote: Yasuo Ohgaki wrote: Yasuo Ohgaki wrote: Zeev Suraski wrote: Finally, it's out. www.php.net/~zeev/php-4.0.7RC3.tar.gz In addition to previous problem, CGI build seems to print following line again.. Minor problems with phpinfo() while running PHP as Apache module. Logo images(PHP/Zend) are not displayed. *** I don't have those problems. Can you reproduce ? PHPInfo() : http://hellekin.com/info.php hellekin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Security Audit 4.0.7RC2
Hello people, this is a security audit of PHP-4.0.7RC2 (4.0.6 is also available) where you can find : - Potential threats such as buffer Overflows, Race Conditions, Format Strings and Temporary files. - Which functions are dangerous and how to replace them. - Where (files and lines) you can find them. The software behind that audit reads C source code to find selected patterns. It is currently under development. Thanks to Philippe Langlois for providing the audit and code. The results do not mean there *is* a flaw, but that corrections may be implemented to avoid such flaws. http://hellekin.multimania.com/hitscore.php (This is temporary URL. Do not bookmark nor forward). how -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1
At 17:13 17/08/2001 +0300, Zeev Suraski wrote: At 17:05 17-08-01, Cynic wrote: I'd do this: 4.0.7: php.ini-standard basically today's php.ini-dist php.ini-recommendedbasically today's php.ini-optimized + the proposed security related changes what this is exactly I don't know. perhaps only register_globals off This already exists today (except -standard is still called -dist, as there's no real reason to change it). We may try to encourage people to read php.ini-recommended at the and of the build process, because I fear nobody's looking at it today. *** That's pretty clear. Maybe we could make a setup script that would write the php.ini for the user depending on the --config_file_path value ? It would propose an automatic setup (either -dist or -recommended) or a manual setup (yes|no,1|0 style). In we I don't count myself as I know Perl almost like a (real) camel. 4.1.0: php.ini-standard php.ini-recommended as contained in 4.0.7 + anything else you think should be there (it can be more strict than 4.0.7's rec.) php.ini-compat php.ini-standard as contained in 4.0.7 I'm not sure that we can just move to do -recommended version, 4.1.0 or not. The nature of recommendations is that some people accept them, and some do not :) None of the things in the php.ini-recommended file is a clear-cut must-have, and some people will prefer doing without them. We'll have to think about each change separately. Remember that we only use the version change to catch people's attention. It doesn't mean that we can suddenly make PHP much more 'hostile' :) *** OTOH, maybe PEAR people would like to see some comfortable defaults ? And while I'm at it: can the Powers That Be consider switching the default setting for display_startup_errors to On in either of the ini files? I believe (my experience indicates it) that this would help to lower the confusion in some cases quite a bit: a message instead of just a 500 can change one's day. There's a good reason for this default setting. A clear message will not only change your day, but also the guy who's trying to hack your site's day :) For example, with display_startup_errors set to on, a request can be easily made that will expose the full path of any scripts on your site. It may make good sense to set it on in the -recommended version, as it's safe in conjunction with display_errors=0 and log_errors=1. Zeev *** I understood that 4.0.7 / 4.1.0 would be a question of what we want next. If E_ALL brings better code, why not encourage that ? Democracy is good as long as it's evolving. If we encourage a default lax behavior, lax coders we'll have. If we encourage tighter programming, even the novice can cope with it and learn faster, and make less mistakes, etc. Is that too optimistic ? Or am I forgetting the existing code base ? I think that as $HTTP_*_VARS disappear, lots of people will have to change that (Search/Replace + delete the corresponding global calls) anyway in order to use the new $_* arrays in future versions. It's probably better to bother people once for good instead of once every version. The purpose of 4.0.* vs .4.1.* should be clear for all : it's a new step and you have to make it. RFC hellekin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1
At 19:16 17/08/2001 +0300, Stanislav Malyshev wrote: ZS While we're at it, I think that we should also take another ZS recommendation from the advisory that brought this mess upon us ZS - and turn URL fopens off by default. Well, generally I personally would even go further and make two functions - one for file-only fopen (about 90% of fopen usage?) and another which would open everything and the kitchen://sink. Or make some switch, etc. - configuration option doesn't seem to me fit here, it's not per-server but per-script property if you want URL fopens or not. *** Consider a mutli-user environment, like an ISP, where many users can script on the same server. In that case, we need a system-wide configuration flag. However, I agree with you that some cases may require having allow_url_fopen On while preventing most of the others from using it. I think that case is not depending on PHP but rather on a correctly implemented httpd server. hellekin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] [security] allow_url_fopen
Hello, a vulnerability was published yesterday concerning a possible security hole for sites using PHP. http://www.net-security.org/text/bugs/995534301,88119,.shtml SUMMARY A local user can write a one-line script calling itself via HTTP by using fopen(). This can lead to a denial of service by exhaustion of available ports. This overrides the maximum_execution_time. SOLUTIONS - Switch allow_url_fopen to Off in php.ini DEV NOTE - This would be safe to : - include url fopen() in --disable-sockets - put allow_url_fopen Off by default in php.ini hellekin P.S.: there is another security bug affecting 4.0.5 and 4.0.6 for mail() : http://www.net-security.org/text/bugs/995534103,28541,.shtml -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Latest CVS sablot error
Hello, does someone know about this ? sablot.c:217: parse error before `*' sablot.c: In function `php_rshutdown_sablot': sablot.c:251: `SABLOTG_HANDLE' undeclared (first use in this function) sablot.c:251: (Each undeclared identifier is reported only once sablot.c:251: for each function it appears in.) sablot.c: In function `_php_sablot_error': sablot.c:1352: `SABLOTG_HANDLE' undeclared (first use in this function) make[3]: *** [sablot.lo] Error 1 It's on a debian with latest sablotron packages on yesterday's and today's CVS. hellekin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
At 15:07 25/07/2001 -0700, PHP wrote:
On Wed, Jul 25, 2001 at 07:31:59AM -0700, Rasmus Lerdorf wrote:
Because not everyone agrees that this is actually highly recommended.
Most third-party PHP code you may want to run will not work very well with
register_globals off. And turning register_globals off isn't actually as
helpful from a security perspective as many people seem to think.
The basic thing it would help would be in cases like this:
?
if($user=='rasmus') {
$ok = true;
}
if($ok) {
... secure code ...
}
?
Don't forget the use of session variables.
On one page you:
session_start();
session_register(user);
$user = 'admin';
And then on another page you:
session_start();
if ($user == 'admin')
{
}
If a malicious user goes to the second page first
they could overwrite $user and break security.
*** That's why one should use $HTTP_SESSION_VARS =8)
At my office we are 30+ developpers from many different backgrounds and
skill levels.
Very few people tend to declare their variables and almost none make use of
HTTP_*_VARS except for POST.
Most people rely on the network security, trusting the NOC, but failing
to realize that direct web access can be harmful.
Our codebase is quite secure I believe, but if you take every individual
scripts, most of them are not.
I think forcing to make use of HTTP_*_VARS by register_globals=off would
break a whole lot of code around (both inside our company and in the wild).
But it brings the advantage of putting most of the security over to PHP
instead of innocence of the user and moreover makes the code more
understandable.
I'm looking forward to HAL2001 to discuss those points with other
attendants, then release some guidelines for securing PHP code.
Any contribution is welcome.
hellekin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: HAL 2K1
At 18:29 24/07/2001 +, wrote: In article [EMAIL PROTECTED], Hellekin O. Wolf wrote: As the Apache conference in Dublin is cancelled, I wanted to know if there is an alternative for meeting... Are there some PHPers going to to the Netherlands on August 10-12 ? =8) http://www.hal2001.org/ I know that some will attend. Be aware of all kinds of cops that will check if you are trying to do something illegal. Regards, Hans *** We're talking about a PHP meating (with an a ;-) which would be held during HAL2001, not talking about doing something illegal and I don't think most hackers would appreciate the amalgam with crackers =8) Anyway, this would be the perfect place to talk about PHP security. I've heard rumors regarding possible buffer overflows in PHP but I didn't see anything published. If such BOs exist, HAL may be a really good place to learn about it. I received about 5 mails from different people who will attend. I'll continue centralizing information about this event, so please feel free to contact me off-list if you attend HAL2001 and wish to participate in some PHP-centered discussions. All suggestions are welcome of course =8) hellekin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] HAL 2K1
As the Apache conference in Dublin is cancelled, I wanted to know if there is an alternative for meeting... Are there some PHPers going to to the Netherlands on August 10-12 ? =8) http://www.hal2001.org/ hellekin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] 4.0.6 Packaged!
At 10:04 21/06/2001 +0300, Andi Gutmans wrote: http://www.php.net/~andi/php-4.0.6.tar.gz *** Configured, compiled and ran under ten minutes using the instructions i posted yesterday for RC4. Yeahay ! Welcome to the world new release ;-) hellekin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] PHP 4.0.6RC1 ready for testing
At 11:59 16/05/2001 +0200, Daniel Beulshausen wrote: At 22:39 15.05.2001 +0300, Andi Gutmans wrote: I can do a basic build but I think Daniel Beulshausen might be able to do a more complete build with a lot of Windows extensions. Or is there anyone else? i've uploaded a build at http://www.php4win.de/php-4.0.6-rc1.exe i'd appreciate if it could be mirrored somewhere, as it's going to be deleted from the server in a few days. daniel *** I just downloaded it and got some warning about a missing MSVCR70.dll : it seems to me that previous discussions elsewhere stated that this DLL is quite new, like a .NET thing... Sounds like libtool-1.4 on Debian to me =8\ hellekin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: 4.0.5: Merge Request
At 19:06 25/04/2001 +0100, James Moore wrote: Its doesnt at all :) We are using it as a temporary codename until we can think of a better one. - James *** Brazil ? It starts with a B and it's all a Bug Story... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: ; arg seperator
At 00:54 04/04/2001 +0200, Hartmut Holzgraefe wrote: [EMAIL PROTECTED] wrote: Please stop crossposting to the PHP-DEV and the PHP-QA mailing list. Most people interesting in this theme are reading both. And so it is really annoying to get everything twice. a bad idea IMHO as long as the topic is related to both lists as this will break the thread in the archives for one of the lists -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 *** np, --- FOR ARCHIVES : Please follow-up this discussion on [EMAIL PROTECTED] --- No cross-posting please. To subscribe to php-qa mailing-list : PHP Quality Assurance Mailing List http://www.php.net/support.php OR mailto:[EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming
At 22:33 07/03/2001 +0200, Andi Gutmans wrote: Why not bzip2_? *** Well, if bzip2_, then gzip_ ! If gz_ then bz_ or bz2_. Am I wrong or too fastidious ? hellekin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] New Site Design
It rock ! =8) Wonderful Colin... how -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming
At 23:48 06/03/2001 -0700, Zak Greant wrote: Andi wrote: [snip] Yep. Let's start doing some damage. bzip2 is a very good victim. bzclose - bz_close bzcompress - bz_compress bzdecompress - bz_decompress bzerrno - bz_errno bzerror - bz_error bzerrstr - bz_errstr bzflush - bz_flush bzopen - bz_open bzread - bz_read bzwrite - bz_write Can anyone see a problem with the proposed name changes? *** What is the difference between error ad errstr ? Maybe errstr should be changed to errmsg ? (Did I say that elsewhere ? ;-) As the file extension is .bz2, maybe the prefix should be bz2_ as well (it's an algorithm, not a version right ?) Comparing Gzip and Bzip2 functions : bz_closegz_close bz_compress gz_compress bz_decompress gz_uncompress -- Something must be done here. bz_errno- bz_error- bz_errstr - bz_flush? bz_open gz_open bz_read gz_read bz_writegz_write, gz_puts - gz_eof - gz_file - gz_getc - gz_gets - gz_getss - gz_passthru - gz_rewind - gz_seek - gz_tell - gz_readfile hellekin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming
At 17:22 07/03/2001 +0200, Andi Gutmans wrote: *** What is the difference between error ad errstr ? Maybe errstr should be changed to errmsg ? (Did I say that elsewhere ? ;-) As the file extension is .bz2, maybe the prefix should be bz2_ as well (it's an algorithm, not a version right ?) How about error_message or error_string? *** Well, errmsg/errstr are everywhere else, be it in PHP or C. errno would take the lifting also... We would end with function names like : mysql_error_number() mysql_error_string() Looks great regarding paragraph formatting but wastes lots of keystrokes ;-) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming
Well, let's start fire =8) I think the compression extensions should follow the same standard. The one you proposed for bzip2 should be applied to gzip functions as well. readgzfile - gz_readfile (or gzreadfile), at least to keep functions names in alphabetical order ;-) Also, I know the gd extension follows the library API, but names are really long and would benefit from being prefixed with img_ or gd_, img_ being my favorite because one usually use $img = imagecreate... and not $gd = imagecreate... But gd_ is more standard compliant as it takes the extension name. Indeed, this extension doesn't follow the naming convention (imagecolorallocate should look more like gd_allocate_color) Concerning the database extensions, I noticed that there are both [db]_fieldtype and [db]_field_type for some of them. I assume that the shorter one is to be an alias to the longer one and that only the longer one would be documented. Concerning DB especially, shouldn't dblist be renamed dbmlist to keep consistent with its own family, if not underscored ? OCI and DB are the only database extensions without underscores. Although Andi's suggestion is not to bother with consistent extensions, it is probably a good idea to keep extensions "families" consistent altogether. So, oci* functions would also gain an underscore. getallheaders... Two changes instead of one, but for better compliance... get_all_headers... Too much overhead ? Maybe DOMXML and GETTEXT functions would benefit from a complete lifting ;-) EXIF : read_exif_data - exif_read_data gmp_clrbit - gmp_clr_bit ? Hmmm... gmp_clear_bit ? The gmp_ functions look odd... You have gmp_gcdext, gmp_sqrt, gmp_powm then gmp_perfect_square I don't have a solution for that. =8( In HYPERWAVE functions you have hw_connection_info then hw_deleteobject... One of those looks wrong. hw_errormsg - hw_errmsg (to keep consistent with all other errmsg functions around). Output buffering handlers should remain consistent such as ob_[handler type]_handler (see ob_gzhandler - ob_gz_handler) I didn't quite follow the thread for the last two weeks and my intervention may seem to be a step back from there. Just my 2cts. phpversion - phpversion *** you meant php_version =8) user_error *** Yes, error_user would be offensive ;-) hellekin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] ext/ming : configure error
Hi, for the last few snapshots of PHP, configure have had problems finding libming.so In the configure file, the test is made on $i/libming.so and should be made on $i/lib/libming.so (around line 25168) hellekin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] snpashot broken ?
Hello, I've been fighting with the latest snapshots to build on a Debian with Apache 1.3.17 via APXS with and without SSL (EAPI). Although it configures and builds correctly, it fails at Apache startup with a Segmentation Fault error (no coredump, no log). If anyone can tell me how to gather more information, I'd be happy to issue a full report. hellekin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Time for 4.0.5?
Can we propose extensions outside of the main distribution ? I like the idea of downloading what you want. Through a form, you would chose the extensions you need, then submit and receive a custom GZIP or BZ2 file. It sounds doable. Any constraint, dependency to work out ? Yes, the m4 stuff... Can we open a thread on that specific topic of a PHP-downloader ? * Regarding midgard, although it is considered beta, I'm for including it into the main distrib for RC1, so that people can test it and eventually the midgard team can release a final version before 4.0.5 ships. hellekin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Changes in bug system..
At 18:41 01/02/2001 +0100, Sascha Schumann wrote: On Thu, 1 Feb 2001, Jani Taskinen wrote: The emails sent by the bug system now have a note about _not_ replying to the emails but using the web interface instead. Instead of forcing those people who contribute their free time to use one particular way of communication, I'd prefer to enable them to use either email or the web interface. - Sascha *** Using procmail we might be able to forward any such replies to a script that would mimick the web interface... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Changes in bug system..
I do like Hellekin's suggestion to use procmail to automate the entry of messages into the bug system - however, I have no idea how reliabile the system is or how much effort is needed to implement it. --zak *** I'll have an eye on it. I recently worked on an automated subscription system using procmail, php as CGI and MySQL. Probably php.net can provide the same environment =8) how -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
