moregw developer IRC session, October 9th

18:02:01 k-fish welcome everybody!
18:02:06 hondzik Hi
18:02:20 k-fish just to make you aware of the fact: i'm logging this, so be polite :)
18:02:37 k-fish loge was here earlier, i hope he'll join again.
18:03:11 hondzik so what topics do we want to discuss?
18:03:13 k-fish tom: good work with the webmail2 module. seems as if the people love it :)
18:03:26 hondzik I like it too:)
18:03:28 tom thanks
18:03:31 k-fish i have a short list. shall i present you with all items to get an overview?
18:03:40 * k|p hopes you have a privacy statement
18:03:47 hondzik sure
18:04:07 * k-fish ? a privacy statement? huh?
18:04:13 k-fish anyway:
18:04:17 k-fish 1. removal of old wmail
18:04:27 k-fish 2. SQL portability and beyond
18:04:34 k-fish 3. magic_quotes_gpc
18:04:41 k-fish 4. logging code
18:04:46 k-fish 5. performance tuning
18:04:53 k-fish 6. PHP 4.0.x support
18:04:58 k-fish anything to add?
18:05:12 hondzik error_reporting(E_ALL) ? :))
18:05:21 k-fish make that 7. :)
18:05:40 k-fish 8. XSS exploits
18:05:53 tom rights management ?
18:06:07 k-fish 9. rights mngmnt. right.
18:06:46 hondzik api for users modules (overview,...) ?
18:07:02 k|p working on it
18:07:26 k-fish yep. that's 10, but we should try to keep the amount of information handle-able (sp?)
18:07:28 k-fish i'd propose to talk about the things in order. i'll log the session, and summarize (as usual). ok?
18:08:13 * brr is back (gone 00:21:05)
18:08:46 hondzik ok
18:09:06 brr What about upgrade support?
18:09:20 k-fish wait and see :)

introducing k|p

18:09:30 k-fish ok, first some personalities...
18:09:41 k-fish you sure know k|p by now, no?
18:09:50 * k|p bows
18:10:00 k-fish take a look at the settings module, and see for yourself: great stuff.
18:10:16 k-fish *applause*
18:10:18 hondzik I agree, cool
18:10:37 k-fish and i have already seen a sneak preview of the new module manager. wow.
18:10:41 tom it's very good and easy to use
18:11:13 k-fish ok. should suffice, no? :)
18:11:23 k-fish k|p: anything you want to say for yourself?
18:11:24 k|p thanks all (from now on i will only comment usefuly)
18:11:30 k-fish :)

wmail removal

18:11:37 k-fish ok, 1. removal of old wmail
18:11:46 hondzik asap :)
18:11:47 k|p just that i'm glad to be on the team (oops)
18:11:57 k-fish i can do this within a minute, any objections?
18:12:04 k-fish (k|p: no problem :)
18:12:24 tom some people want the functionality to delete messages directly on the server ...
18:12:46 k-fish in the new module? can you add that?
18:13:07 tom I will add this, but this takes some time
18:13:17 k-fish is this something that would stop us from removing (old) wmail?
18:13:38 tom some people use the old one to remove mails
18:13:54 k-fish ah. hm. so? opinions please!
18:14:33 brr Remove the old webmail! It is junk!
18:14:49 k|p attic it and create the functionality in wm2 asap
18:15:17 tom perhaps we can offer it as an extra download until the function is in wm2 ?
18:15:59 hondzik tom: yes, it will be best
18:16:14 k-fish tom: how long will it take to add this to wm2 (roughly)?
18:16:43 tom there are some other that (I think) are more important, about 2-3 weeks
18:16:59 tom other things ...
18:17:32 k-fish 2-3 weeks? ok, i doubt we'll see 0.6.6 earlier. i'll remove the code from CVS, and if need be, we can bundle a seperate module download. ok?
18:18:05 tom that's ok
18:18:09 hondzik ok

SQL portability

18:18:30 k-fish fine. 2. SQL portability
18:18:40 k-fish who did not read my email on this?
18:19:03 hondzik i did
18:19:30 k-fish ok. so you all know (roughly) what the status is.
18:19:43 k-fish i did not committ yet, because of some issues to be discussed later.
18:20:08 k-fish but there needs work to be done, after i committ those changes. just to warn you :)
18:20:35 k-fish ok, who could test on what database, aside MySQL and PostgreSQL?
18:20:58 hondzik not me, I have only MySQL installed :(
18:21:24 tom I can test mssql
18:21:33 k-fish that would be good.
18:21:35 canani I can test PostgreSQL
18:21:56 k-fish oracle anybody? msql? db2? ...?
18:22:08 canani and maybe firebird ...
18:22:27 k-fish sapdb?
18:22:48 k-fish does anyone know someone else who could test on other db's?
18:23:05 k-fish if not, we'll have to call for volunteers :)
18:23:19 brr Sybase. Did you mention that?
18:23:40 k-fish no. do you have that available?
18:24:17 brr Sorry. At work we use both Oracle, Sybase and MS SQL. But it is running servers... I don't take the change to run tests on them.
18:25:23 k-fish production systems running mgw?
18:25:32 canani i have many
18:25:42 k-fish brr: could you create a parallel test-only install?
18:25:49 k-fish canani: so you are out friend :)
18:25:51 canani of course
18:25:55 k-fish s/out/our/
18:26:10 k-fish ok, so it seems testing is not that big a problem.
18:26:34 k-fish i'll try to create an overview page, were we can summarize test results.
18:26:44 brr k-fish: Sorry. I think it will be difficult. I don't have the knowledge or the installation CDs to do that....
18:27:02 k-fish brr: ok, no problem. you'd find too many bugs anyway ;)
18:27:16 k-fish anything else on that subject that wasn't mentioned yet?
18:27:52 k-fish ok, my plan is this:
18:28:16 k-fish as soon as moregroupware *runs* on PostgreSQL (and possibly other systems), go ahead and ...
18:28:35 k-fish add foreign key constraints! tada! opinions?
18:28:49 canani yes, please!
18:29:39 k|p transactions? .. does that work with adodb even if the db doesn't support it?
18:29:54 --> yoyo- ( has joined #moregroupware
18:30:07 k-fish hm, transactions... i'd have to look at the docs.
18:30:21 k-fish is this something that is of great importance?
18:30:36 k-fish (in moregroupware in particular, i mean)
18:31:47 k-fish from adodb manual:
18:31:54 k|p well, for a clean db yes, but because many db's don't support it, we probably have to compensate for failures in code ourselves
18:32:02 k-fish BeginTrans() Returns true if successful. Some databases will always return false if transaction support is not available.
18:32:15 k|p (read many=mysql)
18:32:23 hondzik I don't think we need transactions, but it should be nice feature
18:32:52 k-fish so it should work regardless of the db. we could add this were it fits, and those who use a database lacking transaction support - their fault. no?
18:33:00 k-fish hondzik: yep.
18:33:05 canani foreign key constraints are more important in my opinion.
18:33:06 hondzik k|p: i think mysql = most of mgw users
18:33:16 k|p hondzik : i know :(
18:33:29 k-fish hondzik: well, it's the only thing that works right now... :(
18:33:46 k-fish i'd migrate to pgsql asap.
18:33:49 k|p talk about transactions again when mysql 4 is out
18:34:13 k-fish well, even late 3.23.x releases support transactions, if using innodb, no?
18:34:33 k-fish maybe we should add something to setup, that makes it possible to choose table type for mysql.
18:35:30 hondzik or maybe detect mysql version (if its possible) and choose best type...
18:35:48 k|p i would wait for mysql to get things right .... a lot of work for just a minor issue
18:36:45 k-fish true. we probably have more important things to do.
18:37:09 k-fish so we could add this, and those who want it to work, should use the "right" database.
18:37:17 k-fish what else on databases stuff?
18:37:37 hondzik some upgrade mechanism?
18:37:46 brr Upgrade possabilities? Or will you discuss that later?
18:38:06 hondzik probably later...
18:38:40 k-fish hm. fits here - let's finish SQL portability, and talk about upgrades.
18:38:50 k-fish k|p: do you have some roadmap for this?
18:39:51 k|p wel, it's almost impossible to upgrade change like the one from configtagid to configtag name automaticly, but minor changes, added columns etc are doable
18:40:23 k|p as long as we define the datatypes that can be used in db
18:40:36 k-fish true. such big changes need a seperate update script, or sth like that.
18:40:58 k-fish well, the datatypes i used for now do most things we need, and are portable.
18:41:14 k-fish if those suffice, we don't a meta type system.
18:41:16 k|p yes, they can be avoided if the db design is thought through well when making a design
18:41:32 k-fish there are two principal ways i see for db upgrades.
18:41:49 k|p yes, if we limit to those db upgrade can be done
18:41:54 k-fish 1. prepare update sql files manually (alter table ...)
18:42:14 k-fish 2. create a "diff" on the fly, by comparing the existing db, and the install.sql file.
18:42:23 k-fish i'd vote for 1... (to be honest)
18:42:33 brr Oh no!
18:42:42 hondzik me too
18:42:44 k|p both options cry for transactions btw :p
18:42:59 k-fish brr: prepare manuyll, apply automatically. like this...
18:43:26 <-- yoyo- has quit ("bye")
18:43:28 k-fish in setup/ of each module, we have install.sql, like now. and probably uninstall.sql (more from k|p, probably)
18:43:50 k-fish and then thngs like update-05.sql, update-06.sql
18:44:05 k-fish those have to be prepared for each release, and will then be applied by setup, if needed.
18:44:18 k|p uninstall.sql -> i vote YES (strongly)
18:44:30 k-fish that's what i'd try, though i am open for better suggestions all the time!
18:44:59 brr Remember that not everyone like to hack databases!
18:45:04 k|p i vote for option 1 too, option 2 is tricky and will introduce quite a few problems (i know)
18:45:15 k-fish brr: setup will do it for you!
18:45:23 k|p brr, option 1 will be just as easier as option 2 in the end
18:45:55 k-fish othr way would be to use metabase for this. but it needs XML db descriptions...
18:46:04 brr OK! If I can e. g. upgrade my MGW 0.6.3 installations to e. g. MGW 0.6.7 without too much manually database hacking I will be very satisfied!
18:46:10 k-fish it could do 2. out of the box (should do)
18:46:46 k-fish brr: i imagine setup to look at the version, then apply the needed upgradexx.sql files
18:47:16 k-fish though it might be tricky to rely on the moregroupware version alone. module version numbers would probably be better. hm..
18:47:31 brr k-fish: OK. No more comments from me regarding this topic!
18:48:23 k|p k-fish : a quick look at metabase, looks good, who's gonna do it?
18:49:35 k-fish do what? take the (closer) look?
18:49:56 k|p yes :)
18:50:35 k-fish hm. i could do it. but we'd have to coordinate this with the new setup code of yours.
18:51:10 k-fish any more thoughts on this?
18:51:12 k|p will we limit db support to those db's supported by adodb and metabase?
18:51:19 k-fish k|p: yes.
18:51:53 k|p i would be happy to hand over my setup hacks to anybody that want's to use it further :)
18:53:21 canani regarding testing ... is there a list of which modules are assigned to which developer ?
18:53:41 canani so that i can send testing reports to the correct person ?
18:54:22 canani or should I pot it to the delveloper's maillist?
18:54:23 brr
18:54:25 k-fish canani: yes, see
18:55:07 hondzik it's out of date :( but I can update it...
18:55:14 k-fish k|p: you want to hand over the setup stuff to someone else? what's still missing?
18:55:22 k-fish hondzik: not too much out of date... :)
18:55:40 k-fish hondzik: i have access to it now as well.
18:56:06 k-fish canani: but best is to submit bug reports via
18:56:21 hondzik yeah i know, thanks for updating it, i absolutely forgot to do it :(
18:56:22 k|p k-fish : nothing compared to current setup i think (asside from a little code cleaning/nicening)
18:57:23 --- Notify: newb is online (
18:57:24 k-fish k|p: ok, so why not add it to cvs? needs to be done along with the new xml files and mod manager, no?
18:57:30 k|p k-fish : i can clean it all up and consider it stable next week
18:58:04 k|p k-fish : yes, ok
19:00:03 k-fish ok. after that we'll look at upgrade possibilities. anything else on this?
19:00:50 hondzik not from me :)


19:02:05 k-fish ok. 3. magic_quotes_gpc()
19:02:15 k-fish i'd like to drop that requirement.
19:02:33 k-fish to do this we need to ensure proper quoting of all data before db insertion.
19:02:48 k-fish was in my mail as well. anything we need to dicuss on this?
19:03:19 hondzik only needed is to use $conn->quote($HTTP_...) ? It should be done quikly I think
19:04:59 k|p all is clear here
19:05:07 k-fish hondzik: basically, yes. or cast to integer for numbers.
19:05:29 hondzik ok, clear
19:05:30 k-fish and if working on a file, we could replace the qstr() call with the quote() call
19:06:11 k-fish ok, who is going to test this? we need to make sure to hit all the places we need :)
19:06:19 k-fish notes, todo and contacts work
19:06:33 k-fish projects will be taken care of.
19:06:35 k-fish (by me)
19:06:57 k-fish webmail2 - tom is this clean now? i think you did that, right?
19:07:00 hondzik i'm not sure about calendar, but Išll look at it
19:07:00 tom webmail, of course
19:07:38 tom only those that were buggy, there are many addslashes in the code
19:09:19 tom I'll change the others
19:09:25 k-fish addslashes()? make sure you only do this if magic_quotes is off...
19:09:45 k-fish ok, volunteers for checking the other modules?
19:10:01 k|p <- admin, settings
19:11:24 k-fish come on people :)
19:11:54 k|p is brr gone?
19:12:08 k-fish ok, i'll check partprog and outboard
19:12:26 k-fish and brr has to do the remaining modules :)
19:12:34 k-fish we'll see.
19:12:42 hondzik and i'look at settings
19:12:59 k-fish i will remove the check for magic_quotes_gpc=onn from setup then, ok?
19:13:17 tom ok
19:13:17 hondzik ok
19:13:26 k-fish fine.
19:13:42 k|p hondzik : i wanted to do that, there is no sql in there anyway :p
19:13:55 hondzik yeah, i know:)
19:14:10 k-fish very funny :)

logging functionality

19:14:22 k-fish next: 4. logging code. k|p, your turn...
19:14:24 hondzik so you can do settings and i'll take admin
19:14:32 k|p hondzik : k
19:15:16 k|p I wrote a simple class that allows you to log action/whatever like:
19:15:29 k|p $L->_log(ERROR, "Error opening module dir", __LINE__, __FILE__);
19:16:42 k|p there are different logging levels ... this may help in solving a few bugs if ppl add logs of thier sessions
19:16:54 k-fish can this be used statically? L::_log()?
19:17:05 k-fish probably... where is this configured?
19:17:11 k|p are number of things are logged like session, user, module, etc
19:17:27 k|p what do you mean staticlly?
19:18:06 k-fish well, do we have to do a global $L before we can use it? or can we just call it without creating an instance?
19:18:19 k-fish never used that feature, but it seems cool :)
19:18:46 k|p ow .. in functions ... erm .... dunno
19:19:58 k-fish well, anyway. would this be in userfunc?
19:20:26 k|p probably not ... but you shouln't log to much i think, more like check points in your code ... a lot of things fail without reason (a saw login problems on the list for example)
19:20:51 IpSo__ Does MGW have a "action log" ? ie: a log explaining all actions carried out in a certain module?
19:21:56 k|p IpSo__ : no, that's why i propose this. the admin module can be modified to view logs
19:21:58 k-fish k|p: if i add a logging call, is it done everytime, or only if some debug flag is set?
19:22:20 k-fish :)
19:23:14 k|p k-fish : when creating the class you can define the logging level: $L = new logger(ERROR|WARNING|NOTICE|INFO);
19:23:37 k|p the levels should be configurable somewhere
19:24:23 k-fish ok. so we'd have to create an instance early in the code, and configure log level there.
19:24:45 k-fish what do the others think about that? would you think this is useful for development?
19:24:46 IpSo__ k|p: But you stated you shouldn't log too much? What I'm getting at is a log that has entries such as: Joe Blow Logged In -> Joe Blow deleted appointment -> Joe Blow deleted contact -> Joe Blow Logged Out.
19:25:01 k|p yes, include the class in container and initiate it in appconfig somewhere
19:25:26 k-fish IpSo__: ah. that is something different. hm. do we need that? like a transaction log.
19:25:44 tom I think this can help finding bugs
19:25:48 IpSo__ k|p: Something like that, yes, it can get quite large (easily purged though) can be _very_ useful for tracing steps back. If your wondering where an appointment went, or who changed settings in a project and when etc...
19:26:42 k-fish maybe this can be done with the same function.
19:26:59 k-fish add it on important "checkpoints", as suggested.
19:27:09 brr Maybe the logging can show if someone has tried to hack into MGW?
19:27:23 k-fish and in normal use just log the most importnat stuff, and when developing, set debug level higher, and get *huge* amounts of data.
19:27:30 brr Maybe the user should have been closed after e. g. 3 or 5 wrong tries to log in.
19:27:32 k|p IpSo__ : yes, that would be nice .. log Joe Blow deleted as INFO ... logs are rotated after a certain size ... filepointer is kept open during the script so the only log time spent is writing so to disk ... a good kernel handles this ok :)
19:28:01 IpSo__ k-fish: I've implemented something similar on a current project I'm working on, and it has been invaluable. I log all kinds of things. Everything from failed login attempts, to editing/deleting/inserting any item in the application.
19:28:41 k-fish ok, would you two (IpSo__ and k|p) like to tune the concept a bit more, and propose a method for logging?
19:29:01 k|p IpSo__ : as long as you define enough log level, you can log anything (btw, my tab button dislikes you again :p)
19:29:06 k|p k-fish : gladly
19:29:17 IpSo__ ;)
19:29:19 k|p :p
19:29:46 k-fish ok. so we'll look forward to your proposal then :)
19:30:00 k-fish anything else on this topic?
19:30:13 k-fish maybe from a real user: brr, what would you like to log in daily use?
19:30:17 IpSo__ ability to set log levels per module?
19:31:00 k|p IpSo__ : we will make great things i think :)
19:31:09 tom globals should be better to read the logs ?
19:31:27 canani contact and public appointment updating or deletion
19:31:58 brr k-fish: Many wrong login tries should be logged, I think.... And deletion of shared appointments and contacts... If you delete your own contacts / appointments it is not so very important to log that...
19:31:58 k-fish canani: what is logged later depends on the module code.
19:32:11 k|p tom: huh?
19:32:16 k-fish brr: ok.
19:32:54 k|p tom : i am a little slow
19:33:11 tom ok
19:33:19 canani webmail attachments uploads should be logged too
19:33:41 tom yes
19:34:15 brr Maybe a log regarding how much space each webmail user is using???
19:34:27 k|p this is all up to the programmers, ipso and i will try to create the facilities to do so
19:34:52 tom not a log but an overview about all things regarding used disc space
19:35:35 k-fish ok. k|p is right, this depends on the module programmer later on.
19:35:38 k-fish next topic?
19:35:44 * k|p agress
19:35:49 IpSo__ k|p: ability to log to a file or db or file + db would on a per module, per log level basis be nice as well. :)
19:36:19 IpSo__ yes, next topic. :)

performance tuning

19:36:28 k-fish 5. performance tuning
19:36:39 k-fish this integrates with the last topic
19:37:03 k-fish if the logs provide timestamps, code using large amounts of time can be spotted probably.
19:37:20 k-fish and the there is database tuning.
19:37:49 k-fish someone (i'd have to search my emails for more details) talked to me about looking into adding indexes.
19:38:01 k-fish did you know we don't use any indexes yet? it's true...
19:38:06 IpSo__ async db queries for things like logs, so the page can still be sent to the user while log entries are taking place?
19:40:33 k|p do we want to do performance tuning?
19:41:01 IpSo__ k-fish: theres not a single index in the MGW schemas?
19:41:30 tom I'm indexing all emails ...
19:41:34 k-fish IpSo__: afaik not. some primary keys, which create implicit indexes, but...
19:41:49 k-fish tom: ok, so you're the hero if the day :)
19:42:10 tom (but only primary keys)
19:42:21 k-fish k|p: well, the person i talked to said moregroupware was very slow compared to other apps.
19:42:33 IpSo__ obviously, indexes are a must. :) I'm quite surprised to hear this actually.
19:43:08 k-fish i can put up a simple patch to enable SQL logging, and we could then EXPLAIN the SQL to find optimization potentials...
19:43:29 tom perhaps speed up by using frames ?
19:43:30 k-fish i can give this a start for the core parts, but i won't be able to optimize all modules...
19:43:31 IpSo__ postgresql has very nice features that can help build proper indexes and make sure they are used.
19:43:35 k|p i don't think any db creates keys without indexing them
19:43:43 k|p tom : noooooo
19:43:49 k-fish but we acces not only keys, that's the problem.
19:44:08 k-fish tom: frames: no. the overhead here does *not* come from loading the menu all the time :)
19:44:59 brr The webmail2 module is a bit slower than the rest of the modules.......
19:45:10 k-fish brr: well, it's rather complex.
19:45:31 IpSo__ proper indexes are a must, in even a small table (4000 rows), proper use of indexes can give 5-10x speed improvements
19:45:44 tom parsing emails connecting to pop3 / imap / smtp cannot be very fast
19:45:51 k-fish ok, i'll give this a start next week, and report the results to the mailing list. ok?
19:46:22 canani who said the performance problem is due to database accesses ?
19:46:45 k-fish this is likely. there may be other reasons as well, true.
19:46:54 k-fish any hints from you on this? experiences?
19:46:56 tom smarty ?
19:47:09 k-fish probably not. the fastest engine around, afaik
19:47:26 hondzik really big tables in html :(
19:47:30 tom what about the recompile-option is this always on ?
19:47:31 k-fish one can tune the settings for production use, though.
19:47:35 k|p the performance problems are probably due to bad program structure and db/query design
19:47:43 k-fish tom: that's what i meant :)
19:47:53 IpSo__ k-fish: do you know anyone who uses MGW on Postgres in production? They could enable statistics gathering in postgres and it will tell you which tables/indexes are used/not used, could be very useful to quickly squash the slowest areas.
19:48:21 k-fish k|p: yep. if we can imporve performace by simple changes SQL table design, we should do this first.
19:48:32 k-fish then look at the basic design failures.
19:49:10 k-fish hondzik: HTML cleanup needs to be done, true. i did it whenever working on a template, though there still needs work to be done.
19:49:33 k-fish Mozilla e.g. is much faster when not working in "quirks mode". this needs clean (X)HTML, though...
19:49:55 k|p my log class lets you time parts of code, like: $L->time("name"); while { bla; } $L->time("name") .. a log entry is then created that notes the time taken
19:50:32 k|p this will holefully help finding design faults
19:50:51 k-fish ok.
19:50:54 k-fish next topic?
19:50:58 k|p ok

PHP 4.0.x support

19:51:07 k-fish 6. PHP 4.0.x support
19:51:48 k-fish 20 responses on survey, 1 using 4.0.x
19:51:57 k|p current survey results? (and are they representative?)
19:52:12 * k|p is too slow
19:52:15 k-fish current, yes. representative, who knows?
19:52:23 IpSo__ k-fish: regarding my last statement -
19:52:23 hondzik ok
19:52:23 brr Will it be possible to get MGW to work really fast? As far as I can manage to understand the biggest problem is limitations in the browser technology....
19:53:01 k-fish IpSo__: noted, will read later :)
19:53:19 k-fish brr: in a LAN that should be not too big a problem...
19:53:37 hondzik I'm not sure about it, i'm running php4.1.2 but there is probably lot of people usong 4.0.6
19:53:45 k-fish anyway, if we dump 4.0.x support, we can switch to using $_GET and friends...
19:54:04 k-fish well, who is running moregroupware anyway?
19:54:25 k-fish a) locally, office or sth. probably an admin around, upgradin should be possible.
19:54:50 k-fish b) hosted server. most providers run current PHP, due to security fixes. no?
19:55:06 k|p b) yes
19:55:08 hondzik hopefuly yes
19:55:23 IpSo__ yes.
19:55:30 IpSo__ <-- works for web hosting company.
19:55:38 brr a) => No problems for me.... I can upgrade my three running MGW installations...
19:55:45 tom at least 4.1.x
19:56:01 IpSo__ we upgrade everytime an exploit is found. :) Otherwise we usually leave it alone.
19:57:02 k-fish one comment on the survey was: "Progress means updating"...
19:57:31 IpSo__ why would someone _not_ upgrade to at least 4.1?
19:58:21 hondzik there is no reason to not update
19:58:30 brr IpSo__: Not everyone is freaks like you. I can manage to install a Linux distribution, but not to upgrade PHP....
19:58:56 IpSo__ brr: distro's provide RPMs/debs to upgrade when exploits are found too.
19:58:59 brr IpSo__: But I run my three MGW installations at the moment on Windows NT. And at NT I know how to upgrade!
19:59:19 hondzik brr: :)
19:59:35 tom even SuSE gives updates for 4.1.x for 7.3
19:59:38 brr IpSo__: Hm. Yes. No... I have tried some upgrades. Allways dependencies - problems...
20:00:06 IpSo__ brr: yes, thats valid. I suggest apt-rpm. :)
20:00:21 k|p brr : but mostly mgw will be installed by a sys admin on the system of his choice ... if he is not the sys admin there will be one around who is able to ungrad it, i think
20:01:04 brr No big deal for me... As you have said everyone should run new PHP versions because of security reasons...
20:02:15 k-fish ok, so will we dump 4.0.x support then?
20:02:30 canani RH provides P{HP upgrades for 7.xx due to security vurnerability.
20:02:32 k-fish or shall we ask for votes on the user mailing list first?
20:02:53 hondzik we should ask the list
20:03:16 k-fish ok, i'll do it.
20:03:30 k|p did we not do that with the survey already?
20:03:31 k-fish how long should voting be "open" then?
20:03:57 k-fish well, i asked what versions were used - not if people would mind dropping support for 4.0.x
20:04:02 hondzik till next monday?
20:04:10 k|p true
20:04:56 k-fish monday - ok. my SQL portability fixes will have to wait until then, I'm afraid. i used $_SESSION all over the place, and only wnat to change that if needed :)
20:05:03 k-fish s/wnat/that
20:05:11 k-fish s/wnat/want
20:05:17 * k-fish is confused :)
20:06:46 k-fish next topic?
20:07:05 hondzik yes, I'll have to go in 20 minutes :(

error reporting and E_ALL

20:07:56 k-fish 7. error_reporting E_ALL. hondzik, go ahead.
20:08:09 k-fish has been your suggestion, after all :)
20:09:23 hondzik I tried to set error_reporting to E_ALL. it makes a lot of warnings in all included files :(
20:09:31 tom is E_ALL the same as E_ERROR | E_WARNING | E_PARSE | E_NOTICE ?
20:09:36 hondzik like module_exec,...
20:09:52 hondzik yes, it's the higher level :))
20:10:04 k-fish most about uninitialized variables, right?
20:10:22 hondzik we are using a lot of unitialized variables, especially array indexes
20:10:25 IpSo__ I heard warnings do degrade performance... so this could be part of the performance tuning topic?
20:10:37 k-fish can mostly be fixed by checking with isset() before using a var, i guess
20:10:45 k-fish IpSo__: only if you log those, i guess.
20:10:58 hondzik I did'n hear this, but if it's true it's real break
20:11:11 k-fish for a production system, i'd set logging to some lower level anyway
20:11:18 IpSo__ E_ALL promotes good coding practice too.
20:11:19 k-fish hondzik: true.
20:11:24 k-fish IpSo__: true :)
20:11:50 IpSo__ though, I think I turn E_ALL off in phpGACL... I should double check that. :)
20:12:04 k-fish but: do we need some coordinated effort to clean this up, or can we lay this in the hands ot the module coders?
20:12:15 k-fish and who takes care of the core code?
20:12:22 hondzik E_ALL is too high, but we should decide on some level
20:12:36 k|p why is it too high?
20:12:45 k-fish without E_ALL i don't get any erros at all, so...
20:12:54 k|p i would vote for the coders taking care of it
20:13:08 k-fish (aside from really having broken something)
20:13:14 k-fish k|p: and the core?
20:13:22 k-fish userfunc, etc?
20:13:29 hondzik maybe it's not too high, but it'll we a lot of work to fix it :))
20:13:40 k-fish hondzik: would you be willing to do that? ;)
20:13:52 k|p hondzik : yes, but it only has to be done once and we're clear
20:13:54 hondzik the core and calendar are probably the bigest problems
20:14:07 hondzik k|p: right
20:14:11 --- Notify: newb is offline (
20:14:33 hondzik in the core is lot of oninicialized indexes in arrays
20:14:39 brr Hopefully someone fix the buggy calendar module... I really need a "bug free" calendar!
20:15:20 hondzik brr: k-fish did a lot of work on calendar and I'll try to work on it too
20:15:48 brr Yes! K-fish has done A GREAT JOB with the calendar. But some bugs still live. Regarding rights.
20:15:58 k-fish ok, we can decide on the "who" later, i'd say.
20:16:26 k-fish summary: we want to have the code as clean as possible, but fixing severe bugs has higher priority. right?
20:16:30 hondzik you're right, but the rights system is more complex problem which we have to discuss
20:16:49 k-fish yep, that is the next-but-one topic :)
20:16:56 --> Li ( has joined #moregroupware

XSS exploits, security

20:17:01 k-fish real quick on 8. XSS exploits
20:17:22 k-fish someone suggested to make it possible to restrict access to just the IP that started a session.
20:17:41 k-fish i like that idea, and will try to add that to the code. ok?
20:17:51 tom a simple checkbox when logging in
20:18:03 hondzik i like it too
20:18:04 k-fish with a checkbox on the login form, yep, to disable it in case of problems...
20:18:18 k-fish ok. anything else on this?
20:18:23 brr If you access MGW through a proxy? What will happen??? Will MGW log the real IP or the proxy IP?
20:18:27 k|p k-fish : you were against that a while ago because some ppl get new ip's from there providers
20:18:40 hondzik maybe it should be in some general settings for admins only
20:18:42 k-fish k|p: yep, but if one can disable it when logging in...
20:18:58 k|p does anybody know if this ip changing goes any furter than C-subnets?
20:19:05 k|p k-fish : thue
20:19:18 k-fish hondzik: this way you could either disable or enable it... the other way case to case.
20:19:42 IpSo__ k|p: yes it most likely can.
20:19:44 k-fish maybe mixing this is possible: the admin can disable disabling of the check when logging in. (clear?)
20:20:04 hondzik clear :)
20:20:10 k-fish fine :)
20:20:27 k-fish i'll write up a proposal and post it to the list.
20:20:29 IpSo__ you could do other checks... if IP causes problems.
20:20:36 k-fish examples?
20:20:42 k|p IpSo__ : ok, pitty :)
20:21:14 IpSo__ they might be the greatest, but you could grab the user-agent string + screen res etc... match against those instead perhaps?
20:21:25 k|p store session keys in session and recompute them when the session is accessed again
20:22:22 k-fish k|p: huh?
20:23:15 k|p yes, as ipso proposes, hash that data and store it in session, it should be the same next time round, so when you try to access the session again, the same data is hashed, compared, and if it is the same, you know the same user is accessing the session
20:23:26 IpSo__ stats programs grab all kinds of information from the browser... combining as much of that as possible could do the trick if IP's cause problems.
20:24:42 k|p does register globals = off fit in here?
20:24:45 k-fish ah. ok.
20:25:02 k-fish k|p: this should be the goal ASAP, anyway!
20:25:10 IpSo__ or use SSL and don't worry about it?
20:25:16 k-fish fits better in the next topic...
20:25:27 k-fish IpSo__: that is possible anyway. i use it that way.
20:26:20 k-fish forgte my "ntext topic" nonsense above...
20:26:43 k-fish XSS get's really hard when register_globals is off, yes.
20:27:43 k-fish but when someone adds a JS call to some data that is later put into the HTML page, and sends the cookie to some remote server, one still can steal a session. therefore the check on the ip, etc...
20:28:02 k-fish but register_globals=off should be possible, true.
20:28:30 k-fish ok, 9. rights management now?
20:28:39 k-fish or some more on XSS and security?
20:28:56 k|p k-fish : but if you use enough data in the session key, the stealer will have a very hard time mimicing it all
20:29:21 IpSo__ k|p: yes, its not perfect, but thats the idea.
20:29:35 * brr does not care so very much about the security as MGW is used only in the LAN at the inside of firewalls.
20:29:42 IpSo__ actually...
20:29:56 IpSo__ k-fish: every look at and how they do it?
20:30:18 k-fish IpSo__: no. interesting?
20:30:21 IpSo__ they don't use SSL at all... but I think they have some nifty challange/response thing setup.
20:30:40 IpSo__ clear text passwords aren't sent over the wire... but they don't use SSL.
20:31:03 IpSo__ I found it interesting... not sure if it will help us here or not though.
20:31:11 k-fish ah. phplib did that for some years. md5 using javascript, and send that over the net.
20:31:35 k-fish you can still steal the sent hash when not using SSL, though.
20:31:55 k-fish to protect the actual passwords, SSL or IpSec or ... is the way to go.
20:32:01 IpSo__ yes, but they use a challange/response to guard against that I think.
20:32:16 IpSo__ VNC does something similar too I think.
20:32:21 k-fish hm. we should have a look some time.
20:32:47 k|p but mgw does not need to be so secure somebody would want to waste loads of processor time thying to decrypt the hash (which is near imposible anyway)
20:33:06 k|p s/thying/trying
20:33:17 hondzik sorry, I have to leave now:( I will read your discusion tomorow
20:33:24 k-fish k|p: true, but if only the hash is sent, then you can inject that without the need to decrypt it.
20:33:25 --- hondzik is now known as hondzik_logging
20:33:44 k|p k-fish : ah, of course :)
20:33:55 IpSo__ yes, no decryption needed.
20:34:29 IpSo__ again, the "proper" way is to use SSL... but there are alternatives that can work quite well.
20:35:15 k-fish next topic? it's getting late...
20:35:51 k|p yes, somebody should have told me to have dinner before this meeting :)

rights management

20:36:03 k-fish 9. rights management
20:36:20 k-fish k|p: those sessions always take longer than you think :)
20:36:40 k-fish k|p, IpSo__: your turn, right?
20:37:28 k|p nothing from me, go ipso! ... :p
20:38:08 IpSo__ well, the gf is out of town for 10 days, so I should have lots of time to work on phpGACL. ;)
20:38:29 k-fish ok, to give the others some more info:
20:38:48 k-fish IpSo__ works on phpgacl, right?
20:38:57 k-fish ah, btw, the survey results:
20:39:07 IpSo__ A minor feature release will be coming soon, then hopefully I can try getting a small module in MGW to use it.
20:39:22 IpSo__ k-fish: Yes,
20:39:55 k-fish unix like permissions (rwx) lead with 20/58
20:40:08 k-fish then follows ACL with 19/58
20:40:22 k-fish then current system with 16/58
20:40:28 IpSo__ wow, close.
20:40:57 k-fish so the unix rwx system "wins", but i think ACLs would be a better solution.
20:41:06 IpSo__ well, ACLs can "mimic" rwx, and I would think the "current system" as well.
20:41:17 k-fish as one of you stated, most people know relatively less about ACL systems...
20:41:26 k-fish IpSo__: true.
20:41:32 IpSo__ in the intrest of not making 19/58 people upset, it might be worth using an ACL system. ;)
20:41:41 k|p agree
20:41:46 k-fish yep.
20:41:58 IpSo__ however...
20:42:07 IpSo__ ACL system == much more processing power.
20:42:27 k-fish in what sense?
20:42:51 IpSo__ well, its much more powerful, so if people start using all its features...
20:43:41 IpSo__ now your checking permissions on every contact, or every note, or every appointment for any number of different possible permissions.
20:44:28 k-fish ok, but people keep asking for the possibility make an entry only visible for users of a certain group, etc.
20:44:35 k-fish so they obviously want those features.
20:44:53 IpSo__ right, its a tradeoff of course... but measures can be taken to minimize the disadvantages.
20:45:07 IpSo__ I've already added hased directory caching in phpGACL, which greatly improves the performance.
20:45:17 k-fish yep. read that...
20:45:27 k-fish what else would you suggest?
20:45:43 IpSo__ your looking about 5ms per acl_check() that hits the db, and about .5-1ms that hits cache.
20:46:18 IpSo__ so, I can see some cases where you would have 1-5 acl_check()'s per "row", or per "contact"
20:46:56 IpSo__ so you display 10 contacts to the user, that could be 50 acl_check()'s or about 250ms if all of them hit the db.
20:47:19 k-fish not too bad
20:47:43 tom what about a directory structure with 500 checks ??
20:48:04 k-fish where would that happen?
20:48:07 IpSo__ 500 checks that all hit the cache? 500ms roughly.
20:48:33 tom I'm planning rights for public email folder
20:48:57 IpSo__ see, a row that has 5 acl_check()'s, usually 90% of those will be the same one each time.
20:48:59 k-fish ok, but you would only have to check for the items you actually are going to display.
20:49:44 k|p and hence the problem ... you don't know that till after the acl_checks
20:49:57 k-fish yep. another thing that comes to my mind: will it still be possible to use ADOdb's paging feature?
20:49:57 IpSo__ phpgacl caches in memory, per page load to speed things up even more, so subsequent acl_check()'s that are identical are very light.
20:50:34 k-fish or will we have to enhance that to take ACLs into account?
20:50:44 IpSo__ k-fish: paging has to be looked in to more, but adodb can be extended so it would work.
20:51:02 IpSo__ again though, that is where performance can become an issue too.
20:51:25 k|p that would the best solution, but would make upgrading adodb an issue
20:51:54 IpSo__ I can't see what we can do about it though, if someone has 1000 contacts that some user _may_ be able to see, we have to check permissions on all 1000 to find out for sure.
20:52:47 IpSo__ k|p: not really, adodb is all OO, so I can easily include a class that extends it with phpGACL, I can't see that being much of a problem at this point.
20:53:05 k-fish ok.
20:53:26 IpSo__ k|p: it should only be a small number of functions, yes there will have to be some maintenance, but I think it would be minor.
20:53:33 k-fish IpSo__: do you think you could write a proposal in the next two weeks?
20:53:57 k-fish we shouldn't try this before 0.6.6, there are other issues as well. don't mix too much :)
20:54:08 k-fish so we have some time for this to prepare.
20:54:14 IpSo__ k-fish: I'll see what I can do, I actually have never looked at MGW beyond the online demo. so that will be the first step. :)
20:54:35 k-fish well, don't be shocked :)
20:54:38 IpSo__ k-fish: when is 0.6.6 scheduled to release?
20:55:02 IpSo__ and which module do you think would be the easiest/best to test phpGACL on?
20:55:06 k-fish IpSo__: there is no scheduled date yet. after the changes to SQL have stabilized enough...
20:55:34 k-fish IpSo__: easiest probably notes or todo, most useful probably contacts
20:56:01 IpSo__ k-fish: okay, in the coming weeks I will see what I can do and keep you all updated.
20:56:12 k-fish ok, more on this?
20:56:15 brr Hm. Will the new rights part solve bug # 613245?
20:56:50 k-fish yep, this should be fixed along the way...


20:57:33 k-fish next (last) topic: module API
20:57:37 k-fish a broad issue...
20:58:22 k-fish and probably makes sense to talk about that after things like module manager demands, rights, etc. have been discussed more in depth...
20:58:23 k-fish or?
20:58:41 k-fish k|p_: do you have some plans for a new overview module?
20:59:04 k|p k-fish : only plans
20:59:05 k-fish this would be another prerequisite for a module API: how to provide overview functions
20:59:26 k-fish ok, so i guess we can shift the module API topic on to a later IRC session. opinions?
20:59:34 k|p that would be the main issue
20:59:52 k|p fine with me ... we have much to do anyway :p
21:00:05 k-fish true :)
21:00:26 k-fish ok, thank you everybody for joining tonight.
21:00:52 k-fish as promsied i'll summarize the session, i can't promise to do it this week, though...
21:01:01 k|p np
21:01:24 tom f-fish: thank YOU for leading this session
21:01:48 k-fish tom: you are welcome :)
21:01:53 tom s/f-/k-
21:02:03 k-fish :)
21:02:30 k-fish ok, i declare open discussion now :) have fun...
21:02:33 k|p happy coding everybody :)
21:05:02 <-- tom has quit ("Leaving")
21:05:05 k|p IpSo__ : talk to you next week about logging
21:05:15 k|p bye all
21:05:23 k-fish bye
21:06:18 --- You have left channel #moregroupware ("good night...")