This restores the behaviour from before the move to utf8mb4 and should help legacy blogs not having charset issues, that went from latin1 to utf8 to now utf8mb4
See #655.
I don't understand the code either (I don't even see
where this code path belongs to - do we have a
facitlity to show comments "from ... to"?), but
the current regexp is obviously wrong, and the
one suggested by @hannob is obviously
(syntactically) correct, so it should be no
problem to change that.
Fixes#655.
Signed-off-by: Thomas Hochstein <thh@inter.net>
We don't need to check against the filename
without extension, because it's only the
extension that may be problematic.
Signed-off-by: Thomas Hochstein <thh@inter.net>
Steps to reproduce:
1) Upload a PHP script to the Media Libray,
naming it "test" (or any other name
without extension).
2) Rename it to "exploit.php." (trailing dot!)
On Linux, the file will be renamed to
"exploit.php..", which is safe and
cannot be exploited.
On Windows though, the file will be
renemad to "exploit.php" and is then
remotely executable by calling it
from "/uploads/exploit.php".
Thanks to Junyu Zhang <rgdz.eye@gmail.com>
for spotting this!
Signed-off-by: Thomas Hochstein <thh@inter.net>
After fixing the other ML file renaming bugs,
it was now possible to rename a file without
extension into a file that *does* have an
extension - so we need to check against
active content.
Signed-off-by: Thomas Hochstein <thh@inter.net>
The renaming code added a dot '.' to the
filename on disk even if the file hat no
extension. Therefore, the file name on disk was
different from the name in the database,
triggering the database purging code on the
next ML display.
(serendipity_displayImageList() will delete
files from the database that don't exist
any longer on disk.)
This code won't add spurious dots for
empty extensions, keeping disk and
database in sync.
Signed-off-by: Thomas Hochstein <thh@inter.net>
Completing 1ed4b9e7eca2a0c371582a454c232c
As we already have an (unused) language
constant for this error, we seem to have
had this kind of check before ...
Signed-off-by: Thomas Hochstein <thh@inter.net>
* plugin_api.inc.php:
- Add static list of bundled plugins.
- Add function to check if plugin is
bundled.
* plugins.inc.php:
- Set source of plugin
(Spartacus, bundled or local).
* plugins.inc.tpl:
- Display plugin source.
* Add language constants.
Signed-off-by: Thomas Hochstein <thh@inter.net>
When installing / updating plugins, plugin data
is fetched from Spartacus first; those plugins
will habe "Spartacus" as "pluginlocation".
Later on, information about installed plugins
is fetched from cache / database, overwriting
the previously fetched data for all installed
plugins. After that, "pluginlocation" is
"local" even for plugins that live on
Spartacus if they have been installed.
So we save "pluginlocation" data to a new
"pluginsource" field before merging /
overwriting so we can detect plugins that
are available on Spartacus.
This data is present in plugins.inc.tpl
and can be used there.
Signed-off-by: Thomas Hochstein <thh@inter.net>
Note: Native to utf8 will not work if the data in the database table is actually utf8! These are helper functions for during the alpha, to make testing easier, not tasks for the beta/stable
utf8mb4 did not work on a test server with large prefix (=not 3000 byte index limit, only 1000) on Depian 9/mariadb 10.1.44, because the row format was not barracuda (by default?)
If $limit is empty(), no limit is set, so we can
set the LIMIT statement to "" to achieve the same.
But an empty() $limit can be "0", so the
generated SQL statement could end with "0"
instead of the LIMIT statement. We catch this
with forcing an empty() $limit to "".
Fixes#636.
(No matter that this shouldn't even happen.)
Signed-off-by: Thomas Hochstein <thh@inter.net>
