Interesting issue. Not directly related to my inquiry, but certainly something to be considered.
I guess we have two issues: 1) Malicious binary packagers who insert exploits into otherwise harmless plugins and 2) malicious plug-in authors, who code exploits right in. Moreover, I don't think we can expect code reviews to occur. As Michael already said, one goal of the new structure is that we only let "trusted" developers and/or packagers in. Of course, this only moves the problem to deciding who is trusted, and I guess we can expect that mistakes will be made. In my opinion, this is really an issue of the gimp's security architecture in general, but one whose risk could be increased because of the relative ease of installing new plug-ins. Sandboxing might be a possibility. In the old times, plug-ins used to be executed as separate processes, so app-armor and similar approaches would be applicable. On Wed, Apr 9, 2014 at 2:51 PM, Alexandre Prokoudine < alexandre.prokoud...@gmail.com> wrote: > On Wed, Apr 9, 2014 at 4:43 PM, Tobias Jakobs wrote: > > >> It's a wee bit more complicated. Think of e.g. security concerns. > >> Sure, you can sit down and analyze the code of every submitted plugin, > >> but this solution is not scalable, and a scalable solution (as in > >> "automated check for exploits") is likely to be expensive. > > > > But this is not a new problem. If you at the moment download anything > from > > the registry and install it, it could destroy your system. > > Exactly. You need to 1) go, 2) find, 3) download, 4) find out, how to > install, 5) install. > > Whereas the proposed system suggests taking away steps 1), 3) and 4). > > The expected effect of that will be a huge increase of deployed > extensions and, as a consequence, an increased interest to GIMP from > people who write exploits. My concern is how this interest can > realistically be handled, because we shall be paying for a better > technology with an increased reputation risk. > > > This should not stop us from improving it. > > I wasn't even implying that. > > Alexandre > _______________________________________________ > gimp-developer-list mailing list > List address: gimp-developer-list@gnome.org > List membership: > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list > -- Ingo Lütkebohle, Dr.-Ing. Machine Learning and Robotics Lab, IPVS, Universität Stuttgart http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle +49-711-685-88350 PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F 57D4 CD90 C164 34AD CE5B -- Ingo Lütkebohle, Dr.-Ing. Machine Learning and Robotics Lab, IPVS, Universität Stuttgart http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle +49-711-685-88350 PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F 57D4 CD90 C164 34AD CE5B _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
