Hi all, I see your point, David. If we announce something EOL (which is quite a „hard“ thing in terms of the ASF), we might loose potential volunteers, who might want to maintain and contribute by patching and/or fixing 3rd party vulnerabilities by forking.
I like the idea of labeling something „inactive“ in terms of development accompied by some sort of explanation in an info box on the website. I would call it Option (F). For example, something like: „Please note: There is no active development or maintenance for the 7.1.x branch of TomEE, i.e. releases from the 7.1.x branch are very unlikely, bugs exclusive to these versions are not actively fixed, and security vulnerability reports will not be checked against the 7.1.x branch. If you depend on 7.1.x, consider upgrading to 8.0.x or 9.0.x. If this is not possible, we are open for contributors / volunteers to maintain the 7.1.x“ Then, we link to a new page where we explain how it works (cross- references to the contribution pages and some others like commercial support, etc.) and list our requirements regarding CVEs fixes. If we decide to go this route, I can setup a draft for discussion. The „cool“ thing of „inactive“ would be, that if someone steps up and volunteers to maintain an older version, we can give them a try and do a release, if we feel comfortable with it. Regarding „policies“: Afaik some other projects tend to have a policy like „we maintain 2 – 3 versions in parallel“. Do we need something similar in order to mark some version branch as „inactive“ or do we want to do it on a „per version“ basis without being bound to some policy? While I also like the endoflife.date website, it might be a bit difficult for TomEE to determine concrete dates without having some sort of policy in place. Gruß Richard Am Mittwoch, dem 03.08.2022 um 08:59 +0200 schrieb Swell: > Hi. > > I often use website like > https://endoflife.date/tomcat to know if I really must upgrade. Very > useful > to know the status of projects. I feel I’m not the only one using it > and > people could have a use for TomEE out there, let it be marked as EOL > or > inactive. > > Swell > > > On Wed 3 Aug 2022 at 08:48, Jean-Louis Monteiro < > jlmonte...@tomitribe.com> > wrote: > > > Yeah if users want to maintain and fix third party libraries, I'm > > fine with > > that and I'm also fine to do a release when it's ok. > > > > Inactive is fine. We just need to find something and document it on > > our > > website. > > -- > > Jean-Louis Monteiro > > http://twitter.com/jlouismonteiro > > http://www.tomitribe.com > > > > > > On Tue, Aug 2, 2022 at 10:06 PM David Blevins < > > dblev...@tomitribe.com> > > wrote: > > > > > How about a simple “inactive” label? > > > > > > -David > > > > > > On Tue, Aug 2, 2022 at 2:41 PM David Blevins < > > > david.blev...@gmail.com> > > > wrote: > > > > > > > My personal perspective is that if there are people who want to > > > > focus > > > their > > > > time on 7.1.x (option B), I’m happy to let them. They would > > > > need to > > do a > > > > complete job however (I.e. not option A). > > > > > > > > That said, if I had to do the work it’d be option C, D, or E. > > > > > > > > My discomfort with labeling something EOL is i1) t strongly > > > > implies we > > > > would reject offers to maintain the release and 2) it implies > > > > we know > > in > > > > advance there will be no contributions. > > > > > > > > For example say we had a vote to EOL a branch and the vote was > > > > not > > > > unanimous. IMHO there’s no harm in letting the person who voted > > > > -1 > > have a > > > > shot at maintaining the branch/release. That also doesn’t mean > > > > we can > > > > obligate the volunteer to contribute and produce releases on a > > particular > > > > schedule or even guarantee they produce future releases at all. > > > > > > > > That said I do see value in letting users know contributions > > > > are not > > > > happening on a particular release. One could argue the release > > > > date > > does > > > > that. But if we want to be more clear say after a year of no > > > > releases > > we > > > > put a label on it that says contributions are not happening, > > > > but they > > > would > > > > be welcome. Maybe that label is a link to a page that says > > > > “you’re > > > welcome > > > > to maintain it”, but also makes it clear you’d have to > > > > completely patch > > > it > > > > as we don’t like to release things with several CVEs in there. > > > > > > > > Brainstorming. > > > > > > > > > > > > All this said, if people vote B can you also state if you > > > > intend to > > > > contribute towards that goal. If we get several votes for B, > > > > but no > > > actual > > > > volunteers to work on B clearly B is not actually an option. > > > > > > > > -David > > > > > > > > On Tue, Aug 2, 2022 at 1:19 PM Richard Zowalla <r...@apache.org > > > > > > > wrote: > > > > > Hi all, > > > > > > > > > > thanks for the thread, JL! Sorry, a bit longer than > > > > > anticipated ;) > > > > > > > > > > As promised in the other thread, I took a look at the grype > > > > > scan > > > > > results. While were are many false positives (mostly related > > > > > to the > > > > > Geronimo specs and ActiveMQ), there are indeed some CVEs of > > > > > interest: > > > > > > > > > > - cxf > > > > > - tomcat (will be fixed in the next tomcat release) > > > > > - xmlsec (should most likely be possible to update) > > > > > - jackson-databind (should most likely be possible to update) > > > > > > > > > > Imho, the most important ones originate from cxf 3.1.18 for > > > > > which we > > > > > won’t get patches anymore, i.e. we would need to fork, > > > > > backport the > > > > > relevant CVE fixes and release it as shaded dependency within > > > > > TomEE. > > > > > > > > > > I think the main issue arises from the fact, that we never > > communicated > > > > > or announced some sort of EOL statement for any of the older > > > > > branches > > > > > (1.7.x, 7.0.x or 7.1.x) like it is done for example for > > > > > Tomcat [1]. > > > > > > > > > > The silent reader or the wise developer will know, that no > > > > > release > > > > > withing the last two years most certainly means eol for the > > respective > > > > > series but there will be a (perhaps rather small) community > > > > > of people > > > > > waiting for a release while running with their vulnerable > > > > > TomEE for > > > > > the last years. > > > > > > > > > > Therefore, I see the following options (no ordering, no > > > > > preferences, > > > > > just a listing): > > > > > > > > > > #### > > > > > > > > > > ## Option (A) > > > > > > > > > > We decide to do a release without patching the known CXF CVEs > > > > > and > > > > > announce the EOL of the 7.1.x series in a similar manner as > > > > > it done > > in > > > > > Tomcat [1]. > > > > > > > > > > In this announcement, we state that security vulnerability > > > > > reports > > will > > > > > not be checked against the 7.1.x branch, bugs affecting only > > > > > the > > 7.1.x > > > > > branch will not be addressed and releases of the 7.1.x branch > > > > > are > > > > > highly unlikely. After a certain grace period, we remove the > > > > > 7.1.x > > > > > download links, the documentation from the website and the > > > > > artifacts > > > > > from the cdn. Note, that all 7.1.x releases will always be > > > > > available > > > > > from the archive. > > > > > > > > > > ## Option (B) > > > > > > > > > > We decide to do a release, patch the known CXF CVEs by > > > > > forking CXF > > and > > > > > release it as shaded dependency within TomEE. Subsequently, > > > > > we > > announce > > > > > the EOL of the 7.1.x similar to option (A). > > > > > > > > > > ## Option (C) > > > > > > > > > > We decide, that 7.1.4 from 2020 was the final release of the > > > > > 7.1.x > > > > > series. Subsequently, we announce the EOL of the 7.1.x > > > > > similar to > > > > > option (A). > > > > > > > > > > ## Option (D) > > > > > > > > > > We don’t release a new version of the 7.1.x series and do not > > announce > > > > > any sort of EOL statement (status quo). We agree to not put > > > > > much > > effort > > > > > into the 7.1.x series and stop maintaining it. > > > > > > > > > > ## Option (E) > > > > > > > > > > We don’t release a new version of the 7.1.x series and do not > > announce > > > > > any sort of EOL statement (status quo). We agree to not put > > > > > much > > effort > > > > > into the 7.1.x series and stop maintaining it. To avoid user > > confusion, > > > > > we remove the download links, the documentation and the > > > > > artifacts > > from > > > > > the cdn but all 7.1.x release will always be available from > > > > > the > > > > > archive. > > > > > > > > > > ## Option (F) – (Z) > > > > > > > > > > » Your Input Here « > > > > > > > > > > #### > > > > > > > > > > Perhaps there are other options as well, but that are the > > > > > ones, which > > > > > directly went into my mind while thinking about it. A similar > > > > > discussion needs to be done for 1.7.x and 7.0.x if we find > > > > > some > > > > > consensus for the 7.1.x series. > > > > > > > > > > I am a bit torn apart in this discussion. On the one hand, I > > > > > am > > > > > thinking: “Hey, we somehow “owe” the community one last > > > > > release > > before > > > > > declaring it eol and stop maintaining it”. On the other hand, > > > > > this > > > > > rational could also be used as an excuse to ask for a “last” > > > > > 7.0.x > > or a > > > > > “last” 1.7.x. > > > > > > > > > > I agree, that releasing a TomEE 7.1.5 with known CXF > > > > > vulnerabilities > > > > > isn’t really desirable and we cannot maintain 3rd party libs > > > > > indefinitely. We might be better in investing resources in > > > > > 8.0.x and > > a > > > > > stable 9.0.x release in order to later shift our attention to > > > > > EE10 ;) > > > > > > > > > > Gruß > > > > > Richard > > > > > > > > > > > > > > > > > > > > [1] https://tomcat.apache.org/tomcat-80-eol.html > > > > > > > > > > > > > > > Am Dienstag, dem 02.08.2022 um 16:07 +0200 schrieb Jean-Louis > > Monteiro: > > > > > > Hi all, > > > > > > > > > > > > Don't want to hijack the other thread, so starting a new > > > > > > one based > > on > > > > > > the > > > > > > discussion. > > > > > > > > > > > > I don't think releasing a "last 7.1.x" version with CVEs > > > > > > would be > > of > > > > > > > any good > > > > > > > > > > > > I join Alex on this one. Does it really make sense to > > > > > > release a > > TomEE > > > > > > app > > > > > > server with known CVEs? > > > > > > > > > > > > I'm not arguing on the grype output and the validity or not > > > > > > of the > > > > > > report. > > > > > > But overall, we do have EOL libraries in there and we know > > > > > > we won't > > > > > > get > > > > > > patches even for CVEs for CXF and other libraries. > > > > > > > > > > > > > @Alex Thanks. We might not be able to address all CVEs as > > > > > > > some of > > > > > > > the > > > > > > libs used for EE7 aren't patched / updated anymore. I will > > > > > > have a > > > > > > look. > > > > > > > > > > > > This is also your point Richard. > > > > > > > > > > > > Based on this, does it mean we should call 7.1.x EOL and > > > > > > stop > > > > > > producing > > > > > > releases? > > > > > > The path to TomEE 8.x is pretty straightforward and > > > > > > backward > > > > > > compatible so > > > > > > it's not like moving from 8.x to 9.x. > > > > > > > > > > > > What do you think? > > > > > > > > > > > > -- > > > > > > Jean-Louis Monteiro > > > > > > http://twitter.com/jlouismonteiro > > > > > > http://www.tomitribe.com > > > > > > > > > > > > > > > > > > ---------- Forwarded message --------- > > > > > > From: Zowalla, Richard <richard.zowa...@hs-heilbronn.de> > > > > > > Date: Tue, Aug 2, 2022 at 3:48 PM > > > > > > Subject: [CANCEL] [VOTE] Apache TomEE 7.1.5 > > > > > > To: dev@tomee.apache.org <dev@tomee.apache.org> > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > thanks for the concerns raised. Better to check the CVE > > > > > > report and > > do > > > > > > a > > > > > > re-roll ;-) > > > > > > > > > > > > @JL: Will take a look. > > > > > > > > > > > > @Alex Thanks. We might not be able to address all CVEs as > > > > > > some of > > the > > > > > > libs > > > > > > used for EE7 aren't patched / updated anymore. I will have > > > > > > a look. > > > > > > > > > > > > Gruß > > > > > > Richard > > > > > > ________________________________ > > > > > > Von: Jean-Louis Monteiro <jlmonte...@tomitribe.com> > > > > > > Gesendet: Dienstag, 2. August 2022 15:30:31 > > > > > > An: dev@tomee.apache.org > > > > > > Betreff: Re: [VOTE] Apache TomEE 7.1.5 > > > > > > > > > > > > -1 (binding) > > > > > > > > > > > > Something went bad during the release. Looks like our libs > > > > > > are > > still > > > > > > 1.7.5-SNAPSHOT. > > > > > > -- > > > > > > Jean-Louis Monteiro > > > > > > http://twitter.com/jlouismonteiro > > > > > > http://www.tomitribe.com > > > > > > > > > > > > > > > > > > On Tue, Aug 2, 2022 at 2:37 PM Alex The Rocker < > > alex.m3...@gmail.com > > > > > > wrote: > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > [-1] (non binding) > > > > > > > > > > > > > > Indeed, I downloaded TomEE+ 7.1.5 binary (from > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/dev/tomee/staging-1206/tomee-7.1.5/apache-tomee-7.1.5-plus.tar.gz > > > > > > > ) > > > > > > > and then I ran Grype (https://github.com/anchore/grype) > > > > > > > on > > > TomEE+'s > > > > > > > archive extract directory. > > > > > > > > > > > > > > That gives 2 Critical and 125 High CVEs (see attached > > > > > > > Grype > > output > > > > > > > for > > > > > > > this scan). > > > > > > > > > > > > > > I agree with whoever will say that Grype isn't quite > > > > > > > smart, but > > > > > > > nevertheless the world is now paranoid with security > > > > > > > matter. > > > > > > > > > > > > > > I don't think releasing a "last 7.1.x" version with CVEs > > > > > > > would be > > > > > > > of > > > > > > > any good, so Grype's output is all false positive, then > > > > > > > at least > > we > > > > > > > need a statement to avoid confusion in this page: > > > > > > > https://tomee.apache.org/security/tomee.html > > > > > > > > > > > > > > Please also note in attached Grype output the Warning > > > > > > > lines > > related > > > > > > > to > > > > > > > archive-xbean-asm6-shaded-4.8.jar: isn't that showing a > > > > > > > somehow > > > > > > > malformed MANIFEST ? > > > > > > > > > > > > > > Thanks, > > > > > > > Alex > > > > > > > > > > > > > > Le lun. 1 août 2022 à 19:35, Richard Zowalla < > > > > > > > r...@apache.org> a > > > > > > > écrit : > > > > > > > > Hi all, > > > > > > > > > > > > > > > > this is a first attempt at a vote for a release of > > > > > > > > Apache TomEE > > > > > > > > 7.1.5 > > > > > > > > > > > > > > > > It is a maintenance release with some bug fixes and > > dependencies > > > > > > > > upgrades for which were was some interest on the list. > > > > > > > > > > > > > > > > Yet, a discussion, if this will be the last release of > > > > > > > > the > > 7.1.x > > > > > > > > series, is pending. > > > > > > > > > > > > > > > > Here are some infos: > > > > > > > > > > > > > > > > Maven Repo: > > > > > > > > > > https://repository.apache.org/content/repositories/orgapachetomee-1206 > > > > > > > > <repositories> > > > > > > > > <repository> > > > > > > > > <id>tomee-7.1.5-release-test</id> > > > > > > > > <name>Testing TomEE 7.1.5 release > > > > > > > > candidate</name> > > > > > > > > <url> > > > > > > > > > > https://repository.apache.org/content/repositories/orgapachetomee-1206 > > > > > > > > </url> > > > > > > > > </repository> > > > > > > > > </repositories> > > > > > > > > > > > > > > > > > > > > > > > > Binaries & Source: > > > > > > > > https://dist.apache.org/repos/dist/dev/tomee/staging-1206/ > > > > > > > > > > > > > > > > Tag: > > > > > > > > https://github.com/apache/tomee/tree/tomee-project-7.1.5 > > > > > > > > > > > > > > > > Latest (green) CI/CD build: > > > > > > > > > > > > > > > > https://ci-builds.apache.org/job/Tomee/job/tomee-7.1.x/19/ > > > > > > > > > > > > > > > > Release notes: > > > > > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320&version=12349482 > > > > > > > > Here is an adoc generated version of the changelog as > > > > > > > > well: > > > > > > > > > > > > > > > > > > > > > > > > == Dependency upgrade > > > > > > > > > > > > > > > > [.compact] > > > > > > > > - link: > > > > > > > > https://issues.apache.org/jira/browse/TOMEE-2959[TOMEE-959]2 > > j > > > > > > > > ackson 2.12.0 > > > > > > > > - link: > > > > > > > > https://issues.apache.org/jira/browse/TOMEE-3941[TOMEE-3941] > > > > > > > > ActiveMQ 5.16.5 > > > > > > > > - link: > > > > > > > > https://issues.apache.org/jira/browse/TOMEE-3985[TOMEE-3985] > > > > > > > > BatchEE 1.0.2 > > > > > > > > - link: > > > > > > > > https://issues.apache.org/jira/browse/TOMEE-3772[TOMEE-3772] > > > > > > > > JUnit 4.13.2 > > > > > > > > - link: > > > > > > > > https://issues.apache.org/jira/browse/TOMEE-2979[TOMEE-2979] > > > > > > > > MyFaces 2.2.14 > > > > > > > > - link: > > > > > > > > https://issues.apache.org/jira/browse/TOMEE-4016[TOMEE-4016] > > > > > > > > Myfaces 2.2.15 > > > > > > > > - link: > > > > > > > > https://issues.apache.org/jira/browse/TOMEE-2958[TOMEE-2958] > > > > > > > > Tomcat 8.5.61 > > > > > > > > - link: > > > > > > > > https://issues.apache.org/jira/browse/TOMEE-4017[TOMEE-4017] > > > > > > > > Tomcat 8.5.81 > > > > > > > > - link: > > > > > > > > https://issues.apache.org/jira/browse/TOMEE-2939[TOMEE-2939] > > > > > > > > bcprov-jdk15on 1.67 > > > > > > > > - link: > > > > > > > > https://issues.apache.org/jira/browse/TOMEE-4018[TOMEE-4018] > > > > > > > > bcprov-jdk15on 1.70 > > > > > > > > - link: > > > > > > > > https://issues.apache.org/jira/browse/TOMEE-3719[TOMEE-3719] > > > > > > > > commons-io 2.8 > > > > > > > > > > > > > > > > == Bug > > > > > > > > > > > > > > > > [.compact] > > > > > > > > - link: > > > > > > > > https://issues.apache.org/jira/browse/TOMEE-2919[TOMEE-2919] > > > > > > > > java.util.ConcurrentModificationException error > > > > > > > > deploying ear > > in > > > > > > > > TomEE > > > > > > > Plus 7.1.4 > > > > > > > > - link: > > > > > > > > https://issues.apache.org/jira/browse/TOMEE-2968[TOMEE-2968] > > > > > > > > Postgres connection error when a password contains "}" > > > > > > > > - link: > > > > > > > > https://issues.apache.org/jira/browse/TOMEE-2125[TOMEE-2125] > > > > > > > > Datasource config: MaxWait, > > > > > > > > timeBetweenEvictionRunsMillis and > > > > > > > MinEvictableIdleTimeMillis are ignored > > > > > > > > - link: > > > > > > > > https://issues.apache.org/jira/browse/TOMEE-3718[TOMEE-3718] > > > > > > > > Missing mime mappings > > > > > > > > > > > > > > > > == Improvement > > > > > > > > > > > > > > > > [.compact] > > > > > > > > - link: > > > > > > > > https://issues.apache.org/jira/browse/TOMEE-2957[TOMEE-2957] > > > > > > > > Fix OWASP Checks on ASF Jenkins Environment > > > > > > > > - link: > > > > > > > > https://issues.apache.org/jira/browse/TOMEE-2973[TOMEE-2973] > > > > > > > > TomEE :: Examples :: JSF2/CDI/BV/JPA/DeltaSpike uses > > > > > > > > too old > > > > > > > > version of > > > > > > > commons-lang3 > > > > > > > > Please VOTE > > > > > > > > > > > > > > > > [+1] go ship it > > > > > > > > [+0] meh, don't care > > > > > > > > [-1] stop, there is a ${showstopper} > > > > > > > > > > > > > > > > The VOTE is open for 72h or as long as needed. > > > > > > > > > > > > > > > > Gruß > > > > > > > > Richard > > > > > > > > > > > > > > > > > > -- > > > > Sent from my iPhone > > > > > > > -- > > > Sent from Gmail Mobile > > >
smime.p7s
Description: S/MIME cryptographic signature
