Re: [Gimp-developer] Gimp Registry Future

[Jehan Pagès <jehan marmottard gmail com>]

Hi Simone,

On Sun, Apr 13, 2014 at 12:44 AM, Simone Karin Lehmann
<simone lisanet de> wrote:
> Hi Jehan,
>
> Am 12.04.2014 um 12:57 schrieb Jehan Pagès <jehan marmottard gmail com>:
> > I don't think it is necessary for the addition of third party servers
> > to be made too difficult (and in particular having to recompile is
> > over and in practice means that a normal user will never be able to do
> > it, but it would be made easy only to scammers). It could just be a UI
> > preference. As long as we display proper warnings "at your own risk"
> > because unreviewed plug-ins can simply do anything to a user's
> > machine.
> >
> > Also if we decided to use branding for protection of users, I would
> > say that a third party build can be named GIMP if and only if the only
> > plug-in server active by default if the official one.
>
> Doesn’t this conflict with the GPL? Let’s assume, I take the GIMP sources and add my own plugin server 
> which offers only precompiled OS X binaries, how is that different to the current situation where I provide 
> those plugins already installed in the application bundle? Am I forced to name my bundle different?

No this is not a conflict with GPL. The code is still GPL and we
cannot prevent anyone from reusing, modifying, and distributing it.
Nor are we willing to (at least in my case, but I think, in the case
of other contributors too). I deeply like FLOSS and would not want to
change this in any way.

Trademark is something else and is completely parallel to code. This
is about usage of "names". You can still use GIMP code and do whatever
you want with it (provided that follows GPL, of course, like no
proprietary relicensing), but then you cannot say it is GIMP anymore.
It is "something else", a fork. So it should be called differently.
Someone can still make a scam with GIMP code and we won't be able to
tell him anything about the usage of our code (well a judge could, but
not license-related :p), but at least we could tell one not to name
the scam after GIMP and use its popularity.
That's very common in Free Software. Linux does it
(http://www.linuxfoundation.org/about/linux-foundation-trademark-usage-guidelines),
Mozilla too, and about this there is the very famous story of why
Firefox is *not* named Firefox in Debian (which is a major Linux
distribution!):
http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project
And so on. I believe most of the big projects does trademark damage
control. GIMP is one of the very few that don't do it yet.

Note that I don't like trademarking and any legal stuff in general. I
so much prefer the kind of half-hippy state we are in. But we have to
admit that abuses are getting a little out of control (as said
earlier, many scams are trying to use GIMP name), and in the absence
of other solution (but we are welcoming any other proposal), this one
is not worse than others. As I said though, that's "damage control".
The goal is not to kill third party build (we are Free Software, and
by such, bound to have third party builds), only to decide at which
point we cannot approve build differences anymore. At which point a
patched build cannot be considered "GIMP" anymore.

This is more about trust. Some people trust "us" ("us" being a very
vague concept of the many contributors who met, discussed and agreed
to do things a certain way over the years), they trust our decision
and what we approve of. Someone using the name surrounded by such
trust for a completely different agenda without going through the
common consensus and usual discussion with the rest of the community
could be seen as "deceiving" people. And that's not necessarily in a
bad way, like for a scam. That can be for acceptable reasons (the
Debian case is interesting. Apparently they did not care about waiting
for Mozilla approval first for patching Firefox). But that still is a
different program in the end.
Because yes I understand why you ask. You have a build quite different
in several aspects and it could be a problem if we go with branding
control (I don't know at all if we will! Note that's only
supposition), I have no idea how this would end up for you. But as
said above, this does not have to be seen as a bad thing necessarily.
If ever a trademark conflict prevented a third party modified build to
be called GIMP, that is still in effect a close fork from GIMP, and
you can still say it. Simply it would have to be named differently
because that is in effect different and can be confusing to users too.
IceWeasel (the Firefox rebranded by Debian) has its own popularity too
and many people are proud to say they use it (even though everyone
knows and there is no secret about the fact that it is mostly a
Firefox rebranded, but potentially with slight differences here and
there).

I'd say that's a choice. If a contributor really don't want to play
the game of sharing contributions, discussing, arguing even, and
coming to compromises with one's own ideas, well one choose to be on
its own.
And I know that's frustrating, for all of us! I would love to see
everything go my way and each and every of my whims being immediately
accepted and implemented by me or someone else. Also agreeing all
together is slow. To have something actually happens takes time. I
would have time to implement specific features 4 times myself in the
meantime instead of arguing about details!
But I know also that I need the others and that I couldn't make GIMP
what it is without all the other contributors. So I can't just drop
everyone else and go my own way. So I feel it is only fair that if
someone was to decide and go one's own way, this is not GIMP anymore.
One can't have both at the same time: GIMP (as a community software
made by *many*) and full power of decision (self-led project where you
are the only boss).

> > If you build
> > GIMP by adding any third party server, without telling the user about
> > it, it can be a scam risk because
>
> of course this _might_ be a risk, IMO it’s the same sort of risk as if you install some precompiled binary 
> plugin from one the uncounted Linux distributions.

Not at all! The distributions you are talking about do exactly what I
meant. First of all, they don't accept binary uploads from random
dude. I don't know if you ever contributed a package to any Linux
distribution: you don't upload any kind of binary; you only write down
the information on how to build from source in a spec file. You can
add last minute *separate* patches, but that's it; you don't provide
the main code (it is taken from the actual source), so any change
you'd try to do on the code is easily reviewed by your peers. And the
finale binaries are built by the distribution servers.

As for the original source itself, well the package maintainer won't
review the whole code if that's a very famous plug-in, I guess (you
probably don't review G'mic. It has its own many developers and
contributors), but you would review some plug-in coming from nowhere.
Especially if the package has been provided by a one-time contributor.

Linux distrib's package managements are pretty safe, and indeed imply
"no binary upload", "signing" (try to install a package from an
unknown source: you'll have a warning about the risk, and you can
continue or cancel) and "peer review", just as I want.
So no, the risks are very low. And that's exactly the kind of low risk
that I would want to provide if we were to provide easy plug-in
management.

> > the user would not have had the
> > original warning (hence would feel safe while one may not be).
>
> OTOH, if one provides his own plugin server repository, such a message in the ‚official‘ GIMP will 
> discredit the ‚non-official‘ version as a possible security risk only  because of some other kind of 
> distribution.

Well we can't vouch for everyone, especially if we don't know them. If
they really want to have the approval from GIMP, they can as well
contribute and improve the main plugin repository. Now there may be
reasons at times when you just cant to do this, and they can be fine
reasons. When this happens, there is nothing we can do. We don't know
what is "behind the servers" of this person. We have no idea what is
being done to provided plugins: are they modified before installation?
Are ads added? Are spyware added? Anything bad done? In most case, of
course that is not the case, and a third party repository is perfectly
fine. But we just don't know. How can we vouch for them?

The person has to build one's own community, one's own public trust.
If this person does not want to share with us and trust us, we cannot
share back the trust given to the GIMP. This is only about trust
networking.
And that's not a discredit from anyone. That's just a fact: we don't
know, so there is a risk "as far as we know".

Also most software and distributions are similar: when third party
repositories are possible, there will be people making them. They are
not discredited (at the opposite if the possibility to make them was
given to the community!) but the original project cannot vouch for
them. And they'll always tell it: there is a risk, the project cannot
check what is there, this is "untrusted", etc.

If I look at Ubuntu's PPA for instance, before the installation
procedure, it is written: "You can update your system with unsupported
packages from this untrusted PPA by [...]". When reading details:
"Important: The contents of Personal Package Archives are not checked
or monitored. You install software from them at your own risk. "
But still that does not prevent users to install software from PPA. :-)

> To make this clearer, I’ll give some example.
> Think of the current situation on OS X. The stock GIMP bundle from gimp.org is not code signed. AFAIK this 
> is because one has to have a paid Apple developer account to get a code signing certificate and currently 
> no one wants to pay the annual fee. Now, to bypass the warning a user will get if he installs this unsigned 
> application, he’s advised to turn off this security check in OS X’s System Preferences. Hhmm, IMO not a 
> good advice in the sense of security.
>
> Now, as you know, I provide a compiled GIMP application bundle with many third party plugins. My 
> application bundle _is_ code signed. Should I display a warning, that if if a user want’s to install the 
> stock GIMP he’s doing it at his own risk, because he get’s advised to turn off a security feature of his 
> operating system? How would the core developer team feel about this?

Well I don't know. First a question: so are you saying that our
current official OSX packages (the ones available on our ftp server
and mirrors) are not signed? That's a honest question, I have no idea
(and because I'm going to sleep now, I won't connect on IRC to ask
this). Well if that is really the case, I'd say we need some
contributor willing to pay for it (or use one's existing one). You,
maybe? Then we would be able to sign GIMP and any reviewed and
compiled-on-our-server plugin.

I mean, GIMP is a community project. There is no duty from us to
anyone. We all work on what we like. I happen to not use OSX. So I
can't take care of this side. And if it happens that apparently no OSX
developer in the whole world seem to care enough about GIMP to sign it
for us, well... what can we do? It seems that there is not enough love
from the OSX world to GIMP. Why don't you contribute by signing the
official GIMP then, if that is to improve security for users? Why
would the solution be to not sign anything instead? That does not look
very logical to me (and the right solution looks much simpler).

> Don’t get me wrong, code signing is a very useful feature. But forcing third party developers to use only 
> _one_ specific distribution path or otherwise getting discredited as a possible security risk is not a good 
> move. Even Apple let’s you sign your code to pass the code signing test on first launch and still let you 
> distribute your applications however you want.

Ok I think you misunderstood. Nobody proposed to force anything. And
with the previous discussion (which is just this: a discussion, not
even a line of code. Also note well that I don't talk in the name of
GIMP or anything. Just to make sure. I talk in my personal name as a
single contributor, giving one's opinion on a matter), we were even
saying we could very well allow third party repositories. And people
would most likely still be able to install plug-ins the old way if
they find some code lying on a forum, or websites listing plugins like
the current registry.gimp.org. Simply we cannot take responsibility
for them. Anyone can write a fake GIMP plugin which does very harmful
stuff. So if a plugin does not pass through our slightly safer and
controlled procedure (not 100%, but at least some automatic code
review, then human code review if automatic code reviews digged up
strange stuff, then community voting/commenting once the plugin is
out, etc.), there is a risk, and we say it. That's it. Nothing more.
There is no discredit. We hate nobody and at the opposite, we would
really love people to come to us. We just can't vouch for black boxes.

A comparison for the end:
What you are asking here is that if a complete stranger, hidden under
a mask and a cape, brings a black box with a strange tic-tac sound
inside and asks us to give the box to one of our friend, we should say
"yes of course no prob". Then we go to our friend, who trusts us of
course, and tell him "hey that's cool stuff, open it!".

Of course maybe that was just a very cool man with trendy clothes, and
he just offers awesome clocks around. But I don't know this. So I
can't vouch for this unknown masked guy. If I am very nice, at best
this second scenario would likely happen: I would take the box with a
stick and tell my friend "this strange masked guy gave me this ticking
box for you. Well... be careful. Maybe that's not dangerous, but I
definitely don't know. Decide at your own risk what you do with it."
That's the "accept unsigned plugins and repositories but with
warnings" scenario.
On the other hand, if the stranger comes to me and we open the box
together, and we can actually see the extra cool clock in it, and he
let me rebuild the clock and close the box myself to be sure. Then
I'll be much more confident to tell my friend "hey that's a cool clock
inside. I checked." This one is the "go through the official plugin
repository and follow its rules" scenario.

That's all I'm saying. Nothing more. Nothing about wanting to
discredit anyone. :-)

Jehan

> Simone Karin
> _______________________________________________
> 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