On 2012-05-18 at 22:26 +0200, Marcin Mirosław wrote:
> Thanks for answer. May i ask for another review?
> This reports are commented in the same way as report about dcc: "Stack
> address stored into global variable"
> http://mejor.pl/exim-4.77/report-IORFNM.html#EndPath
This is $auth1, which is *checked* where it occurs in server_condition.
That check is done while this function is in scope, in the OK branch.
So the var is left dangling in the event that auth fails, but nothing
will ever refer to it, so it's not a bug.
If there's another authentication attempt, the variables will be reset
first, so this can never be referred to in its current form.
It's still a little cleaner to not leave a global variable pointing to
invalid memory, even if it won't be referenced, so I've cleaned that up.
> http://mejor.pl/exim-4.77/report-thpTB0.html#EndPath
iplookup, only used at Cambridge, its use discouraged. Which would be
why problems have not arisen elsewhere; it's a Router, so something
referring to the expansion variables in a later Router is a mistake, so
people aren't writing such configs and we're not being bitten.
Looks like it's worse, as all the expansion variables will be pointing
to it.
So it requires a broken config to reference these, but it's still bad
for us to make it too easy for a broken config to cause a crash, so I've
fixed this too.
> http://mejor.pl/exim-4.77/report-kWMaKG.html#EndPath
Not a problem. This is a function only called by -bmalware, so Exim
exits after calling it, and the variable can never be referred to.
If these are the only complaints though, it's worth silencing the
message by resetting message_id to NULL afterwards.
So: one absolutely not a problem, one almost certainly not a problem,
and one which is a problem but requires a strongly-discouraged router
designed for one specific environment, *and* a broken config, to
trigger.
Will push in a moment.
Thanks for the reports,
-Phil
