Plugin Manager

[nicinabox]

What you are saying here makes a lot of sense to me. The one area that I would worry about is the "Addons are registered with an official server" model. This will work for the core stuff but Toms already said he worrys about "implied endorsment by hosting addons".

 

"Registering" means that there is a central list that the installer can pull from. This is the glue that creates a unified system. Anyone can register an addon. There is no peer review for this part. This is how rubygems and npm works--not a new concept. There's no "verification" here, and is probably not needed. Addons source should be open source on Github or other so the source can be reviewed by anyone. We could even introduce a "verification" or "official addon" system if need be to help bubble up the best ones.

 

How viable would it be to allow any number of Addon repositories? Alternatively we will need to come up with some sort of GPL unRAID Addon counsil/peer review system

 

Addons should be hosted on their own repo. Git preferred. SVN is probably possible. Addons should provide their own licenses. They are not the responsibility of Lime Technology.

[zoggy]

What you are saying here makes a lot of sense to me. The one area that I would worry about is the "Addons are registered with an official server" model. This will work for the core stuff but Toms already said he worrys about "implied endorsment by hosting addons".

 

"Registering" means that there is a central list that the installer can pull from. This is the glue that creates a unified system. Anyone can register an addon. There is no peer review for this part. This is how rubygems and npm works--not a new concept. There's no "verification" here, and is probably not needed. Addons source should be open source on Github or other so the source can be reviewed by anyone. We could even introduce a "verification" or "official addon" system if need be to help bubble up the best ones.

 

How viable would it be to allow any number of Addon repositories? Alternatively we will need to come up with some sort of GPL unRAID Addon counsil/peer review system

 

Addons should be hosted on their own repo. Git preferred. SVN is probably possible. Addons should provide their own licenses. They are not the responsibility of Lime Technology.

 

the problem that i've seen with this approach is when people beat the actual authors to the punch.. and for example lets say they register 'xbmc' and that's not really the right one.. or ever worse.. a malicious one.. people then could quite easily install something they think is trust worthy but have ill consequences. anyways having some sort of moderation is a solution for that.. but thats more overhead than i'm sure tom or anyone wants...

 

[drawz]

aitch nailed it, but I feel like we are reinventing the wheel here. There are countless other distros out there with a variety of different ways to manage packages, dependencies, and plugins. Several of these, such as OpenELEC, OpenWrt, Synology, etc. are very specialized and limited distros. There much be a way we can work off of what they are doing.

 

In theory, using the official Slackware package repository and one of the compatible package managers is the way to go, BUT we are still based on Slackware 13.1, which is now 3 years old. Critical security fixes are available (incorporated in unRAID though??), but it's not exactly up to date, which may cause problems when trying to keep plugins current.

 

Ok, maybe it's not so simple....that upgrade to Slack 14.0 Tom mentioned would help. Really, if we could get on board with unRAID running on any modern distro that stays up to date in general, it would be a lot easier to do all of this. In fact, it would also make Tom's life easier with regards to hardware support and kernel updates...

 

In conclusion - this needs to wait for 5.1 or 5.2, as much as I want it.

[Joe L.]

Does crossing the 5.0 barrier break 4.7 unMenu plugins?

no, they still work as they did

[nicinabox]

the problem that i've seen with this approach is when people beat the actual authors to the punch.. and for example lets say they register 'xbmc' and that's not really the right one.. or ever worse.. a malicious one.. people then could quite easily install something they think is trust worthy but have ill consequences. anyways having some sort of moderation is a solution for that.. but thats more overhead than i'm sure tom or anyone wants...

 

You make a valid point. It's sort of a catch-22 situation. Either have a gatekeeper that approves each addon (which leads to nonpartial judgement), or allow anyone to publish addons and risk something malicious.

 

That's where verified packages come in. Addons should be developed in the open (Github is preferrable). A malicous author would be unable release peer-reviewed, open source code with malicious intent. We can further validate packages without blocking installs by officially verifying them. That could mean they're peer reviewed, rated, both, or something else. Basically, something so say "hey, this addon is high quality".

 

After that, naming is sort of on the honor system. Don't clobber up namespaces unless you really mean to develop and support an addon for that namespace. This approach has worked well in the ruby and node communities. Malicious packages aren't really a problem.

[nicinabox]

aitch nailed it, but I feel like we are reinventing the wheel here. There are countless other distros out there with a variety of different ways to manage packages, dependencies, and plugins. Several of these, such as OpenELEC, OpenWrt, Synology, etc. are very specialized and limited distros. There much be a way we can work off of what they are doing.

 

In theory, using the official Slackware package repository and one of the compatible package managers is the way to go, BUT we are still based on Slackware 13.1, which is now 3 years old. Critical security fixes are available (incorporated in unRAID though??), but it's not exactly up to date, which may cause problems when trying to keep plugins current.

 

Ok, maybe it's not so simple....that upgrade to Slack 14.0 Tom mentioned would help. Really, if we could get on board with unRAID running on any modern distro that stays up to date in general, it would be a lot easier to do all of this. In fact, it would also make Tom's life easier with regards to hardware support and kernel updates...

 

In conclusion - this needs to wait for 5.1 or 5.2, as much as I want it.

 

You're totally right. Unfortunately, Slackware doesn't follow the same philosophy as these distros. It doesn't have a good package manager by design. I'm all for moving to a Debian or CentOS based system, but that's not what we have right now, nor in the prospective future. If unraid were to move to a stripped down Ubuntu, for instance, that would easily solve package management. We'd still be left will addon management for unraid.

[zoggy]

so back to what i've brought up before.

 

The whole plugin thing involves multiple problems that need to be solved. Personally I do not think this is something that should be rushed.. or hold back 5.0. Especially this close to the finish line.

 

With that said, there needs to be a dialog going from the community on what they want/expect/need. Especially when there are so many smart people willing to donate their time to make something better.

 

Tom knows whats included with unraid and what he feels is worthy of including going forward. There are several apps that could be included with unraid by default that would make things a little easier going forward, however this then starts to add some bloat to the install - which some people may not appreciate / have the resources for.

Python? Ruby? PHP? Perl? then SVN? GIT? BZR? CVS? etc..

 

The foundation is important and the choices we make should be sensible.

 

What architecture should the plugin manager support?

Should we only show the bleeding edge, or maintain the last 2 versions + beta/dev, that way we give options if one isnt working well.. fallback support?

 

The package manager in slackware is not great for automation / unraid's purposes. I suggested using something like slapt-get that is a wrapper ontop of the slackware package manager (uses those calls) but extends it slightly to give it more 'apt' like feel. This is only one piece of the puzzle, and trying to figure out the tools to put the puzzle together is another battle in it self.

 

It doesn't make sense to use bazaar if everything else uses git..  but services like launchpad offers translation support while github doesnt.. 

(I personally dislike bzr compare to git, but translations is one of github's weak points.. why with Sabnzbd we have a launchpad repo for translations and then everything else is on github)

 

PHP allows one to write quick code.. but due to the lack of enforcing good coding habits.. its also very easy to write sloppy code. Perl allows for much more efficient code but there is a bit more of a learning curve.. Python works well and tends to enforce better habits, however it does have its own pitfalls with unicode strings.. Ruby can do some wonderful things but coding in it is not for everyone.. since its the new kid on block there also isnt the user base that the other languages have in comparison (prepare the torches).. Sticking to shell scripting seems to make sense but there are a bit of extra work involved as you can only do so much in a script (you can do some amazing things in a script.. but it takes that much more code compared to a 'real' language)...

 

How does other NAS solutions handle their plugins? Synology, QNAP, Drobo, ReadyNAS, WHS, FreeNAS ?

 

[dalben]

The fact other NAS solutions handle plugins well is probably a good reason, from a Lime tech / Unraid product point a view, to hold back the release of 5.0.

[nicinabox]

so back to what i've brought up before.

 

The whole plugin thing involves multiple problems that need to be solved. Personally I do not think this is something that should be rushed.. or hold back 5.0. Especially this close to the finish line.

 

With that said, there needs to be a dialog going from the community on what they want/expect/need. Especially when there are so many smart people willing to donate their time to make something better.

 

Agreed. I believe the community can put this together outside of the 5.0 release. I got some fantastic feedback about how people use Unraid.

 

Tom knows whats included with unraid and what he feels is worthy of including going forward. There are several apps that could be included with unraid by default that would make things a little easier going forward, however this then starts to add some bloat to the install - which some people may not appreciate / have the resources for.

Python? Ruby? PHP? Perl? then SVN? GIT? BZR? CVS? etc..

 

The foundation is important and the choices we make should be sensible.

 

Yes. The key here is not to load up everything out of the box. That truly is wasteful of resources. What we do need are sensible defaults though. Python, PHP, and Ruby are easy to get running. Python and Ruby sometimes go hand in hand (Sinatra is a good example). Perl is rather outdated.

 

You mention resources...it's 2013. If your system doesn't have the resources to run what's provided, then it's easy to fallback to the basics basics. However, the systems that can run the "latest and greatest" (which really should take much) shouldn't be hindered by the 15 year old systems. That's the problem we are currently sitting with.

 

What architecture should the plugin manager support?

Should we only show the bleeding edge, or maintain the last 2 versions + beta/dev, that way we give options if one isnt working well.. fallback support?

 

Great question. I feel like we won't know this unless we have a better idea of what versions are currently being used. Something like 1 out of 30 users is not on 5.0rc according to the survey. Many systems are 2 years old or newer. This gives a great starting point for using more modern technologies.

 

The package manager in slackware is not great for automation / unraid's purposes. I suggested using something like slapt-get that is a wrapper ontop of the slackware package manager (uses those calls) but extends it slightly to give it more 'apt' like feel. This is only one piece of the puzzle, and trying to figure out the tools to put the puzzle together is another battle in it self.

 

Agreed. I've been doing some research on slapt-get myself. I think it has some potential, but I haven't gotten it to be 100% reliable yet.

 

It doesn't make sense to use bazaar if everything else uses git..  but services like launchpad offers translation support while github doesnt.. 

(I personally dislike bzr compare to git, but translations is one of github's weak points.. why with Sabnzbd we have a launchpad repo for translations and then everything else is on github)

 

I'm not sure exactly what you  mean by translations. i18n?

 

PHP allows one to write quick code.. but due to the lack of enforcing good coding habits.. its also very easy to write sloppy code. Perl allows for much more efficient code but there is a bit more of a learning curve.. Python works well and tends to enforce better habits, however it does have its own pitfalls with unicode strings.. Ruby can do some wonderful things but coding in it is not for everyone.. since its the new kid on block there also isnt the user base that the other languages have in comparison (prepare the torches).. Sticking to shell scripting seems to make sense but there are a bit of extra work involved as you can only do so much in a script (you can do some amazing things in a script.. but it takes that much more code compared to a 'real' language)...

 

Ruby isn't exactly new. It's 15-20 years old--almost as old as Python. It has a huge user base and extremely stable code. Not to mention very high quality code overall. Writing Ruby is almost like writing English and the syntax is very fluid. Checkout the code for getting system information in Ruby (I would link to the simplefeatures SystemInformation.php for comparison, but it doesn't seem to be public)

 

It would be trivial to setup a DSL (linked for those unfamiliar) so authors could create uniform layouts for addon settings and such. Other addon parts are still shell scripts, not really any different than now.

 

How does other NAS solutions handle their plugins? Synology, QNAP, Drobo, ReadyNAS, WHS, FreeNAS ?

 

I don't know how they do it. But again, we have to be careful to separate OS packages from product addons. Plugin/addon systems have been done many times in the past. We don't have to reinvent the wheel, we just need a wheel that works for our vehicle.

[NAS]

What you are saying here makes a lot of sense to me. The one area that I would worry about is the "Addons are registered with an official server" model. This will work for the core stuff but Toms already said he worrys about "implied endorsment by hosting addons".

 

"Registering" means that there is a central list that the installer can pull from. This is the glue that creates a unified system. Anyone can register an addon. There is no peer review for this part. This is how rubygems and npm works--not a new concept. There's no "verification" here, and is probably not needed. Addons source should be open source on Github or other so the source can be reviewed by anyone. We could even introduce a "verification" or "official addon" system if need be to help bubble up the best ones.

 

This is the point I am making, a single central anything that is in the critical path isnt going to work. This is the route XBMC had to move away from once they realise it was a fundamentally flawed approach.

 

Also consider these three cases in light of the fact Tom has already said he is worried about implied reponsibilty.

 

1. I create addon "super pr0n donwloader". Limetech LLC has to host referecnes to it.

2. I create addon "Limetech sucks use this product instead"

3. Limetech LLC goes away. Every addon dev would be screwed until the base OS was changed or some othre ugly hacks put out there.

 

How viable would it be to allow any number of Addon repositories? Alternatively we will need to come up with some sort of GPL unRAID Addon counsil/peer review system

 

Addons should be hosted on their own repo. Git preferred. SVN is probably possible. Addons should provide their own licenses. They are not the responsibility of Lime Technology.

 

Unfortunately this is incorrect. If Limetech LLC hosts the central list they have a legal burden on what is being deliverd using their delivery mechanism. There are plenty of cases for this in torrent and nzb land.

 

Rightly or wrongly this is the legal landscape we line in. Again this is another reason XBMC went the "many repo" option.

 

Also even in Linux land we split repos by license type. We are designing in a fundamental limit if we can only have one repo.

 

 

Dont get me wrong I think the way these ideas are going are superb but we need to keep the big picture in mind as well.

 

[MvL]

How does other NAS solutions handle their plugins? Synology, QNAP, Drobo, ReadyNAS, WHS, FreeNAS ?

 

Hi, I'm not sure if i belong here. It's an interesting read though.

 

FreeNas use light virtualization (Jails) for there plugins. They introduced it in there latest version. http://doc.freenas.org/index.php/Jails 

 

I think this approach add a extra layer of security...

[JustinAiken]

Worrying too much about security on plugins is putting the horse a couple of miles before the cart... Most power users have what, 5-10 plugins installed?  A simple attractive way to manage/update these is more pressing... I mean, I've apt-getted 100's of times, installed a plethora of XBMC Addons, and I can't even begin to count the number of Rubygems I've used - and I've never had a problem with security.  When I find a gem that's broken for some reason, I can usually find it on Github and fix it...

 

Dependencies and a standard packaging format are the problems we need to solve, not adding extra layers of virtualization or worrying about if someone makes a plugin recommending Drobo...

 

I think aitch's unto something with a DSL and semvar versioning,

[jumperalex]

Worrying too much about security on plugins is putting the horse a couple of miles before the cart...

 

You LITERALLY could not be more wrong if you tried.  There is absolutely no such thing as thinking about security too soon.

 

Sent from my Galaxy Nexus using Tapatalk 2

 

 

[Dephcon]

There is absolutely no such thing as thinking about security too soon.

 

There is no greater truth in IT/software.

[MvL]

Maybe virtualization is to much for unraid.., just reporting how freenas it does...

[nicinabox]

This is the point I am making, a single central anything that is in the critical path isnt going to work. This is the route XBMC had to move away from once they realise it was a fundamentally flawed approach.

 

Also consider these three cases in light of the fact Tom has already said he is worried about implied reponsibilty.

 

1. I create addon "super pr0n donwloader". Limetech LLC has to host referecnes to it.

2. I create addon "Limetech sucks use this product instead"

3. Limetech LLC goes away. Every addon dev would be screwed until the base OS was changed or some othre ugly hacks put out there.

 

This is a bit hyperbolic. Let me point you to a question on Stackoverflow that answers this nicely.

 

There's nothing fundamentally different about my suggestion then the current setup. I'm not familiar with what XBMC's situation is exactly, but this is how package management works for rubygems and node and it's not a problem.

 

Remember, the user takes an action to manually install addons here--they don't just sneak into your system magically. Don't install software you don't trust, simple as that.

 

How viable would it be to allow any number of Addon repositories? Alternatively we will need to come up with some sort of GPL unRAID Addon counsil/peer review system

 

Addons should be hosted on their own repo. Git preferred. SVN is probably possible. Addons should provide their own licenses. They are not the responsibility of Lime Technology.

 

Unfortunately this is incorrect. If Limetech LLC hosts the central list they have a legal burden on what is being deliverd using their delivery mechanism. There are plenty of cases for this in torrent and nzb land.

 

Rightly or wrongly this is the legal landscape we line in. Again this is another reason XBMC went the "many repo" option.

 

Also even in Linux land we split repos by license type. We are designing in a fundamental limit if we can only have one repo.

 

 

Dont get me wrong I think the way these ideas are going are superb but we need to keep the big picture in mind as well.

 

You may have misunderstood me. I am saying authors should use their own repos. The "central list" needs little more than a key value store of released addons. Like Aptitude pulls from an official list of packages, we need to pull from an official list, regardless of where they are hosted[1].

 

Limetech hosts a list of plugins in the wiki right? That's a reference to install a plugin. The only real difference is that it would move to being automated through an API. Licenses are the responsibility of the author, but the repos should be open source so the code can be read and improved.

 

Addons, by nature, are an unofficial extension to core services.

 

[1] "Hosting" should be done from Github, in my opinion. It's quite easy to build the package this way. Proof of concept. This is how Bower works.

[NAS]

There is absolutely no way Limetech is going to host any reference to "super pr0n downloader" and thats the crux of this.

 

If Limetech LLC has to be the holder of some unique master list that is required for a plugin to be installed then it is destined to become a problem as they have made this plugin available.

 

It does not matter if the code came from them, they were a decision maker in the delivery path.

 

The system also has to be able to operate completely independent of Limetech LLC to be truly scalable and useful.

 

And this is the XBMC repository reference. They had the same problem and overcame it by allow an number of repository's. Most people stick with the one official "list/repository" but many add several allowing them to install many questionable plugins completely independent of XBMC.

 

Are we at crossed purposes talking around different points?

[butlerpeter]

I think that, in the first instance, the plugin manager should just be a frontend for the current way of installing plugins. Essentially removing the need to go to a terminal.

 

The user can provide the path to the plugin file, either locally or a remote url, and the plugin manager then handles downloading (if necessary, and running installplg.

 

It would also be good if there was a way to control, in once place, which plugins get installed and in which order they are installed.

 

For now I think that would be all that is needed - it takes what we have now and prettys it up. Any questions on package management or hosting can then be dealt with in the correct manner, and a full blown plugin manager released with 5.X (or 6.X).

[nicinabox]

There is absolutely no way Limetech is going to host any reference to "super pr0n downloader" and thats the crux of this.

 

Of course. But that's also the case right now in the wiki. I hear what you're saying, but it's really not a problem. It would be easy to unregister or remove references to a malicious addon, if such a thing ever happened. Folks aren't just going to load their systems up with bogus addons just because.

 

If Limetech LLC has to be the holder of some unique master list that is required for a plugin to be installed then it is destined to become a problem as they have made this plugin available.

 

It does not matter if the code came from them, they were a decision maker in the delivery path.

 

The system also has to be able to operate completely independent of Limetech LLC to be truly scalable and useful.

 

I intend it to run independently of Limetech. There's no reason anyone should be a gatekeeper here.

 

[RobJ]

Great discussion here!  Lots of valid concerns raised, followed by lots of intelligent ideas.  Keep it up!

 

Here are my own suggestions, to help with current concerns about the current wiki Plugin list.  These are just proposals, but I'd like to begin implementing them (or alternatives as suggested by others) as soon as any of them appear to receive general acceptance.  These may all be superseded by the great ideas above, but I'd like to put something in place now, and since there are some of us who already monitor all UnRAID wiki pages, we just need a better structure in place, to significantly improve the current security and integrity of the current plugin acquisition process.  This strictly applies to the listing process, not to plugin or dependency management.

 

1. Require that any modification to the UnRAID Plugins wiki page can only be made by approved plugin guardians (any moderator or plugin author or approved plugin guardian).  I'd like to add a column to the table for individuals who will police a specific plugin, making each plugin self-policing.  Initially it should be the plugin author(s), but it is possible that a plugin dev may not want to be bothered or leave, so if there are a few motivated and trusted individuals that volunteer to monitor all changes, they can be approved by the current plugin guardians/authors as guardians for that plugin.  It would be good to have them listed on the wiki page with the URL to their forum profile page, making it easy for anyone to contact them if something suspicious is spotted.

 

1a. Any page modification will be reverted ruthlessly, if it appears to be unauthorized.  I thought about nicer ways to handle this (a warning or PM to the author), but security requirements (I think) essentially mandate immediate removal of unauthorized changes.  Reversions can be made by any guardian or moderator.  I welcome any page monitors, UnRAID users who will examine any page changes, checking for changes by authorized editors, checking for correct information, especially checking any URL's changed, checking the MD5, checking the associated forum post for its validity, checking subsequent posts for either general acceptance of the new or changed plugin, or warnings about malicious content.  I especially invite UnRAID individuals who may have wanted to contribute to unRAID but don't otherwise feel qualified and may not post very often, to consider monitoring wiki pages such as the Plugins page.  The more individuals we have doing so, means the more eyes around the world that may be awake and watching.  You can actively check the pages by periodically checking RecentChanges or the page history, or passively monitor it by being subscribed and receiving email notifications of all changes to a page.

 

2. Add MD5 near plugin URL.  When plugin changes, MD5 must change also.  I thought about having them stored elsewhere, such as a special page or the announcement forum post but cannot justify it.  With the current wiki page, the best place is with the plugin URL.

 

3. Require a date of issue listed with each plugin.  There will always be a small window of vulnerability on a publicly editable wiki page, between the malicious plugin posting and its correction/reversion.  So whether it is a new plugin or an update to an existing plugin, today's date should be posted with it.  This helps a user who is unfamiliar with a specific plugin know how long it has been out, and whether it has received sufficient review.  Appropriate guidelines should be posted at the top of the wiki page that warn users to check the date, and if they aren't familiar with the current forum discussion, wait at least a few days, hopefully enough time to catch and revert malicious or buggy plugins.  I note that many of the current plugins listed do have the date of issue, but not all, and I believe that all should have it.

 

4. Require an announcement post in the UnRAID forum, and add a link (near the plugin URL) to this post, for any new or updated plugin, so that a guardian or monitor can verify the plugin, from its wiki listing to its forum announcement, and easily check subsequent posts for acceptance or rejection of the wiki listing changes.  I assume that some authors will keep this pointed to the initial announcement which they will keep updated, and other author(s) will post anew and keep the wiki listing updated with the latest announcement post.  The latter is better for plugins with multiple authors.

 

5. Add a possible status warning label, near the Plugin name.  This would normally be blank, but in certain cases could be something like *SUSPICIOUS*, *MALICIOUS! DO NOT INSTALL*, *NEW AND UNVERIFIED*, etc.  These would probably all be temporary, should result in further appropriate actions, such as edit reversion or even listing removal.

 

6. Add guidelines to the wiki page.  At the top should be guidelines to plugin users (check the issue date, current forum postings, MD5, etc).  At the bottom should be guidelines for page monitors (check each edit for its authorized author, current date (not backdated to appear old and trustworthy), correct info, correct URL's, correct MD5, correct forum post, general forum acceptance, etc) and guidelines for plugin authors and guardians (recommended page syntax for plugins data, maintaining guardian list, etc).

 

These are just my ideas, designed to add some peer review and enforcement policies, feel free to object or improve, etc.  One possible problem, we may need Tom's approval to modify the structure of the table!

 

icon    Plugin Name  (optional warning label)

URL's of forum thread, public info (optional), etc                Plugin Type      Author(s)      Guardians      Plugin URL, MD5, Announcement post, date of issue

Long Description

 

[NAS]

Great discussion here!  Lots of valid concerns raised, followed by lots of intelligent ideas.  Keep it up!

 

Here are my own suggestions, to help with current concerns about the current wiki Plugin list.  These are just proposals, but I'd like to begin implementing them (or alternatives as suggested by others) as soon as any of them appear to receive general acceptance.  These may all be superseded by the great ideas above, but I'd like to put something in place now, and since there are some of us who already monitor all UnRAID wiki pages, we just need a better structure in place, to significantly improve the current security and integrity of the current plugin acquisition process.  This strictly applies to the listing process, not to plugin or dependency management.

 

1. Require that any modification to the UnRAID Plugins wiki page can only be made by approved plugin guardians (any moderator or plugin author or approved plugin guardian).  I'd like to add a column to the table for individuals who will police a specific plugin, making each plugin self-policing.  Initially it should be the plugin author(s), but it is possible that a plugin dev may not want to be bothered or leave, so if there are a few motivated and trusted individuals that volunteer to monitor all changes, they can be approved by the current plugin guardians/authors as guardians for that plugin.  It would be good to have them listed on the wiki page with the URL to their forum profile page, making it easy for anyone to contact them if something suspicious is spotted.

 

1a. Any page modification will be reverted ruthlessly, if it appears to be unauthorized.  I thought about nicer ways to handle this (a warning or PM to the author), but security requirements (I think) essentially mandate immediate removal of unauthorized changes.  Reversions can be made by any guardian or moderator.  I welcome any page monitors, UnRAID users who will examine any page changes, checking for changes by authorized editors, checking for correct information, especially checking any URL's changed, checking the MD5, checking the associated forum post for its validity, checking subsequent posts for either general acceptance of the new or changed plugin, or warnings about malicious content.  I especially invite UnRAID individuals who may have wanted to contribute to unRAID but don't otherwise feel qualified and may not post very often, to consider monitoring wiki pages such as the Plugins page.  The more individuals we have doing so, means the more eyes around the world that may be awake and watching.  You can actively check the pages by periodically checking RecentChanges or the page history, or passively monitor it by being subscribed and receiving email notifications of all changes to a page.

 

2. Add MD5 near plugin URL.  When plugin changes, MD5 must change also.  I thought about having them stored elsewhere, such as a special page or the announcement forum post but cannot justify it.  With the current wiki page, the best place is with the plugin URL.

 

3. Require a date of issue listed with each plugin.  There will always be a small window of vulnerability on a publicly editable wiki page, between the malicious plugin posting and its correction/reversion.  So whether it is a new plugin or an update to an existing plugin, today's date should be posted with it.  This helps a user who is unfamiliar with a specific plugin know how long it has been out, and whether it has received sufficient review.  Appropriate guidelines should be posted at the top of the wiki page that warn users to check the date, and if they aren't familiar with the current forum discussion, wait at least a few days, hopefully enough time to catch and revert malicious or buggy plugins.  I note that many of the current plugins listed do have the date of issue, but not all, and I believe that all should have it.

 

4. Require an announcement post in the UnRAID forum, and add a link (near the plugin URL) to this post, for any new or updated plugin, so that a guardian or monitor can verify the plugin, from its wiki listing to its forum announcement, and easily check subsequent posts for acceptance or rejection of the wiki listing changes.  I assume that some authors will keep this pointed to the initial announcement which they will keep updated, and other author(s) will post anew and keep the wiki listing updated with the latest announcement post.  The latter is better for plugins with multiple authors.

 

5. Add a possible status warning label, near the Plugin name.  This would normally be blank, but in certain cases could be something like *SUSPICIOUS*, *MALICIOUS! DO NOT INSTALL*, *NEW AND UNVERIFIED*, etc.  These would probably all be temporary, should result in further appropriate actions, such as edit reversion or even listing removal.

 

6. Add guidelines to the wiki page.  At the top should be guidelines to plugin users (check the issue date, current forum postings, MD5, etc).  At the bottom should be guidelines for page monitors (check each edit for its authorized author, current date (not backdated to appear old and trustworthy), correct info, correct URL's, correct MD5, correct forum post, general forum acceptance, etc) and guidelines for plugin authors and guardians (recommended page syntax for plugins data, maintaining guardian list, etc).

 

These are just my ideas, designed to add some peer review and enforcement policies, feel free to object or improve, etc.  One possible problem, we may need Tom's approval to modify the structure of the table!

 

icon    Plugin Name  (optional warning label)

URL's of forum thread, public info (optional), etc                Plugin Type      Author(s)      Guardians      Plugin URL, MD5, Announcement post, date of issue

Long Description

 

For sure we need to abandon all thought of using the wiki in this. There is literally no way of securing a wiki to the level we need. The codebase is too large and given far to much attention by attackers to ever be secure.

 

Lest we forget that up for grabs is root at a huge bunch of huge servers. Thats a target worth some effort.

[WeeboTech]

While I'm all for extending unRAID, I think the complexity of it all has turned me away from it. 

When I see the battery of applications that people start to run on unRAID and the problems it causes, I start to ask myself why.

 

It was pretty easy to set up ESX, Do what I need to do in a traditional Linux environment and use unRAID as a file server.

 

How does XBMC community manage the addons?

What about CPAN?

 

Using the Wiki as a central directory repository has some advantages, but it seems like it could get messy pretty fast.

 

Some suggested author based repositories, and I'm sort of leaning in that direction.

 

I think that, in the first instance, the plugin manager should just be a frontend for the current way of installing plugins. Essentially removing the need to go to a terminal.

 

The user can provide the path to the plugin file, either locally or a remote url, and the plugin manager then handles downloading (if necessary, and running installplg.

 

It would also be good if there was a way to control, in once place, which plugins get installed and in which order they are installed.

 

For now I think that would be all that is needed - it takes what we have now and prettys it up. Any questions on package management or hosting can then be dealt with in the correct manner, and a full blown plugin manager released with 5.X (or 6.X).

 

I'm pretty much feeling this for now. However, don't let that discourage the conversation.

 

I'm still curious how CPAN or XBMC addons or that methodology could come into play.

[nicinabox]

I think that, in the first instance, the plugin manager should just be a frontend for the current way of installing plugins. Essentially removing the need to go to a terminal.

 

The user can provide the path to the plugin file, either locally or a remote url, and the plugin manager then handles downloading (if necessary, and running installplg.

 

It would also be good if there was a way to control, in once place, which plugins get installed and in which order they are installed.

 

For now I think that would be all that is needed - it takes what we have now and prettys it up. Any questions on package management or hosting can then be dealt with in the correct manner, and a full blown plugin manager released with 5.X (or 6.X).

 

Yes! Folks should be able to browse a list through the web app and install plugins as needed. Or use the terminal if they desire. In either case, there are quite a few details and abstractions that need to be carried out before we can just pretty it up and release a full blown package manager.

 

Step 1: Idea

Step 2:

Step 3: Profit!

[drawz]

Given the rate of updates to unRAID and the long periods without communication from Tom, I think any solution that relies on Limetech for approval or any other interaction will not work well.

 

Clearly, there is not a quick and obvious solution. The plugin and package managers should be a part of 5.1+.

[bmfrosty]

One thing that I'd like to see, separate from the plugins, is a bigger set of base packages included.

 

I look at:

 

http://lime-technology.com/wiki/index.php/UnRAID_Plugins

 

and I see a lot of common packages.  If we could get at least the SSL/SSH stuff sorted out for the base install, it would slim this list.

 

Combine that with a limetech hosted repo for PLG files, and we'd be a lot closer to something that we can build a plugin manager on top of.