Andreas Metzler wrote:
> The text has been slightly updated with one oof the latest uploads, it
> now reads
That's the last sentence changed. We also need a title text; maybe
Exim 4.94
(The upstream "brand name" usually seems to be capitalised, whereas the
Debian (meta)package name is "exim4".)
> -----------------
> Please consider exim 4.93/4.94 a *major* exim upgrade. It introduces the
We don't really need to mention 4.93 here and below, and if we put
4.94 in the title we can just say "the version of Exim in bullseye"
everywhere else.
> concept of tainted data read from untrusted sources, like e.g. message
> sender or recipient. This tainted data (e.g. $local_part or $domain)
> cannot be used among other things as a file or directory name or command
> name.
>
> This WILL BREAK configurations which are not updated accordingly.
> Old Debian exim configuration files also will not work unmodified, the new
(Pedantically, needs a semicolon or suchlike rather than a comma.)
> configuration needs to be installed with local modifications merged in.
>
> Typical nonworking examples include:
> * Delivery to /var/mail/$local_part. Use $local_part_data in combination
> with check_local_user.
> * Using
> data = ${lookup{$local_part}lsearch{/some/path/$domain/aliases}}
> instead of
> data = ${lookup{$local_part}lsearch{/some/path/$domain_data/aliases}}
> for a virtual domain alias file.
>
> The basic strategy for dealing with this change is to use the result of a
> lookup in further processing instead of the original (remote provided)
> value.
(Is it possible we could shorten this by pointing to some external
reference here?)
>
> To ease upgrading there is a new main configuration option to temporarily
> downgrade taint errors to warnings, letting the old configuration work with
> the newer exim. To make use of this feature add
> .ifdef _OPT_MAIN_ALLOW_INSECURE_TAINTED_DATA
> allow_insecure_tainted_data = yes
> .endif
> to the exim configuration (e.g. to /etc/exim4/exim4.conf.localmacros)
> *before* upgrading to exim 4.93/4.94 and check the logfile for taint
> warnings. This is a temporary workaround which is already marked for
> removal on introduction.
> -----------------
So if I'm getting this formatting right it would be:
<section>
<title>Exim 4.94</title>
<para>
Please consider the version of Exim in bullseye a
<emphasis>major</emphasis> Exim upgrade. It introduces the
concept of tainted data read from untrusted sources, like e.g.
message sender or recipient. This tainted data (e.g.
<literal>$local_part</literal> or <literal>$domain</literal>)
cannot be used among other things as a file or directory name or
command name.
</para>
<para>
This <emphasis>will break</emphasis> configurations which are not
updated accordingly. Old Debian Exim configuration files also
will not work unmodified; the new configuration needs to be
installed with local modifications merged in.
</para>
<para>
Typical nonworking examples include:
</para>
<itemizedlist>
<listitem>
<para>
Delivery to <filename>/var/mail/$local_part</filename>. Use
<literal>$local_part_data</literal> in combination with
<literal>check_local_user</literal>.
</para>
</listitem>
<listitem>
<para>
Using
</para>
<programlisting>
data = ${lookup{$local_part}lsearch{/some/path/$domain/aliases}}
</programlisting>
<para>
instead of
</para>
<programlisting>
data = ${lookup{$local_part}lsearch{/some/path/$domain_data/aliases}}
</programlisting>
<para>
for a virtual domain alias file.
</para>
</listitem>
</itemized>
<para>
The basic strategy for dealing with this change is to use the
result of a lookup in further processing instead of the original
(remote provided) value.
</para>
<para>
To ease upgrading there is a new main configuration option to
temporarily downgrade taint errors to warnings, letting the old
configuration work with the newer Exim. To make use of this
feature add
</para>
<screen>
.ifdef _OPT_MAIN_ALLOW_INSECURE_TAINTED_DATA
allow_insecure_tainted_data = yes
.endif
</screen>
<para>
to the Exim configuration (e.g. to
<filename>/etc/exim4/exim4.conf.localmacros</filename>)
<emphasis>before</emphasis> upgrading and check the logfile for
taint warnings. This is a temporary workaround which is already
marked for removal on introduction.
</para>
</section>
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
