On 1 April 2016 at 18:14, Kasim Ahmic <kasim.ah...@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
. 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 <patda...@gmail.com> wrote:
>> Continuing on some discussions from irc...
>> Registry.gimp.org 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 README.md 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-developer-list mailing list
> List address: gimp-developer-l...@gnome.org
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives: https://mail.gnome.org/archives/gimp-developer-list
gimp-web-list mailing list