[Phpmyadmin-devel] Re: Debate on using newly added PHP (and MySQL) functions in core phpMyAdmin functions:
Hi Geert! Debate? Which debate? It's a requirement, isn't it?
And this is defenitly also the most correct way to solve the problem - as array_unique first was introduced in PHP 4.0.0 and by the way was broken in PHP 4.0.4
Right and It's also the nicest and the quickest way to do it ;)
This also calls for a general "WATCH OUT" to all us developers - please keep in mind that "core" phpMyAdmin functions must not rely on newly added PHP functions - as phpMyAdmin is used on many platforms that has not been....
Well I thinks this is what we have done till now and that's the main reason for the "defines.inc.php3" library. BTW you forgot to write that PMA should be use with most (all) browsers, let's say from Lynx/NS3 to IE6/Moz 0.9.4.
Comments on this is welcome and appreciated
Done ;) Loïc ______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif
Hey again :-)
Debate? Which debate? It's a requirement, isn't it?
Well, if we decides that we don't give a damn about older software-versions then we can do it - so we must start with agreeing that it's a requirement and not an option... But hopefully we all agree - but I mention it because we are many people in the development team - and because more and more people (users) suggest ways of improving the source code - and my point was that not all bugfixes may just end up implemented in phpMyAdmin without checking (and maybe even discussing) security and compablity issues... My greatest fear at the moment is that with all the many code-changes that's made every day - that we start to compromise with both security and compability issues - and with this very powerfull database administration tool - it's IMNSHO very - very very - important to always keep security issues as a top priority - it's better to leave out a fancy feature to later implementation - than to just give a damn about the security and hope that it'll be fixed later... (that's also why I think that the website and documentation might need an update stating that it's a very bad idea running CVS development versions in productions environments) and maybe we ought to start supplying fix patches to the current final version - specially when security issues is adressed, resolved and corrected. Instead of just keep telling people to upgrade to the latest CVS development version where the fix has been supplied. Get my thoughts?
Well I thinks this is what we have done till now and that's the main reason for the "defines.inc.php3" library.
I certainly agree - and let's all keep doing it that way! But we've need to remind us selves about this from time to time ;o)))
BTW you forgot to write that PMA should be use with most (all) browsers, let's say from Lynx/NS3 to IE6/Moz 0.9.4.
Again - I coulden't agree more - it's more important to keep browser compability (for usage on many platforms and in many browsers) than to make nice, fancy and keen view features that's only working in the newest version of IE etc. -- Kind regards Geert Lund
Geert Lund - SilverSoft Productions a écrit :
Hey again :-)
Debate? Which debate? It's a requirement, isn't it?
Well, if we decides that we don't give a damn about older software-versions then we can do it - so we must start with agreeing that it's a requirement and not an option... But hopefully we all agree - but I mention it because we are many people in the development team - and because more and more people (users) suggest ways of improving the source code - and my point was that not all bugfixes may just end up implemented in phpMyAdmin without checking (and maybe even discussing) security and compablity issues...
My greatest fear at the moment is that with all the many code-changes that's made every day - that we start to compromise with both security and compability issues - and with this very powerfull database administration tool - it's IMNSHO very - very very - important to always keep security issues as a top priority - it's better to leave out a fancy feature to later implementation - than to just give a damn about the security and hope that it'll be fixed later...
Geert, I respect the points you mention, but I would like a clarification on your part. Are you only "feeling" a fear, or do you have facts to back your point that the code-changes are starting to compromise security and compatibility? The beauty of open-source development is that anyone can see the changes and send warnings to a developer or to the list; and I think that all developers here are open to discuss their changes and improve our collective skills. Marc
Hey Marc (and others)...
I respect the points you mention, but I would like a clarification on your part.
Shoot away ;O)
Are you only "feeling" a fear, or do you have facts to back your point that the code-changes are starting to compromise security and compatibility?
No, no, I woulden't say that any of the developers on the project in generally has started to write code that compromise security or compability... But I call for the awareness of the dangerous path of development being maintained on a large project with many developers and even more users helping with supplying bugfixes and feature improvements/enhancements - as I see it for the moment the code is very stable and the security is good - but with the many code-rewrites and more code-rearrangeing that's made, we should keep more and more attention to not only checking the code for browser-compability - but also checking that security isen't compromised with the many code-changes. And I still haven't seen any discussions on any code-rewrites - that's about whether the change might create a security issue or not - and most of our testusers (that uses the CVS version) will not sit down and test code for security breaches, but only that new (and old) features work correct - with the correct (and legal) use of phpMyAdmin. So I was in no way attempting to imply that any on the developer team writes lazy/faulty code or anything that... With my starting mail - I simply wanted to draw attention to an issue that might become a problem in the long run - if we just keep our minds into feature-enhancement (and feature-bugfixes) and fancy things in general - and not stay focused on the importance in writing code with as few security breaches as possible. A good example is the inclusion of the phpinfo.php3 file - which provides really important information about the server that phpMyAdmin runs on - and nobody had their attention to including the AUTH-check in this file... A mistake that wasen't fatal in any way - but the next mistake might be far more fatal... My question to some thoughts (in which my original post was intended): can we afford to make fatal mistakes in this matter - in an administration application used by 100.000+ users around the world - used by administrators, developers, ISPs etc. etc. etc. - can we afford to _hope that_/_rely on_ some one will find the security holes before the release of final-versions of phpMyAdmin? Just because we all might be caught up in rewriting code and enhancing features or adding new fancy stuff (because that's far more fun than to check already written code) ;o) Hope this clears it up a bit? But please anybody - do comment in any way - because I think that focus on this subject is in any way for the best of phpMyAdmin ;-))) PS. It might look like I'm being paranoid - but I work as a web system developer at the largest ISP in Denmark (TDC Internet), and has to keep focus on security in all that I do :-/ (sometime it would be more fun just write new stuff and fuck the 'bad' code I've written i the past - but I don't think that my employer think it's fun when someone compromises the security, database-integrity etc. Wow - that was a long answer :-))) But in any way - I'll check out the code more closely and see if I can find stuff that might be a problem - as soon as I'm done with the server-cluster setup I'm doing these next couple of days :-))) -- Kind regards Geert Lund
participants (3)
-
Geert Lund - SilverSoft Productions -
Loïc -
Marc Delisle