Re: "compinit -i" not excluding some insecure dirs?

[Bart Schaefer <schaefer@brasslantern.com>]

On Sep 28,  7:28am, Andrew Janke wrote:
}
} What is the expected behavior for compinit's "-i" switch? The doco says 
} it will " silently ignore all insecure files and directories". I 
} interpret that to mean "silently exclude insecure files and dirs from 
} use in the completion system", as opposed to "silently ignore the 
} security check failures and use them anyway". If this is the case, it 
} looks like there might be an issue with the "compinit -i" code.

There's only so much that compinit can do.  It doesn't actually change
your $fpath to remove the insecure directories; it merely doesn't look
at them when scanning for files that contain #compdef, #autoload, etc.
on the first line.

So if you have fpath=(/insecure /secure) and there is _kill in both
places, the one in /secure will be used for #compdef at time of
compinit, but the one in /insecure will still be used at the time
the function is called, because $fpath search order says it should.

I must grudgingly admit that this is closely related to Ray Andrew's
(incorrect) expectation that once the "autoload" *command* is issued,
the source file of the corresponding function is locked down.

To really be secure, a re-check would have to be done at the instant
of the first function call, or all the functions would have to be pre-
loaded at the instant of compaudit (which is exactly what compinit is
attempting to *avoid* doing).