[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: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20090401/236efe0c/attachment.html>