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
andrew@??? 
