Re: [Gimp-developer] [Gimp-web] Gitlab as a replacement for

On 1 April 2016 at 18:14, Kasim Ahmic <kasim ahmic gmail com> wrote:
I personally am a huge supporter of redoing the registry, and I like the ideas you've proposed here. My 
only concern is one that was actually brought up by someone else a few months ago; registry integration 
within GIMP and the possibility of viruses.

I don't quite remember who mentioned it, but they brought up that registry integration within GIMP itself 
could potentially open the doors to viruses unless a virus detection feature was built into GIMP as well. 
Now, I'm not entirely sure how true this is but I would like to hear a final say on this whether this is an 
actual issue or not.

If it is an issue, what would be the best way to handle it? I'd imagine that building virus scanning within 
GIMP would take quite a long time and be pretty impractical. As such, I would suggest that we go with a 
self hosted solution so that we could incorporate a virus scanner on there to scan all the uploaded assets. 
Either that, or a hosted solution like GitLab that come with a virus scanning option along with it.

Again, not sure how much of an issue this even is. Just a thought.

So - this would be one of the main  purposes of a "curation" -
Only non-malicious assets would be made available as "safe" from the
Having security features on the client side (i.e. on the computer of
the person running GIMP), is
not feasible: one single line of code in a rogue plug-in can wipe the
user harddrive.
. Assuring assets are safe, even if few, and can't be maliciously
modified, in the repository is hard enough -
but can be done.

The hard-to-balance thing is allowing publication of assets by a large
amount of people, and having process/volunteers
to ensure these assets are safe. Either way, I think the download and
install should be done with a few clicks from wthin GIMP itself -
we don't have to burden users to locate the file in a browser,
download it, copy it to the right folder, set its file properties
if that is not needed. If the assets represent a danger, they will
represent an equal danger in this "manual way".

 - Kasim Ahmić

Sent from my iPhone

On Apr 1, 2016, at 4:32 PM, Pat David <patdavid gmail com> wrote:

Continuing on some discussions from irc... is down for the count.

I was thinking recently about some ideas for a possible replacement.
Mostly thinking along the lines of what made the registry work well for

In the rest of this email, I'll use the term "asset(s)" to refer to things
like plug-ins, scripts, or brushes/gradients/curves/other assets.

Some essential functionality based on the old registry drupal instance:

1. Upload/Download assets for GIMP.
2. Describe the asset (usually by the uploader).
3. Comment on the assets.

This was handled previously by using drupal, which treated each entry as a
post/node that included the ability to upload files, write about the files
as a post, and had comment threads below it.

Keeping this functionality would be good, I think.  The ability to post an
asset is a given, but the ability to interact around it helps foster the
community (and provides nice feedback for the authors).

From those thoughts, what would be nice to have in a replacement:

1. Provide at least the same previous functionality (as listed above).
2. Managed or easier to manage and keep updated.
3. Easier account management.
4. Collaborative environment for shared assets
5. Support possible GIMP integration in the future (one-click asset


Initially, I had thought Github might be a good option for this but given
its closed-source nature decided to investigate something like GitLab

I like this idea personally due to some nice infrastructure:

1. The service is hosted + managed (and available as Free Software just in
case we felt we needed to break out and host it ourselves).
2. The service integrates OAuth sign-in using a few different account types
(lowers barrier to entry to participate).
   a. they use accounts, Google, Twitter, Github, or bitbucket accounts
for sign-in.
3. Projects maintain all the git-goodness for control and tracking
4. Projects created as a git project can have a full description/README
along with issue tracking integrated in the site

So, we can fulfill the original registry functionality and get the added
benefit of a git infrastructure for those wanting to contribute, user
accounts using OAuth to make it easy to participate, and the ability to do
some interesting things (git submodules).

In speaking with Jehan about this, we should also consider what might be
needed to support the ability to install assets from within GIMP in the
future easily.


Jehan suggested that each script/plugin/asset have it's own git repo.
This would be handy, particularly if script authors did this as well (as it
considerably eases the inclusion of external repos as submodules).
However, akk points out that many folks don't (won't?) organize their repos
in this way (it gets a little... unwieldy pretty quickly if you have many

I'd like some input on what would make the most sense or work best for
possible organization of repos.

I was also thinking that we could include some simple metadata in both any
script files and the files as a means to possibly help parsing
relevant information for automated inclusion at a later date (GIMP plug-ins
installer type of idea).


Initially I was thinking that curating the scripts for inclusion would be
important.  It's certainly possible for a smaller subset of all of the
available scripts from the registry now to pick out ones that we use and
check that they're not malicious and properly tagged/included.  For
instance, there's a handful of scripts that I personally find myself using
often and can help validate/curate for inclusion.  I don't mind doing more
as needed.

I just wanted to get a discussion started about how we might consider
moving forward on something like this.  I think the scripts/plug-ins are
important enough to users that it would be good to try and get something up
and running soon.

I have started experimenting with including submodules from other author
repos and how it might look here:

I look forward to hearing some thoughts on this!

Pat David
gimp-web-list mailing list
gimp-web-list gnome org
gimp-developer-list mailing list
List address:    gimp-developer-list gnome org
List membership:
List archives:

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]