RE: Question about releases available for download

[Mcalexander, Jon J.]

Ding Ding Ding. Chris wins! Yes, that was the word.

Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

> -Original Message-
> From: Christopher Schultz 
> Sent: Wednesday, October 18, 2023 9:42 PM
> To: users@tomcat.apache.org
> Subject: Re: Question about releases available for download
> 
> Jon,
> 
> On 10/18/23 15:39, Mcalexander, Jon J. wrote:
> > Thanks Mark. I'm sorry if I stated it incorrectly. I meant the issue
> > with JDBC being broken, etc. the stuff that prompted the immediate new
> > releases.
> I think the word you were looking for was "regression", not "recursion" ;)
> 
> -chris
> 
> >> -Original Message-
> >> From: Mark Thomas 
> >> Sent: Wednesday, October 18, 2023 2:04 PM
> >> To: users@tomcat.apache.org
> >> Subject: Re: Question about releases available for download
> >>
> >> On 18/10/2023 18:29, Mcalexander, Jon J. wrote:
> >>> Hi Mark, et-al,
> >>>
> >>> With the recursion error with these releases in mind, should 8.5.94,
> >>> 9.0.81,
> >> and 10.1.15 be available for download via the archives? Should they
> >> not be removed and a not placed in the location that they have been
> >> removed due to introduced issues?
> >>
> >> Recursion error?
> >>
> >> Regardless, all ASF releases will always be available from the ASF 
> >> archives.
> >> That is ASF policv and I don't see it changing.
> >>
> >> Yes, old releases have bugs and/or security issues. Yes, some of
> >> those bugs / security issues are quite nasty. That is why we always
> >> recommend using the latest release of a current supported major version.
> >>
> >> Maven Central has a similar policy. Once a release is published to
> >> Maven Central it is pretty much impossible to get it removed.
> >>
> >> Mark
> >>
> >>>
> >>> Just asking,
> >>>
> >>> Thanks.
> >>>
> >>> Dream * Excel * Explore * Inspire
> >>> Jon McAlexander
> >>> Senior Infrastructure Engineer
> >>> Asst. Vice President
> >>> He/His
> >>>
> >>> Middleware Product Engineering
> >>> Enterprise CIO | EAS | Middleware | Infrastructure Solutions
> >>>
> >>> 8080 Cobblestone Rd | Urbandale, IA 50322
> >>> MAC: F4469-010
> >>> Tel 515-988-2508 | Cell 515-988-2508
> >>>
> >>>
> >>
> jonmcalexan...@wellsfargo.com
> >>> This message may contain confidential and/or privileged information.
> >>> If you
> >> are not the addressee or authorized to receive this for the
> >> addressee, you must not use, copy, disclose, or take any action based
> >> on this message or any information herein. If you have received this
> >> message in error, please advise the sender immediately by reply
> >> e-mail and delete this message. Thank you for your cooperation.
> >>>
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Dealing with an insecure Struts application on Tomcat

[Alan F]

I am looking at security steps to mitigate issues with a 1.x Struts based app.

I have recommended the following until an upgrade resource is available

Remove application from current shared datasource
Remediate high risk CVE scored vulnerabilities (x4 with high EPSS rating)
Reduce exposure to internal audience.
Create new db and instance for above isolated datasource

Would you take it further and ensure this runs on it's own separate Tomcat 
instance?
Any other recommendations?

RE: Tomcat minor update

[Aditya Shastri]

That's interesting.

The way I do the start.sh in my Catalina base is:

BASEDIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )/..
export CATALINA_BASE=$(realpath ${BASEDIR})

/opt/tomcat/tomcat-9/tomcat-9-latest/bin/startup.sh

I could just say $(realpath /opt/tomcat/tomcat-9/tomcat-9-latest)

The old version is we get rid off after 7 days just in case a rollback is 
needed.

As for Windows, I was under the impression that they are not big fans of 
symlinks anyway so maybe that's ok? :-D

Thank you Mark and Chris!

-Original Message-
From: Christopher Schultz 
Sent: Wednesday, October 18, 2023 7:32 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat minor update

Mark and Aditya,

On 10/18/23 04:21, Mark Thomas wrote:
> On 17/10/2023 22:47, Aditya Shastri wrote:
>> Hello,
>>
>> We have several tomcat instances that use a single CATALINA_HOME which
>> is a symlink for a specific version. The Tomcat instance we use is
>> very barebones and doesn't have any of the apps that come with it.
>>
>> For example,
>> The CATALINA_HOME points to a symlink
>> /opt/tomcat/tomcat-9/tomcat-9-latest ->
>> /opt/tomcat/tomcat-9/apache-tomcat-9.0.80.
>>
>> Now, if I want to upgrade to apache-tomcat-9.0.82, I normally do the
>> following steps:
>> 1. Stop all the running instances of tomcat in the various
>> 'CATALINA_BASE'.
>> 2. Update the symlink /opt/tomcat/tomcat-9/tomcat-9-latest from
>> /opt/tomcat/tomcat-9/apache-tomcat-9.0.80 to
>> /opt/tomcat/tomcat-9/apache-tomcat-9.0.82.
>> 3. Start all the instances.
>>
>> This method appears to work, and I read it as the most appropriate
>> method.
>>
>> My question is, can I change the symlink,
>> '/opt/tomcat/tomcat-9/tomcat-9-latest', while all the instances are
>> running and restart the instances when I have downtime?
>
> Probably not. You might get away with it sometimes but sometimes you are
> going to see errors.
>
>> Does Tomcat load all the CATALINA_HOME jar(s) (not including the
>> webapps folder) and config to memory thereby not caring if the
>> libraries have changed or does it realize that something has changed?
>
> No. The JVM loads classes when they are first referenced.
>
> The issue will be if you update the symlink, then Tomcat tries to load
> another class and the class from the new version is not compatible with
> the classes from the old version. A failure is unlikely but not
> impossible. I wouldn't risk it.

I wonder if we could solve this, at least on *NIX, by resolving
CATALINA_HOME by using `readlink -f`. This would allow you to use a
symlink to point to Tomcat but after catalina.sh is invoked,
CATALINA_HOME could be replaced with a canonicalized one which does not
contain a symlink anymore. Maybe there is a similar
utility/command/path-mangling-magic available on Windows?

That would allow you to change the symlink and not disturb any
currently-running Tomcat instances. You would obviously not want to
remove the old version from the disk before shutting-down those
instances, of course.

-chris




The information in this electronic mail communication (e-mail) contains 
confidential information which is the property of the sender and may be 
protected by the attorney-client privilege and/or attorney work product 
doctrine. It is intended solely for the addressee. Access to this e-mail by 
anyone else is unauthorized by the sender. If you are not the intended 
recipient, you are hereby notified that any disclosure, copying, or 
distribution of the contents of this e-mail transmission or the taking or 
omission of any action in reliance thereon or pursuant thereto, is prohibited, 
and may be unlawful. If you received this e-mail in error, please notify us 
immediately of your receipt of this message by e-mail and destroy this 
communication, any attachments, and all copies thereof.

Southwest Gas Corporation does not guarantee the privacy or security of 
information transmitted by facsimile (fax) or other unsecure electronic means 
(including email). By choosing to send or receive information, including 
confidential or personal identifying information, via fax or unencrypted 
e-mail, you consent to accept any associated risk.

Thank you for your cooperation.

Re: Question about releases available for download

[Christopher Schultz]

Jon,

On 10/19/23 11:33, Mcalexander, Jon J. wrote:

Ding Ding Ding. Chris wins! Yes, that was the word.


https://www.youtube.com/watch?v=NtfVgzXTp7Q

-chris


-Original Message-
From: Christopher Schultz 
Sent: Wednesday, October 18, 2023 9:42 PM
To: users@tomcat.apache.org
Subject: Re: Question about releases available for download

Jon,

On 10/18/23 15:39, Mcalexander, Jon J. wrote:

Thanks Mark. I'm sorry if I stated it incorrectly. I meant the issue
with JDBC being broken, etc. the stuff that prompted the immediate new
releases.

I think the word you were looking for was "regression", not "recursion" ;)

-chris


-Original Message-
From: Mark Thomas 
Sent: Wednesday, October 18, 2023 2:04 PM
To: users@tomcat.apache.org
Subject: Re: Question about releases available for download

On 18/10/2023 18:29, Mcalexander, Jon J. wrote:

Hi Mark, et-al,

With the recursion error with these releases in mind, should 8.5.94,
9.0.81,

and 10.1.15 be available for download via the archives? Should they
not be removed and a not placed in the location that they have been
removed due to introduced issues?

Recursion error?

Regardless, all ASF releases will always be available from the ASF archives.
That is ASF policv and I don't see it changing.

Yes, old releases have bugs and/or security issues. Yes, some of
those bugs / security issues are quite nasty. That is why we always
recommend using the latest release of a current supported major version.

Maven Central has a similar policy. Once a release is published to
Maven Central it is pretty much impossible to get it removed.

Mark



Just asking,

Thanks.

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508





jonmcalexan...@wellsfargo.com

This message may contain confidential and/or privileged information.
If you

are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply
e-mail and delete this message. Thank you for your cooperation.





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



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



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



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



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

Re: [OT] Dealing with an insecure Struts application on Tomcat

[Christopher Schultz]

Alan,

On 10/19/23 12:44, Alan F wrote:

I am looking at security steps to mitigate issues with a 1.x Struts based app.


Is this from a "Struts 1 is vulnerable" perspective? Because -- on paper 
-- it is. Vulnerable that is. But that doesn't necessarily mean that 
your application is vulnerable. I encourage you to read the CVEs 
associated with Struts 1 to see if they apply to you.



I have recommended the following until an upgrade resource is available

Remove application from current shared datasource
Remediate high risk CVE scored vulnerabilities (x4 with high EPSS rating)
Reduce exposure to internal audience.
Create new db and instance for above isolated datasource

Would you take it further and ensure this runs on it's own separate Tomcat 
instance?
Any other recommendations?


This depends upon what your threat model is. If the application seems 
like it's vulnerable, then isolating it from other applications may make 
some sense. But if your primary concern is access to the underlying 
data, then isolating the application won't protect the data.


I'm not sure what you mean by "shared data source". If you have a 
server-defined data source that is being shared by individual 
applications, then you probably just shouldn't be doing that in general.


Note that upgrading from Struts 1 to Struts 2 will probably require a 
complete rewrite of your application. :/


-chris

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