Re: [exim] tainted data issues

Pàgina inicial
Delete this message
Reply to this message
Autor: Andrew C Aitchison
Data:  
A: exim-users
Assumpte: Re: [exim] tainted data issues

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