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 <gabriel.gru...@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 <o...@wlkp.org> > *Date: *Friday, 30. July 2021 at 10:35 > *To: *users@cocoon.apache.org <users@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.gru...@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 <vincent.n...@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-unsubscr...@cocoon.apache.org > For additional commands, e-mail: users-h...@cocoon.apache.org > >