On 1 April 2016 at 18:14, Kasim Ahmic <kasim.ahmic@xxxxxxxxx> 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 server-side. 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@xxxxxxxxx> 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 >> folks. >> >> 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 >> install?). >> >> >> >> GitLab? >> ====== >> >> Initially, I had thought Github might be a good option for this but given >> its closed-source nature decided to investigate something like GitLab >> instead. >> >> 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. >> >> >> Organization >> ========= >> >> 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 >> scripts). >> >> 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). >> >> >> Curation >> ====== >> >> 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: >> >> https://gitlab.com/GIMP/GIMP-Scripts/tree/master >> >> I look forward to hearing some thoughts on this! >> >> pat >> -- >> Pat David >> https://pixls.us >> http://blog.patdavid.net >> _______________________________________________ >> gimp-web-list mailing list >> gimp-web-list@xxxxxxxxx >> https://mail.gnome.org/mailman/listinfo/gimp-web-list > _______________________________________________ > gimp-developer-list mailing list > List address: gimp-developer-list@xxxxxxxxx > 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@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
