Good day, team
The Fedora legal team has discovered a potential licensing problem in
the PHPExcel library bundled with phpMyAdmin. If true, and I am not a
lawyer but it seems they are correct, that puts phpMyAdmin itself in
violation and Fedora would then remove our package until we resolve the
licensing problem.
The report is at https://bugzilla.redhat.com/show_bug.cgi?id=629214 and
the Tom there is from the Fedora Legal team, Robert is the (friendly)
Fedora phpMyAdmin maintainer who I've also copied on this message (who
first came to us on IRC to discuss this problem).
It looks like the problem had been reported to the PHPExcel in February
of 2010 but not resolved
(http://phpexcel.codeplex.com/Thread/View.aspx?ThreadId=83335).
Robert's also mentioned that they're investigating a similar claim
regarding tcpdf; I believe that discussion is at
https://bugzilla.redhat.com/show_bug.cgi?id=548260
Regards,
~isaac
Hi,
Query statistics tab greatly increases page load time in my browser -
I get about 5s delay before tabs are created which is IMO too slow.
Removing "<?php printQueryStatistics(); ?>" from the code decreases it
to less than a second and causes page load event to be fired about 10
seconds earlier (at 2nd second instead of 12th).
I think this should be fixed, eg. by initializing chart only when user
actually navigates to it.
--
Regards,
Piotr Przybylski
Michal,
not to long ago I thought I saw codemirror highlighting mysql keywords
in red. Now there seems to be no related css classes for the
highlighting anymore. Was this change on purpose?
I managed to break the Jenkins build :(
This happened when I was fixing a bug where triggers cannot be
associated with views, as reported by Madhura on the list. Well, I just
added in some calls to PMA_table::isView() to fix the issue, but the
PMA_table class calls PMA_DBI_get_tables_full() which is not defined in
unit tests. I'm not sure how I can fix this. Any ideas? Thanks.
Rouslan
Hi Rouslan,
Are triggers applicable to views?
I had errors when I tried to create a trigger on a view. MySQL documentation
says that you can not associate a trigger with a view [1].
So I suggest we hide the 'Triggers' tab while browsing a view. And also
removing views from the 'Table' drop down in the 'Create Trigger' dialog.
--
Thanks and Regards,
Madhura Jayaratne
[1] http://dev.mysql.com/doc/refman/5.0/en/create-trigger.html
Hi Tyron,
On 20 Jul 2011, at 17:12, Tyron Madlener <tyronx(a)gmail.com> wrote:
>
> I have a good idea in this regard. When we have all "Hint"-tooltips
> centralized, we could easily add a config setting to disable all hint
> tooltips. That might be very convenient for advanced users.
>
I agree with you. Advanced users may not want to see the hints everytime they use phpMyAdmin. I'll try to add this configuration after I finish the grid editing feature.
P.S. I think you accidentally press Reply instead of Reply All in your gmail, so your message only delivered to me, instead to the list.
--
Aris Feryanto
Hi all,
While attending to a bug [1], I came across the following.
Suhosin imposes a limit of 512 on the length of the variable that can be
passed via a GET [2]. This is often problematic as in PMA we encounter long
parameters (long sql queries, where clauses when no unique key is there
etc). Due to the same problem [3] $cfg['LinkLengthLimit'] configuration was
lowered to more stricter 1000 from 2000, which is more acceptable.
In this particular bug the problem is that, though the URL length is under
1000, one parameter, 'sql_query', violates the Suhosin limit. What
should be our stand on this. Should we adhere to Suhosin default values?
In 3.5 we have a possible solution for this [4] and we can still lower
$cfg['LinkLengthLimit'] value without losing the look and feel. However this
needs to have JS enabled and I'm not sure whether we want to impose that
condition for the 3.4 series.
--
Thanks and Regards,
Madhura Jayaratne
[1]
https://sourceforge.net/tracker/?func=detail&atid=377408&aid=3380946&group_…
[2]
http://www.hardened-php.net/suhosin/configuration.html#suhosin.get.max_valu…
[3]
https://sourceforge.net/tracker/?func=detail&aid=3358750&group_id=23067&ati…
[4] https://sourceforge.net/mailarchive/message.php?msg_id=27839987
Hi,
I would like to propose some changes to demo server configuration
which would testing of edge cases a bit easier. Lately I've seen a few
bugs related to data escaping which would manifest only in some edge
cases and two issues with AJAX that could be discovered earlier if
demo server's configuration would be changed a bit. Some of them were
really old, some relatively new.
1. Data escaping.
Everyone seems to remember about PMA_backquote() and escaping
database data, but htmlspecialchars() for database and column names is
sometimes missing, as well as PMA_escapeJsString(). With database
`evil*/>` and table `evil'"*/>`(`so_<a'm>*/_i`, `quo"te`, `comm<!--
ent`, `plain`) I immediately broke some functionality (currently I
can't recall what it was exactly), and I suppose we can have a few
more such cases.
2. `server` variable.
Demo server and possibly all student's servers run MySQL database as
server 0, so that all cases of missing variable go unnoticed. For me
fun started with server 1, when phpMyAdmin randomly warned about me
missing variables due to changed security token. After some digging I
discovered that this happened due to missing/broken 'server' argument
in AJAX query, which caused PMA to regenerate this token and rendered
some links with the old one unusable.
So, I propose to:
1. Exchange MariaDB and MySQL databases in config file.
2. Change automatic login to select MySQL database which now has index 1.
3. Create some sample database with tables and columns which are
potentially dangerous.
Also, create a guidelines for future GSOC with a sample configuration
consisting of two servers (the first one can be a broken fake, student
should work with the second one) and a SQL script which creates tables
from point 3. above, with some explanation on escaping and that MySQL
identifiers can also contain dangerous data (not a security issue, but
it do can break page layout).
--
Regards,
Piotr Przybylski
Hi
...resending to the list...
Dne Thu, 4 Aug 2011 21:13:16 +0300
Tyron Madlener <tyronx(a)gmail.com> napsal(a):
> On Thu, Aug 4, 2011 at 8:51 PM, Michal Čihař <michal(a)cihar.com> wrote:
> > This is just limiting access to file_echo.php to users who are allowed
> > to use phpMyAdmin (and thus have login to MySQL). I see no reason
> > having publicly available echo service in phpMyAdmin.
>
> But don't you need valid mysql credentials to get a session (and token) anyway?
Yes, though the token might be valid longer than MySQL credentials, so
it's better to check both.
> Since the file uploading is handled by the browser, I cannot think of
> a case where you can upload a file unintentionally, or in any way get
> it uploaded through other means than manually uploading it yourself.
> I'd be really curious to know how a hacker can do anything malicious
> in this direction.
You can easily place form on other page and redirect it to this file.
This is data you receive from outside, you should never trust it.
> > If you don't need any HTML code inside, htmlspecialchars will help
> > here. Also if you set content type to JSON, browser will not process it
> > as HTML.
>
> Ah yes, great solution :)
> It just didn't into my mind to actually change the http header, even
> though its so obvious.
> I'll change that today.
Okay, please base changes on current master, I've made numerous changes
to that file.
--
Michal Čihař | http://cihar.com | http://blog.cihar.com