#1553 Regression: KeePass no longer loads plugins from user-writable config directory

[Ryan Hayle]

I noticed that after upgrading to 2.34, none of my plugins were loaded. After a considerable amount of digging, I finally found this in the release notes:
"Plugins are now loaded only directly from the application directory and from any subdirectory of the 'Plugins' folder in the application directory."

This is an extremely poor choice. Users should never be modifying files in a system directory directly. I know Windows users have never understood or cared about any concepts relating to security, but for the rest of us, this is a huge red-flag. Manually-installed plugins need to go into ~/.config/KeePass/Plugins, while only plugins installed from an actual package belong in the KeePass installation directory (e.g. /usr/lib/keepass2/Plugins). Basically, anything in /usr or \Program Files should be considered entirely off-limits to manual user modification. Otherwise that is an abuse of administrative privledges.

I'm not sure why you did this in the first place, but please fix this regression ASAP! If loading a rogue plugin is the concern, then the new plugin version information signatures could be utilized to manually authorize loading of specific plugin versions.

Thank you for your continued work on this essential tool.

[Ryan Hayle]

Edit: Here's a quick hack to work around this issue until it is fixed: creating a symlink from /usr/lib/keepass2/plugins/username to /home/username/.config/KeePass/plugins wil allow all the local plugins to be loaded. It still requires modifying the filesystem in /usr, but at least it's only one small symlink.

[wellread1]

Documented behavior is not a bug.

Please post about things you would like changed in the Discussion forum or make a feature request.

KeePass is a Windows program, which does not have a linux like usr/lib/ directory. Plugins are application extensions of the KeePass program and properly stored in the KeePass application directory until such time as Windows changes its architecture.

[T. Bug Reporter]

As an old-school computer geek, your comment that

Users should never be modifying files in a system directory directly

is a huge red flag for me. I see the need for administrative access merely as a reminder to the user that these actions are not to be taken lightly - and not as a blanket prohibition of them. To me, anybody who can't be trusted to go into /usr or \Program Files occasionally is unqualified to be operating a computer, let alone installing programs on that computer. I know these opinions have fallen out of favor, but it's still how I feel. I also feel that all program code belongs in \Program Files, regardless of who does or doesn't use it.

That being said, if you wanted to file a Feature Request for a more hands-off method of managing plugins, I might actually support that. :-)

(P.S. If you knew some of the history of why and how quickly this change was made, you might feel differently about labeling this as a "regression".)

[Dominik Reichl]

Plugin files fit much better into the program files directory than in the user's profile directory. The file access rights are more appropriate, plugins are available for all users of the PC, and the application files and user data separation is better. So, this will not be changed.

Best regards,
Dominik

[cracket]

I think your explanation is very inconsistent, as plugins are in most of applications that I know - part of user configuration as well. And plenty of windows applications support user configurable plugins-for example web browsers. The separation is true but either on system, and on user level.
Same applies to installers - most of windows applications (application files) can be installed to all users or only current user. It's the matter of good or bad design of application, so I understand it's not a following best practices made you to choose this design for KeePass.

Not only MS Windows is going towards having fully functional applications without need for administative permissions, but this require good design and taking into account overriding and customizing all aspects of application on user level.

[Paul]

Application / plug-in configuration is at the user level with settings stored in the configuration file. The actual plug-in is executable code and rightly belongs in the program files directories.

cheers, Paul