From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21702 invoked by alias); 28 Sep 2015 21:17:41 -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: 36685 Received: (qmail 6323 invoked from network); 28 Sep 2015 21:17:39 -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 autolearn=ham autolearn_force=no version=3.4.0 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=V32qg3bDPsUpKY6bqkm1XrRXQx0SIidNidW4B+BnqOI=; b=WCNcT3isWW5JglXzAnvKfLHozx5yicNqk57vWOyMq1YQdqKeWDfJs9VB+neHOvimHE Mnveu1DbCfkQOIkO3gzwxQEIXPLoC013IWyatGQAFrQn4oQamRkWSXf2Ul4Mh/fb5M1h n9pTXJ5zCLehqbCrxUiLllAFfZTDVvInlgVhKnOtxNBOByCmxu4inX1E0VItFmH7tEX3 oLO2Vt8+PuGhwftBYczI6lQwBohUiL8HJT64KDM9fVP5KCl3a8WkpF5VcxD+21sBRI32 xXpX5Gp7p1LMCveUhj476GcXPryLHQsUpvXLV648EF9dYNJbDZn4U/QfiGr/LTdKr2+E LuYw== X-Gm-Message-State: ALoCoQlSNWjsC9S4TJUe4EUvbRAUCWs0su8FhGLPcIcpsr77J8THBNk2+FVOmc//cI0P9iTNxt6j X-Received: by 10.182.105.33 with SMTP id gj1mr11811989obb.77.1443475054958; Mon, 28 Sep 2015 14:17:34 -0700 (PDT) From: Bart Schaefer Message-Id: <150928141732.ZM15458@torch.brasslantern.com> Date: Mon, 28 Sep 2015 14:17:32 -0700 In-Reply-To: <56092456.3000006@apjanke.net> Comments: In reply to Andrew Janke ""compinit -i" not excluding some insecure dirs?" (Sep 28, 7:28am) References: <56092456.3000006@apjanke.net> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: "compinit -i" not excluding some insecure dirs? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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).