New Plugins Home (where Notepad++ will load from)

MAPJe71

Alternative solution:

Don’t allow installation in %LOCALAPPDATA%\Notepad++\plugins\ when plugin/dll already available in %ALLUSERSPROFILE%\Notepad++\plugins\ i.e. allow only one installation location.
When duplicate plugins are detected (e.g. manually installed by user in %LOCALAPPDATA%\Notepad++\plugins\), load the one that is favorite (e.g. configuration option named UserProfile with value All or Current).

Furthermore, it would be nice/helpfull when the PluginAdmin has a column indicating where each plugin is installed e.g. AllUsers or %UserName%.

SinghRajenM

@donho

I do understand the need. However, there’ll be some situation which make Plugins Admin behaviour inconsistent:
If the same plugin foo.dll is in 2 different locations, %ALLUSERSPROFILE%\Notepad++\plugins\foo\foo.dll and %LOCALAPPDATA%\Notepad++\plugins\foo\foo.dll
Notepad++ should load only one (let’s say the one in %LOCALAPPDATA%). If user removes this plugin by using Plugins Admin, after restart, the one in %ALLUSERSPROFILE% will be loaded by Notepad++ - user will be confused.

I feel this can be handled easily.

Always, give preference to user location (preferably %appdata% over %localAppdata%), than the global location which can be %allusersprofile%.
All default plugin can go to global location.
New plugin installation should go to user location. Even update of an existing plugin should go to user location only. Because Npp will give preference to user location always as per #1.
If user tries to remove a plugin then

if plugin present only in global scope (e.g. %allusersprofile%), then don’t actually remove a plugin, rather mark it in ignored list. This list should be maintained in user scope. It can be written either as config file somewhere in %appdata% or in HKCU. %appdata% is preferred as it can roam from PC to PC for domain users.
if plugin present in both user and global scope, then remove the plugin from user scope and mark it in ignore list as well so that loading from global scope will be avoided.

dinkumoil

@donho

What will be the location for nppPluginList.dll?

dinkumoil

@donho

When plugin authors want to update a plugin they have to change the related entry in the plugin list. Thus they need the ability to test if this entry works correctly.

Since the nppPluginList.dll file can not be changed we need another approach. What are your ideas/plans concerning this point?

pnedev

@SinghRajenM said:

if plugin present only in global scope (e.g. %allusersprofile%), then don’t actually remove a plugin, rather mark it in ignored list.

I like this idea of yours. It is an efficient way out of the problem where user A doesn’t want particular plugin and by removing it removes it for all other users as well.

But the approach to install and prefer always the user version of a plugin is two-folded. It depends on the way you look at it.
If you look from an administrator’s perspective you might want the users to access specific set of plugins (including specific versions) that are known to be safe and the possibility for a user to overwrite your secure version with his custom one is a nightmare. You can see @Fran-Favorini 's post here.

donho

@dinkumoil

What will be the location for nppPluginList.dll?

There is no impact for plugins location or am I missing somethings?

When plugin authors want to update a plugin they have to change the related entry in the plugin list. Thus they need the ability to test if this entry works correctly.
Since the nppPluginList.dll file can not be changed we need another approach. What are your ideas/plans concerning this point?

They should always use the tools with the current plugin list. It should be enough for testing, shouldn’t it ?

SinghRajenM

@pnedev

If you look from an administrator’s perspective you might want the users to access specific set of plugins (including specific versions) that are known to be safe and the possibility for a user to overwrite your secure version with his custom one is a nightmare.

Oh, I see. But even this also can be handled using config or registry whether to allow user to load/install/update plugin. This config can be written by providing an another checkbox on installer’s last page (just before finish), or can be pushed as group policy from domain users.

Otherwise, standard user will never be able to use any new plugin because s/he can’t write to %allusersprofile%. This way we are just blocking normal user to use full-fledged plugin managers even administrator does not set any policy explicitly. However, this statement is not validated, but I feel it is true in most of the cases. Correct me, if I am wrong.

dinkumoil

@donho

The current discussion about how and where to install plugins has overlayed the questions in my comment. I wanted to have exact infos about these topics.

@donho said:

@dinkumoil said:

What will be the location for nppPluginList.dll?

There is no impact for plugins location or am I missing somethings?

Maybe this is the wrong topic to ask this question. There was a discussion if the file maybe should be stored under %ProgramData% in order to make it available to all users. I wanted to know the current status of that discussion.

They should always use the tools with the current plugin list. It should be enough for testing, shouldn’t it ?

OK, question answered.

donho

@dinkumoil said:

Maybe this is the wrong topic to ask this question. There was a discussion if the file maybe should be stored under %ProgramData% in order to make it available to all users. I wanted to know the current status of that discussion.

What’s your thought about it then?

dinkumoil

@donho said:

What’s your thought about it then?

I think it would be better to store it under %ProgramData%. A plugin list only available for that user who installed Notepad++ makes no sense, especially as in the future the plugins itself seem to get stored under %ProgramData% as well.

pnedev

@SinghRajenM said:

However, this statement is not validated, but I feel it is true in most of the cases. Correct me, if I am wrong.

I’m not quite familiar with that but your comment sounds perfectly reasonable to me.

donho

The idea of plugins loading from both default / user folders is good (I said it and I say it again), but in order to avoid plugins management conflict and simplefy the implementation, I think it’s a nice-to-have but not a must-to-have feature. Therefore it won’t be implemented.

donho

@dinkumoil said:

I think it would be better to store it under %ProgramData%. A plugin list only available for that user who installed Notepad++ makes no sense, especially as in the future the plugins itself seem to get stored under %ProgramData% as well.

@dinkumoil & @SinghRajenM :
It’s a good idea to have one list for all users. However, the nppPluginList.dll is supposed to be updated independently. It means Notepad++ which is launched without Admin right cannot modify the data in %Programdata%. So plugin list cannot be in %Programdata% because it cannot be updated by users without admin right.
Or you’ve got a solution for that?

mavelli

Notepad++ loads plugins from: <NPP_INST_DIR>\plugins
is strictly needed if you are in an environement where the enterprise sets the MS Windows AppLocker to allow only binaries from a certain position or every binary needing a signature and everything is pre-packaged.

in such an environment, users cannot install plugins themselves but every plugin needed by a user needs to be pre-packaged with NPP itself and then distributed to all.

any idea how this can be achieved with 7.6? i am one of the NPP users in this environment and also responsible for the instructions how to package it.

dinkumoil

@donho

If the file nppPluginList.dll gets stored under %ProgramData% I guess the exact path would be %ProgramData%\Notepad++\plugins\config\nppPluginList.dll.

If plugins get installed under %ProgramData% the exact path would be %ProgramData%\Notepad++\plugins\<plugin-name>\<plugin-name>.dll.

These would be two different locations. Thus it would be possible to change during installation of Notepad++ the NTFS access rights of the directory %ProgramData%\Notepad++\plugins\config to grant access to all users.

The nppPluginList.dll doesn’t contain executable code and, I guess, it is loaded with the flags LOAD_LIBRARY_AS_DATAFILE | LOAD_LIBRARY_AS_IMAGE_RESOURCE, thus access rights for all users should not introduce any risk.

BUT what’s about plugin installation? Storing plugins under %ProgramData%\Notepad++\plugins\<plugin-name> would also require elevated rights, a thing GUP.exe currently doesn’t do (maybe it is even not able to do).

If we want plugins to be installed under %ProgramData% we need a GUP.exe that is able to trigger UAC when copying a files to a certain directory. Thus GUP.exe could be used to download and install nppPluginList.dll and plugins themself.

Because GUP.exe isn’t able to provide user feedback during plugin installation I think it is necessary to extend this program anyway. The current version is too simple - too much KISSes ;-).

Some thoughts from a higher point of view:

As far as I know all these discussions about where and how to store plugins derive from the idea to publish a Windows Store App variant of Notepad++. Because Microsoft issued the policy that an UWP package has to be immutable it is not possible to change the content of an UWP app’s installation directory.

BUT Microsoft has also issued the policy that files with executable code have to be stored under %ProgramFiles% because this location offers some sort of protection against malware attacks. Thus neither %LocalAppData% nor %ProgramData% is the right place for storing plugin DLL files.

It seems like the author of the UWP package spec had not in mind that there could be UWP apps which provide a plugin interface, thus he brought us into a dilemma - it makes no difference where plugin DLL files get stored, as long as the location tries to fit the requirements of an UWP app the location is WRONG, because of the one or the other policy.

How about declining the requests for a Notepad++ UWP app variant because of security concerns and because the whole concept of UWP apps is crap?

There is a certificate protected SciLexer.dll and SHA-256 hashes of plugin ZIP files to prevent malware and man-in-the-middle attacks but DLL files get stored at unsecure locations - it’s a paradoxon.

chcg

See https://github.com/NightRi-se/notepad-plus-plus/issues/10 and workaround https://github.com/NightRi-se/notepad-plus-plus/issues/19 for UWP. Plugins seems to be a problem in that environment.

donho

@dinkumoil
Indeed, it’s just implemented in 61402a354f214fab8d6899ec19e57f657268c0c6 :
https://github.com/notepad-plus-plus/notepad-plus-plus/commit/61402a354f214fab8d6899ec19e57f657268c0c6

However, I really don’t think it’s a good idea to put plugin list in %PROGRAMDATA%. The reason is the following:
The UAC elevation will be required for updating plugin list - and it’s the case for one part of use case (no idea about the percentage).
Another use case (IMO it’s more common) is without UAC elevation to update plugins list - to make Notepad++ hard to use for just one usage case, that’s what I’m trying to avoid to.

dinkumoil

@donho said:

Indeed, it’s just implemented in 61402a354f214fab8d6899ec19e57f657268c0c6 :

Thumbs up!

However, I really don’t think it’s a good idea to put plugin list in %PROGRAMDATA%. The reason is the following:
The UAC elevation will be required for updating plugin list - and it’s the case for one part of use case (no idea about the percentage).
Another use case (IMO it’s more common) is without UAC elevation to update plugins list - to make Notepad++ hard to use for just one usage case, that’s what I’m trying to avoid to.

Sorry, but I don’t understand exactly what you are talking about. I can see it was late when you did that posting… ;-)

Is far as I can see you say that UAC elevation would be required when updating the plugin list if it would be stored under %ProgramData%. This is true if the NTFS access rights for the storage location of the plugin list are left at the default setting.

But during Notepad++ installation UAC elevation is required anyway. Thus the installer could create the directory %ProgramData%\Notepad++\plugins\config for storing the plugin list and set its NTFS access rights to grant access for all users. Thus when the plugin list gets updated no UAC elevation would be required.

Since the plugin DLL files themself would be stored under %ProgramData%\Notepad++\plugins\<plugin-name> this location would be still protected against changing/replacing plugin DLL files without UAC elevation.

donho

@dinkumoil said:

Sorry, but I don’t understand exactly what you are talking about. I can see it was late when you did that posting… ;-)

Sorry for not being clear. What I tried to say is:

plugin list is in %ProgramData%, then wingup needs UAC elevation - which is annoying
plugin list is in %AppData%, then wingup DOES NOT needs UAC elevation - which is good

And I’m quite sure 80% of use case is suitable for the 2nd solution. Only 20% of use case need the 1st solution. If we apply the 1st one, we make annoying 80% users.

Is far as I can see you say that UAC elevation would be required when updating the plugin list if it would be stored under %ProgramData%. This is true if the NTFS access rights for the storage location of the plugin list are left at the default setting.

But during Notepad++ installation UAC elevation is required anyway. Thus the installer could create the directory %ProgramData%\Notepad++\plugins\config for storing the plugin list and set its NTFS access rights to grant access for all users. Thus when the plugin list gets updated no UAC elevation would be required.

Then that’s a good news - any link about that?

Edit: Just find this one and will try it:
https://stackoverflow.com/questions/116876/how-do-you-set-directory-permissions-in-nsis

It could be the solution, however I’m not sure such solution is suitable for the companes’ administrators, since they don’t want plugin List generally.

@Fran-Favorini & @Zanzaraaa What do you think about such behaviour?

dinkumoil

@donho said:

Then that’s a good news - any link about that?

No, I don’t have a link to prove that, it’s based on my experience. In my company I’m among writing code for our main product resposible for writing the installer of the software using InnoSetup. The settings file of the software is stored in a subfolder of %ProgramData% since we want to achieve that all users of the computer share the same settings. Our users mostly work under a restricted Windows user account, thus in the beginning we had the issue that they were not able to save their custom settings. I solved that by granting full access for all users to the files in the settings file’s directory during installation of the program.

EDIT (response to your Edit): Well, users can see plugins, but they can not install them.