Community
    • Login

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

    Scheduled Pinned Locked Moved Notepad++ & Plugin Development
    117 Posts 22 Posters 94.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • chcgC
      chcg
      last edited by

      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?

      1 Reply Last reply Reply Quote 2
      • dinkumoilD
        dinkumoil
        last edited by

        @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.

        donhoD 1 Reply Last reply Reply Quote 5
        • donhoD
          donho @chcg
          last edited by

          @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.

          1 Reply Last reply Reply Quote 2
          • donhoD
            donho @dail
            last edited by

            @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 :)

            dailD 1 Reply Last reply Reply Quote 2
            • dinkumoilD
              dinkumoil
              last edited by

              @donho

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

              1. I installed version 1.2.1 of my AutoCodepage plugin.
              2. I exited Npp and patched my nppPluginList.json by inserting the data of version 1.2.2 of the plugin.
              3. After a restart of Npp PA showed correctly that there is an update available for my plugin, I clicked button “Update”.
              4. Npp pointed out that a restart would be required to install the plugin, I clicked “Yes”.
              5. 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)

              1 Reply Last reply Reply Quote 1
              • dinkumoilD
                dinkumoil
                last edited by

                @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.

                1 Reply Last reply Reply Quote 1
                • dailD
                  dail @donho
                  last edited by

                  @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.

                  1 Reply Last reply Reply Quote 4
                  • chcgC
                    chcg
                    last edited by

                    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.

                    donhoD 1 Reply Last reply Reply Quote 2
                    • donhoD
                      donho @dinkumoil
                      last edited by 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.

                      1 Reply Last reply Reply Quote 4
                      • dinkumoilD
                        dinkumoil
                        last edited by

                        @donho

                        Tested and worked.

                        1 Reply Last reply Reply Quote 1
                        • chcgC
                          chcg
                          last edited by

                          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.

                          1 Reply Last reply Reply Quote 3
                          • dinkumoilD
                            dinkumoil
                            last edited by

                            @donho

                            The new plugin PA has some structural problems:

                            1. The new and (in my opinion) far too simple and unflexible folder structure in the plugin ZIP files as well as on the harddisk.
                            2. 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.

                            dailD donhoD 2 Replies Last reply Reply Quote 2
                            • dailD
                              dail @dinkumoil
                              last edited by

                              @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.

                              donhoD 1 Reply Last reply Reply Quote 2
                              • dinkumoilD
                                dinkumoil
                                last edited by

                                @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.

                                dailD 1 Reply Last reply Reply Quote 1
                                • dailD
                                  dail @dinkumoil
                                  last edited by

                                  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.

                                  1 Reply Last reply Reply Quote 0
                                  • donhoD
                                    donho @chcg
                                    last edited by 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.

                                    1 Reply Last reply Reply Quote 2
                                    • donhoD
                                      donho @dinkumoil
                                      last edited by donho

                                      @dinkumoil said:

                                      The new plugin PA has some structural problems:

                                      1. The new and (in my opinion) far too simple and unflexible folder structure in the plugin ZIP files as well as on the harddisk.
                                      2. 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.

                                      1 Reply Last reply Reply Quote 1
                                      • donhoD
                                        donho @dail
                                        last edited by

                                        @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?

                                        1 Reply Last reply Reply Quote 0
                                        • dinkumoilD
                                          dinkumoil
                                          last edited by

                                          @donho said:

                                          The path of plugin config file should always be %APPDATA%\Notepad++ \plugins\Config since plugin folder will be erase entirely during its update.

                                          I’m not talking about the config files. I’m talking about additional files the plugins need to function properly (e.g. DLLs, help files, documentation). Install in a test environment e.g. the plugins XML Tools, CS-Script, NppExec, ComparePlugin, MarkdownViewerPlusPlus and CodeAlignment. Then look into <Npp-installation-folder>\plugins and <Npp-installation-folder>\doc and you will see what I mean.

                                          All these plugins create subfolders/store files in the folders mentioned above (DLLs, CHM help files, HTML and TXT files). With the new “One plugin - one folder” policy plugin developers have to change their code to cope with it (can take more or less effort). If they don’t do it the plugin ist lost for the community.

                                          Repackaging of plugin ZIP files could be done by community volunteers but isn’t sufficient. Changing the code of foreign plugins and recompile them is much more complicated (obtain permission to fork, make adaptions to current development tools, analyse and understand the code, make required changes).

                                          1 Reply Last reply Reply Quote 1
                                          • oleg-shilo81O
                                            oleg-shilo81
                                            last edited by

                                            Hi there, I am the author of CS-Script plugin and I would really appreciate if a few critical point as confirmed/elaborated.

                                            1. A few recent changes to the plugin hosting model make it very difficult to maintain plugins. Can you please confirm if the new “One plugin - one folder” model is a final change? Currently I have the following plugin structure working OK while not strictly following the PluginAdmin model:

                                              Notepad++
                                                \-- plugins
                                                      \-- CSScriptNpp
                                                            |-- CSScriptNpp
                                                            |      |-- CSScriptNpp.asm.dll (managed)
                                                            |      |-- CSScriptLibrary.dll
                                                            |      |-- . . .
                                                            |
                                                             \-- CSScriptLibrary.dll (native)
                                              
                                            2. From plugin-admin.html: The json file will be built into the a binary (nppPluginList.dll), which will be signed (for thes sake of security) and be included in the official distribution.
                                              Does this mean that any plugin updates users will need to wait until Notepad++ is updated?
                                              If it is the case, would it be more beneficial to have a separate release schedule for Notepad++ and for PluginList. SublimeText3 and VSCode has achieved this quite harmoniously. May be a similar model can be adopted for Notepad++ as well.

                                            3. @doho said: The path of plugin config file should always be %APPDATA%\Notepad++\plugins\Config since plugin folder will be erase entirely during its update.
                                              For years plugins\Config folder was used by the various plugins to store plugin specific configuration. It worked very well because Notepad++ and plugins’ configuration were completely decoupled. “erase entirely during its update” completely breaks the existing paradigm.
                                              Is there any plans to to somehow reconcile the needs of Notepad++ and the plugins?

                                            4. Is there any plans to replace ultimately misleading plugin initialization error message “This ANSI plugin is not compatible with your Unicode Notepad++ v7.5.9” with something more accurate?

                                            1 Reply Last reply Reply Quote 2
                                            • First post
                                              Last post
                                            The Community of users of the Notepad++ text editor.
                                            Powered by NodeBB | Contributors