phpwebsite-developers

[Phpwebsite-developers] New Module (ArticleManager) - Need Feedback

[Eloi G. <el...@re...>]

Hey all!

I have a new 0.90 module that I'm putting the finishing touches on =
before I post it up on SourceForge.  I need you guys to give it a quick =
run through so I can figure out what bugs I've missed. =20

I have it currently set up on www.realvidreams.com/testbed  - there's a =
page on the site that gives an overview of the module's features.

I'm not leaving the site wide open, so you'll only see the functions =
available to:

1) an admin who can add, edit or delete their own articles & =
upload/include images in articles, (username / password: admin / =
tester),  or

2) a registered user who add, edit or delete their own articles but =
requires approval before publication.  No image functionality is =
allowed.  (username / password: tester / tester)

I just updated it to rc3, so there may be site-related snafus that noone =
knows about yet.  In any case, please let me know! =20

Eloi George

[Phpwebsite-developers] Module Substitution

[Matthew M. <ma...@tu...>]

This is not in direct response to Eloi's new module (good job btw) but
just a question that needs consideration for the future.

Suppose someone creates a better content module than one produced
in-house. I know that many of the developers here have several things
going on at one time (I can think of two huge ones off the top of my
head). Perhaps, if an outside developer is willing, we could ask if they
would like their module to become part of our distro.

Here is the rub though.
- We would all need to agree it should be done.
- The in house developer would need to agree
- The outside developer would have to guarantee support.

Again, this may not come up, but I know that there are some modules we are
working on that might have a more dedicated developer outside the
unversity.

Please discuss with pros and cons for both sides.

Matt
-- 
Matthew McNaney
Internet Systems Architect
Electronic Student Services
Appalachian State University
Phone: 828-262-6493
phpwebsite.appstate.edu
ess.appstate.edu

Re: [Phpwebsite-developers] Module Substitution

[Geoff S. <ge...@ho...>]

I disagree with part of your analysis.

For the module to become part of the distro, the in-house developer needs 
take over the module. If the original developer wants to help, that is 
great. But, if the outside developer disappears or gets hit by a truck, the 
maintenance would revert to the in-house developer.

Also, if the module becomes part of the distribution, then the in-house 
developer is de facto responsible for it even if the original developer is 
still involved. The in-house developer takes on responsibility to insure 
that the module:

1. Continues to reflect architecture and coding standards.
2. Maintains consistent user interface.
3. Enhancements meet the approval of the in-house team.

Seems to me there ought to be three levels of module:

1. Those developed in-house or "taken over" as part of the distro.
2. Those that meet  a certification standard and are considered "official" 
modules developed by a third-party.
3. Those that work with phpWebsite but which have not been reviewed and 
approved.

Geoff
www.hostricity.com


At 01:46 PM 12/28/2002 -0500, Matthew McNaney wrote:
>This is not in direct response to Eloi's new module (good job btw) but
>just a question that needs consideration for the future.
>
>Suppose someone creates a better content module than one produced
>in-house. I know that many of the developers here have several things
>going on at one time (I can think of two huge ones off the top of my
>head). Perhaps, if an outside developer is willing, we could ask if they
>would like their module to become part of our distro.
>
>Here is the rub though.
>- We would all need to agree it should be done.
>- The in house developer would need to agree
>- The outside developer would have to guarantee support.
>
>Again, this may not come up, but I know that there are some modules we are
>working on that might have a more dedicated developer outside the
>unversity.
>
>Please discuss with pros and cons for both sides.
>
>Matt
>--
>Matthew McNaney
>Internet Systems Architect
>Electronic Student Services
>Appalachian State University
>Phone: 828-262-6493
>phpwebsite.appstate.edu
>ess.appstate.edu
>
>
>
>
>-------------------------------------------------------
>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

Re: [Phpwebsite-developers] Module Substitution

[<ad...@tu...>]

Doh!  I guess I missed this before I posted my last mail.  I like this
idea, especially the part about "Continues to reflect architecture and
coding standards".  I'm sure the guys hate me sometimes since I'm kind of
the defacto standards and structure dude and I get onto peeps about their
code.
User interface can be flexible as far as how it looks since all modules in
the future should template ALL their output.  This will allow admins, or
Phil :), to setup their user interfaces anyway they wish ().

+1 from me Geoff

Adam

> Also, if the module becomes part of the distribution, then the in-house
> developer is de facto responsible for it even if the original developer
> is  still involved. The in-house developer takes on responsibility to
> insure  that the module:
>
> 1. Continues to reflect architecture and coding standards.
> 2. Maintains consistent user interface.
> 3. Enhancements meet the approval of the in-house team.
>
> Seems to me there ought to be three levels of module:
>
> 1. Those developed in-house or "taken over" as part of the distro. 2.
> Those that meet  a certification standard and are considered "official"
> modules developed by a third-party.
> 3. Those that work with phpWebsite but which have not been reviewed and
> approved.
>
> Geoff
> www.hostricity.com
>
>
> At 01:46 PM 12/28/2002 -0500, Matthew McNaney wrote:
>>This is not in direct response to Eloi's new module (good job btw) but
>> just a question that needs consideration for the future.
>>
>>Suppose someone creates a better content module than one produced
>> in-house. I know that many of the developers here have several things
>> going on at one time (I can think of two huge ones off the top of my
>> head). Perhaps, if an outside developer is willing, we could ask if
>> they would like their module to become part of our distro.
>>
>>Here is the rub though.
>>- We would all need to agree it should be done.
>>- The in house developer would need to agree
>>- The outside developer would have to guarantee support.
>>
>>Again, this may not come up, but I know that there are some modules we
>> are working on that might have a more dedicated developer outside the
>> unversity.
>>
>>Please discuss with pros and cons for both sides.
>>
>>Matt
>>--
>>Matthew McNaney
>>Internet Systems Architect
>>Electronic Student Services
>>Appalachian State University
>>Phone: 828-262-6493
>>phpwebsite.appstate.edu
>>ess.appstate.edu
>>
>>
>>
>>
>>-------------------------------------------------------
>>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
>
>
>
>
> -------------------------------------------------------
> 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


---------------------------------------------------------------------
Adam Morton
Developer - Electronic Student Services
http://phpwebsite.appstate.edu
Founder - Appalachian Linux Users Group
http://alug.appstate.edu

Re: [Phpwebsite-developers] Module Substitution

[Geoff S. <ge...@ge...>]

Adam:

As someone who has programmed in God-only-knows how many languages over the 
last 30 years, I can tell you that phpWebSite will die a slow and agonizing 
death unless you maintain architectural and programming standards. Here's why:

As a system ages, bugs are fixed, features are added, and things are 
changed for dozens of reasons. If the work is simply done to meet a 
deadline without any real thought to architecture and standards, eventually 
(and I guarantee this will happen) the code becomes so patched and so 
unwieldy and so tied-in-together weird ways that no one actually knows how 
the code really works and changing one thing will break another seemingly 
unrelated thing. Programmers make it even worse by changing code that looks 
like it should have something to with what they are working on for extra 
insurance. At this point, you can only program the system by folklore and 
eventually you have to do a complete re-write of the system because it is 
so cumbersome, nothing can be done.

So, when folks complain about you pushing them on standards and 
architecture, tell them to shut their traps and get back to work!

By the way, this usually works: "OK, you can code this any way you want as 
long as you agree to be available 24 hours a day 7 days a week for as long 
as your code is part of this system." (That's not really a good bargain for 
you because the code usually affect other areas of the system as well.)

Geoff

At 08:25 PM 12/31/2002 -0500, ad...@tu... wrote:
>Doh!  I guess I missed this before I posted my last mail.  I like this
>idea, especially the part about "Continues to reflect architecture and
>coding standards".  I'm sure the guys hate me sometimes since I'm kind of
>the defacto standards and structure dude and I get onto peeps about their
>code.
>User interface can be flexible as far as how it looks since all modules in
>the future should template ALL their output.  This will allow admins, or
>Phil :), to setup their user interfaces anyway they wish ().
>
>+1 from me Geoff
>
>Adam
>
> > Also, if the module becomes part of the distribution, then the in-house
> > developer is de facto responsible for it even if the original developer
> > is  still involved. The in-house developer takes on responsibility to
> > insure  that the module:
> >
> > 1. Continues to reflect architecture and coding standards.
> > 2. Maintains consistent user interface.
> > 3. Enhancements meet the approval of the in-house team.
> >
> > Seems to me there ought to be three levels of module:
> >
> > 1. Those developed in-house or "taken over" as part of the distro. 2.
> > Those that meet  a certification standard and are considered "official"
> > modules developed by a third-party.
> > 3. Those that work with phpWebsite but which have not been reviewed and
> > approved.
> >
> > Geoff
> > www.hostricity.com
> >
> >
> > At 01:46 PM 12/28/2002 -0500, Matthew McNaney wrote:
> >>This is not in direct response to Eloi's new module (good job btw) but
> >> just a question that needs consideration for the future.
> >>
> >>Suppose someone creates a better content module than one produced
> >> in-house. I know that many of the developers here have several things
> >> going on at one time (I can think of two huge ones off the top of my
> >> head). Perhaps, if an outside developer is willing, we could ask if
> >> they would like their module to become part of our distro.
> >>
> >>Here is the rub though.
> >>- We would all need to agree it should be done.
> >>- The in house developer would need to agree
> >>- The outside developer would have to guarantee support.
> >>
> >>Again, this may not come up, but I know that there are some modules we
> >> are working on that might have a more dedicated developer outside the
> >> unversity.
> >>
> >>Please discuss with pros and cons for both sides.
> >>
> >>Matt
> >>--
> >>Matthew McNaney
> >>Internet Systems Architect
> >>Electronic Student Services
> >>Appalachian State University
> >>Phone: 828-262-6493
> >>phpwebsite.appstate.edu
> >>ess.appstate.edu
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>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
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
>
>
>---------------------------------------------------------------------
>Adam Morton
>Developer - Electronic Student Services
>http://phpwebsite.appstate.edu
>Founder - Appalachian Linux Users Group
>http://alug.appstate.edu
>
>
>
>
>-------------------------------------------------------
>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

Re: [Phpwebsite-developers] Module Substitution

[Eloi G. <el...@re...>]

+1 for Geoff's 3-tier structure.

Since I can really only explain from the viewpoint of my module, let me give
some background.  The idea for Article Manager was born from a feature
request that I posted on SF. After some thought, I realized that bugging
Matt & Adam for features that probably only I needed would take their time
away from the vastly more important and difficult task of creating what I
think is the greatest CMS ever.  So I learned PHP & started writing.

I later sent Adam a msg saying that I'd like to send my code up for possible
development as the new PageMaster, but then I ran across a few messages on
'Nuke boards from people saying that phpWS looks promising, but there're
only a few third-party modules available.  This struck me because it was the
same concern I had when I first discovered phpWS.

Announcements & PageMaster are wonderful modules.  They're easy to install
and the average admin can get started without clicking on the help buttons
to find out what a "publication date" is used for.  Article Manager is
geared more for "enterprise" sites, like schools, online 'zines, and
information repositories.  Still easy to use, but overkill for a web newbie
wanting to put up a blog.  This week I'll finish the Import/Export functions
so that you're never locked into any particular module.

I'd be estatic if Article Manager became a part of the distro, but and the
end of it all I'd be happier if instead of people saying "phpWS is great,
but there's no 3rd-party modules for it",  they start saying "phpWS offers
excellent ease & functionality out of the box, and once you start plugging
in those 3rd-pary modules -- Wow!"

I also agree with Geoff's assertion.  I am committed to supporting my
modules and the source code is heavily commented so anyone else can get up
to speed pretty quickly, but heaven forbid a shark gets me (more likely
'cause I live on a tropical island) development of the core phpWS shouldn't
get set back.

-Eloi George-

Re: [Phpwebsite-developers] Module Substitution

[Don S. <do...@se...>]

So would you guys like us to discuss modules we want to develop first?  I 
guess I missed the beginning of this thread.

I do think it's a good idea, to avoid overlap and then to combine 
resources.

I personally have 3 modules on my plate.  First one I can't really discuss 
yet.  Second one is a full-fledged contact database that will take 
sub-modules to turn it into things like an alumni database to rival 
pay-for-play services like classmates.com and alumni.net.  Third is the 
big papa.  A fantasy-sports module that will allow a single host to run 
(in theory) infinite leagues of varing sports.

The contact project is on sourceforge as aevum.  The fantasy project is on 
sourceforge as ffl.  If anyone wants to help or even offer suggestions or 
testing (although all projects are in alpha planning at the moment), my 
co-developers and I would welcome you.

Thanks,
Don.

On Mon, 30 Dec 2002, Eloi George wrote:

> +1 for Geoff's 3-tier structure.
> 
> Since I can really only explain from the viewpoint of my module, let me give
> some background.  The idea for Article Manager was born from a feature
> request that I posted on SF. After some thought, I realized that bugging
> Matt & Adam for features that probably only I needed would take their time
> away from the vastly more important and difficult task of creating what I
> think is the greatest CMS ever.  So I learned PHP & started writing.
> 
> I later sent Adam a msg saying that I'd like to send my code up for possible
> development as the new PageMaster, but then I ran across a few messages on
> 'Nuke boards from people saying that phpWS looks promising, but there're
> only a few third-party modules available.  This struck me because it was the
> same concern I had when I first discovered phpWS.
> 
> Announcements & PageMaster are wonderful modules.  They're easy to install
> and the average admin can get started without clicking on the help buttons
> to find out what a "publication date" is used for.  Article Manager is
> geared more for "enterprise" sites, like schools, online 'zines, and
> information repositories.  Still easy to use, but overkill for a web newbie
> wanting to put up a blog.  This week I'll finish the Import/Export functions
> so that you're never locked into any particular module.
> 
> I'd be estatic if Article Manager became a part of the distro, but and the
> end of it all I'd be happier if instead of people saying "phpWS is great,
> but there's no 3rd-party modules for it",  they start saying "phpWS offers
> excellent ease & functionality out of the box, and once you start plugging
> in those 3rd-pary modules -- Wow!"
> 
> I also agree with Geoff's assertion.  I am committed to supporting my
> modules and the source code is heavily commented so anyone else can get up
> to speed pretty quickly, but heaven forbid a shark gets me (more likely
> 'cause I live on a tropical island) development of the core phpWS shouldn't
> get set back.
> 
> -Eloi George-
> 
> 
> 
> 
> -------------------------------------------------------
> 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
> 
> 
> 

[Phpwebsite-developers] Security Alerts

[Geoff S. <ge...@ho...>]

Here's another one to be batted around.

I'd like to see a registry of all sites using phpWebsite. The registry 
would include contact information for the proprietor and whether the site 
should be listed in a public directory of phpWebsites or not.

One purpose of the registry would be so that when security issues are 
discovered, an alert can be sent to registered sites a day or two before 
the security issue is published publicly on phpwebsite.appstate.edu.

If this is done by a module in phpWebsite that receives the information and 
then emails it to the proprietor, only active websites would receive the 
alert. This would prevent anyone from registering just to get the security 
updates. (They'd at least have to have a running phpWebSite).

Theoretically, this gives phpWebSite proprietors an opportunity to fix 
their sites BEFORE the security breach is made public. I'm pretty sure that 
two of my sites were defaced because the person who did the dirty deed 
found out about the breach by reading about it on phpwebsite.appstate.edu 
before I did.

I realize that there are hacker sites, etc. that publish this stuff and 
which we have no control. However, just making sure that all registered 
sites are alerted as quickly as possible would be a big help.

I discussed this with Brian Brown months ago and his take was "something 
like that would be great but, I'm not sure that it is workable."

By the way, a counter could be incorporated so that we could say 
"phpWebSite now has 876,477 active sites."

So, having worked through this, here's my suggestion for a registration module:

Registration module would:

Allow admin to register site with the phpWebSite registry.

Specify whether or not site will be listed in the public directory at 
phpwebsite.appstate.edu.

Allow admin to receive notification of updates to phpWebSite and to modules.

Allow admin to receive communications from phpwebsite.appstate.edu such as 
security alerts (admin specifies an email address. The website receives the 
communication and forwards it to the email address. That way, if the site 
is no longer running, or, no longer using phpwebsite, the message doesn't 
go to that person.)

Maintain a count of all phpWebsites.

Maintain a public directory of all phpWebSites that want to be listed.

Geoff

Re: [Phpwebsite-developers] Security Alerts

[Eloi G. <el...@re...>]

+1

Sounds cool.  Sounds like a modified links module.

Re: [Phpwebsite-developers] Security Alerts

[Don S. <do...@se...>]

+ infinity + 1

Don.

On Mon, 30 Dec 2002, Geoff Staples wrote:

> Here's another one to be batted around.
> 
> I'd like to see a registry of all sites using phpWebsite. The registry 
> would include contact information for the proprietor and whether the site 
> should be listed in a public directory of phpWebsites or not.
> 
> One purpose of the registry would be so that when security issues are 
> discovered, an alert can be sent to registered sites a day or two before 
> the security issue is published publicly on phpwebsite.appstate.edu.
> 
> If this is done by a module in phpWebsite that receives the information and 
> then emails it to the proprietor, only active websites would receive the 
> alert. This would prevent anyone from registering just to get the security 
> updates. (They'd at least have to have a running phpWebSite).
> 
> Theoretically, this gives phpWebSite proprietors an opportunity to fix 
> their sites BEFORE the security breach is made public. I'm pretty sure that 
> two of my sites were defaced because the person who did the dirty deed 
> found out about the breach by reading about it on phpwebsite.appstate.edu 
> before I did.
> 
> I realize that there are hacker sites, etc. that publish this stuff and 
> which we have no control. However, just making sure that all registered 
> sites are alerted as quickly as possible would be a big help.
> 
> I discussed this with Brian Brown months ago and his take was "something 
> like that would be great but, I'm not sure that it is workable."
> 
> By the way, a counter could be incorporated so that we could say 
> "phpWebSite now has 876,477 active sites."
> 
> So, having worked through this, here's my suggestion for a registration module:
> 
> Registration module would:
> 
> Allow admin to register site with the phpWebSite registry.
> 
> Specify whether or not site will be listed in the public directory at 
> phpwebsite.appstate.edu.
> 
> Allow admin to receive notification of updates to phpWebSite and to modules.
> 
> Allow admin to receive communications from phpwebsite.appstate.edu such as 
> security alerts (admin specifies an email address. The website receives the 
> communication and forwards it to the email address. That way, if the site 
> is no longer running, or, no longer using phpwebsite, the message doesn't 
> go to that person.)
> 
> Maintain a count of all phpWebsites.
> 
> Maintain a public directory of all phpWebSites that want to be listed.
> 
> Geoff
> 
> 
> 
> -------------------------------------------------------
> 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
> 
> 
> 

Re: [Phpwebsite-developers] Security Alerts

[Matthew M. <ma...@tu...>]

I agree. Originally it was going to be built into the install. I'll see if
this is something that can be built in before final release.

Matt

-- 
Matthew McNaney
Internet Systems Architect
Electronic Student Services
Appalachian State University
Phone: 828-262-6493
phpwebsite.appstate.edu
ess.appstate.edu

Re: [Phpwebsite-developers] Security Alerts

[Philip M. <lis...@li...>]

+1 from me, would love to get security updates.

-- 
Philip McAllister < uk . co . liquidsand @ phil >
  "All I ask is the chance to prove that money can't make me happy"
  - Spike Milligan

[Phpwebsite-developers] Security Alerts/Update Notification

[Jeremy A. <ja...@tu...>]

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/runnin=
g
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=92s.  If someone does not want to li=
st
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 t=
o
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=92s.  Any developers wou=
ld
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=92s.  Boost would also work with th=
e
backend of this to allow users on the admin side of there site the same
flexibility.

I=92m going to play devils advocate on the privileged user list for secur=
ity
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.=20
Not telling every one at once will always have this problem.  I do howeve=
r
thank you are right about users having time to get their sites updated an=
d
secure and not getting blindsided be a cracker.  I would propose this.  W=
e
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=92s would follow on t=
he
release of the patch/upgrade.

Now on to distributing phpWebSite updates and advisory=92s. I propose tha=
t
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.=
=20
These lists will not be available to receive any email from others.=20
Second it will give users a more flexible way of receiving info.  They ca=
n
get digest, each email, ...  There would be two lists the updates list an=
d
the security list.

Last but not least boost.  Boost will always be a more active client.=20
Matt can talk more on this subject but boost will have the ability to be =
a
true =93update=94 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!

--=20
Jeremy Agee
phpWebSite Development Team (http://phpwebsite.appstate.edu)
Appalachian State University
SF.net id: jagee or 94756

Re: [Phpwebsite-developers] Security Alerts/Update Notification

[Geoff S. <ge...@ho...>]

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

Re: [Phpwebsite-developers] Security Alerts/Update Notification

[Jeremy A. <ja...@tu...>]

Geoff I'm not tying to shoot your idea down but i am going to continue to
play the devils advocate.  Thank for the input!

> 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

This would mean our server would have to open an individual http process
to talk to all the site on the list.  What if it would not get there?  It
would also have to keep retrying on fail.  Also this is a lot of server
load.

>  and the phpWS forwards it to an email address specified by the admin on

You now have a client on all installed just sitting there listing.  You
will need to do lots of checks.  You could for example have something say
send the admin a message 1000000 times.  Or some other DOS attack to max
the server cpu.

> 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 can be faked!  Yes it would probable eliminate a few script kiddy's
but this is not who we are really worried about.  It is even easer
considering they can see your code.

>
> 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

-- 
Jeremy Agee
phpWebSite Development Team (http://phpwebsite.appstate.edu)
Appalachian State University
SF.net id: jagee or 94756