You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Vincent Neyt <vi...@gmail.com> on 2021/07/19 12:03:14 UTC
using cocoon 2.1 in the long-term, security concerns
Hi Cocoon users,
I'd like to ask your opinion on the long-term security risks of running
Cocoon on a server. The colleague responsible for the servers at my
university is inquiring if the software I'm using for my website is up to
date and is concerned that I'm using outdated software that could in the
future pose a security risk.
I'm using cocoon 2.1.11, which I could probably upgrade to 2.1.13 without
many problems. But I'm concerned about the long-term, and wondering if it
would perhaps be better to reprogram the website I've been working on for
10 years into eXist DB (which would be a huge time investment). I like
cocoon very much and would love to continue using it if it's possible.
I'm curious to hear your thoughts about using Cocoon 2.1 for the long term:
will it still work well inside future versions of servlet containers like
Tomcat? What about the java dependencies? And will cocoon 2.1 continue to
put out updates when security risks are identified?
thanks very much,
Vincent
Re: using cocoon 2.1 in the long-term, security concerns
Posted by Leszek Gawron <ou...@wlkp.org>.
On Mon, Jul 19, 2021 at 2:27 PM Cédric Damioli <cd...@apache.org> wrote:
> Hi,
>
> Not only Tomcat, but each and every dependency your particular project
> uses.
> As of today, Cocoon 2.1 works well in a Java 11+/Tomcat 9+ environment,
> with all dependencies upgraded.
>
> Cocoon 2.1.13 itself contained a fix for a security-related issue, but in
> the past years, there wasn't many security issues targeting Cocoon core.
>
>
cocoon 2.2 does NOT work with spring 4+ - the fixes are trivial though
(some deprecated API usages have to be corrected)
Jetty 9 needs to have web fragments configuration disabled or it doesn't
start cocoon webapp at all
I've made some forked changes for my organization and ... lost the sources.
Fixing it again should be no problem if someone here would go for a
release.
Java 11 is no problem - the only thing I remember is some simple
commons-beanutils usage querying Java version - the forced maven dependency
fixed the issue.
Re: using cocoon 2.1 in the long-term, security concerns
Posted by Cédric Damioli <cd...@apache.org>.
Hi,
Not only Tomcat, but each and every dependency your particular project uses.
As of today, Cocoon 2.1 works well in a Java 11+/Tomcat 9+ environment,
with all dependencies upgraded.
Cocoon 2.1.13 itself contained a fix for a security-related issue, but
in the past years, there wasn't many security issues targeting Cocoon core.
HTH,
Regards,
Cédric
Le 19/07/2021 à 14:05, warrell harries a écrit :
> The Tomcat version must be updated to address these concerns.
>
> That should do it
>
> On Mon, 19 Jul 2021, 13:03 Vincent Neyt, <vincent.neyt@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hi Cocoon users,
>
> I'd like to ask your opinion on the long-term security risks of
> running Cocoon on a server. The colleague responsible for the
> servers at my university is inquiring if the software I'm using
> for my website is up to date and is concerned that I'm using
> outdated software that could in the future pose a security risk.
>
> I'm using cocoon 2.1.11, which I could probably upgrade to 2.1.13
> without many problems. But I'm concerned about the long-term, and
> wondering if it would perhaps be better to reprogram the website
> I've been working on for 10 years into eXist DB (which would be a
> huge time investment). I like cocoon very much and would love to
> continue using it if it's possible.
>
> I'm curious to hear your thoughts about using Cocoon 2.1 for the
> long term: will it still work well inside future versions of
> servlet containers like Tomcat? What about the java dependencies?
> And will cocoon 2.1 continue to put out updates when security
> risks are identified?
>
> thanks very much,
> Vincent
>
--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org
Re: using cocoon 2.1 in the long-term, security concerns
Posted by warrell harries <wa...@gmail.com>.
The Tomcat version must be updated to address these concerns.
That should do it
On Mon, 19 Jul 2021, 13:03 Vincent Neyt, <vi...@gmail.com> wrote:
> Hi Cocoon users,
>
> I'd like to ask your opinion on the long-term security risks of running
> Cocoon on a server. The colleague responsible for the servers at my
> university is inquiring if the software I'm using for my website is up to
> date and is concerned that I'm using outdated software that could in the
> future pose a security risk.
>
> I'm using cocoon 2.1.11, which I could probably upgrade to 2.1.13 without
> many problems. But I'm concerned about the long-term, and wondering if it
> would perhaps be better to reprogram the website I've been working on for
> 10 years into eXist DB (which would be a huge time investment). I like
> cocoon very much and would love to continue using it if it's possible.
>
> I'm curious to hear your thoughts about using Cocoon 2.1 for the long
> term: will it still work well inside future versions of servlet containers
> like Tomcat? What about the java dependencies? And will cocoon 2.1 continue
> to put out updates when security risks are identified?
>
> thanks very much,
> Vincent
>
Re: using cocoon 2.1 in the long-term, security concerns
Posted by gelo1234 <ge...@gmail.com>.
Hello Vincent,
It depends on your future Strategy. Cocoon is very flexible. We've been
running Cocoon 3.0-beta in production with Tomcat9/10, Quarkus and even
Kubernetes 1.20 etc. No problems at all :)
with Java 8 :) We cannot switch to Java 11, because it's not compatible
with Cocoon libraries anymore :( That's the only obstacle.
Maybe someone could "update" cocoon stack to use Java 11 LTS JVM? Or now 17
LTS? :)
As long as it does its job, Cocoon is fine! Although the amount of
pipelines that are still in use in our Cocoon deployments decreased in
time.
We switched to Vue.js framework as frontend and Spring-Boot 2 as backend
technologies, all running on Kubernetes multi-clusters.
Both Vue and Spring-Boot 2 are very lightweight and suit our needs better
(to build Web-Portals) than Cocoon. Even though we still use Cocoon for
some integration stuff and fast
proxy/gateway to many "old" services or database access.
Greetings,
Greg
pon., 19 lip 2021 o 14:03 Vincent Neyt <vi...@gmail.com> napisał(a):
> Hi Cocoon users,
>
> I'd like to ask your opinion on the long-term security risks of running
> Cocoon on a server. The colleague responsible for the servers at my
> university is inquiring if the software I'm using for my website is up to
> date and is concerned that I'm using outdated software that could in the
> future pose a security risk.
>
> I'm using cocoon 2.1.11, which I could probably upgrade to 2.1.13 without
> many problems. But I'm concerned about the long-term, and wondering if it
> would perhaps be better to reprogram the website I've been working on for
> 10 years into eXist DB (which would be a huge time investment). I like
> cocoon very much and would love to continue using it if it's possible.
>
> I'm curious to hear your thoughts about using Cocoon 2.1 for the long
> term: will it still work well inside future versions of servlet containers
> like Tomcat? What about the java dependencies? And will cocoon 2.1 continue
> to put out updates when security risks are identified?
>
> thanks very much,
> Vincent
>
Re: using cocoon 2.1 in the long-term, security concerns
Posted by Leszek Gawron <ou...@wlkp.org>.
I have never attempted a cocoon release - doesn't look like a trivial task,
so maybe someone here has more experience?
I'd like one more thing "fixed" if it's possible:
org.apache.cocoon.forms.formmodel.Repeater has some "crazy" limitation that
has hit me several times on production:
if (size > 500) {
//throw new RuntimeException("Client is not allowed to
specify a repeater size larger than 500.");
}
could we lift that off or at least make the constraint configurable ?
On Fri, Jul 30, 2021 at 1:37 PM Gabriel Gruber <ga...@workflow.at>
wrote:
> Hi Leszak,
>
>
>
> Yeah, a release would be nice – Fix version 2.2.1 was stated in this
> ticket https://issues.apache.org/jira/browse/COCOON-2347
>
>
>
> But was never released though…
>
> Cheers,
>
> Gabriel
>
>
>
> *From: *Leszek Gawron <ou...@wlkp.org>
> *Date: *Friday, 30. July 2021 at 10:35
> *To: *users@cocoon.apache.org <us...@cocoon.apache.org>
> *Subject: *Re: using cocoon 2.1 in the long-term, security concerns
>
> I am sorry for not reading the thread to the last message. Maybe a release
> then?
>
>
>
> On Tue, Jul 20, 2021 at 12:39 PM Gabriel Gruber <
> gabriel.gruber@workflow.at> wrote:
>
> Hi Vincent,
>
>
>
> We at Workflow are also still using Cocoon 2.2 as part of our main product
> and are running it with Java 11 and Tomcat 9 on Windows and Linux OSes. In
> the past we did not see any major problem with cocoon which were not
> solvable. From a security perspective maybe the biggest thread was a
> directory traversal opportunity if you would use ResourceReader cocoon
> component in the wrong way allowing users to use the /.. in
> URL/request-parameters being forwarded to the path of the resource to be
> read in order to traverse the directory of the deployment.
>
>
>
> Latest Cocoon 2.2 trunk is also compatible with Spring 4.x by the way.
>
>
>
> Cheers,
>
> Gabriel Gruber
>
> www.workflow.at
>
>
>
>
>
> *Von:* Vincent Neyt <vi...@gmail.com>
> *Gesendet:* Dienstag, 20. Juli 2021 12:28
> *An:* users@cocoon.apache.org
> *Betreff:* Re: using cocoon 2.1 in the long-term, security concerns
>
>
>
> Thank you very much Warrell, Cédric, Greg and Chris.
>
>
>
> I'm happy to hear that you believe Cocoon poses a very low security risk
> as long as Tomcat and Java are up to date, and that Cocoon should continue
> to work well with future versions of T & J as long as the dependency
> libraries in Cocoon are updated. (At least until Tomcat 9 is no longer
> supported.)
>
>
>
> best wishes,
>
> Vincent
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Jul 19, 2021 at 6:35 PM Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
> Vincent,
>
> On 7/19/21 08:03, Vincent Neyt wrote:
> > Hi Cocoon users,
> >
> > I'd like to ask your opinion on the long-term security risks of running
> > Cocoon on a server. The colleague responsible for the servers at my
> > university is inquiring if the software I'm using for my website is up
> > to date and is concerned that I'm using outdated software that could in
> > the future pose a security risk.
> >
> > I'm using cocoon 2.1.11, which I could probably upgrade to 2.1.13
> > without many problems. But I'm concerned about the long-term, and
> > wondering if it would perhaps be better to reprogram the website I've
> > been working on for 10 years into eXist DB (which would be a huge time
> > investment). I like cocoon very much and would love to continue using it
> > if it's possible.
> >
> > I'm curious to hear your thoughts about using Cocoon 2.1 for the long
> > term: will it still work well inside future versions of servlet
> > containers like Tomcat? What about the java dependencies? And will
> > cocoon 2.1 continue to put out updates when security risks are
> identified?
>
> I, like you, have been running Cocoon 2.1.x for years and would like to
> continue to rely on it for some important functions at $work.
>
> I don't see any reason it wouldn't run on current and future Tomcat
> versions. There are a few "current" versions of Tomcat, and the only one
> I would expect to have some issues would be the Tomcat 10.x series,
> which implement the "Jakarta EE" specifications instead of the "Java EE"
> specifications. For the most part, these specifications are simply
> package-renamed versions of the original Java EE specs. So, for example,
> javax.servlet.whatever becomes jakarta.servlet.whatever and so on.
>
> Tomcat has a migration tool which can migrate a binary web application
> (e.g. WAR file) from Java EE to Jakarta EE. It would be good to know if
> that tool works on a webapp which is Cocoon itself and/or
> Cocoon-bundled-with-your-application.
>
> I'm a Tomcat committer and if there are any problems, we could work
> together to make sure Cocoon has plenty of life left in it.
>
> With the semi-recent release of Cocoon 2.2, are there members of the
> community who would be interested in converting the project into a
> Jakarta EE-based project? There is no particular rush, and most of the
> conversion can be done essentially with a single sed script. But working
> that into the build process so you can say "build me a Java EE-based
> Cocoon" versus "build me a Jakarta EE-based Cocoon" would be really
> beneficial moving into the future.
>
> [As a Cocoon user, I'd love to know what is necessary to upgrade from
> Cocoon 2.1 to 2.2. We have an ant-based build process for our
> application which starts with a pre-built cocoon.war and customizes it
> with everything we need. So if e.g. Maven can build Cocoon into a WAR
> file, I might be all set.]
>
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
Re: using cocoon 2.1 in the long-term, security concerns
Posted by Gabriel Gruber <ga...@workflow.at>.
Hi Leszak,
Yeah, a release would be nice – Fix version 2.2.1 was stated in this ticket https://issues.apache.org/jira/browse/COCOON-2347
But was never released though…
Cheers,
Gabriel
From: Leszek Gawron <ou...@wlkp.org>
Date: Friday, 30. July 2021 at 10:35
To: users@cocoon.apache.org <us...@cocoon.apache.org>
Subject: Re: using cocoon 2.1 in the long-term, security concerns
I am sorry for not reading the thread to the last message. Maybe a release then?
On Tue, Jul 20, 2021 at 12:39 PM Gabriel Gruber <ga...@workflow.at>> wrote:
Hi Vincent,
We at Workflow are also still using Cocoon 2.2 as part of our main product and are running it with Java 11 and Tomcat 9 on Windows and Linux OSes. In the past we did not see any major problem with cocoon which were not solvable. From a security perspective maybe the biggest thread was a directory traversal opportunity if you would use ResourceReader cocoon component in the wrong way allowing users to use the /.. in URL/request-parameters being forwarded to the path of the resource to be read in order to traverse the directory of the deployment.
Latest Cocoon 2.2 trunk is also compatible with Spring 4.x by the way.
Cheers,
Gabriel Gruber
www.workflow.at<http://www.workflow.at>
Von: Vincent Neyt <vi...@gmail.com>>
Gesendet: Dienstag, 20. Juli 2021 12:28
An: users@cocoon.apache.org<ma...@cocoon.apache.org>
Betreff: Re: using cocoon 2.1 in the long-term, security concerns
Thank you very much Warrell, Cédric, Greg and Chris.
I'm happy to hear that you believe Cocoon poses a very low security risk as long as Tomcat and Java are up to date, and that Cocoon should continue to work well with future versions of T & J as long as the dependency libraries in Cocoon are updated. (At least until Tomcat 9 is no longer supported.)
best wishes,
Vincent
On Mon, Jul 19, 2021 at 6:35 PM Christopher Schultz <ch...@christopherschultz.net>> wrote:
Vincent,
On 7/19/21 08:03, Vincent Neyt wrote:
> Hi Cocoon users,
>
> I'd like to ask your opinion on the long-term security risks of running
> Cocoon on a server. The colleague responsible for the servers at my
> university is inquiring if the software I'm using for my website is up
> to date and is concerned that I'm using outdated software that could in
> the future pose a security risk.
>
> I'm using cocoon 2.1.11, which I could probably upgrade to 2.1.13
> without many problems. But I'm concerned about the long-term, and
> wondering if it would perhaps be better to reprogram the website I've
> been working on for 10 years into eXist DB (which would be a huge time
> investment). I like cocoon very much and would love to continue using it
> if it's possible.
>
> I'm curious to hear your thoughts about using Cocoon 2.1 for the long
> term: will it still work well inside future versions of servlet
> containers like Tomcat? What about the java dependencies? And will
> cocoon 2.1 continue to put out updates when security risks are identified?
I, like you, have been running Cocoon 2.1.x for years and would like to
continue to rely on it for some important functions at $work.
I don't see any reason it wouldn't run on current and future Tomcat
versions. There are a few "current" versions of Tomcat, and the only one
I would expect to have some issues would be the Tomcat 10.x series,
which implement the "Jakarta EE" specifications instead of the "Java EE"
specifications. For the most part, these specifications are simply
package-renamed versions of the original Java EE specs. So, for example,
javax.servlet.whatever becomes jakarta.servlet.whatever and so on.
Tomcat has a migration tool which can migrate a binary web application
(e.g. WAR file) from Java EE to Jakarta EE. It would be good to know if
that tool works on a webapp which is Cocoon itself and/or
Cocoon-bundled-with-your-application.
I'm a Tomcat committer and if there are any problems, we could work
together to make sure Cocoon has plenty of life left in it.
With the semi-recent release of Cocoon 2.2, are there members of the
community who would be interested in converting the project into a
Jakarta EE-based project? There is no particular rush, and most of the
conversion can be done essentially with a single sed script. But working
that into the build process so you can say "build me a Java EE-based
Cocoon" versus "build me a Jakarta EE-based Cocoon" would be really
beneficial moving into the future.
[As a Cocoon user, I'd love to know what is necessary to upgrade from
Cocoon 2.1 to 2.2. We have an ant-based build process for our
application which starts with a pre-built cocoon.war and customizes it
with everything we need. So if e.g. Maven can build Cocoon into a WAR
file, I might be all set.]
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org<ma...@cocoon.apache.org>
For additional commands, e-mail: users-help@cocoon.apache.org<ma...@cocoon.apache.org>
Re: using cocoon 2.1 in the long-term, security concerns
Posted by Leszek Gawron <ou...@wlkp.org>.
I am sorry for not reading the thread to the last message. Maybe a release
then?
On Tue, Jul 20, 2021 at 12:39 PM Gabriel Gruber <ga...@workflow.at>
wrote:
> Hi Vincent,
>
>
>
> We at Workflow are also still using Cocoon 2.2 as part of our main product
> and are running it with Java 11 and Tomcat 9 on Windows and Linux OSes. In
> the past we did not see any major problem with cocoon which were not
> solvable. From a security perspective maybe the biggest thread was a
> directory traversal opportunity if you would use ResourceReader cocoon
> component in the wrong way allowing users to use the /.. in
> URL/request-parameters being forwarded to the path of the resource to be
> read in order to traverse the directory of the deployment.
>
>
>
> Latest Cocoon 2.2 trunk is also compatible with Spring 4.x by the way.
>
>
>
> Cheers,
>
> Gabriel Gruber
>
> www.workflow.at
>
>
>
>
>
> *Von:* Vincent Neyt <vi...@gmail.com>
> *Gesendet:* Dienstag, 20. Juli 2021 12:28
> *An:* users@cocoon.apache.org
> *Betreff:* Re: using cocoon 2.1 in the long-term, security concerns
>
>
>
> Thank you very much Warrell, Cédric, Greg and Chris.
>
>
>
> I'm happy to hear that you believe Cocoon poses a very low security risk
> as long as Tomcat and Java are up to date, and that Cocoon should continue
> to work well with future versions of T & J as long as the dependency
> libraries in Cocoon are updated. (At least until Tomcat 9 is no longer
> supported.)
>
>
>
> best wishes,
>
> Vincent
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Jul 19, 2021 at 6:35 PM Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
> Vincent,
>
> On 7/19/21 08:03, Vincent Neyt wrote:
> > Hi Cocoon users,
> >
> > I'd like to ask your opinion on the long-term security risks of running
> > Cocoon on a server. The colleague responsible for the servers at my
> > university is inquiring if the software I'm using for my website is up
> > to date and is concerned that I'm using outdated software that could in
> > the future pose a security risk.
> >
> > I'm using cocoon 2.1.11, which I could probably upgrade to 2.1.13
> > without many problems. But I'm concerned about the long-term, and
> > wondering if it would perhaps be better to reprogram the website I've
> > been working on for 10 years into eXist DB (which would be a huge time
> > investment). I like cocoon very much and would love to continue using it
> > if it's possible.
> >
> > I'm curious to hear your thoughts about using Cocoon 2.1 for the long
> > term: will it still work well inside future versions of servlet
> > containers like Tomcat? What about the java dependencies? And will
> > cocoon 2.1 continue to put out updates when security risks are
> identified?
>
> I, like you, have been running Cocoon 2.1.x for years and would like to
> continue to rely on it for some important functions at $work.
>
> I don't see any reason it wouldn't run on current and future Tomcat
> versions. There are a few "current" versions of Tomcat, and the only one
> I would expect to have some issues would be the Tomcat 10.x series,
> which implement the "Jakarta EE" specifications instead of the "Java EE"
> specifications. For the most part, these specifications are simply
> package-renamed versions of the original Java EE specs. So, for example,
> javax.servlet.whatever becomes jakarta.servlet.whatever and so on.
>
> Tomcat has a migration tool which can migrate a binary web application
> (e.g. WAR file) from Java EE to Jakarta EE. It would be good to know if
> that tool works on a webapp which is Cocoon itself and/or
> Cocoon-bundled-with-your-application.
>
> I'm a Tomcat committer and if there are any problems, we could work
> together to make sure Cocoon has plenty of life left in it.
>
> With the semi-recent release of Cocoon 2.2, are there members of the
> community who would be interested in converting the project into a
> Jakarta EE-based project? There is no particular rush, and most of the
> conversion can be done essentially with a single sed script. But working
> that into the build process so you can say "build me a Java EE-based
> Cocoon" versus "build me a Jakarta EE-based Cocoon" would be really
> beneficial moving into the future.
>
> [As a Cocoon user, I'd love to know what is necessary to upgrade from
> Cocoon 2.1 to 2.2. We have an ant-based build process for our
> application which starts with a pre-built cocoon.war and customizes it
> with everything we need. So if e.g. Maven can build Cocoon into a WAR
> file, I might be all set.]
>
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
AW: using cocoon 2.1 in the long-term, security concerns
Posted by Gabriel Gruber <ga...@workflow.at>.
Hi Vincent,
We at Workflow are also still using Cocoon 2.2 as part of our main product and are running it with Java 11 and Tomcat 9 on Windows and Linux OSes. In the past we did not see any major problem with cocoon which were not solvable. From a security perspective maybe the biggest thread was a directory traversal opportunity if you would use ResourceReader cocoon component in the wrong way allowing users to use the /.. in URL/request-parameters being forwarded to the path of the resource to be read in order to traverse the directory of the deployment.
Latest Cocoon 2.2 trunk is also compatible with Spring 4.x by the way.
Cheers,
Gabriel Gruber
www.workflow.at
Von: Vincent Neyt <vi...@gmail.com>
Gesendet: Dienstag, 20. Juli 2021 12:28
An: users@cocoon.apache.org
Betreff: Re: using cocoon 2.1 in the long-term, security concerns
Thank you very much Warrell, Cédric, Greg and Chris.
I'm happy to hear that you believe Cocoon poses a very low security risk as long as Tomcat and Java are up to date, and that Cocoon should continue to work well with future versions of T & J as long as the dependency libraries in Cocoon are updated. (At least until Tomcat 9 is no longer supported.)
best wishes,
Vincent
On Mon, Jul 19, 2021 at 6:35 PM Christopher Schultz <ch...@christopherschultz.net>> wrote:
Vincent,
On 7/19/21 08:03, Vincent Neyt wrote:
> Hi Cocoon users,
>
> I'd like to ask your opinion on the long-term security risks of running
> Cocoon on a server. The colleague responsible for the servers at my
> university is inquiring if the software I'm using for my website is up
> to date and is concerned that I'm using outdated software that could in
> the future pose a security risk.
>
> I'm using cocoon 2.1.11, which I could probably upgrade to 2.1.13
> without many problems. But I'm concerned about the long-term, and
> wondering if it would perhaps be better to reprogram the website I've
> been working on for 10 years into eXist DB (which would be a huge time
> investment). I like cocoon very much and would love to continue using it
> if it's possible.
>
> I'm curious to hear your thoughts about using Cocoon 2.1 for the long
> term: will it still work well inside future versions of servlet
> containers like Tomcat? What about the java dependencies? And will
> cocoon 2.1 continue to put out updates when security risks are identified?
I, like you, have been running Cocoon 2.1.x for years and would like to
continue to rely on it for some important functions at $work.
I don't see any reason it wouldn't run on current and future Tomcat
versions. There are a few "current" versions of Tomcat, and the only one
I would expect to have some issues would be the Tomcat 10.x series,
which implement the "Jakarta EE" specifications instead of the "Java EE"
specifications. For the most part, these specifications are simply
package-renamed versions of the original Java EE specs. So, for example,
javax.servlet.whatever becomes jakarta.servlet.whatever and so on.
Tomcat has a migration tool which can migrate a binary web application
(e.g. WAR file) from Java EE to Jakarta EE. It would be good to know if
that tool works on a webapp which is Cocoon itself and/or
Cocoon-bundled-with-your-application.
I'm a Tomcat committer and if there are any problems, we could work
together to make sure Cocoon has plenty of life left in it.
With the semi-recent release of Cocoon 2.2, are there members of the
community who would be interested in converting the project into a
Jakarta EE-based project? There is no particular rush, and most of the
conversion can be done essentially with a single sed script. But working
that into the build process so you can say "build me a Java EE-based
Cocoon" versus "build me a Jakarta EE-based Cocoon" would be really
beneficial moving into the future.
[As a Cocoon user, I'd love to know what is necessary to upgrade from
Cocoon 2.1 to 2.2. We have an ant-based build process for our
application which starts with a pre-built cocoon.war and customizes it
with everything we need. So if e.g. Maven can build Cocoon into a WAR
file, I might be all set.]
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org<ma...@cocoon.apache.org>
For additional commands, e-mail: users-help@cocoon.apache.org<ma...@cocoon.apache.org>
Re: using cocoon 2.1 in the long-term, security concerns
Posted by Vincent Neyt <vi...@gmail.com>.
Thank you very much Warrell, Cédric, Greg and Chris.
I'm happy to hear that you believe Cocoon poses a very low security risk as
long as Tomcat and Java are up to date, and that Cocoon should continue to
work well with future versions of T & J as long as the dependency libraries
in Cocoon are updated. (At least until Tomcat 9 is no longer supported.)
best wishes,
Vincent
On Mon, Jul 19, 2021 at 6:35 PM Christopher Schultz <
chris@christopherschultz.net> wrote:
> Vincent,
>
> On 7/19/21 08:03, Vincent Neyt wrote:
> > Hi Cocoon users,
> >
> > I'd like to ask your opinion on the long-term security risks of running
> > Cocoon on a server. The colleague responsible for the servers at my
> > university is inquiring if the software I'm using for my website is up
> > to date and is concerned that I'm using outdated software that could in
> > the future pose a security risk.
> >
> > I'm using cocoon 2.1.11, which I could probably upgrade to 2.1.13
> > without many problems. But I'm concerned about the long-term, and
> > wondering if it would perhaps be better to reprogram the website I've
> > been working on for 10 years into eXist DB (which would be a huge time
> > investment). I like cocoon very much and would love to continue using it
> > if it's possible.
> >
> > I'm curious to hear your thoughts about using Cocoon 2.1 for the long
> > term: will it still work well inside future versions of servlet
> > containers like Tomcat? What about the java dependencies? And will
> > cocoon 2.1 continue to put out updates when security risks are
> identified?
>
> I, like you, have been running Cocoon 2.1.x for years and would like to
> continue to rely on it for some important functions at $work.
>
> I don't see any reason it wouldn't run on current and future Tomcat
> versions. There are a few "current" versions of Tomcat, and the only one
> I would expect to have some issues would be the Tomcat 10.x series,
> which implement the "Jakarta EE" specifications instead of the "Java EE"
> specifications. For the most part, these specifications are simply
> package-renamed versions of the original Java EE specs. So, for example,
> javax.servlet.whatever becomes jakarta.servlet.whatever and so on.
>
> Tomcat has a migration tool which can migrate a binary web application
> (e.g. WAR file) from Java EE to Jakarta EE. It would be good to know if
> that tool works on a webapp which is Cocoon itself and/or
> Cocoon-bundled-with-your-application.
>
> I'm a Tomcat committer and if there are any problems, we could work
> together to make sure Cocoon has plenty of life left in it.
>
> With the semi-recent release of Cocoon 2.2, are there members of the
> community who would be interested in converting the project into a
> Jakarta EE-based project? There is no particular rush, and most of the
> conversion can be done essentially with a single sed script. But working
> that into the build process so you can say "build me a Java EE-based
> Cocoon" versus "build me a Jakarta EE-based Cocoon" would be really
> beneficial moving into the future.
>
> [As a Cocoon user, I'd love to know what is necessary to upgrade from
> Cocoon 2.1 to 2.2. We have an ant-based build process for our
> application which starts with a pre-built cocoon.war and customizes it
> with everything we need. So if e.g. Maven can build Cocoon into a WAR
> file, I might be all set.]
>
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
Re: using cocoon 2.1 in the long-term, security concerns
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Vincent,
On 7/19/21 08:03, Vincent Neyt wrote:
> Hi Cocoon users,
>
> I'd like to ask your opinion on the long-term security risks of running
> Cocoon on a server. The colleague responsible for the servers at my
> university is inquiring if the software I'm using for my website is up
> to date and is concerned that I'm using outdated software that could in
> the future pose a security risk.
>
> I'm using cocoon 2.1.11, which I could probably upgrade to 2.1.13
> without many problems. But I'm concerned about the long-term, and
> wondering if it would perhaps be better to reprogram the website I've
> been working on for 10 years into eXist DB (which would be a huge time
> investment). I like cocoon very much and would love to continue using it
> if it's possible.
>
> I'm curious to hear your thoughts about using Cocoon 2.1 for the long
> term: will it still work well inside future versions of servlet
> containers like Tomcat? What about the java dependencies? And will
> cocoon 2.1 continue to put out updates when security risks are identified?
I, like you, have been running Cocoon 2.1.x for years and would like to
continue to rely on it for some important functions at $work.
I don't see any reason it wouldn't run on current and future Tomcat
versions. There are a few "current" versions of Tomcat, and the only one
I would expect to have some issues would be the Tomcat 10.x series,
which implement the "Jakarta EE" specifications instead of the "Java EE"
specifications. For the most part, these specifications are simply
package-renamed versions of the original Java EE specs. So, for example,
javax.servlet.whatever becomes jakarta.servlet.whatever and so on.
Tomcat has a migration tool which can migrate a binary web application
(e.g. WAR file) from Java EE to Jakarta EE. It would be good to know if
that tool works on a webapp which is Cocoon itself and/or
Cocoon-bundled-with-your-application.
I'm a Tomcat committer and if there are any problems, we could work
together to make sure Cocoon has plenty of life left in it.
With the semi-recent release of Cocoon 2.2, are there members of the
community who would be interested in converting the project into a
Jakarta EE-based project? There is no particular rush, and most of the
conversion can be done essentially with a single sed script. But working
that into the build process so you can say "build me a Java EE-based
Cocoon" versus "build me a Jakarta EE-based Cocoon" would be really
beneficial moving into the future.
[As a Cocoon user, I'd love to know what is necessary to upgrade from
Cocoon 2.1 to 2.2. We have an ant-based build process for our
application which starts with a pre-built cocoon.war and customizes it
with everything we need. So if e.g. Maven can build Cocoon into a WAR
file, I might be all set.]
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org