cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Enhancing Cocoon Visibility
Date Wed, 16 Jan 2002 10:11:55 GMT
Michael Hartle wrote:
> 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.

You are suggesting 'security thru obscurity' then?

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

what are you talking about? 

Apache has such version information since day one but nothing prevented
people to be happy and host securely with it.

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

yeah, just like all the millions of apache sites do outthere, right?

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

How do you know this isn't going on?

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

To unsubscribe, e-mail:
For additional commands, email:

View raw message