Re: Backporting patch for CVE-2023-46589 to Tomcat 8.0.14

[Mark Thomas]

On 16/01/2024 15:20, Sean Whitton wrote:

Hello Mark,

On Mon 18 Dec 2023 at 05:00pm GMT, Mark Thomas wrote:


Am I understanding this request correctly?

Freexian has sold at least one customer - probably multiple
customers - long term support for Tomcat 8.0.x and has now found that
it is unable to provide that support.

Feexian's solution to this dilemma is to ask the Tomcat community -
who stopped supporting Tomcat 8.0.x over five years ago in June 2018 -
to provide free support to fill this gap in Freexian's capability to
support Tomcat.

There are several things that don't seem right about the above so I am
looking forward to you correcting my understanding of the
circumstances of this request.


I'd like to apologise for making a request that you felt was ill-placed.
It was not our intent to abuse this forum.  I am new to this work, and I
didn't reflect adequately on how I was interacting with you not merely
as an ordinary volunteer Free Software developer, which is what I'm used
to.


Thank you.


In fact, Freexian is keen to offer to contract with upstream developers
when external expertise is required.  We should have mentioned that
possibility in our first contact.  I resolved the issue I posted about
after sleeping on it, but perhaps on some other occasion we'll have an
opportunity to work together.

Should we (Freexian) find ourselves at some future point in need of
assistance of a similar nature, is there a better way to find upstream
developers that can help and do contracting work than posting to this
list?


This list is probably best. I don't think there would be any objection 
to an occasional request for contracting help with a little background 
as long as the subsequent discussion was taken off-list.



My apologies again, and also for following up only almost a month later.
This thread was delivered to a mail folder into which I did not expect
it would go.


Understood.

Good to hear that you got the issue resolved.

Mark

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

Re: Backporting patch for CVE-2023-46589 to Tomcat 8.0.14

[Sean Whitton]

Hello Mark,

On Mon 18 Dec 2023 at 05:00pm GMT, Mark Thomas wrote:

> Am I understanding this request correctly?
>
> Freexian has sold at least one customer - probably multiple
> customers - long term support for Tomcat 8.0.x and has now found that
> it is unable to provide that support.
>
> Feexian's solution to this dilemma is to ask the Tomcat community -
> who stopped supporting Tomcat 8.0.x over five years ago in June 2018 -
> to provide free support to fill this gap in Freexian's capability to
> support Tomcat.
>
> There are several things that don't seem right about the above so I am
> looking forward to you correcting my understanding of the
> circumstances of this request.

I'd like to apologise for making a request that you felt was ill-placed.
It was not our intent to abuse this forum.  I am new to this work, and I
didn't reflect adequately on how I was interacting with you not merely
as an ordinary volunteer Free Software developer, which is what I'm used
to.

In fact, Freexian is keen to offer to contract with upstream developers
when external expertise is required.  We should have mentioned that
possibility in our first contact.  I resolved the issue I posted about
after sleeping on it, but perhaps on some other occasion we'll have an
opportunity to work together.

Should we (Freexian) find ourselves at some future point in need of
assistance of a similar nature, is there a better way to find upstream
developers that can help and do contracting work than posting to this
list?

My apologies again, and also for following up only almost a month later.
This thread was delivered to a mail folder into which I did not expect
it would go.

-- 
Sean Whitton

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

Re: Backporting patch for CVE-2023-46589 to Tomcat 8.0.14

[Mark Thomas]

On 18/12/2023 17:00, Mark Thomas wrote:

On 17/12/2023 16:32, Sean Whitton wrote:

Hello,

I am working to backport the fix for CVE-2023-46589 to Tomcat version
8.0.14, which is what we have in Debian "jessie".  This is under the
Extended LTS project for older Debian releases, run by Freexian SARL.
 


Sean,

Am I understanding this request correctly?

Freexian has sold at least one customer - probably multiple customers - 
long term support for Tomcat 8.0.x and has now found that it is unable 
to provide that support.


Feexian's solution to this dilemma is to ask the Tomcat community - who 
stopped supporting Tomcat 8.0.x over five years ago in June 2018 - to 
provide free support to fill this gap in Freexian's capability to 
support Tomcat.


There are several things that don't seem right about the above so I am 
looking forward to you correcting my understanding of the circumstances 
of this request.


I haven't seen a response to my previous post so for the benefit of any 
Freexian customers that are watching this thread.


The setError() call is important.

I have back-ported the fix for CVE-2023-46589 to Tomcat 7.0.x at $dayjob 
and it required 9 changes to be back-ported.


Community support for 8.0.x ended 2.75 years earlier than 7.0.x 
therefore I would expect back-porting of the CVE-2023-46589 fix to 8.0.x 
to require additional patches to be back-ported in addition to the 9 
required for 7.0.x.


Mark




Mark




I am having a problem backporting this hunk of the fix:

--8<---cut here---start->8---
--- a/java/org/apache/catalina/connector/InputBuffer.java
+++ b/java/org/apache/catalina/connector/InputBuffer.java
@@ -346,11 +348,23 @@ public class InputBuffer extends Reader
  try {
  return coyoteRequest.doRead(bb);
  } catch (BadRequestException bre) {
+    // Set flag used by asynchronous processing to detect 
errors on non-container threads

  coyoteRequest.setErrorException(bre);
+    // In synchronous processing, this exception may be 
swallowed by the application so set error flags here.
+
coyoteRequest.setAttribute(RequestDispatcher.ERROR_EXCEPTION, bre);

+    coyoteRequest.getResponse().setStatus(400);
+    coyoteRequest.setError();
+    // Make the exception visible to the application
  throw bre;
  } catch (IOException ioe) {
+    // Set flag used by asynchronous processing to detect 
errors on non-container threads

  coyoteRequest.setErrorException(ioe);
+    // In synchronous processing, this exception may be 
swallowed by the application so set error flags here.
+
coyoteRequest.setAttribute(RequestDispatcher.ERROR_EXCEPTION, ioe);

+    coyoteRequest.getResponse().setStatus(400);
+    coyoteRequest.setError();
  // Any other IOException on a read is almost always due 
to the remote client aborting the request.

+    // Make the exception visible to the application
  throw new ClientAbortException(ioe);
  }
  }
--8<---cut here---end--->8---

The problem is that coyoteRequest does not have a setError method.
I believe that this is because Tomcat 8.0.14 is earlier than commit
662f9f4f0f.  I have not been able to determine whether this is
important.  Can I skip the setError() call, or do I need to call it some
other way?

Many thanks.



-
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: Backporting patch for CVE-2023-46589 to Tomcat 8.0.14

[Azhar Jainul Abdeen]

 

We, the RECDO organization is a legally registerednon-profit entity based in 
Kantale, Trincomalle. RECDO was established in 2000and serves marginalized 
communities in the Eastern Province, particularly theTrincomalee District. 
Our work focuses on the following thematic areas:community policing and public 
safety; gender equality, women’s’ empowerment andgender mainstreaming; 
educational outreach, Child wellbeing & protection;water, sanitation& Health; 
participatory governance ,disaster risk reduction and climate 
adaptation including rural agriculture;entrepreneurship development& 
livelihood; rights-based social wellbeing,peace and community conflict 
resolution. We have successfully collaborated withreputed bilateral 
international donors and government sector for theimplementation of 
comprehensive projects.  RECDO executed human-development oriented projects in 
partnership with TheAsia Foundation, GlobalFund for Children, C.I.E.LO 
(France), Muslim Aid, ONUR, ICES and CEPA (Colombo)Thank you very muchBest 
Regrads Azhar 
On Monday, 18 December 2023 at 11:55:31 am GMT-8, Emmanuel Bourg 
 wrote:  
 
 Le 18/12/2023 à 18:15, Michael Osipov a écrit :

> SCNR: https://unixsheikh.com/articles/the-delusions-of-debian.html

That's a low blow, this post smells more like an old systemd rant mixed 
with a complete misunderstanding on how Debian works than a well founded 
criticism.

Emmanuel Bourg


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

  

Re: Backporting patch for CVE-2023-46589 to Tomcat 8.0.14

[Emmanuel Bourg]

Le 18/12/2023 à 18:00, Mark Thomas a écrit :


Am I understanding this request correctly?


Mostly, but for the context, if ever that makes it morally more 
acceptable, Freexian here is merely a vehicle to found independent 
contributors to work and maintain old packages, it's nothing like a 
RedHat sized company trying to maximize its profits and the dividends of 
its shareholders.


That said, I agree with Mark that it isn't reasonable to expect support 
for an EOLed version. For Debian ELTS I usually advise aligning the 
Tomcat version with the one in the following Debian release to ease the 
maintenance. So that would mean pulling the Tomcat 8.5 package from 
Debian Stretch to Jessie.


Emmanuel Bourg


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

Re: Backporting patch for CVE-2023-46589 to Tomcat 8.0.14

[Emmanuel Bourg]

Le 18/12/2023 à 18:15, Michael Osipov a écrit :


SCNR: https://unixsheikh.com/articles/the-delusions-of-debian.html


That's a low blow, this post smells more like an old systemd rant mixed 
with a complete misunderstanding on how Debian works than a well founded 
criticism.


Emmanuel Bourg


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

Re: Backporting patch for CVE-2023-46589 to Tomcat 8.0.14

[Michael Osipov]

On 2023/12/18 17:00:43 Mark Thomas wrote:
> On 17/12/2023 16:32, Sean Whitton wrote:
> > Hello,
> > 
> > I am working to backport the fix for CVE-2023-46589 to Tomcat version
> > 8.0.14, which is what we have in Debian "jessie".  This is under the
> > Extended LTS project for older Debian releases, run by Freexian SARL.
> >  
> 
> Sean,
> 
> Am I understanding this request correctly?
> 
> Freexian has sold at least one customer - probably multiple customers - 
> long term support for Tomcat 8.0.x and has now found that it is unable 
> to provide that support.
> 
> Feexian's solution to this dilemma is to ask the Tomcat community - who 
> stopped supporting Tomcat 8.0.x over five years ago in June 2018 - to 
> provide free support to fill this gap in Freexian's capability to 
> support Tomcat.
> 
> There are several things that don't seem right about the above so I am 
> looking forward to you correcting my understanding of the circumstances 
> of this request.

SCNR: https://unixsheikh.com/articles/the-delusions-of-debian.html

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

Re: Backporting patch for CVE-2023-46589 to Tomcat 8.0.14

[Mark Thomas]

On 17/12/2023 16:32, Sean Whitton wrote:

Hello,

I am working to backport the fix for CVE-2023-46589 to Tomcat version
8.0.14, which is what we have in Debian "jessie".  This is under the
Extended LTS project for older Debian releases, run by Freexian SARL.
 


Sean,

Am I understanding this request correctly?

Freexian has sold at least one customer - probably multiple customers - 
long term support for Tomcat 8.0.x and has now found that it is unable 
to provide that support.


Feexian's solution to this dilemma is to ask the Tomcat community - who 
stopped supporting Tomcat 8.0.x over five years ago in June 2018 - to 
provide free support to fill this gap in Freexian's capability to 
support Tomcat.


There are several things that don't seem right about the above so I am 
looking forward to you correcting my understanding of the circumstances 
of this request.


Mark




I am having a problem backporting this hunk of the fix:

--8<---cut here---start->8---
--- a/java/org/apache/catalina/connector/InputBuffer.java
+++ b/java/org/apache/catalina/connector/InputBuffer.java
@@ -346,11 +348,23 @@ public class InputBuffer extends Reader
  try {
  return coyoteRequest.doRead(bb);
  } catch (BadRequestException bre) {
+// Set flag used by asynchronous processing to detect errors on 
non-container threads
  coyoteRequest.setErrorException(bre);
+// In synchronous processing, this exception may be swallowed by 
the application so set error flags here.
+coyoteRequest.setAttribute(RequestDispatcher.ERROR_EXCEPTION, bre);
+coyoteRequest.getResponse().setStatus(400);
+coyoteRequest.setError();
+// Make the exception visible to the application
  throw bre;
  } catch (IOException ioe) {
+// Set flag used by asynchronous processing to detect errors on 
non-container threads
  coyoteRequest.setErrorException(ioe);
+// In synchronous processing, this exception may be swallowed by 
the application so set error flags here.
+coyoteRequest.setAttribute(RequestDispatcher.ERROR_EXCEPTION, ioe);
+coyoteRequest.getResponse().setStatus(400);
+coyoteRequest.setError();
  // Any other IOException on a read is almost always due to the 
remote client aborting the request.
+// Make the exception visible to the application
  throw new ClientAbortException(ioe);
  }
  }
--8<---cut here---end--->8---

The problem is that coyoteRequest does not have a setError method.
I believe that this is because Tomcat 8.0.14 is earlier than commit
662f9f4f0f.  I have not been able to determine whether this is
important.  Can I skip the setError() call, or do I need to call it some
other way?

Many thanks.



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