On Thu, 12 Nov 2020, Mike Tubby via Exim-users wrote:
Here's a proposal for a compromise in an attempt to satisfy these, competing,
requirements with a phased approach:
1. Publish a roadmap for Exim - likely things to arrive in 4.95, 4.96, 4.97
... and that there will be an Exim 5.0 out in roughly XX months. This
doesn't have to be stuck to - its forward looking not a 'promise' but can
include item (5) below.
2. Keep the tainted data model as it is now
3. Don't give the user's new untaint methods that fix one thing and
potentially break another, e.g. internationalisation
4. Document tainted data more fully:
* what tainted data is
* what can go wrong if you trust it when you shouldn't
* why you need to change
* examples of configurations and recommendations
Ensure the documentation includes the road-signs to the right way to do
things to avoid cargo-cult
5. Add a new config variable:
taint_mode = warn | enforce
which is initially defaults to 'warn' and which bleaches to
mainlog/paniclog or even stdout on start warning:
a) of the perils of tainted data;
b) tells the user this this feature is going to be removed in a
future release
c) points to the documentation (3)
Eg:
Exim: Configuration uses tainted data which is currently allowed may
be dangerous. This will be removed in a future release. For info see
https://exim.org/tainted_data.html
At some later release (4.96, 4.97 ?) switch from the default of 'warn' to
the default of 'enforce', effectively allowing the user to swim against the
tide by switching back to 'warn' if they must.
Implement the taint_mode with a sun-set, i.e planned removal at Exim 5.0.
6. Implement Jeremy's relatively light weight:
${if tainted{my_suspect_expansion} {expand_this} {expand_that}}
Which he said would be simple to code and test and allow some workarounds
to be implemented for some use cases.
7. Publicity.
Generally good. Thanks Mike.
Some points:
A/ I believe that one reason we have got into this position is that
"suspect" data is currently being used in many ways that the main
developers had not imagined.
*** This means that other people are in a better position then Jeremy etc.
*** to write (at least one pass of) the new documentation.
B/ Given that the likes of Ubuntu are now shipping v4.94,
would it not be reasonable to default to
taint_mode = enforce
- anyone who is up to date already has this, so that is least surprise ?
If 4.95 bleats unless taint_mode is explicitly set to something, we will
get some free publicity, and the user will know to set taint_mode = warn
until they have addresses the issue.
The later release (4.96, 4.97 ?) will then merely need to bleat
if taint_mode is set to "warn".
(I am tempted to suggest that this should be a persistent bleat, like the
Warning: No server certificate defined; will use a selfsigned one.
Suggested action: either install a certificate or change
tls_advertise_hosts option
message.)
C/ I see 6. ${if tainted{ as primarily a debugging feature;
once {expand_this} and {expand_that} are pinned down for an installation,
I believe that {my_suspect_expansion} will usually turn out to be a constant.
--
Andrew C. Aitchison Kendal, UK
[email protected]
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
