From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29355 invoked by alias); 14 Jun 2018 10:06:58 -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: List-Unsubscribe: X-Seq: 43010 Received: (qmail 10713 invoked by uid 1010); 14 Jun 2018 10:06:58 -0000 X-Qmail-Scanner-Diagnostics: from out2-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(66.111.4.26):SA:0(-2.6/5.0):. Processed in 1.577258 secs); 14 Jun 2018 10:06:58 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_PASS,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=PJQOcb o81wjRSiH87Gq1vfmp66RSJV8DJydNcUxL1is=; b=hF22SN5T3SgeQuADbrqChb oozQxZqfNBvABOyu7SauRBKvEAAimeLCJX5i2/fZqcybKDc6KcVHeyIsAFh5vtbw Ajw8HmD0KlcnRpTL7TvN/J5FZ7pGD5NM7S49eUHJuHwUXNl67+QRzIV8knbjiqFw nsuUs+6+8/Bm2e0B5eGKdbZrrvd+4h6vJ97fiKldfmstfrfrfkRgiQbnJ6xZ9clH VY5XmaEifN+zI+v9f99+pj6rOplQoizBjOi2G1G0AhkTOlZAUOoNfhJ8C3ZgxFXp kceZRWdF293DY3SEYWb0pOCUYOfh78h92Ekn2IONK+Bh/VioIh7lYeE0lE5q4zkA == DKIM-Signature: v=1; a=rsa-sha256; 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-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=PJQOcb o81wjRSiH87Gq1vfmp66RSJV8DJydNcUxL1is=; b=aJ84/Z0mwSafVdnrpGXwXi DY2LXbniIRo7qY6WbjWpS/+6lEFooP9DLR8HULyxGOc4kKD1YLCFMEBlMaYJr1w8 Cksop8X1Cd5PRbxvNPP7YAp3+f0xL10e2CjmFR8I40CB25K5dIwsDqL7h0H/3cV4 VDAeiysd6eTnPag6NWOg4LSLs1mEptqmGNd4RQ9jK9rvpGCJI/X/SCL1BhbEazL2 3DI7Mc74ZqxmuNwUzhYUjtfIaZCaF3una/VlizMJSofzN/QuxYXYHywHpfyxKEFN qH7lWlbSLRFyXk2hLBGQFbFrGghCB6rVGpYQjI3dEgIsLMVApxt43EnI5X29ii2g == X-ME-Proxy: X-ME-Sender: Date: Thu, 14 Jun 2018 10:06:51 +0000 From: Daniel Shahaf To: zsh-workers@zsh.org Subject: Re: [PATCH] _gpg: Use explicit UIDs for public / secret keys. Message-ID: <20180614100651.qjpfyo3uuyxwnblt@tarpaulin.shahaf.local2> References: <20180609200940.17041-1-doron.behar@gmail.com> <20180609203932.x3s4hbmbl6rtba76@tarpaulin.shahaf.local2> <20180612105457.wnuoenlfzapgosmf@NUC.doronbehar.com> <20180612221411.GA20129@osmium.lan> <20180613151748.dktvf3xm6m6zdrb5@NUC.doronbehar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180613151748.dktvf3xm6m6zdrb5@NUC.doronbehar.com> User-Agent: NeoMutt/20170113 (1.7.2) Doron Behar wrote on Wed, Jun 13, 2018 at 18:17:48 +0300: > On Tue, Jun 12, 2018 at 06:14:11PM -0400, Phil Pennock wrote: > > Unless you need trust information or some of the specific parts of the > > userid, using `--fast-list-mode` can have significant wins too. > > I have ran `diff` on the output of `gpg --list-public-keys > --with-colons` and `gpg --list-public-keys --fast-list-mode > --with-colons` and there was no significant reduce in the amount of > output with my version of gpg, as noted in the commit message you > quoted. > > > > > Matthew's link to > > > > is accurate and good guidance. As is his pointer to check the correct > > column numbers. > > > > Since columns may be added or removed in the format, as explained in > this documentation, I think it'll be better not to hard-code the > columns' numbers while parsing. Where exactly does the gpg documentation say that columns may be *removed* in future gpg 2.x releases? I don't see any such statement in doc/DETAILS. My understanding is that columns may be added *at the end* only, and never removed until 3.x; that way, forward-compatible output parsing is possible. That implies that our parsing should (a) hardcode column numbers per column type, e.g., if the value of the first column is "fpr" then only check the Nth and Mths columns, etc; and that any fields after the last *must not* be parsed in any way. > Therefor, I'm inclined to go through all > of the fields after `fpr` and after `uid` in every line. With the field > in the line with `fpr`, it's easy to be sure of the `uid` we get from > this line since we can check if it's matched against `[A-F0-9]{40}`. > > As for the line with description (or usually an email address), I'm not > sure what regex match to test on it before putting it in the right > array.. As already pointed out by Daniel, testing it with `=~ "@"` is > not good enough. Perhaps here we'll use a hard-coded number as > documented in gpg's repository? I need some opinions here.. > The value to match against should be obtained from a hard-coded field number for a given value of the first line, yes. As to matching against it by regex, ideally we'd leave matching to compsys so matchers like _approximate could kick in. > > Beware that recent versions of GnuPG always show fingerprints, for keys > > and subkeys, because (per commit message) "The fingerprint should always > > be used thus we should always print it."; so you'll get multiple `fpr:` > > records per top-level key, although between the `sec` or `pub` top-level > > introducer and the `uid:` lines for _that_ key there should just be the > > top-level fingerprint. > > > > > > > > Welcome to the world of GnuPG integration. You have my sympathy. But > > also my encouragement. :) > > > > -Phil > > Anyway, I've created a draft that should be a much better and much more > understood but it's not ready yet as I'm not sure about what I explained > above, this is it: > > > local public_keys_lines=(${(f)"$(_call_program public-keys ${(q)words[1]} ${(q)needed} --list-public-keys --list-options no-show-photos --with-colons)"}) > local -a uids emails > local i j parts > for (( i = 1; i < ${#public_keys_lines[@]}; ++i )); do > parts=(${(@s.:.)public_keys_lines[$i]}) > if [[ ${parts[1]} == "fpr" ]]; then > # This loop ensures that no matter if fields are added, the last field > # that is built from 40 upper case A-Z letters is used as the uid. As explained above: the parsing should completely ignore any fields in an "fpr" line beyond the 11th (since it so happens that currently 'fpr' lines have 11 fields in them). > # We named the variable current_uid becuase it may have many email > # addresses. > for (( j = 2; j <${#parts[@]}; ++j )); do > if [[ "${parts[$j]}" =~ "[A-F0-9]{40}" ]]; then > current_uid="${parts[$j]}" > fi > done > i=$((i + 1)) > parts=(${(@s.:.)public_keys_lines[$i]}) > while [[ ${parts[1]} == "uid" ]]; do > for (( j = 2; j <${#parts[@]}; ++j )); do > # FIXME? > if [[ "${parts[$j]}" =~ "@" ]]; then Can't you just change this condition to «if true; then», so compsys would do the matching itself> > uids+=("${current_uid}") > emails+=("${parts[$j]}") > fi > done > i=$((i + 1)) > parts=(${(@s.:.)public_keys_lines[$i]}) > done > fi > done > _describe -t public-keys 'public key' emails uids > > For me it works great and it is much faster then before, yet I'm not > sure about the if statement right below the `FIXME` comment. Cheers, Daniel