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

dinkumoil

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.

donho

@dinkumoil said:

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

User can “install” a plugin list by copying a signed plugin list manually. But it’s true that users cannot install plugins if they don’t have Admin right. I think it’s OK to store nppPluginList.dll in %ProgramData%\Notepad++\Config\.

dinkumoil

@donho

In the last days I’ve noticed many support requests here in the forum that followed a common pattern:

After installing Notepad++ v7.6 users can only see Plugin Admin and plugin menu entries if they start Notepad++ under an administrative account. The solution of this issue was that these users normally work under a restricted Windows account, thus they had to provide credentials of an administrative account to install Notepad++. As a consequence the standard plugins, plugin config files and even Notepad++ config files get installed to the user profile of this administrative account used during installation.

In the past it was a common case to install plugins for all users, thus users are not used to have user specific plugins. Furthermore, I think that most users are not aware of the implications of installing programs under another (administrative) Windows account than their own (that’s the reason for the support requests I mentioned above).

I would like to suggest that installing plugins for all users, i.e. installing them to %ProgramData%, should be the standard case in future Notepad++ versions. This would prevent a lot of similar support requests.

Sure, users who already migrated to v7.6 and moved their plugins to %LocalAppData% will run once again into the issue that they have to move the plugins. But this is only one time more and it takes not so much effort since the new directory structure of the plugins directory already exists under %LocalAppData%, it only has to be moved as a whole to %ProgramData%.

Meta Chuh

@donho

currently we have to answer these following 2 scenarios again and again:

users installed to C:\Program Files ((x86)) with the option “Don’t use %APPDATA%” selected
in this case neither plugins nor plugins admin is visible after the installation

possible solutions:
a - more complicated:
grey out “Don’t use %APPDATA%” if the selected path matches %PROGRAMFILES% or %PROGRAMFILES(X86)%

b - quick and dirty:
remove “Don’t use %APPDATA%” completely from the installer.
so from now on it has to be done manually creating a DoLocalConf.xml and copying all files to the np++ directory

the installer was invoked by users without admin rights, so all plugin and plugins admin will reside inside the %LOCALAPPDATA% and %APPDATA% of the Administrator account they have entered but not within the invokers %LOCALAPPDATA% and %APPDATA%
(as @dinkumoil has posted above)

possible solutions:
a - more complicated:
find a way to get the invokers environment instead of %LOCALAPPDATA% and %APPDATA%
it “could” be done a bit complicated by making a 2 stage installer, first has as invoker rights in it’s manifest and writes the invokers environment paths to a common temp location, then the first stage calls the elevated real installer which reads the invokers path from there instead of the installers environment

b - quick(er):
always install to a common environment path like %PROGRAMDATA% as default
and additionally make an installer option to use %LOCALAPPDATA%/%APPDATA% instead for people who might want it or if they want keep it as it is now

what are your thoughts and ideas about this ?

donho

@dinkumoil

I would like to suggest that installing plugins for all users, i.e. installing them to %ProgramData%, should be the standard case in future Notepad++ versions. This would prevent a lot of similar support requests.

Let’s say we let Notepad++ install plugins into: %PROGRAMDATA%\Notepad++\plugins\ by default.
If the described issue is just a small part of use case, then there might be a lot of users (up to 70% maybe?) will be bothered by UAC for updating, installing or removing plugins.

It’s shame to make this feature harder to use, don’t you think so?

dinkumoil

@donho said:

It’s shame to make this feature harder to use, don’t you think so?

Users are used to confirm UAC dialogs when installing plugins from the old Plugin Manager and confirming is only one mouse click, not that hard. If the design of GUP.exe is appropriate (I don’t know if it currently is or not) one UAC confirmation could be sufficient to install a bunch of plugins at once.

In turn, installing Notepad++ and having hassle with the plugin management system is really bad. Apart from that the related support questions here in the forum will never stop and if they are ignored (because they are annoying) users will be upset. You can see this effect already (“Why are these questions ignored?” and so on). Please note: Users usually don’t search the forum for similar topics before posting their questions.

donho

@dinkumoil said:

Users are used to confirm UAC dialogs when installing plugins from the old Plugin Manager and confirming is only one mouse click, not that hard. If the design of GUP.exe is appropriate (I don’t know if it currently is or not) one UAC confirmation could be sufficient to install a bunch of plugins at once.

In this case, %LOCALAPPDATA%\Notepad++\plugins\ is not needed anymore.

dinkumoil

@donho said:

In this case, %LOCALAPPDATA%\Notepad++\plugins\ is not needed anymore.

Well, at most.

When Notepad++ gets installed, admin rights are required. If an administrator trusts his users and/or the community of Notepad++ plugin developers, he could select “Allow plugin installation to the user profile (%LocalAppData%)” during installation. As a result users could install plugins without admin rights later on. I think this was the use case of this option in Notepad++ versions prior to v7.6.

I don’t know, but I think this could be the most uncommon use case. It wouldn’t be that bad to loose this feature.

donho

FYI, the plugins loading schema has been modified again. Please recheck the 1st post of this thread.

donho

@Meta-Chuh

grey out “Don’t use %APPDATA%” if the selected path matches %PROGRAMFILES% or %PROGRAMFILES(X86)%

I will see what I can do about it.

The 2nd point will be solved in the next release (see new schema of the first post).

Meta Chuh

@donho

thanks a lot, much appreciated
your edit (28 November 2018) looks perfect, clean and straight forward

so if i’m correct, you can and will remove ${If} $arePlugins4AllUsers == “true” and all pluginsForAllUsers.xml sections
as they are not necessary for anything anymore, correct ?
if yes, it’s a perfect cleanup

greetings
MetaChuh

donho

@Meta-Chuh said:

so if i’m correct, you can and will remove ${If} $arePlugins4AllUsers == “true” and all pluginsForAllUsers.xml sections
as they are not necessary for anything anymore, correct ?
if yes, it’s a perfect cleanup

Yes, they are not necessary anymore. I will do a clean up

donho

FYI: The 1st post of this thread has been updated: new plugin list locations are added.

OldMcWeb

Hi,
im new here and like to contribute some thoughts from a user perspective.

In the current case as a user I get the changelog with a link to https://notepad-plus-plus.org/features/plugin-admin.html
Then I start searching for the PluginAdmin, found out that i need admin privileges.
That’s a debatable move, but ok I can understand the thoughts behind.
Then I found that my plugins are under the admin profile AppData.
Ok makes sense to me, but now i find this thread telling me that things will totally change in the next release again.

As a idea:

Make it configurable where your plugins are stored. Maybe from the setup and in an config file.
Put more Info for this changes in the changelog, the link to https://notepad-plus-plus.org/features/plugin-admin.html
helps but is only a part of the solution
Maybe add a menu item in [?] -> GotoPluginFolder

Don’t get me wrong, I don’t want to criticize your hard work, but I like to show that the last update was very confusing for probably lot of users.

MrOuzo

I use Notepad++ many years, with many plugins and config files. I have 2 points to store all Programm ,plugins and configuration… now i have so sort and show to all config and whatever that it comes into the right location… its a bad thing and i stay on lower than 7.6. so i know it works.
If its a new installation and you have no good working configuration, i say its ok to install this new worst admin plugin. For a updated install its better to use all the locations as is it… for every dll-plugin a directory with his own name…brrrr