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

[Andrew Janke <floss@apjanke.net>]

On 9/28/15 5:17 PM, Bart Schaefer wrote:
> 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.
But in this case I think it *is* scanning the insecure directory: I had 
a _foo only in /insecure, not in /secure, and it still got picked up by 
compinit and used for completion. (Sorry if my example was unclear: I 
copied _kill to _foo just so I'd have a readily recognizable completion 
output.)

But that's a good point about $fpath at the function call time really 
being what matters.
>
> 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).