From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17591 invoked by alias); 28 Sep 2015 21:52:26 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 36686 Received: (qmail 18974 invoked from network); 28 Sep 2015 21:52:19 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.0 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=JOIgRCp1qBQjP41 bi42rLR9a6D0=; b=s1JVPGHsYLT1eG8Nt0WmCyb/XLCYMuYA5x2JBjORCdiuIOQ PplG4/NEcWBR2rDVVIRv6F39Ex+BrtDtgND30ZDrhaLdDUTSLQeMtIgLWt619ljL 8IgjWqo9/FWclmHQlT/jub9QxhhZxF06HCfF9qrXnDDcgAxDhCqBNFDXWyJI= X-Sasl-enc: ufCr3/8rBErg6NAfqfJGKuSEe1eVNaU73hBmND7XU2ju 1443477126 Subject: Re: "compinit -i" not excluding some insecure dirs? To: Bart Schaefer , Zsh hackers list References: <56092456.3000006@apjanke.net> <150928141732.ZM15458@torch.brasslantern.com> From: Andrew Janke Message-ID: <5609B684.2010303@apjanke.net> Date: Mon, 28 Sep 2015 17:52:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <150928141732.ZM15458@torch.brasslantern.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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).