Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 743388 - >=mail-mta/exim-4.94* changed semantics for expansions and variables.
Summary: >=mail-mta/exim-4.94* changed semantics for expansions and variables.
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Fabian Groffen
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-09-18 16:49 UTC by Sven E.
Modified: 2021-05-07 22:52 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sven E. 2020-09-18 16:49:47 UTC
Starting with 4.94 some of the semantics for the config changed. Various variables get 'tainted' and therefore cannot longer be used in expansions as before.

For existing installations this breaks setups all to easy.

Could we therefore add a warning or something to the ebuild, notifying people that they should expect some trouble with the update?

Changelog says:
JH/20 Taint checking: disallow use of tainted data for
      - the appendfile transport file and directory options
      - the pipe transport command
      - the autoreply transport file, log and once options
      - file names used by the redirect router (including filter files)
      - named-queue names
      - paths used by single-key lookups
      Previously this was permitted.

However information on what gets tainted and what not is rather thin for now. (Personally I'd expect a Chapter in the official Reference on this).

On top the syntax for i.e. sqlite lookups changed (no Changelog item for this).
Comment 1 Fabian Groffen gentoo-dev 2020-09-19 06:54:41 UTC
I hear your annoyance, which I share towards upstream.  They've had some more bugreports from people like you, which they waved away with "read the docs", "replace this var with that one" or something alike.

I don't really now what to do with this, I can add a warning but I don't know what it should say.  Typically this is a message you want to see before (e.g. news item) but since the specifics are vague (as you pointed out) it raises more questions than it answers.
Comment 2 Sven E. 2020-09-19 10:42:16 UTC
I see your point. For now I rolled back to 4.93, which is fine. It is indeed an annyoance, if you run into this and there's no straight fix. Of course I can read the docs, no doubt, but even then things are not completely clear.

Ontop error messages are somewhat misleading, but that's another story.

I guess the only possible thing would be, to warn abnout the changes and to recommend looking into them before rolling out on production systems. That does of course not really fix things, but people can at least avoid the trap for now and take their time to i.e. create another installation for thorough testing (or a good afternoon reading of the whole reference).

And yes, I think we can agree that upstream did not really do a good job here.
Comment 3 Juan David Ibáñez Palomar 2020-10-19 16:10:55 UTC
Maybe suggest users to at least test the routers (with exim -bt) before restarting exim? Update configuration, test routers, restart, watch the logs.
Comment 4 Fabian Groffen gentoo-dev 2021-01-06 09:19:36 UTC
https://lists.exim.org/lurker/message/20201228.130922.420b984c.en.html

in particular (quote)

Before publishing the next release of Exim we'd like to sort out some things
first, most notably:

- how to proceed with the taint checks (to give distros a chance
to include the next Exim release w/o breaking old configurations)
Comment 5 Fabian Groffen gentoo-dev 2021-05-04 19:48:29 UTC
I've pushed out a news item notifying of this since 4.94.2 is fast-stabled now due to security reasons.
Comment 6 Sven E. 2021-05-07 22:52:51 UTC
Regarding the news item:

"Particularly, the use of $local_part in any transport, should likely be
updated with $local_part_data.  Check your local_delivery transport,
which historically used $local_part."

local_part_data might aswell be empty, if the router does not use local_parts option.

The nastiness of those changes lie in the tiny details :-/.