From: Geoff S. <ge...@ho...> - 2003-01-02 00:05:39
|
Jeremy: I want to re-iterate the security breech comment I made previously. I'm suggesting a module that is part of the phpWS core for the purpose of registering a phpWebsite and for receiving security updates. If the security notices are sent to the phpWS module of registered sites and the phpWS forwards it to an email address specified by the admin on his own site, this guarantees that you don't get the security alerts unless you are actually running phpwebsite and you have registered your site. This at least guarantees that anyone wanting to receive security information for nefarious purposes is running a registered phpWS. This won't stop the problem, but, it does put a significant obstacle in the way. I suspect that many pranksters would simply go somewhere else with their pranks because they didn't want to bother with setting up and hosting a phpWS instance to be ready for any security breaches that occur. I figured that the registration / security module would provide a public directory of phpWebsites and that each site admin could choose whether or not they wanted their site listed in the public directory. It seems to me that from a functionality standpoint the registration, security updates, and public directory are closely enough related that a single module would be best because it puts all of these functions in a single place for the site admins. I like your idea of alerting to a security breach immediately before a fix is available so that admins will know to be on the look out for the fix, to back up their site if needed as protection, and to plan the time to implement the fix when available. Geoff At 06:36 PM 1/1/2003 -0500, Jeremy Agee wrote: >Ok none of his is set in stone but lots of things talked about here have >been on the drawing board for a while. I have posted before on some of >theses subjects so see old email for back info (module master list/running >phpws master list). > >First I would not like to see a user forced to list his site on the list >just to get security/update advisory's. If someone does not want to list >there site they should have the right too. Basically the who is running >phpWebSite list should remain separate. > >Now to the user part of update/security. We have had plains to build a >master list for both users and developers. This list will allow anyone to >both see/browse modules and to get usefully info (latest version/home >page/mod developer contact, etc). This would also be the place where >developers would make releases/security advisory's. Any developers would >have there module/themes/other associated with there account on phpws and >could be able to update there info on the fly. The module would then do >the work to send out updates/advisory's. Boost would also work with the >backend of this to allow users on the admin side of there site the same >flexibility. > >I'm going to play devils advocate on the privileged user list for security >advisories. There is no way we can control who sees this. Some one bad >could just as easily get this information and use it agents every one. >Not telling every one at once will always have this problem. I do however >thank you are right about users having time to get their sites updated and >secure and not getting blindsided be a cracker. I would propose this. We >have an advisory go out lets say 24 hours ahead of time to simply >announcing there will be a security update that should be applied. It >will not contain any useful info but will be a reminder to people that >they need to do an update in a day. A full advisory's would follow on the >release of the patch/upgrade. > >Now on to distributing phpWebSite updates and advisory's. I propose that >we use mailman (mailing lists) for this part. It means we do not have to >worry about bounce stuff or any other part of email. Mailman will do our >work but will receive its info from the module on the master list system. >These lists will not be available to receive any email from others. >Second it will give users a more flexible way of receiving info. They can >get digest, each email, ... There would be two lists the updates list and >the security list. > >Last but not least boost. Boost will always be a more active client. >Matt can talk more on this subject but boost will have the ability to be a >true "update" client. > >I would like to add a small side note on licensing of this module. This >is not very important now but may need to be discussed. If this is >licensed under the GPL commercial/non GPL module will not be able to take >advantage of this system. If it is LGPL they will be able to user it. >This only means more use if it is LGPL so no one will really notice. It >would also insure phpWebSite user that are using commercial software will >stay secure/up2date too. Remember security is only as good as your >weakest link! > >-- >Jeremy Agee >phpWebSite Development Team (http://phpwebsite.appstate.edu) >Appalachian State University >SF.net id: jagee or 94756 > > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Phpwebsite-developers mailing list >Php...@li... >https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |