E107: Duplicate private message menu items

[realmontazeri]

pm_menu (pm) and private_msg_menu (pm) are duplicates items in menu management.

[Jimmi08]

I can't confirm this. 2.3.1

@realmontazeri screenshot would be nice. With Chrome you can paste them directly without local saving.

[realmontazeri]

I can't confirm this. 2.3.1

@realmontazeri screenshot would be nice. With Chrome you can paste them directly without local saving.

So, how do I remove this duplicate item in my panel?

[Jimmi08]

via FTP check the content of your PM plugin and delete it manually (compare with 2.3. version). You can use the rescan plugin directory tool then.

[realmontazeri]

via FTP check the content of your PM plugin and delete it manually (compare with 2.3. version). You can use the rescan plugin directory tool then.

pm_template.php and private_msg_menu.php from 2018 were the issue, why file inspector didn't detect those files?

[CaMer0n]

@Deltik Any thoughts on this one?

[Deltik]

When I copy the files

• e107_plugins/pm/pm_template.php
• e107_plugins/pm/private_msg_menu.php

from e107 v1.0.4 into my e107 HEAD test installation, File Inspector flags them as insecure files, which I believe is the intended behavior:

File Inspector also flags those files regardless of the installed e107_system/core_image.phar file. I can't find evidence of File Inspector not detecting those files based on the provided information.

[Moc]

Hmm alright. I do think we need to tweak it a little because those files are not 'known to be exploitable'. It has nothing to do with security. These files are just replaced or obsolete, and need to be removed to avoid issues like the one reported in the original issue report.

[Deltik]

Erm, I just noticed that @CaMer0n changed the e_file_inspector behavior. Now, all old files are marked as insecure instead of just the files on the insecure list.

This was not the behavior I intended because old core files are not necessarily insecure files. @CaMer0n, is the intended behavior to prompt for the removal of old core files? If so, that information should not be stored in e_file_inspector::$insecureFiles.

---

For reference, this is what should have been displayed by File Inspector with a populated e107_system/core_image.phar:

[Deltik]

Okay, I see what started the confusion: The insecure file list was stored in a variable called admin_start::$deprecated, which conflated what was deprecated and what was insecure.

[Deltik]

I've fixed the file inspector so that it no longer confuses insecure files with the cached list of deprecated files generated on the previous run: https://github.com/e107inc/e107/commit/2eebd4f0ca7088cd2672d0e95567dba60322e4c2

[Deltik]

@realmontazeri: File Inspector would not have detected the old core files if you are running a Git revision. The core integrity image (e107_system/core_image.phar) is currently not automatically loaded for each Git revision. Only packaged releases contain the core integrity image.

Auto-downloading the core integrity image for every Git revision is on my wishlist.