cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <acoli...@nc.rr.com>
Subject Re: [RT] Enhancing Cocoon Visibility
Date Wed, 16 Jan 2002 02:20:06 GMT
On Tue, 2002-01-15 at 20:25, Andrew C. Oliver wrote:
> Just to sound off on the security concerns about the header string.  No
> offense to the speaker, but I don't believe that covering up solves
> anything.  Scanners usually aren't that smart (as to check first).  As
> an example.  Ask me how many gazillion hits I get a month looking for a
> windows based exploit on my linux server!  Does it check?  No.  If the
> string is there and the scanner checks for it before sending a hundred
> thousand exploits, if you ask me thats a good thing.  The lazy guy who
> didn't upgrade gets hit instead of EVERYONE.  
> 
> The cover it up method of dealing with security is no longer workable
> now that the Internet is here and high speed semi-anonymous connections
> are widely available.
> 
> -Andy
> 

Sorry for the confusion...that was meant as a reply to this email not
the one it was sent on (I missed and clicked):

The first impression of mine is that approaching a viable interest like
this scares the shit out of me, pardon my language please.

Yes, I mostly agree on your assessment, both Cocoon and its users
benefit from the visibility, but enforcing visibility by either
polluting their URI space (1) or "extending" someone elses web
application semantics (2) is something I would consider as an offence to
the current user base and incompatible to the concept of free
participation. I would consider (3) to be the least intrusive one, but
preventing people to disable this either due to their personal taste or
for a real need of theirs is dangerous:

* Being able to question version information to automatically exploit
defects or security holes is something that I started hating when I had
my first bigger source-level look into a project, which was the de-facto
standard DNS server BIND; a certain, specific DNS query (class=chaos,
type=txt) makes bind respond with more than sufficient versioning
information, a perfect basis for automation. I *do* believe in
publically declaring defects and security holes, but I am against making
it *that* easy for script kiddies.

* Not being able to turn of versioning information opens up a
possibility for articifical incompatibilities or product capabilities; I
do not yet expect this to happen, but I'd hate it to see some commercial
tool of mine either refuse to work with a cocoon-based web system or
request an upgrade to a pro version I directly could buy online.


I understand the hunger for visibility for this project, but enforcing
this is the wrong way; my guess is that this would only spark an
open-source project for filtering this out, and any measures taken to
protect that versioning information from being stomped out of the
original source code would only make it worse. Instead, let's turn to
make people think about freely supporting Cocoon instead; do we have a
"this site is powered by cocoon" button readily / widely available ? We
might put that directly into each and every release for a start,
encouraging people to use it whereever possible.

Concerning visibility, what about writing a book about Cocoon as a
community project, publishing it and using any what-so-ever-income to
help fund Apache ? What about writing articles for computer magazines
such as c't or iX in Germany ?

Best regards,

Michael Hartle


> 
> On Tue, 2002-01-15 at 19:27, Robert Koberg wrote:
> > I agree with Michael that doing this will make users think twice (perhaps
> > even make them leave without further investigation), but I would still do
> > it. Branding is extremely important. I don't know how you guys do this work
> > for no pay.  If cocoon was put on the VC table (even now) you guys would
> > walk away set for life - then you can do whatever you want (and piss-off
> > whover you want :)
> > 
> > I have an (old) idea that might work in this situation.
> > 
> > (note: I used to work for MACR)
> > 
> > At Macromedia we sold authoring software that allowed author-users to create
> > CDROM (~web~) pieces/movies.  They could freely distribute the
> > pieces/movies. If they did not want to pay any licensing fees for
> > distribution they had to show the MACR logo (perhaps C2's version is the
> > header??) at the end of the movie (that is, 'Made With Macromedia' as a
> > vector graphic).
> > 
> > What if apache projects adopted the same type of thing?  'Use it for free
> > and advertise the project, else if you do not want to help promote the
> > project pay us a licensing fee that will go to fund further apache
> > projects'. Of course, if you do that you are going to have to have
> > finance.apache.org and accounting.apache.org  to handle everything :)
> > 
> > You can say the licensing fee goes to buying the best hardware & track user
> > bases (that are not detectable) so projects can be given appropriate weight
> > on the apache servers.
> > 
> > best,
> > -Rob
> > 
> > 
> > 
> > 
> > 
> > From: "Michael Hartle" <mhartle@hartle-klug.com>
> > 
> > 
> > > Stefano Mazzocchi wrote:
> > >
> > > >what to do?
> > > >
> > > >I see a number of solutions (you have more, make yourself heard):
> > > >
> > > > 1) adding an implicit 'cocoon-status' resource (for example
> > > >/about-cocoon)
> > > >
> > > > 2) adding a implicit 'about' resource view (for example
> > > >?cocoon-view='about')
> > > >
> > > > 3) adding cocoon-specific HTTP header to the response (for example
> > > >x-cocoon: 2.0.12)
> > > >
> > > >Of course, we must prevent people from having the chance to disable this
> > > >so we must make sure things have a very low impact on resource.
> > > >
> > > The first impression of mine is that approaching a viable interest like
> > > this scares the shit out of me, pardon my language please.
> > >
> > > Yes, I mostly agree on your assessment, both Cocoon and its users
> > > benefit from the visibility, but enforcing visibility by either
> > > polluting their URI space (1) or "extending" someone elses web
> > > application semantics (2) is something I would consider as an offence to
> > > the current user base and incompatible to the concept of free
> > > participation. I would consider (3) to be the least intrusive one, but
> > > preventing people to disable this either due to their personal taste or
> > > for a real need of theirs is dangerous:
> > >
> > > * Being able to question version information to automatically exploit
> > > defects or security holes is something that I started hating when I had
> > > my first bigger source-level look into a project, which was the de-facto
> > > standard DNS server BIND; a certain, specific DNS query (class=chaos,
> > > type=txt) makes bind respond with more than sufficient versioning
> > > information, a perfect basis for automation. I *do* believe in
> > > publically declaring defects and security holes, but I am against making
> > > it *that* easy for script kiddies.
> > >
> > > * Not being able to turn of versioning information opens up a
> > > possibility for articifical incompatibilities or product capabilities; I
> > > do not yet expect this to happen, but I'd hate it to see some commercial
> > > tool of mine either refuse to work with a cocoon-based web system or
> > > request an upgrade to a pro version I directly could buy online.
> > >
> > >
> > > I understand the hunger for visibility for this project, but enforcing
> > > this is the wrong way; my guess is that this would only spark an
> > > open-source project for filtering this out, and any measures taken to
> > > protect that versioning information from being stomped out of the
> > > original source code would only make it worse. Instead, let's turn to
> > > make people think about freely supporting Cocoon instead; do we have a
> > > "this site is powered by cocoon" button readily / widely available ? We
> > > might put that directly into each and every release for a start,
> > > encouraging people to use it whereever possible.
> > >
> > > Concerning visibility, what about writing a book about Cocoon as a
> > > community project, publishing it and using any what-so-ever-income to
> > > help fund Apache ? What about writing articles for computer magazines
> > > such as c't or iX in Germany ?
> > >
> > > Best regards,
> > >
> > > Michael Hartle
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> > 
> -- 
> www.superlinksoftware.com
> www.sourceforge.net/projects/poi - port of Excel format to java
> http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
> 			- fix java generics!
> 
> 
> The avalanche has already started. It is too late for the pebbles to
> vote.
> -Ambassador Kosh
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
-- 
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
			- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message