[geeklog-devel] GSOC 2009

[Matt West]

> My name is Tim Patrick, I am a first year student at Conestoga  
> College in Kitchener Canada, studying software engineering.

Hi Tim, thanks for sending us a draft of your proposal. My name is  
Matt West, I'm the mentor for this project.


> This project is appealing because I would like to see this become  
> much like mozillas add-on website, where users can have the add-ons  
> installed automatically with no downloading, unzipping, and placing  
> in folders. A one click process.

We would like the plugin installation and update process to be as  
seamless as possible for the user. The Mozilla/Firefox Addons site is  
a good example of how to do this and would be a good model to follow.


> Some type of verification (digitally signed) for each plugin on the  
> main repository would be an idea as well. This would ensure that the  
> plugin being installed is verified by Geeklog to be OK and free from  
> any malicious code.

Some form of signing or checksumming is a good idea. It wouldn't  
prevent the installation of a malicious plugin but it would assure the  
user of the plugin's authenticity and if they can trust the origin  
they can trust the plugin. The same idea is applied with signed SSL  
certificates. If I visit a website that has a certificate signed by  
Verisign, then I am extending my trust in Verisign to that website.


> As well, users will be able to download plugins from anywhere,  
> however if the root domain is not a geeklog trusted site, a warning  
> will be displayed telling the user malicious plugins may be  
> installed, and to make sure you trust the developer, or download  
> from the trusted geeklog site. This would prevent users from  
> unwittingly downloading malicious code.  The user will have to  
> concientiously click a check box and then continue to install the  
> non-trusted plugin.

Good. There was some discussion yesterday about using a blacklist to  
maintain a list of malicious repositories. Any thoughts on whether  
this is a good or bad idea?


> For updating, my idea is that the users site will automatically  
> check the plugin repository for an update on the update list that it  
> will publish every x day(s) (or every login) and if an update  
> matches one of the installed plugins, download the necessary update,  
> and update the plugin. This list would be in a simple XML structure  
> for easy and quick parsing, and be very small in size to prevent  
> network holdups. This will be modeled off the GNOME (Linux GUI)  
> update software, where it will check every login for updates by  
> downloading the small xml file, parsing, and if an update, informing  
> the user of the update, and then having them click one button  
> (Update) to allow them to have all the updates installed.
> As well, for each update, it would be an idea to have a flag  
> associated with the update, that indicates if the user can ignore  
> the update, can delay the update, or whether it is a mandatory  
> update (A security patch for example).
> A priority would also be a required field for each update.

As Dirk mentioned, it would be best if the plugin didn't automatically  
phone home. The idea we have is that the admin panel will subscribe to  
an "available updates feed." The problem I'm seeing with this idea,  
however, is that as the repository grows this feed will become huge.  
We could limit the size of the feed but then if the site administrator  
doesn't check for updates regularly he might miss an update. This  
could be resolved with a "Check for updates" button that sends a list  
of the plugins that the site is using and receives the list of  
available updates. This would scale much better as the repository  
grows but isn't very elegant. Any thoughts on this?


> For new updates, we can have a manager plugin that allows a  
> administrator to view all new plugins that are avaiable from his  
> subscribed plugin repositories. This means that the administrator  
> can add repositories, delete repositories, and search through all  
> plugins. Much like a package manager (Synaptic) for Linux.
> A simple call to an update button in the manager plugin will load  
> all the plugins from the repositories, and then allow the  
> administrator to scroll through them, or search for one  
> individually. As well, the user will be given the option to download  
> many at a time. Maybe as well, we can allow users to remove them  
> from this manager plugin as well?


Do you mean "For new plugins"? Assuming so, yes, the manager should be  
able to totally remove the plugin. This process should perform all the  
typical user warnings before uninstalling. When I think of a plugin  
manager I envision Synaptic, so that would be a good model.


> The repositories are of two types - open and closed. Open can have  
> any user submit a plugin, where it is then verified by a moderator  
> before being placed for public download. In the case of geek log,  
> this would also allow the moderator to digitally sign the plugin.
> For the closed repository, only members would be able to upload  
> plugins, where they would be optionally approved by a manager. This  
> would be able to be configured in a configuration file.

In Geeklog 1.5 we moved the majority of site configurations from the  
old config.php file to the database. Try to keep any configuration  
information in the conf_values table.


> A bug I fixed was the one located at : http://project.geeklog.net/tracking/view.php?id=824
> This was a very simple bug, that just required adding rawurlencode  
> function the username when the user's file was being named. This  
> allowed user names with reserved browser characters (eg. ? and &) to  
> not break the functionality, as they are converted to the %## code.  
> (Where ## is a hex number). Since all non alpha numeric numbers are  
> encoded, (except _ and -) there is no posibility of duplicate file  
> names unless there are duplicate user names.
> rawurlencode was used insteda of urlencode as urlencode encodes  
> spaces (ascii 32) as a + which will cause an invalid file character  
> in windows.


Thanks for the bug fix :)


Your proposal is good draft and shows a good understanding of the  
project. Besides my comments, we would also like to see a rough  
project timeline. I think that you should also proofread your proposal  
once more, as it contains a few errors.

Take some time to think about my comments and submit a revision. I  
look forward to hearing more on your ideas. If you have any questions  
feel free to chat with me on IRC or email me on the list or directly.

Matt West
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20090329/4e7a3a86/attachment.html>