GNOME.org
 

Re: [Gimp-developer] Fwd: Gimp Registry Future

Hi,

On Fri, Apr 11, 2014 at 7:13 PM, Ingo Lütkebohle <iluetkeb gmail com> wrote:

Oh, and just to clarify, I also mean that effort for *authors* should be
taken into account.


Ok well I understood everything until your "clarification". What
effort for which authors?


On Fri, Apr 11, 2014 at 9:11 AM, Ingo Lütkebohle <iluetkeb gmail com> wrote:


Jehan,

I wholeheartedly support your concerns, but I would advise trying to think
of ways of approaching this in a simpler way. If the registry can support
you in that, let me know.


Well some things can be simplified for the first release, like code
reviews as I said. But some things can't, in my opinion. In
particular, we absolutely need to secure the plugin provenance (secure
channel, signing or any other method) and we absolutely can't
automatically install any binary, with executable rights, generated by
any random person on the internet.

For me, there could be absolutely no discussion about it. That's about
respecting our community, but also about responsibility. The risks to
have malwares are too big, especially for a program as well known,
hence spread, as GIMP. We all know this. As you said yourself, the
registry is receiving more and more abuse. That's an open door for
spam, scam, and much worse. We even have more and more fake GIMP going
on nowaydays on the web, and even on some app stores (very recently
there was such a case, and Michael had to ask for the fake app to be
taken down). We seem to be told on the mailing list of a scam
involving GIMP every few weeks, and that's without counting all the
ones we never hear about. So allowing to install any random,
unreviewed and uncontrolled executable, which can be run under the
user's rights from our official build? That's like creating a
backdoor, a big security breach into a user's data and system.
So no, I don't think there can be much simpler way to this problem.

Note that of course, as a developer, I would first develop a basic
system without much security for quick feature test. But the finale
released system must have all the security in place, when dealing with
such a dangerous feature.


Other than that, the whole searching and browsing UI is likely far from
trivial as you suggest.


Yes you are right. I did not mean to imply all the rest was just easy
stuff (though I mistakenly said so). UI and search algorithm are also
important and difficult (as always). But I still meant to say that for
this specific feature, the security should be taken very seriously. It
just seems to me that your original call (which I saw, has been
relayed by some websites as gimpusers.com) seems to completely
overlook this side, which I think is primordial.

Jehan


cheers



On Fri, Apr 11, 2014 at 3:08 AM, Jehan Pagès <jehan marmottard gmail com>
wrote:


Hi,

On Thu, Apr 10, 2014 at 4:06 PM, scl <scl gplus gmail com> wrote:

Hi,

it's interesting to see what interest such a post can trigger ;-)
To be honest, it wasn't me who started the discussion, I just forwarded
Ingo's call to the mailing list.

'GIMP is easily user-extendable, by ‘one-click’ installation of
plug-ins.' is a part of our product-vision and as far as I remember
there have already been many ideas on this topic, dating back to 2003.

For both the registry and GIMP the situation changes:
Registry: from some or many users who know and use the registry to
potentially every user who can access it conveniently from GIMP. These
are millions.
GIMP: From a standalone application that uses mostly local data to
an application with tighter access to an online service.

I think before we start losing ourselves prematurely in implementation
details like programming language and data formats we should clarify
the overall picture first:
- What are the concrete requirements: functional and nonfunctional
requirements,
- user interaction,
- overall technical architecture and integration into GIMP,
- reuse of existing solutions like package managers,
- who will also care in future for the registry and the plug-in
manager?
- Integration into the Jenkins builds and manpower to handle this.

Examples for functional requirements:
* installing only plug-ins or also other assets,
* curation/quality assurance of provided assets,
* metadata of the assets,
* search and filter functionality.

Examples for nonfunctional requirements:
* performance: be fluent, also with a slow internet connection,
* security, protection against abuse,
* scalability (how many users will access the registry at one time or
at maximum),
* target platform,
* maintainability (even with our given low resources).

Perhaps it would - depending on our resources - first be better to cut
down the registry to the necessary part we can handle, e.g. to remove
the functionality that causes spam and start with a little
thing in GIMP, like a clickable link to open the registry in a
browser and easy to find assets folders in the Preferences.


All this topic is one I am myself very interested too, and I actually
have been thinking about it for 6 months.
If we had been a Gsoc mentor organization this year, I was even hoping
we could find a student willing to kickstart such a plugin management
infrastructure (this was in my personal list of gsoc ideas meant to be
merged with the rest:
http://wiki.gimp.org/index.php/User:Jehan/Hacking:GSoC/2014/Ideas ).

Now if someone wants to take care of this, I am all for not
overworking myself. :-) Otherwise, I would likely tackle the issue
properly in a several months. I am currently farming alpacas :P thus
in the impossibility to focus on such an important problem, but in end
of May I will be much more dedicated to GIMP again (though I have
several GIMP-related priorities at this time, before even thinking
about a plugin management system).

Now before I become silent again, I will still raise what I believe
are much important problems than any technical issues: security and
responsibilities of the GIMP project. If that had been a gsoc project,
I would have given most of the technicalities to the student and would
have taken care of security personally.
Basically having a website where anyone can upload anything and anyone
else is fully responsible for checking oneself and installing manually
is one thing. But providing a plugin management system, released
together and integrated with GIMP, which would download and install on
the user's behalf, and even auto-update plugins is a completely
different matter. If not mistaken, there is no proper sandbox for GIMP
plugins, so they are technically executables that GIMP runs and which
can do many kinds of nasty stuff. We suddenly have a much more bigger
responsibility:

- We must not accept anything without at the very least a minimum of
check. Ideally we would need security analysis programs to
automatically review each and every code uploaded (calls to third
party URIs, attempt to access networks, system calls which are likely
not normal in a GIMP plugins, etc.), then technical-minded
contributors to review codes of any suspicious plugin (being the case
when the previous automatic review did pick up some strange patterns)
for any funny story (scam, attacks, using your computer as a ghost
machine, etc.). We could of course start with a self-managed community
(abuse button, vote system, etc.) until some admin steps in to install
code review scripts, and enough users step in into code review duty.
Many Free Software started their plugin management this way.
Though obviously even with such a community system, I would feel fine
only with at least a minimum of check.

- We should definitely not accept uploaded binaries. For me, this is
an absolute *no*. Binaries are black boxes. What it means is not that
C plugins should be forbidden but that the C plugin devs should upload
their source code *only*. And we should have compilation systems
running on our servers to compile C code for at least each of the 3
main platforms, both 32 and 64bits. That's already 6 compilation
processes to take care of (and we still forget some platforms like BSD
or Solaris!).
That is very cumbersome. But I will absolutely never condone
automatically uploading then installing binary executables into user's
computers, coming from any random dude on the planet.

- Users should always be able to see the code which is running on
their computer. So even for binary plugins, we must at all time keep
the codes, and keep them available to users. I don't speak about
licenses. I obviously prefer Free Software licenses, and if it were
only me to decide, I'd accept only FLOSS plugins. But if ever many
people were ok to accept non-Free plugins in the system, I would not
mind *as long as* we can still see the code. A cool stuff about this
could be to even provide git repositories for plugin developers
(Wordpress does this for instance, and that's very nice).

- Obviously a basic stuff should be that we must sign every plugin, or
they must come through secure channels (SSL/TLS signed), or even both.
Now this said, this is Free Software, and anyone can come in and
compile GIMP after changing URIs to their personal server and modify
public keys to match their own. Then users would trust a scam plugin
that one thinks signed. That's a problem which can't really be easily
fixed. One way is legal. During LGM, the topic of branding has been
several times raised, and that could be used to this effect. We could
effectively forbid any third party compilation to be called "GIMP"
according to some criteria. One of the criteria would be that they
cannot change the plugin servers and any security key that we put in
place for user safety.

In any case, when I read:
«
Specifically, we need a plug-in which could access a back-end database
over the Internet, carry out queries, receive data in XML or JSON
format, download plug-ins, and install them automatically.
»
For me, it feels like a joke. That's the easy part. That's the obvious
side and that can be coded in just a few dozen minutes. But there is
so much more. A system which does only this part, I would never want
it to be a part of released GIMP. If we want to do this (and I want to
do it!), then we must do it well.

Or maybe we don't mean a system part of the official GIMP release. And
in this case, do as you want. :P
But for something official, you have above the minimum I would care
about for this to happen.
Have fun all!

Jehan

P.S.: also to be properly done, such a system would not be only about
downloading and installing. It should also be about managing! That
means that a proper manifest format must be specified to keep track of
installed plugins. This would allow proper listing, uninstallation,
auto-updating, etc. because currently the plugin management is manual
and thus very messy. This is not as important as the security part of
course. But if I were to do this, I would still want to include such
considerations from the start because that would change a lot GIMP
usage.


Kind regards,

Sven




_______________________________________________
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

_______________________________________________
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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]