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

chcg

Are you planning to support legacy plugins, not packaged in the right format needed by the PA? At least for x86 there a plenty plugins not actively maintained, but still functional and which might get lost in this case.

chcg

I think it is not clear from the description if the md5 “id” is the one of the zip file or the main dll.
See https://en.wikipedia.org/wiki/Md5sum :

The underlying MD5 algorithm is no longer deemed secure. Thus, while md5sum is well-suited for identifying known files in situations that are not security related, it should not be relied on if there is a chance that files have been purposefully and maliciously tampered. In the latter case, the use of a newer hashing tool such as sha256sum is recommended.

donho

@chcg said:

Are you planning to support legacy plugins, not packaged in the right format needed by the PA?

The new plugin file system provides simpler and more elegant way to keep plugin own space, and keeping 2 systems working will be time consuming, so the answer is no.

donho

@chcg said:

The underlying MD5 algorithm is no longer deemed secure. Thus, while md5sum is well-suited for identifying known files in situations that are not security related, it should not be relied on if there is a chance that files have been purposefully and maliciously tampered. In the latter case, the use of a newer hashing tool such as sha256sum is recommended.

Agree with you.

Plugin (DLL) hash is generated and submitted by plugin author in plugin list, and it will be verified by Notepad++ after the installation - if the hash is not matched then the installation will be removed.
Using SHA1 or SHA2 instead of MD5 means Notepad++ should implement the SHA1 or SHA2 algorithm - I could be wrong but I think there’s no easy way to implement it without overhead (OpenSSL).
Since MD5 has been already implemented in Notepad++, so it’s used currently:
Security is like sex: when it's good, it's very, very good; when it's bad, it's better than nothing.

If you know any easy way to implement SHA algo without including the overhead, please let me know.

dinkumoil

@Don-Ho

“not packaged in the right format needed by the PA” includes:

Plugin ZIP files with an internal folder structure different from the required one.
DLL files created without version infos. There seem to be programming languages which are not able to include them in the DLL file.

The current PluginManager provides solutions for both of these points. For point 1 see here, for point 2 see here. If you would provide similar solutions in the new PA this would reduce the number of plugins which get lost.

But furthermore there is another serious problem. Some plugins need additional files that have to be copied to a certain location. These files of course have to be deleted when uninstalling the plugin.

My own plugins (AutoCodepage, AutoEolFormat, CustomLineNumbers) are packaged with a little .txt file containing some documentation. The NppExec plugin for instance needs some additional files to function properly (this is true for a lot of other valuable plugins). Currently the new PA can not handle such needs (tested with my AutoCodepage plugin). If you would provide a solution for point 1 mentioned above that would solve this problem too.

Also in your documentation I can’t find a method to delete certain files when uninstalling a plugin.

chcg

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

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.