GNOME Bugzilla – Bug 757057
The installation of .dll's into the plug-ins-subdirectory by additional plug-ins can cause malfunction of others.
Last modified: 2018-05-24 15:50:03 UTC
Bug 756922 discovered a general problem:
The installation of a new version of the „libstdc++6.dll“ by the "GIMP_Extensions_v2.8.20150403.exe" (GIMP Extensions Pack for Windows) into the plug-ins-subdirectory had caused a malfunction of the standard plug-ins "file-pdf-load.exe", "help-browser.exe" and "webpage.exe".
These .exes obvisiosly try to access first the .dll in their own subdirectory /lib/.../plug-ins and find there the version of „libstdc++6.dll“, which the Extension Pack had added. So they cannot find their right „libstdc++6.dll“ in /bin
I recommend to unable this kind of conflicts either by protecting this and other sensitive pathes or by precautions (f. ex. prioriting schemes) in the standard packs.
I would spend a special subtree structure to non-standard plugins.
GIMP does support an arbitrary number of directories for plug-ins.
What exactly are you asking for from GIMP? That we recursively search
plug-in folders for plug-ins, just as we do for brushes, patterns etc?
Jernej has suggested that moving all plug-ins into GIMP's bin directory is probably the only way to make it really hard to cause this - at least by extra copies of DLL files in system directories.
Of course, nothing prevents third-party plug-in packs from doing the same - after all, "../bin/ is where plug-ins belong, isn't it?", and likely cause real damage if they replace some of GIMP's DLL files there.
I guess an intermediary effort could be to appeal to the maintainers of such plug-in packs and ask them to install their plug-ins into new directories.
(In reply to Michael Natterer from comment #1)
> GIMP does support an arbitrary number of directories for plug-ins.
> What exactly are you asking for from GIMP? That we recursively search
> plug-in folders for plug-ins, just as we do for brushes, patterns etc?
No, I ask for protecting a proved installation against beeing disturbed by new parts. There may help a lot of concepts like seperate directories, sandboxes, checksums and lot of things more, which you find in other open sources.
If there is a basic agreement over the desirability, there will be a need for a concept and its objectives and constraints.
First it might be simply an nearly empty directory "3rd_party_plug-in", where there you can find only the how-to's for integrating plug-ins or a link to them.
This directory and its subdirs should be the place, where 3rd-party plug-ins
had to start.
If that's not enough, additionally I can imagine an concept similar to that, I had used to use for my real-time packages. At my active programmers time and on my machines RAM had been very limited, so we needed havy overlayed programms.
For protection of my packages I had kept an protected and closed interface list of overlays (here standard plug-ins) with some information about the code.
Beside the control of the rights, the concept kept care of run time prefetching of the overlays in background, resulting in a fast starting-up without loading-delays during processing. The sampling processes during starting-up gimp is a little bit boring.
Like some open-project-helpers I had workmates, which had difficulties in following roules. So all unproved software had to connect to by a 2nd list.
The registration of a new software part into this list had only been possible with help of a function with a pointer to the start of the new subfunction, global-extension and entry point list. Every third party had to link in this function, when wants that the extension will work fine. It also protected agains conflicts with already installed parts by checking and producing error messages during the linking process (here installation of the 3rd party-sw) without slowing down the runtime.
By this it had been even possible to unswitch standard parts via overlay.
I think that too much protection might nullify the idea of "the user is free to do whatever with the software".
(In reply to Michael Schumacher from comment #4)
> I think that too much protection might nullify the idea of "the user is free
> to do whatever with the software".
Most of the GIMP-users of my orbit have no need for this freedom. They only want postedit their holyday or party snapshots or need something for leisure games or paintings or similar.
The take GIMP, for they want to do a little bit more than postexposing.
They have no clue how to change anything in the program. I rate them to be more than 95 percent of the users. These people have little insight. For them it's GIMP or WINDOWS/LINUX and not a third party, if something is not working fine. So it's a must for the global acceptance of GIMP, not to prevent, but to warn, that there are some problems, which had been introduced afterwards.
Even most users like me, which had learned programming and would be able to use the freedom you mean, have no time or are to sluggish to do it and they would seize a commercial program instead of GIMP, even when they otherwise are a fighter for the open source idea.
The third party plugin makers do not foul play intentionally and so it's sufficient for the first act to help them in reventing fouls.
I think so, it's easy done, to integrate an elsewise empty directory "third-party" with only some information and to broadcast the request for the adherance for some rules to the third parties.
We should really start looking into subdirectories of the plug-in directory,
and encourage 3rd party plug-in installers to put their plug-ins plus
DLLs into such subdirectories. This would fix the problem described here,
but of course NOT if other (broken) installers put stuff into system
Fixing both this bug AND the system directory bug are somewhat mutually
exclusive: we can't put everything into one directory and at the same
time give plug-in installers the freedom to use their own directories...
We definitely should go that way. I made a first commit about this. We don't search recursively, but only at first level. Also let's make a restriction so that we only run a file under the same name. This way, for instance you can have several files under the directory. For instance a Python plugin could have several .py files, but only one is the entry point.
This doesn't fix completely the issue of DLLs interfering with other plugins. Now we need to have to encourage the plugin developers to stop installing DLLs. For 2.10, I propose we just pop-up a warning when we find shared objects in the plugin dirs so that it is visible so to push them to update.
Soon a fix to come when I can make time.
Author: Jehan <email@example.com>
Date: Wed May 24 12:02:52 2017 +0200
app: allow plugin inside first-level directories of plug-ins folders.
We don't search recursively but only at the first level. If a plugin is
in its own subdirectory, the entry point has to be named the same (minus
extension) as the directory. For instance my-plugin/my-plugin for a
binary, or my-plugin/my-plugin.(py|exe|…).
This way, a plugin can load shared objects (libraries, other script
files, etc.) without polluting the main plug-ins directories, and in
particular without interfering with other plug-ins.
This is a first step to fix bug 757057 (DLL files which were used in
app/plug-in/gimppluginmanager-restore.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
Though I'm wondering what is the best test for files we want to warn about. I was thinking that something which is "non executable" should be banned, since DLL are apparently not executables on Windows (which basically uses file extensions). Yet .so files have the executable bit on Linux, so they would not trigger a warning (even though it is also possible to link to libraries at non-classic paths on Linux systems too, for instance using rpath).
Also there are some non-executable installed by GIMP under plug-ins/, in particular pyconsole.py.
Or we could use file extensions?
Nevermind. I will just test for executable files. I'm pretty sure the issue is mostly about plugins on Windows using DLLs (on Linux, such a collision issue would only occur whether 2 plug-ins were compiled with a rpath searching on $ORIGIN, I believe; do plugin devs do that?).
I have the code for this, but I'll just cross-build on Windows to make sure DLL won't be considered as executable by our code.
Having multi-file plugins in sub-directories will be the new best practice but since plug-ins from 2.8 should not break in 2.10, that will only warn.
On 3.0 though, we should probably disable any file which should not be there (by moving it in some disabled/ dir for instance, no delete) because plug-ins which will continue to do this, even though they now have an alternative, are disrupting other plugins. So I'll make a commit on the gtk3-port branch too later as a finale solution for this topic.
This is why I change the milestone to 3.0.
We recently discussed having a more formal subdirectory structure, mostly for plug-ins and also other resources. Not sure if anyone took notes, but this is going to get beyond the scope of this bug, I guess.
Also, it seems that Windows executables in a plug-in directory on a Linux platform can have interesting effects, but this requires more research should become a new report.
Actually in the code I stashed a few years ago, when I did a bit of test for the plugin management system, there was also a formal subdirectory structure. This is an obvious evolution when plugins are distributed as packages.
But yes, this is beyond the scope of the bug because we are not there yet. We may be by 3.0 though. Yet it should not prevent us from doing this first step anyway. :-)
I am not sure if commit efae55a73e98389e38fa0e59ebebcda0abe3ee96 is the right approach.
Moving plug-ins into sub-directories to disable them (possibly temporarily) seems to be an established practice. The change done here would nullify such efforts.
(In reply to Michael Schumacher from comment #13)
> I am not sure if commit efae55a73e98389e38fa0e59ebebcda0abe3ee96 is the
> right approach.
> Moving plug-ins into sub-directories to disable them (possibly temporarily)
> seems to be an established practice. The change done here would nullify such
I don't understand why you opposes this commit and the disabling proposition. These are complementary and I am planning to have both eventually.
Having plug-in in subdirectories is a much common practice (actually I don't know other software which have all their plugins as a single binary such as GIMP; all software usually ask plugin developers to put the code/data into a subdirectory, even when there is a single file only) and is the obvious solution for multi-file plugins. If we want to allow complex plugins too, we must allow for multiple binary files, and we can't have every big plugin out there just dropping a bunch of files in the root plug-ins/ directory. Hence this commit.
Actually we could even go further: force every plugin to have their content in a subdirectory, as does any software out there. I would definitely not be against and this would absolutely fix the DLL issue. I only kept the mixed system, allowing both for compatibility with current installations.
If we want to go this way, I could hack the migration code so that it moves every file under plug-ins/ into a subdirectory with a similar name. This would not be perfect for plugins with DLL or data though, where people will have to go and manually fix these.
I am very sure that Jehan's patch is the right approach. People who
want to disable plug-ins will simply have to do different manual
file system surgery.
Created attachment 353619 [details] [review]
Ok so I am proposing the following steps:
1/ in 2.10, deprecate having plug-ins binaries directly under the plug-ins/ folders. These will still be accepted for compatibility, of course, but will output a warning.
So I wrote a few patches to:
- install all our official plug-ins in sub-directories.
- output a warning when a plug-in is not in a sub-directory.
2/ in 3.0, make the deprecation definitive, i.e. not load plug-ins which don't follow this new separation.
I believe this is the best approach to have properly separated plug-ins. It makes no sense to continue having everything as a big mess under plug-ins/. Even when there is only one binary, a plug-in could want to install a README, a LICENSE/COPYING, some icons or other data.
IMO this is a first step to better managed plug-ins.
Created attachment 353620 [details] [review]
Created attachment 353621 [details] [review]
-- GitLab Migration Automatic Message --
This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/788.