n Wed, Mar 13, 2024 at 2:55 PM Christopher Schultz <ch...@christopherschultz.net> wrote: > > Rémy, > > On 3/12/24 12:05, Rémy Maucherat wrote: > > On Tue, Mar 12, 2024 at 3:02 PM Christopher Schultz > > <ch...@christopherschultz.net> wrote: > >> > >> Mark, > >> > >> On 3/12/24 05:00, Mark Thomas wrote: > >>> On 11/03/2024 21:38, schu...@apache.org wrote: > >>>> This is an automated email from the ASF dual-hosted git repository. > >>>> > >>>> schultz pushed a commit to branch main > >>>> in repository https://gitbox.apache.org/repos/asf/tomcat.git > >>>> > >>>> commit 3ab883aa746a5c577efa39d9080858e53ca77da6 > >>>> Author: Christopher Schultz <ch...@christopherschultz.net> > >>>> AuthorDate: Mon Mar 11 17:38:01 2024 -0400 > >>>> > >>>> Add checking for the age of the Tomcat version running and warn > >>>> if it's getting old. > >>> > >>> How do I disable this check if I don't want to use it? I'd expect > >>> something like set it to "-1". > >> > >> I could add a special case for "disable" or you could set it to a very > >> high value. > >> > >> If your Tomcat installation is still running in 32768 days, you > >> certainly won't give a damn if it starts issuing warnings. > > > > I don't like this either. It might get me into real trouble with my > > downstream, actually. > > > > Unless there's a security issue, I think people don't really really > > have to upgrade working production systems that often. For example, > > between 9.0.62 and 9.0.71, no CVEs above low. And even if there was > > most often a user will not be affected. Upgrading costs testing and > > resources, so ... > > > > I'm not advocating that users should never upgrade, but building in a > > nag by default is not great. Esp 6 months. By the time things are > > upgraded they will start nagging again the next day pretty much. Then > > a warn log about security often cannot be simply ignored. > > Okay. Are you suggestion any of the following? > > 1. A longer default nag-duration
That's a good start. If it is meant to be enabled by default, I would like a value that is long enough so that it is almost certain there's an issue. 2 years ? Rémy > 2. Add an explicit "disable" (e.g. -1) > > 3. Disable the feature by default > > 4. Remove this feature entirely > > The target for this was really 8.5 which will immediately go > out-of-support once 8.5.100 is released. So really the default for > 8.5.100 should be "nag immediately", but we can't expect that anybody > really uses the out-of-the-box server.xml without any customizations, so > specifically setting the duration to some small number of days in > server.xml isn't going to have any effect. > > That's why I made it "on by default". > > Another option would be: > > 5. Change the behavior between 8.5 and the other branches. 8.5 could > have this on-by-default while the others do not. We might make it a > policy to "change to on-by-default around EOL time" so that most people > will not change the configuration from the default, but then the default > changes for the final release(s) in a branch. > > In terms of "you only need to upgrade if there are CVEs"... that would > be a very difficult policy for us to manage, because any release we know > has any CVEs would be released before we knew it had them. Any new > release with fixes cannot announce to the old releases that they need to > be upgraded. > > My goal was to improve security for those who are unlikely to be paying > attention to announce@tomcat or using any of the publicly (and > non-publicly) available bug trackers and services to ensure they aren't > running vulnerable versions of Tomcat. > > We often release fixes without announcing them until long after the > fact, which means that any new release could conceivably be a "security > release". You (downstream) won't know until later whether or not you > should have upgraded. So the best advice is to upgrade as often as it is > convenient for you to do so. This is simply a reminder to do it. > > Since we have releases roughly every month, I figured that > every-6-months would be a good cadence. And it can always be configured > to shut up "forever" if necessary. > > -chris > > --------------------------------------------------------------------- > 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
