tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Strategy for requiring new tcnative capabilities
Date Fri, 17 Jan 2014 17:43:44 GMT

I've added a new function to tcnative to be used in our Java code. I'd
like to commit a patch to Tomcat's Java code to use that new function,
which means there will be a runtime dependency on a particular version
of tcnative.

This is specifically for FIPS mode in SSL so it won't impact a huge
number of people. FIPS mode already requires tcnative 1.2.23 or later
with a suitably-built OpenSSL library.

My new patch is currently written to change the behavior of the
FIPSmode="on" configuration attribute for AprLifecycleListener to
require the new version of tcnative. This will give users more
flexibility over the entry into FIPS mode.

I have a few options here and I'd like some feedback on what everyone's
preferences are:

a) Just let the runtime failure occur and instruct users to upgrade to
the latest tcnative.

b) Re-work the patch such that the current "on" setting is a synonym for
a new "enter" configuration option, and find a new name for "on".

c) Detect the version of tcnative and use different behaviors based upon
the version available and configuration options.

d) Detect the version of tcnative and issue an error if an upgrade is

Option (c) would be the most "compatible" but I really think the default
behavior should change. I don't really like option (b) because the
"usual" setting should just be "on" for most people who want FIPS mode.
Options (a) and (d) will be a pain for anyone who upgrades Tomcat
without upgrading tcnative (and, if I commit today and Tomcat gets
released first, then these folks can't upgrade Tomcat without waiting
for a tcnative release).

Any opinions?


View raw message