New built-in Plugin Admin (Plugin Manager) is ready

dail

My first thoughts:

The MD5 of just the main plugin DLL is not enough. This does not prevent MITM at all. Many plugins come with other DLL or Jar files which could just as easy contain malicious code. One could also argue that even text based config files or scripts could be modified to do malicious things.
Having the json file in the exe is nice for verification…but one of the biggest grips with the old plugin manager is that the list of plugins were not updated frequently enough. This caused plugin developers (such as myself) to worry that if there was a severe bug in their plugin being downloaded…there was a long time before there could be a fixed version available to users. This is even harder because there is no set schedule that the plugin list will be updated since it is dependent on Notepad++ being updated…which varies widely.

Security is like sex: when it's good, it's very, very good; when it's bad, it's better than nothing.

I would argue security is like a condom, it has to work perfectly, because even the slightest flaw means it is useless.

cmeriaux

@donho can you add the release date information for each plugin ?
We could sort the plugin list with its release date in the GUI and find rapidly the new plugin released recently.

Thanks

chcg

My assumption would be that it is planned to release\update the nppPluginList.dll independently of the N++ releases.
Is this correct?
I guess the merging of the PRs at https://github.com/notepad-plus-plus/nppPluginList might be a bottleneck in case of urgent plugin bugfixes.

With NppFTP the plugin start after installation via PluginAdmin while N++ is running seems not to work. It is using docking. Is there something for plugins to fullfill?

dinkumoil

@donho

I found another pitfall in the new PA.

The old PluginManager copies the plugin’s DLL file to the harddisk and performes a restart of Npp after that. Thus it is guaranteed that the NPPN_READY notification is send to all plugins when Npp starts up. In a handler of this notification plugins can process some initialization tasks required to work properly.

The new PA doesn’t init a restart of Npp. Thus after installing plugins their initialization code isn’t processed and they don’t work (tested with my AutoCodepage plugin).

Maybe that’s the reason for

@chcg said:

With NppFTP the plugin start after installation via PluginAdmin while N++ is running seems not to work.

donho

@chcg said:

On SHA-2, maybe:
https://tls.mbed.org/sha-256-source-code
https://github.com/amosnier/sha-2
are usable.

Thank you it’s very helpful! SHA-256 has been implemented in Notepad++ and SHA-256 hash will be used instead of MD5 one in the plugin list.

I’ve just updated the Notepad++ in debug mode binaries for plugin devs to add plugins into nppPluginList.

donho

@dail said:

The MD5 of just the main plugin DLL is not enough. This does not prevent MITM at all. Many plugins come with other DLL or Jar files which could just as easy contain malicious code. One could also argue that even text based config files or scripts could be modified to do malicious things.

Nice thought. Do you have any simple (as possible) solution for that?

Having the json file in the exe is nice for verification…but one of the biggest grips with the old plugin manager is that the list of plugins were not updated frequently enough. This caused plugin developers (such as myself) to worry that if there was a severe bug in their plugin being downloaded…there was a long time before there could be a fixed version available to users. This is even harder because there is no set schedule that the plugin list will be updated since it is dependent on Notepad++ being updated…which varies widely.

The release of nppPluginList will be independent from the release of Notepad++, and in the future, Notepad++ will be notified once there’s a new release of nppPluginList and download it.

As well, nppPluginList will be maintained and released by people of community, since I’ll have not much vacant time for it.

I would argue security is like a condom, it has to work perfectly, because even the slightest flaw means it is useless.

Good quote! Makes sens BTW :)

dinkumoil

@donho

The plugin update process of the new PA doesn’t work.

I installed version 1.2.1 of my AutoCodepage plugin.
I exited Npp and patched my nppPluginList.json by inserting the data of version 1.2.2 of the plugin.
After a restart of Npp PA showed correctly that there is an update available for my plugin, I clicked button “Update”.
Npp pointed out that a restart would be required to install the plugin, I clicked “Yes”.
The window of Npp was closed and a message box appeared:

Can’t unzip:
Operation not permitted or decompression failed

The plugin was not updated, after a restart of Npp version 1.2.1 was still installed.

Installing directly version 1.2.2 of the plugin is no problem, only updating from older version.

Debug info of Npp:

Notepad++ v7.5.9 (32-bit)
Build time : Oct 24 2018 - 09:21:25
Path : C:\Users\Username\Desktop\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : ON
OS : Windows 7 (64-bit)

dinkumoil

@donho

I noticed that the bug I reported above only happens if the NppMenuSearch plugin is installed. I also noticed that after closing Npp there remains a “shadow” of the Document Map (its window frame and the transparent orange scroll block) on the screen and in Windows Taskmanager I can see that the Npp process doesn’t terminate.

I have the NppMenuSearch plugin installed in a regular installation of Npp v7.5.9 (32 bit) too and there the plugin causes no such strange behaviour. But I understand if you are not willing to dig into that plugin-caused problem.

Sorry for the inconvenience.

dail

@donho

Nice thought. Do you have any simple (as possible) solution for that?

Can’t you just hash the entire ZIP file itself? That way you know everything is as expected.

chcg

Regarding security:
Checking the hash of the entire zip is also done by the 32bit PluginManager.
Additionally it should be forced to use https download locations.
Gup.exe companion libcurl needs to be up to date to avoid CVEs/bugs from that side.

donho

@dinkumoil said:

I found another pitfall in the new PA.
The new PA doesn’t init a restart of Npp. Thus after installing plugins their initialization code isn’t processed and they don’t work (tested with my AutoCodepage plugin).

Nice catched! This bug is fixed now in 2 (32 & 64 bit) Notepad++ debug binaries. NPPN_READY is sent to the installed plugin after being loaded:
https://github.com/notepad-plus-plus/notepad-plus-plus/commit/c531a4d42a9b4afe0136d48fdc3c376f67067bb0

Both binaries are available to be downloaded.

dinkumoil

@donho

Tested and worked.

chcg

For NppFTP the NPPN_READY doesn’t solve it completely. Now the docking and the message window are constructed/ visible, but the content is still not there.
Maybe there is another difference to the start of n++ itself.

dinkumoil

@donho

The new plugin PA has some structural problems:

The new and (in my opinion) far too simple and unflexible folder structure in the plugin ZIP files as well as on the harddisk.
After plugin installation Notepad++ is not restarted. That seems to be nice at first glance but causes serious problems.

In summary this means a maintenance nightmare for all plugin authors:

Because of 1. most of the plugins have to be repackaged.
Because of 1. plugin authors have to change access paths for additional files their plugins need to function properly. Despite that these code changes mostly should be easy to do it means some effort of work and time for plugin authors.
Because of 2. even more effort is required to fix the problems caused by that point. These code changes require debugging and maybe restructuring of code.

In my opinion its worth to think about the current concept of the new PA. Wouldn’t it be better to provide a solution that is backward compatible with the existing PluginManager? This way it would be possible to provide all existing plugins seamlessly to the users instead of encumber them a long lasting transition period. Furthermore I’m sure that there will be a bunch of useful plugins which never get updated and thus will be lost for the community.

dail

@dinkumoil

I fully agree with everything said above. I started checking into this and ran into the exact same problems. Some don’t effect me, but especially the restructuring of the zip files is going to be a pain.

I am curious why the zip files need to have another folder inside. Nearly all zip files for plugins have been created for the pre-existing Plugin Manager. I’m not arguing for keeping 100% backwards compatibility but I would suggest using a packaging scheme which most plugins are already designed for unless there are very good reasons why another scheme is needed.

dinkumoil

@dail said:

I am curious why the zip files need to have another folder inside.

Well, this makes the unpackaging code for the plugin ZIP files very simple… ;-)

A possible (and still simple) solution would be to modify the unpackaging code so that it unzips the content of the plugin ZIP files directly to the Npp plugins folder. But even that would not be satisfying. I’m sure that there are plugins whose ZIP file structure is not a mirror of the structure of their files and folders on the harddisk after installation (e.g. my plugins are of this kind).

That’s the reason why I demanded backward compatibility of the new PA to the old Plugin Manager. We need backward compatibility at minimum at the ZIP unpackaging level. That means the new PA should be able to recognize and execute commands similar to the ones in the installation node of the old Plugin Manager’s XML plugin list.

dail

I understand the desire to have 1 folder containing everything for 1 plugin…this makes things simpler to manage/maintain, but this does not work for some plugins

@dinkumoil said:

Well, this makes the unpackaging code for the plugin ZIP files very simple… ;-)

What I’m referring to (1 plugin per folder) wouldn’t be that much harder at all. Just the difference between extract a zip directly, or creating a folder first then extracting the zip into it. But yes I understand what you mean if it wants to be compatible with the other plugins.

donho

@dail said:

Can’t you just hash the entire ZIP file itself? That way you know everything is as expected.

@chcg said:

Regarding security:
Checking the hash of the entire zip is also done by the 32bit PluginManager.

Checking Zip package’s sha-256 hash has been implemented in the testing binaries:
https://notepad-plus-plus.org/pluginListTestTools/

(We need both notepad++.exe and GUP.exe for this new behaviour)

Thank you guys for the suggestions.

donho

@dinkumoil said:

The new plugin PA has some structural problems:

The new and (in my opinion) far too simple and unflexible folder structure in the plugin ZIP files as well as on the harddisk.

After plugin installation Notepad++ is not restarted. That seems to be nice at first glance but causes serious problems.

The PA’s design is for the future but not for the past, and KISS (keep It Simple Stupid). By giving each plugin its own folder, not only it makes plugins’ deployment easier, but also plugin can avoid to have complicate folder structure.

The 2nd point you mentioned is a bug, will be fixed in the future.

Because of 1. most of the plugins have to be repackaged.

It’s done for once, not a “maintenance nightmare”.

Because of 1. plugin authors have to change access paths for additional files their plugins need to function properly. Despite that these code changes mostly should be easy to do it means some effort of work and time for plugin authors.

It’s also done for once. OTOH the plugin folder should be used to store its own binaries or data, not user’s config file. The path of plugin config file should always be %APPDATA%\Notepad++ \plugins\Config since plugin folder will be erase entirely during its update.

donho

@dail said:

but especially the restructuring of the zip files is going to be a pain.

Why will it be painful? Could you elaborate?

I am curious why the zip files need to have another folder inside. Nearly all zip files for plugins have been created for the pre-existing Plugin Manager. I’m not arguing for keeping 100% backwards compatibility but I would suggest using a packaging scheme which most plugins are already designed for unless there are very good reasons why another scheme is needed.

Indeed, it could be created by GUP.exe while the deployment. What’s the scheme for the most plugins then?