[geeklog-devel] geeklog-devel Digest, Vol 26, Issue 30

[Matt West]

> Hey Matt and all,

>

> Here is my revised proposal.. Tell me what you think!

>

> http://docs.google.com/Doc?id=dgfc479g_0cwc6w2hk

>

> Tim


Tim,

Your proposal is very good, well written, and well organized. You have  
covered the project in good detail and I can visualize how it will  
operate once completed. I saw you've already submitted it to Melange  
per our and Google's requests (thanks!).

A few quick comments:


> Private repositories, on the other hand, only allow specific users  

> to upload plugins to the repository.

> [...] As well, private repositories can also limit who is able to  

> connect to and download from their repository. This would be  

> accomplished by a unique key hash that would be downloaded to an  

> approved site, that would log the site in and verify it. These key  

> hashes would be stored in the repository database. As mentioned in  

> the mailing list, there was some question as to why an administrator  

> would require this functionality. In my opinion it is always better  

> to allow for new functionality, instead of limiting the potential.  

> An administrator may want this functionality because they only want  

> to develop a plugin for a friend or for a group of people. However  

> this does go against the concept of open source, so it may be better  

> not to implement it at all.



I can see the usefulness of a closed repository though I'm not sure it  
would be utilized. Dirk, et al, have we received any requests for this  
option? I do like the idea of developing with growth in mind, as you  
mentioned, so I would recommend developing the repository with this in  
mind but leaving the implementation for the "if I have time" part.


> Blacklisting:

> Repositories that contain malicious plugins can be black listed by  

> the main Geeklog site. This would work much like Google's  

> blacklisting for malicious sites. Users would be able to alert  

> Geeklog of malicious repositories, and if Geeklog verified these as  

> malicious, would be added to the Blacklist. This list would be  

> downloaded every time the plugin manager is started, and if a user  

> attempts to install from one of these malicious repositories, they  

> would be alerted of the danger, and the reason the site was black  

> listed. However they would not be prevented from installing a plugin  

> from that repository if they wanted to.

> As well, if they had a blacklisted repository in their repository  

> list, a warning would be displayed every time the user started the  

> plugin manager, with a request to delete the offending repository  

> from the list.


I think that instead of downloading a list every time the plugin  
manager is accessed that the blacklist check should occur when a user  
is adding a new repository. When they click "add" a request could be  
sent to wherever the blacklist is hosted (probably geeklog.net) with  
the address of the repository.


> Project Timeline


Double check Google's timeline, I think the SoC is 11-12 weeks. You  
may want to add a little more detail here.

So think about my comments and I think your proposal is ready to go  
unless any of the other GL devs/mentors have any comments or  
suggestions.

As an aside, we've asked students to consider writing a second  
proposal for another Geeklog project to help distribute the  
application load and increase the student's chance of being accepted.  
We have had *no* applications for our Webservices or Cross Site  
Publication API projects, are either of those something you might be  
interested in working on?

Matt 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://eight.pairlist.net/pipermail/geeklog-devel/attachments/20090401/236efe0c/attachment.htm>