Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [PATCH] _gpg: Use explicit UIDs for public / secret keys.
- X-seq: zsh-workers 42987
- From: Doron Behar <doron.behar@xxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: [PATCH] _gpg: Use explicit UIDs for public / secret keys.
- Date: Tue, 12 Jun 2018 13:54:57 +0300
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=tFuzQcJxhEakttzc1YADSuk5Itw7KIWrzvQK9cS7S1Y=; b=dvmxN22NcLHTD7XFwXcKKW1AJNqZ8aVy+Mf83Y5NYHrhcHNY3ktV8Uqhi50/SkgjQV hXJcfwTJp+wfJiISKauvqe4v7LpXT0CbvzJQ2lxmmYNfv4lMTjR+s42/7l2Rj+fh199L 5SLQBa7wPtQWuFcYSSIyOoZXI33x4YTU20T1jIWwoAQFTJ/S8o4wixsC+5vTFDaduTrt tocOnidLlg9TSfIaY8P5ZXITOJ2ct4GaPbAa7PYiDFazeTFq7b5GgkgIil/ds/+r3V20 wxUj1MHGPdg961YTMIY3qTxRjDrd/gSD3ViW9fXTTgqG4BND18pf7p91UawAg9Zu3QYT 1oew==
- In-reply-to: <20180609203932.x3s4hbmbl6rtba76@tarpaulin.shahaf.local2>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
- Mail-followup-to: zsh-workers@xxxxxxx
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <20180609200940.17041-1-doron.behar@gmail.com> <20180609203932.x3s4hbmbl6rtba76@tarpaulin.shahaf.local2>
Daniel,
I would like you to tell me how can I solve better the `fpr` thing.
To tell you the truth, I have no idea what `fpr` means. I just know, by
comparing the output of `gpg --list-public-keys` with and without
`--with-colons`, that the hexadecimal number afterwards is the actual
key that needs to be used as an argument for these options. The way I
understand it, only if there is an email address / description coming
somewhere after the array element `fpr` (without another `fpr` in
between), then this field is the description.
Please tell me, how can this algorithm get better? I've had one idea in
mind: Perhaps we can perform a more strict pattern matchings test before
adding a uid for example?
On Sat, Jun 09, 2018 at 08:39:32PM +0000, Daniel Shahaf wrote:
> Good morning Doron,
>
> Thanks for revising the patch, however, I'm afraid I do have a few more
> comments:
>
> doron.behar@xxxxxxxxx wrote on Sat, Jun 09, 2018 at 23:09:40 +0300:
> > secret-keys)
> > - _wanted secret-keys expl 'secret key' compadd \
> > - ${${(Mo)$(_call_program secret-keys $words[1] $needed --list-secret-keys --list-options no-show-photos):%<*>}//(<|>)/} && return
> > + local secret_keys=(${(@s.:.)${(f)"$(_call_program secret-keys ${(q)words[1]} ${(q)needed} --list-secret-keys --list-options no-show-photos --with-colons)"}})
> > + local -a uids emails
> > + local i
> > + for i in {1..${#secret_keys[@]}}; do
> > + if [[ ${secret_keys[$i]} == "fpr" ]]; then
>
> I'd like to see the 'fpr' thing (which I have pointed out twice by now) fixed
> before merging. _gpg isn't a function I'm comfortable adding
> relaxed/inaccurate parsing to, and doing the parsing correctly isn't onerous.
>
> > + i=$((i + 1))
> > + local j=$i
> > + while [[ ${secret_keys[$j]} != "fpr" ]] && [ $j -lt ${#secret_keys[@]} ]; do
> > + if [[ ${secret_keys[$j]} =~ "@" ]]; then
>
> This condition false negatives for me, probably because I used a test secret
> key that didn't have an email address attached.
>
> > + emails+="${secret_keys[$j]}"
> > + uids+="${secret_keys[$i]}"
> > + break
> > + fi
> > + j=$((j + 1))
> > + done
> > + i=$j
> > + fi
> > + done
> > + _describe -t secret-keys 'secret key' uids_and_emails
>
> s/uids_and_emails/emails uids/
>
> > ;;
> > ciphers)
> > _wanted ciphers expl cipher compadd \
> > - ${${(s.,.)${(M)${(f)${"$(_call_program ciphers $words[1] $needed --version)"}//,$'\n' #/, }:#Cipher*}#*:}# } && return
> > + ${${(s.,.)${(M)${(f)${"$(_call_program ciphers ${(q)words[1]} ${(q)needed} --version)"}//,$'\n' #/, }:#Cipher*}#*:}# } && return
> > ;;
> > (public-keyids)
> > + _describe -t public-keyids 'public keyids' uids_and_emails
>
> Ditto.
>
> Thanks for hanging in there.
>
> Daniel
Messages sorted by:
Reverse Date,
Date,
Thread,
Author