date:20240607


On 06/06/2024 16:30, Christopher Schultz wrote:

All,

Resurrecting this thread from 2019.

I'd like to remove the SSI configuration from conf/web.xml and put it 
into webapps/docs/ssi-howto.html.


Are there any objections?


None here.

Do we want to go further and consider removing it entirely for Tomcat 12 
onwards. Maybe a question for the users list?


Mark



Thanks,
-chris

On 10/29/19 05:05, Konstantin Kolinko wrote:
пн, 28 окт. 2019 г. в 16:34, Christopher Schultz 
:


[...]

The stock conf/web.xml contains a sample configuration for the SSI
servlet. We will have to decide what to do with that. I can think of
at least two options:

   a. Remove it from the stock conf/web.xml entirely
   b. Add comments to conf/web.xml indicating that the SSI component is
a separate download

I think I like #2 better.


The correct way to enable this feature is to copy those fragments into
one's own WEB-INF/web.xml.  Uncommenting them in the default web.xml
file will have [un]expected consequences.

Thus I am in favor of moving those configuration fragments to 
documentation.


Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove CGI Servlet


On 06/06/2024 16:39, Christopher Schultz wrote:

All,

Resurrecting this thread from 2019.

I will be proceeding with this 4.5-year-old plan to extract the CGI 
servlet to a separate JAR file to make it easy to "remove" from Tomcat 
if operators would prefer to do such things.


I think I'll also move the configuration from conf/web.xml to 
webapps/docs/cgi-howto.html while I'm at it so those vestiges are gone.


+1

Mark




Thanks,
-chris

On 10/28/19 09:55, Christopher Schultz wrote:

All,

Note: this was not a vote.

There was very little feedback, and responses were mixed. We got
exactly one response on the users@ list about real-world usage of CGI,
so we cannot draw any conclusions about real-world uses.

Otherwise, the consensus seems to be that CGIs should stay a part of
the main Tomcat distribution, but that perhaps separating it out into
a distinct JAR file and/or separate distribution might be advantageous.

It appears that the CGIServlet is completely self-contained. It makes
use of the following internal(ish) Tomcat APIs:

org.apache.catalina.util.IOTools
org.apache.juli.logging.Log
org.apache.juli.logging.LogFactory
org.apache.tomcat.util.compat.JrePlatform
org.apache.tomcat.util.res.StringManager

All of these could be replaced if necessary to make a standalone,
container-agnostic package.

It looks like it would be fairly easy to separate-out the CGIServlet
into a separate JAR file packaging if there's utility in that. For
example, security-conscious environments may want to remove that JAR
file entirely from the Tomcat deployment to be absolutely sure that
Runtime.exec() isn't available in the deployed Java code (from the
container; yet I realize that SSIServlet/SSIFilter has this, too).

I'd like to go ahead and move the CGIServlet from the general
catalina.jar file into catalina-cgi.jar. That should only require a
small change to the build.xml script.

Any objections?

-chris

On 10/7/19 10:59, Christopher Schultz wrote:

All,



I recently gave a presentation on locking-down Apache Tomcat[1] and
I briefly discussed the "sharp edges" present in Tomcat. Some of
them are unnecessarily sharp and may be actually unnecessary. I'm
going to make a few proposals to remove functions from Tomcat.



Proposal: Remove CGI Servlet



Justification:



The CGIServlet is another component, like server-side-includes,
which is a remote-code execution (RCE) vulnerability as a feature.
It is very easy to misconfigure. It is arguably not possible to
secure it on Windows[2]. There are better solutions if you want to
run Perl, Python, PHP, or whatever on your server in the form of
the many fine web-server products out there.



-chris




[1]
http://tomcat.apache.org/presentations.html#latest-locking-down-tomc



at

[2]
https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/

23


/everyone-quotes-command-line-arguments-the-wrong-way/



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Implement additional security checks in SecurityLifecycleListener


On 06/06/2024 18:13, Konstantin Kolinko wrote:

чт, 6 июн. 2024 г. в 17:49, Christopher Schultz :


All,

Tomcat's SecurityLifecycleListener currently checks the current working
user's name, the umask and not much else at the moment.

I'd like to add "administrator" as another username to look for. (The
documentation says that "root" is the only current username checked.)

I would also like to add several items from the DISA STIG document found
here:
https://www.stigviewer.com/stig/apache_tomcat_application_sever_9/2021-12-27/

I haven't decided exactly which items to implement, but I will probably
do this as a PR with separate commits for each item.

Are there any objections to be starting this work?


1. Generally, the checks (including the 3 already implemented) are of
an "audit" kind.

An "audit" is something that produces a report.

I wonder whether a listener that operates on a "before init" event is
a good technology for those checks.

Whether it is a good entry point, whether it produces a visible
report, whether it can be run regularly.

Whether it is worth delaying start time to make those checks.

In the case of an "umask" check we already depend on a "3rd party": on
a feature of our startup scripts.

2. Requirements and implementation details depend on an operating system.


This got me wondering if we might want general checks and OS specific 
checks and whether that had any impact on implementation.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Notes from Tomcat security day


Hi all,

I have added the notes from yesterday's security day to the wiki.

https://cwiki.apache.org/confluence/display/TOMCAT/Security+Day+EU+2024

We discussed lots of things and while there are quite a few things the 
folks present agreed would be worth doing, all the actaul decisions need 
to go through dev@ so expect some more threads like the ones Chris has 
already started.


I think I have transferred the notes correctly but feel free to edit the 
notes if I missed soemthing or got the notes wrong.


Cheers,

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 69124] New: https://www.ninjaiptv.fr

https://bz.apache.org/bugzilla/show_bug.cgi?id=69124

Bug ID: 69124
   Summary: https://www.ninjaiptv.fr
   Product: Tomcat Native
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Documentation
  Assignee: dev@tomcat.apache.org
  Reporter: laylamila07021...@gmail.com
  Target Milestone: ---

https://www.ninjaiptv.fr

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 69124] https://www.ninjaiptv.fr

https://bz.apache.org/bugzilla/show_bug.cgi?id=69124

--- Comment #1 from Layla!  ---
Created attachment 39767
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=39767&action=edit
https://www.ninjaiptv.fr

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Security mechanisms to counter spam

2024-06-07 Thread Dimitris Soumis

Hi All,

Due to the surge in spam BZs today, I propose implementing a security
mechanism to counter this issue and prevent further disruption to the
mailing list.

A potential solution could include a honeypot to identify and block bots,
as well as a reCaptcha to verify users. Additionally, should monitor for
multiple requests from the same IP address and block the IP if necessary.

Can also leverage tools like this Mozilla Bugbot Spam Detection Script
 to
identify and filter out spam.

Best regards,

Dimitris

Re: Notes from Tomcat security day

2024-06-07 Thread Coty Sutherland

Looks like a very productive day! Thanks for sharing the notes, Mark.

On Friday, June 7, 2024, Mark Thomas  wrote:
> Hi all,
>
> I have added the notes from yesterday's security day to the wiki.
>
> https://cwiki.apache.org/confluence/display/TOMCAT/Security+Day+EU+2024
>
> We discussed lots of things and while there are quite a few things the
folks present agreed would be worth doing, all the actaul decisions need to
go through dev@ so expect some more threads like the ones Chris has already
started.
>
> I think I have transferred the notes correctly but feel free to edit the
notes if I missed soemthing or got the notes wrong.
>
> Cheers,
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2024-06-07 Thread Michael Osipov

On 2024/06/07 08:05:34 Mark Thomas wrote:
> On 06/06/2024 16:30, Christopher Schultz wrote:
> > All,
> > 
> > Resurrecting this thread from 2019.
> > 
> > I'd like to remove the SSI configuration from conf/web.xml and put it 
> > into webapps/docs/ssi-howto.html.
> > 
> > Are there any objections?
> 
> None here.
> 
> Do we want to go further and consider removing it entirely for Tomcat 12 
> onwards. Maybe a question for the users list?

I need to admit that there are situations where SSI might be prefered over JSP.
Example: I needed limited flexibility for some Asciidoctor generated documents 
dependening whether it is QA or prod. I didn't want to generate multiple sets 
of documents (reduce complexity). Now some lines of SSI display a proper QA 
banner. Good enough for the job. Getting JSP or PHP output with Asciidoctor is 
almost impossible.

Michael

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Enable SecureLifecycleListener by default


Konstantin,

On 6/6/24 12:01, Konstantin Kolinko wrote:

чт, 6 июн. 2024 г. в 17:46, Christopher Schultz :


All,

I'd like to remove the  around the SecureLifecycleListener
in conf/server.xml that we bundle with Tomcat distributions.

Before I do so, are there any objections to making this change?


Its name is "SecurityListener",
org.apache.catalina.security.SecurityListener

https://tomcat.apache.org/tomcat-11.0-doc/config/listeners.html#Security_Lifecycle_Listener_-_org.apache.catalina.security.SecurityListener

Looking at its checks:

- "checkedOsUsers":
It checks the value of System.getProperty("user.name");

1. On Windows it is useless.


:(

What does user.name return when running under Administrator or 
LocalSystem or whatever?



2. It is possible to run as root to be able to bind to port 80. It is
usually done with jsvc (Apache Commons Daemon) and its capability to
drop privileges.

https://commons.apache.org/proper/commons-daemon/jsvc.html#Downgrading_user
https://cwiki.apache.org/confluence/display/TOMCAT/HowTo#HowTo-HowtorunTomcatwithoutrootprivileges?

I wonder what the actual value of "user.name" will be in case of "2.".
The check is performed at "before init" event, thus earlier than jsvc
drops privileges.


We can check :)


- "minimumUmask"
It checks the value of System.getProperty(UMASK_PROPERTY_NAME);
UMASK_PROPERTY_NAME = Constants.PACKAGE + ".SecurityListener.UMASK";

1. On Windows it is useless.


+1 and the documentation says it doesn't do any check on Windows.


2. The property is set by a startup script. If it is started in a
different way (jsvc / daemon.sh, or directly as a Java application -
as done by Eclipse IDE, as an embedded Tomcat), I expect it to break.

- "buildDateWarningAgeDays"

1. It is disabled by default.
2. It is checked at start time, but actual servers may run years
without a reboot.
3. I wonder how it behaves if Tomcat is embedded in some IOT device.

Thus I wonder whether it is worth enabling it.

(But if we want to get real feedback, enabling it now for Tomcat 11 is
a good starting point.)


Yes, this is what I was proposing.

-chris

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Enable SecureLifecycleListener by default


Coty,

On 6/6/24 11:34, Coty Sutherland wrote:

On Thu, Jun 6, 2024 at 10:46 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


All,

I'd like to remove the  around the SecureLifecycleListener
in conf/server.xml that we bundle with Tomcat distributions.

Before I do so, are there any objections to making this change?



No objections from me. I might suggest making the default
buildDateWarningAgeDays something like 6 months though rather than no
default. If we're trying to encourage secure practices warning about older
builds should be part of that config change IMO


I got some pushback from the folks who have to support Tomcat for 
decades which is why it's disabled by default.


I'll keep pushing :)

-chris

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Remove JSP file from ROOT web application

Konstantin,

On 6/6/24 11:26, Konstantin Kolinko wrote:

чт, 6 июн. 2024 г. в 17:44, Christopher Schultz :

All,

I'd like to change the existing webapps/ROOT/index.jsp to index.html and
remove the dynamic elements. Currently, the only truly dynamic element
in the whole file is this:

"
Copyright ©1999-${year} Apache Software
Foundation. All Rights Reserved
"

I don't see any particular reason that the Copyright information must
always show the "current year". We can simply set this to "the current
year" during the release process.

This will mean that the default application will be completely static.
Not much of an upgrade, *but* if a user would prefer to completely
remove Jasper, it means that the default home page will be readable.

Hi, Chris!

+1 !

We missed you this week.

Being involved in moderation of one of our mailing lists, I suspect that
some amount of spam is caused by our default web page,
when it is de-facto used as the front page of a third-party web site.

That is, ASF is wrongly interpreted as an owner of that web site.

My thoughts were:
a) Replace it with a simple static page that just says "It works" or similar.
b) Make content dynamic, so that the current content is shown to
localhost clients only,
and show the "simple" page for anyone else.

An example of "a)" is Apache HTTPD:

https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/docroot/index.html?revision=1200966&view=markup
https://svn.apache.org/viewvc?view=revision&revision=105393
Oct 2004 (19 years, 8 months ago)

My preference is for "a)".

Maybe move the old shiny "root" page to the examples web application.

This is a reasonable idea.

I always thought that httpd's "It works!" page was crappy. I like the
Tomcat one better. But I'd like to disable everything in the ROOT web
application if possible.

Having different behavior for local versus remote visits is an
interesting idea. I wouldn't want to implement something like that
without more support from other committers.

-chris

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)


Michael,

On 6/7/24 08:01, Michael Osipov wrote:

On 2024/06/07 08:05:34 Mark Thomas wrote:

On 06/06/2024 16:30, Christopher Schultz wrote:

All,

Resurrecting this thread from 2019.

I'd like to remove the SSI configuration from conf/web.xml and put it
into webapps/docs/ssi-howto.html.

Are there any objections?


None here.

Do we want to go further and consider removing it entirely for Tomcat 12
onwards. Maybe a question for the users list?


I need to admit that there are situations where SSI might be prefered over JSP.
Example: I needed limited flexibility for some Asciidoctor generated documents 
dependening whether it is QA or prod. I didn't want to generate multiple sets 
of documents (reduce complexity). Now some lines of SSI display a proper QA 
banner. Good enough for the job. Getting JSP or PHP output with Asciidoctor is 
almost impossible.


It's entirely possible to separate SSI into a different project. I 
didn't do it because it uses helper-classes in Tomcat for certain things.


But if SSI is desirable, it can be packaged separately at the cost of 
some additional support classes/methods being copied outside of Tomcat.


I don't want to support it anymore, but it should be easy *for someone 
else* to extract and bundle separately :)


-chris

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 69124] SPAM SPAM SPAM SPAM

https://bz.apache.org/bugzilla/show_bug.cgi?id=69124

Chuck Caldarale  changed:

   What|Removed |Added

Summary|https://www.ninjaiptv.fr|SPAM SPAM SPAM SPAM
 Resolution|--- |INVALID
 Status|NEW |RESOLVED

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Remove JSP file from ROOT web application

2024-06-07 Thread Coty Sutherland

On Fri, Jun 7, 2024 at 8:52 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Konstantin,
>
> On 6/6/24 11:26, Konstantin Kolinko wrote:
> > чт, 6 июн. 2024 г. в 17:44, Christopher Schultz <
> ch...@christopherschultz.net>:
> >>
> >> All,
> >>
> >> I'd like to change the existing webapps/ROOT/index.jsp to index.html and
> >> remove the dynamic elements. Currently, the only truly dynamic element
> >> in the whole file is this:
> >>
> >> "
> >> Copyright ©1999-${year} Apache Software
> >> Foundation.  All Rights Reserved
> >> "
> >>
> >> I don't see any particular reason that the Copyright information must
> >> always show the "current year". We can simply set this to "the current
> >> year" during the release process.
> >>
> >> This will mean that the default application will be completely static.
> >> Not much of an upgrade, *but* if a user would prefer to completely
> >> remove Jasper, it means that the default home page will be readable.
> >
> > Hi, Chris!
>
> +1 !
>
> We missed you this week.
>
> > Being involved in moderation of one of our mailing lists, I suspect that
> > some amount of spam is caused by our default web page,
> > when it is de-facto used as the front page of a third-party web site.
> >
> > That is, ASF is wrongly interpreted as an owner of that web site.
> >
> > My thoughts were:
> > a) Replace it with a simple static page that just says "It works" or
> similar.
> > b) Make content dynamic, so that the current content is shown to
> > localhost clients only,
> > and show the "simple" page for anyone else.
> >
> > An example of "a)" is Apache HTTPD:
> >
> >
> https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/docroot/index.html?revision=1200966&view=markup
> > https://svn.apache.org/viewvc?view=revision&revision=105393
> > Oct 2004 (19 years, 8 months ago)
> >
> > My preference is for "a)".
> >
> > Maybe move the old shiny "root" page to the examples web application.
>
> This is a reasonable idea.
>
> I always thought that httpd's "It works!" page was crappy. I like the
> Tomcat one better. But I'd like to disable everything in the ROOT web
> application if possible.
>

I can get on board with that. My first thought after reading Konstantin's
suggestion was that we should move the ROOT webapp to another context
(maybe something like Quickstart?) and then have the ROOT context be
"Congratulations, it works!" or some variant. Maybe adding a link to the
new location for the full splash page would make sense also?


>
> Having different behavior for local versus remote visits is an
> interesting idea. I wouldn't want to implement something like that
> without more support from other committers.
>

Whether or not I could +1 this depends on the complexity of implementation
and maintenance, and also would need some feedback from users because IMO I
could see confusion arising from differing behavior pretty quickly from
admins that aren't familiar with tomcat unless we make what's happening
obvious directly on the page.

Re: [PROPOSAL] Remove JSP file from ROOT web application

2024-06-07 Thread Felix Schumacher




Am 6. Juni 2024 17:26:27 MESZ schrieb Konstantin Kolinko 
:
>чт, 6 июн. 2024 г. в 17:44, Christopher Schultz :
>>
>> All,
>>
>> I'd like to change the existing webapps/ROOT/index.jsp to index.html and
>> remove the dynamic elements. Currently, the only truly dynamic element
>> in the whole file is this:
>>
>> "
>> Copyright ©1999-${year} Apache Software
>> Foundation.  All Rights Reserved
>> "
>>
>> I don't see any particular reason that the Copyright information must
>> always show the "current year". We can simply set this to "the current
>> year" during the release process.
>>
>> This will mean that the default application will be completely static.
>> Not much of an upgrade, *but* if a user would prefer to completely
>> remove Jasper, it means that the default home page will be readable.
>
>Hi, Chris!
>
>Being involved in moderation of one of our mailing lists, I suspect that
>some amount of spam is caused by our default web page,
>when it is de-facto used as the front page of a third-party web site.
>
>That is, ASF is wrongly interpreted as an owner of that web site.
>
>My thoughts were:
>a) Replace it with a simple static page that just says "It works" or similar.
>b) Make content dynamic, so that the current content is shown to
>localhost clients only,
>and show the "simple" page for anyone else.
>
>An example of "a)" is Apache HTTPD:
>
>https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/docroot/index.html?revision=1200966&view=markup
>https://svn.apache.org/viewvc?view=revision&revision=105393
>Oct 2004 (19 years, 8 months ago)
>
>My preference is for "a)".

+1 for a simple (but still nice to look at) it-works page, when bundled into 
distribution package. 

Maybe a link to follow up steps on that page would be good.

The old site could be used for development builds.

Or as suggested moved into another context. 

I think b) would add too much surprise possibilities for admins/users to be 
worth it.

Felix

>
>Maybe move the old shiny "root" page to the examples web application.
>
>Best regards,
>Konstantin Kolinko
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: dev-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Remove JSP file from ROOT web application

2024-06-07 Thread Raymond Augé

My 2c.

I think a new static page could easily make it clear what happened without
too much discomfort.

"Welcome to the NEW Apache Tomcat static landing page (replace this webapp
with your own... the old one, if deployed, is probably [here](/quickstart))"

etc. etc.

I would think that in a large portion of "enterprise" cases (a.k.a. those
having long maintenance expectations, as is the case at $myworkplace$),
Tomcat is being repackaged and the default ROOT is being overridden before
the default one is ever seen, in which case the fancy landing page isn't
really a problem to begin with and so you're mainly focusing on the stock
deployments and new users where, honestly, would they really know any
difference?

On Fri, Jun 7, 2024 at 9:24 AM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

>
>
> Am 6. Juni 2024 17:26:27 MESZ schrieb Konstantin Kolinko <
> knst.koli...@gmail.com>:
> >чт, 6 июн. 2024 г. в 17:44, Christopher Schultz <
> ch...@christopherschultz.net>:
> >>
> >> All,
> >>
> >> I'd like to change the existing webapps/ROOT/index.jsp to index.html and
> >> remove the dynamic elements. Currently, the only truly dynamic element
> >> in the whole file is this:
> >>
> >> "
> >> Copyright ©1999-${year} Apache Software
> >> Foundation.  All Rights Reserved
> >> "
> >>
> >> I don't see any particular reason that the Copyright information must
> >> always show the "current year". We can simply set this to "the current
> >> year" during the release process.
> >>
> >> This will mean that the default application will be completely static.
> >> Not much of an upgrade, *but* if a user would prefer to completely
> >> remove Jasper, it means that the default home page will be readable.
> >
> >Hi, Chris!
> >
> >Being involved in moderation of one of our mailing lists, I suspect that
> >some amount of spam is caused by our default web page,
> >when it is de-facto used as the front page of a third-party web site.
> >
> >That is, ASF is wrongly interpreted as an owner of that web site.
> >
> >My thoughts were:
> >a) Replace it with a simple static page that just says "It works" or
> similar.
> >b) Make content dynamic, so that the current content is shown to
> >localhost clients only,
> >and show the "simple" page for anyone else.
> >
> >An example of "a)" is Apache HTTPD:
> >
> >
> https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/docroot/index.html?revision=1200966&view=markup
> >https://svn.apache.org/viewvc?view=revision&revision=105393
> >Oct 2004 (19 years, 8 months ago)
> >
> >My preference is for "a)".
>
> +1 for a simple (but still nice to look at) it-works page, when bundled
> into distribution package.
>
> Maybe a link to follow up steps on that page would be good.
>
> The old site could be used for development builds.
>
> Or as suggested moved into another context.
>
> I think b) would add too much surprise possibilities for admins/users to
> be worth it.
>
> Felix
>
> >
> >Maybe move the old shiny "root" page to the examples web application.
> >
> >Best regards,
> >Konstantin Kolinko
> >
> >-
> >To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> >For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow, Java Champion

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

2024-06-07 Thread Michael Osipov



On 2024/06/07 12:54:44 Christopher Schultz wrote:
> Michael,
> 
> On 6/7/24 08:01, Michael Osipov wrote:
> > On 2024/06/07 08:05:34 Mark Thomas wrote:
> >> On 06/06/2024 16:30, Christopher Schultz wrote:
> >>> All,
> >>>
> >>> Resurrecting this thread from 2019.
> >>>
> >>> I'd like to remove the SSI configuration from conf/web.xml and put it
> >>> into webapps/docs/ssi-howto.html.
> >>>
> >>> Are there any objections?
> >>
> >> None here.
> >>
> >> Do we want to go further and consider removing it entirely for Tomcat 12
> >> onwards. Maybe a question for the users list?
> > 
> > I need to admit that there are situations where SSI might be prefered over 
> > JSP.
> > Example: I needed limited flexibility for some Asciidoctor generated 
> > documents dependening whether it is QA or prod. I didn't want to generate 
> > multiple sets of documents (reduce complexity). Now some lines of SSI 
> > display a proper QA banner. Good enough for the job. Getting JSP or PHP 
> > output with Asciidoctor is almost impossible.
> 
> It's entirely possible to separate SSI into a different project. I 
> didn't do it because it uses helper-classes in Tomcat for certain things.
> 
> But if SSI is desirable, it can be packaged separately at the cost of 
> some additional support classes/methods being copied outside of Tomcat.
> 
> I don't want to support it anymore, but it should be easy *for someone 
> else* to extract and bundle separately :)

What is the pain having it off by default, but have the necessary classes still 
provided in the JARs? They do not require any maintenance. They just work, 
don't they?

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Enable SecureLifecycleListener by default

2024-06-07 Thread Tim Funk

Somewhat related and tangential to the other conversations 

Is it worth introducing a system property like
"-Dtomcat.security.harden=true". (Personally not sold yet on the idea)

Then when set to true ...
- It can go nuts with additional SecureLifecycleListener checks
- It can disable all OOTB webapps (ROOT/docs/etc) (Which then requires a
new filter on those webapps)
- Other hardening checks (minimal error pages, server headers, ...)

So from a security perspective, it's trivial to enable. But from a
developer getting started perspective, the docs,etc are easy to see?


-Tim

On Thu, Jun 6, 2024 at 10:46 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> All,
>
> I'd like to remove the  around the SecureLifecycleListener
> in conf/server.xml that we bundle with Tomcat distributions.
>
> Before I do so, are there any objections to making this change?
>
> Thanks,
> -chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [PROPOSAL] Enable SecureLifecycleListener by default

2024-06-07 Thread Coty Sutherland

On Fri, Jun 7, 2024 at 10:33 AM Tim Funk  wrote:

> Somewhat related and tangential to the other conversations 
>
> Is it worth introducing a system property like
> "-Dtomcat.security.harden=true". (Personally not sold yet on the idea)
>

I think I'm +0 on this. Implementing something like this would be nice
because we could leave it off by default and then decide to switch it on at
some future date with lots of warnings to users without having to do it via
configuration change (that probably wouldn't get picked up by any current
installs).

>
> Then when set to true ...
> - It can go nuts with additional SecureLifecycleListener checks
> - It can disable all OOTB webapps (ROOT/docs/etc) (Which then requires a
> new filter on those webapps)
> - Other hardening checks (minimal error pages, server headers, ...)
>

We could probably include checks that cover a big chunk of what's in the
security considerations doc if we really wanted.

>
> So from a security perspective, it's trivial to enable. But from a
> developer getting started perspective, the docs,etc are easy to see?
>
>
> -Tim
>
> On Thu, Jun 6, 2024 at 10:46 AM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> > All,
> >
> > I'd like to remove the  around the SecureLifecycleListener
> > in conf/server.xml that we bundle with Tomcat distributions.
> >
> > Before I do so, are there any objections to making this change?
> >
> > Thanks,
> > -chris
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >
>

[Bug 69125] New: Century Silicon City

https://bz.apache.org/bugzilla/show_bug.cgi?id=69125

Bug ID: 69125
   Summary: Century Silicon City
   Product: Tomcat Native
   Version: 2.0.5
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Library
  Assignee: dev@tomcat.apache.org
  Reporter: centurysiliconc...@gmail.com
  Target Milestone: ---

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 69125] Century Silicon City

https://bz.apache.org/bugzilla/show_bug.cgi?id=69125

Century Silicon City  changed:

   What|Removed |Added

URL||https://www.centurysiliconc
   ||ity.in/
 OS||All

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 69125] Century Silicon City

https://bz.apache.org/bugzilla/show_bug.cgi?id=69125

Coty Sutherland  changed:

   What|Removed |Added

URL|https://www.centurysiliconc |
   |ity.in/ |
 Resolution|--- |INVALID
 Status|NEW |RESOLVED

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 69125] SPAM SPAM SPAM SPAM

https://bz.apache.org/bugzilla/show_bug.cgi?id=69125

Chuck Caldarale  changed:

   What|Removed |Added

Summary|Century Silicon City|SPAM SPAM SPAM SPAM

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 69125] Century Silicon City

https://bz.apache.org/bugzilla/show_bug.cgi?id=69125

Century Silicon City  changed:

   What|Removed |Added

Summary|SPAM SPAM SPAM SPAM |Century Silicon City
URL||https://www.centurysiliconc
   ||ity.in/

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 69125] Century Silicon City

https://bz.apache.org/bugzilla/show_bug.cgi?id=69125

Coty Sutherland  changed:

   What|Removed |Added

URL|https://www.centurysiliconc |
   |ity.in/ |

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 69125] SPAM SPAM SPAM SPAM