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
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
