gpg.el: Signatures from trusted/untrusted keys?

gpg.el: Signatures from trusted/untrusted keys?

[Andreas Fuchs]

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]

Hi,

is it possible to display the status (especially the trust values of a
key) for a signature in the button, such that:

[[PGP Signed Part:Boinkor the Terrible <boink@mail.me.not>]]

becomes:

[[PGP Signed (Trusted) Part:Boinkor the Terrible <boink@mail.me.not>]]

if the signing key is trusted. If I click the button, gpg tells me:

,----[ excerp from opened PGP signature button ]
| gpg: Good signature from "Boinkor the Terrible <boink@mail.me.not>"
| gpg: WARNING: This key is not certified with a trusted signature!
| gpg:          There is no indication that the signature belongs to the owner.
`----

And omits the warning if the key is trusted.

Maybe dicriminating between four states would be a good idea:
* signed:
  - key unretrievable
  - signature broken
  - signature OK:
    o key trusted
    o key untrusted

I think I'll hack up a patch for that today, but don't hold your
breath. (-:

regards,
-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: gpg.el: Signatures from trusted/untrusted keys?

[Andreas Fuchs]

[-- Attachment #1.1: Type: text/plain, Size: 194 bytes --]

Today, I <asf@void.at> wrote:
> I think I'll hack up a patch for that today, but don't hold your
> breath. (-:

Hm, that was easier than I thought. I have attached the output of cvs
diff:

[-- Attachment #1.2: Type: application/pgp-signature, Size: 231 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Patch to display whether a signer's key is trusted or not --]
[-- Type: text/x-patch, Size: 1193 bytes --]

Index: lisp/mml2015.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/mml2015.el,v
retrieving revision 6.34
diff -r6.34 mml2015.el
375c375,380
<       (match-string 1)
---
>       (let ((signer (match-string 1)))
>         (concat
>          (if (re-search-forward "^gpg: WARNING: This key is not certified with a trusted signature!" nil t)
>              ""
>            "Trusted:")
>          signer))
380c385
<     (let (part message signature)
---
>     (let (part message signature gnus-info-set-p)
409a415,417
>                      (mm-set-handle-multipart-parameter
>                       mm-security-handle 'gnus-info "Error.")
>                      (setq gnus-info-is-set-p t)
413a422,424
>                      (mm-set-handle-multipart-parameter
>                       mm-security-handle 'gnus-info "Quit.")
>                      (setq gnus-info-is-set-p t)
415,416c426,428
< 	    (mm-set-handle-multipart-parameter
< 	     mm-security-handle 'gnus-info "Failed")
---
>             (unless gnus-info-is-set-p
>               (mm-set-handle-multipart-parameter
>                mm-security-handle 'gnus-info "Failed"))

[-- Attachment #3: Type: text/plain, Size: 233 bytes --]


Note that currently, this works only with gpg.el, but as mailcrypt does
not even output the signer's name, that feature would be overkill for a
morning hack. (-:

Have fun,
-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

Re: gpg.el: Signatures from trusted/untrusted keys?

[Nuutti Kotivuori]

Andreas Fuchs wrote:
> Today, I <asf@void.at> wrote:
>> I think I'll hack up a patch for that today, but don't hold your
>> breath. (-:
> 
> Hm, that was easier than I thought. I have attached the output of
> cvs diff:

[...]

> Note that currently, this works only with gpg.el, but as mailcrypt
> does not even output the signer's name, that feature would be
> overkill for a morning hack. (-:

Do note that this method of parsing is not very good. A better method
would be to use the status-fd functionality of gnupg and check for
TRUST_* response. But that feature would ofcourse be overkill for a
morning hack ;)

-- Naked

Re: gpg.el: Signatures from trusted/untrusted keys?

[Andreas Fuchs]

[-- Attachment #1.1: Type: text/plain, Size: 827 bytes --]

Today, Nuutti Kotivuori <nuutti.kotivuori@smarttrust.com> wrote:
>> Note that currently, this works only with gpg.el, but as mailcrypt
>> does not even output the signer's name, that feature would be
>> overkill for a morning hack. (-:
> Do note that this method of parsing is not very good. A better method
> would be to use the status-fd functionality of gnupg and check for
> TRUST_* response. But that feature would ofcourse be overkill for a
> morning hack ;)

Again, you are absolutely right. I have modified my morning hack into an
afternoon hack, and although it looks better now, and it works for me,
YMMV. (-:

This beast includes all changes necessary to gpg.el (changes to
gpg-command-verify and gpg-command-verify-cleartext and another alist
mapping TRUST_* values to symbols) and to mml2015.el.


[-- Attachment #1.2: Type: application/pgp-signature, Size: 231 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2.1: Revised^1 patch for gpg signatures with untrusted/trusted keys --]
[-- Type: text/x-patch, Size: 4127 bytes --]

Index: contrib/gpg.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/contrib/gpg.el,v
retrieving revision 1.13
diff -r1.13 gpg.el
305c305
<   '(gpg . ("--batch" "--verbose" "--verify" signature-file message-file))
---
>   '(gpg . ("--status-fd" "1" "--batch" "--verbose" "--verify" signature-file message-file))
326c326
<   '(gpg . ("--batch" "--verbose" "--verify" message-file))
---
>   '(gpg . ("--status-fd" "1" "--batch" "--verbose" "--verify" message-file))
1176a1177,1184
> 
> (defconst gpg-unabbrev-trust-alist
>   '(("TRUST_UNDEFINED" . trust-undefined)
>     ("TRUST_NEVER"     . trust-none)
>     ("TRUST_MARGINAL"  . trust-marginal)
>     ("TRUST_FULLY"     . trust-full)
>     ("TRUST_ULTIMATE"  . trust-ultimate))
>   "Alist mapping capitalized GnuPG trust values to long symbols.")
Index: lisp/mml2015.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/mml2015.el,v
retrieving revision 6.34
diff -r6.34 mml2015.el
62a63,74
> (defvar mml2015-trust-boundaries-alist
>   '((trust-undefined . nil)
>     (trust-none      . nil)
>     (trust-marginal  . t)
>     (trust-fully     . t)
>     (trust-ultimate  . t))
>   "Trust boundaries for a signer's GnuPG key.
> This alist contains pairs of the form (trust-symbol . boolean), with
> symbols that are contained in `gpg-unabbrev-trust-alist'. The boolean
> specifies whether the given trust value is good enough to be trusted
> by you.")
> 
372c384,403
< (defun mml2015-gpg-extract-from ()
---
> (defun mml2015-gpg-pretty-print-fpr (fingerprint)
>   (let* ((result "")
>          (fpr-length (string-width fingerprint))
>          (n-slice 0)
>          slice)
>     (setq fingerprint (string-to-list fingerprint))
>     (while fingerprint
>       (setq fpr-length (- fpr-length 4))
>       (setq slice (butlast fingerprint fpr-length))
>       (setq fingerprint (nthcdr 4 fingerprint))
>       (setq n-slice (1+ n-slice))
>       (setq result
>             (concat
>              result
>              (case n-slice
>                (1  slice)
>                (otherwise (concat " " slice))))))
>     result))
>           
> (defun mml2015-gpg-extract-signature-details ()
374,376c405,417
<   (if (re-search-forward "^gpg: Good signature from \"\\(.*\\)\"$" nil t)
<       (match-string 1)
<     "From unknown user"))
---
>   (let* ((signer (and (re-search-forward "^\\[GNUPG:\\] GOODSIG [0-9A-Za-z]* \\(.*\\)$" nil t)
>                       (match-string 1)))
>          (fprint (and (re-search-forward "^\\[GNUPG:\\] VALIDSIG \\([0-9a-zA-Z]*\\) " nil t)
>                       (match-string 1)))
>          (trust  (and (re-search-forward "^\\[GNUPG:\\] \\(TRUST_.*\\)$" nil t)
>                       (match-string 1)))
>          (trust-good-enough-p (cdr (assoc (cdr (assoc trust gpg-unabbrev-trust-alist)) mml2015-trust-boundaries-alist))))
>     (if (and signer trust fprint)
>         (concat signer
>                 (unless trust-good-enough-p
>                   (concat "\nUntrusted, Fingerprint: "
>                           (mml2015-gpg-pretty-print-fpr fprint))))
>       (error "From unknown user"))))
380c421
<     (let (part message signature)
---
>     (let (part message signature gnus-info-set-p)
409a451,453
>                      (mm-set-handle-multipart-parameter
>                       mm-security-handle 'gnus-info "Error.")
>                      (setq gnus-info-is-set-p t)
413a458,460
>                      (mm-set-handle-multipart-parameter
>                       mm-security-handle 'gnus-info "Quit.")
>                      (setq gnus-info-is-set-p t)
415,416c462,464
< 	    (mm-set-handle-multipart-parameter
< 	     mm-security-handle 'gnus-info "Failed")
---
>             (unless gnus-info-is-set-p
>               (mm-set-handle-multipart-parameter
>                mm-security-handle 'gnus-info "Failed"))
421c469
< 	   (mml2015-gpg-extract-from))))
---
> 	   (mml2015-gpg-extract-signature-details))))

[-- Attachment #2.2: Type: application/pgp-signature, Size: 231 bytes --]

[-- Attachment #3.1: Type: text/plain, Size: 74 bytes --]


Have fun,
-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

[-- Attachment #3.2: Type: application/pgp-signature, Size: 231 bytes --]

Re: gpg.el: Signatures from trusted/untrusted keys?

[ShengHuo ZHU]

Andreas Fuchs <asf@void.at> writes:

> Today, Nuutti Kotivuori <nuutti.kotivuori@smarttrust.com> wrote:
>>> Note that currently, this works only with gpg.el, but as mailcrypt
>>> does not even output the signer's name, that feature would be
>>> overkill for a morning hack. (-:
>> Do note that this method of parsing is not very good. A better method
>> would be to use the status-fd functionality of gnupg and check for
>> TRUST_* response. But that feature would ofcourse be overkill for a
>> morning hack ;)
> 
> Again, you are absolutely right. I have modified my morning hack into an
> afternoon hack, and although it looks better now, and it works for me,
> YMMV. (-:
> 
> This beast includes all changes necessary to gpg.el (changes to
> gpg-command-verify and gpg-command-verify-cleartext and another alist
> mapping TRUST_* values to symbols) and to mml2015.el.

Does the patch for mml2015.el work with the old gpg.el (maybe losing
some features)?  Since gpg.el is not officially maintained in the Gnus
CVS, I have to make sure that it doesn't break anything before adding
it.

ShengHuo

Re: gpg.el: Signatures from trusted/untrusted keys?

[Andreas Fuchs]

[-- Attachment #1.1: Type: text/plain, Size: 1186 bytes --]

Today, ShengHuo ZHU <zsh@cs.rochester.edu> wrote:
> Does the patch for mml2015.el work with the old gpg.el (maybe losing
> some features)?  Since gpg.el is not officially maintained in the Gnus
> CVS, I have to make sure that it doesn't break anything before adding
> it.

I fear not. It heavily depends on gpg being called with --status-fd set
to 1 (or 2, if stderr isn't redirected, I didn't check).

Hmm, I believe I can rewrite this patch as a seperate .el which just
overwrites mml2015-gpg-extract-from (advice is out of the question, I
think) and sets the variables to the right values.

Another thing this patch does is move some of gpg's status messages into
the info text of the mml buttons (for example "Quit." is displayed
instead of "Failed." in the button text). This does not depend on any
changes outside of mml2015.el.

Another thing that I would like to know: What is the opinion of you
people on having a two-line info text on a mime button? I mean buttons
like:

[[PGP Signed Part:Foo Bar <foo@bar.org>
Untrusted, Fingerprint: XXXX YYYY XXXX YYYY XXXX YYYY XXXX YYYY]]


Thanks,
-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: gpg.el: Signatures from trusted/untrusted keys?

[Kai Großjohann]

On Mon, 30 Jul 2001, Andreas Fuchs wrote:

> Today, ShengHuo ZHU <zsh@cs.rochester.edu> wrote:
>> Does the patch for mml2015.el work with the old gpg.el (maybe
>> losing some features)?  Since gpg.el is not officially maintained
>> in the Gnus CVS, I have to make sure that it doesn't break anything
>> before adding it.
> 
> I fear not. It heavily depends on gpg being called with --status-fd
> set to 1 (or 2, if stderr isn't redirected, I didn't check).

Maybe the gpg.el maintainers would be willing to incorporate the
change in their version?

kai
-- 
~/.signature: No such file or directory

Re: gpg.el: Signatures from trusted/untrusted keys?

[ShengHuo ZHU]

Andreas Fuchs <asf@void.at> writes:

> Today, ShengHuo ZHU <zsh@cs.rochester.edu> wrote:
>> Does the patch for mml2015.el work with the old gpg.el (maybe losing
>> some features)?  Since gpg.el is not officially maintained in the Gnus
>> CVS, I have to make sure that it doesn't break anything before adding
>> it.
> 
> I fear not. It heavily depends on gpg being called with --status-fd set
> to 1 (or 2, if stderr isn't redirected, I didn't check).
> 
> Hmm, I believe I can rewrite this patch as a seperate .el which just
> overwrites mml2015-gpg-extract-from (advice is out of the question, I
> think) and sets the variables to the right values.

I've installed the patch with minor modifications.

> Another thing this patch does is move some of gpg's status messages into
> the info text of the mml buttons (for example "Quit." is displayed
> instead of "Failed." in the button text). This does not depend on any
> changes outside of mml2015.el.

Thanks.

> Another thing that I would like to know: What is the opinion of you
> people on having a two-line info text on a mime button? I mean buttons
> like:
> 
> [[PGP Signed Part:Foo Bar <foo@bar.org>
> Untrusted, Fingerprint: XXXX YYYY XXXX YYYY XXXX YYYY XXXX YYYY]]

Fine for me.

ShengHuo

Re: gpg.el: Signatures from trusted/untrusted keys?

[Andreas Fuchs]

[-- Attachment #1.1: Type: text/plain, Size: 543 bytes --]

On 2001-07-30, ShengHuo ZHU <zsh@cs.rochester.edu> wrote:
> Andreas Fuchs <asf@void.at> writes:
>> Hmm, I believe I can rewrite this patch as a seperate .el which just
>> overwrites mml2015-gpg-extract-from (advice is out of the question, I
>> think) and sets the variables to the right values.
> 
> I've installed the patch with minor modifications.

Argh, it seems that I sent you a patch which contained a typo (and
what's worse, it isn't in a comment or a documentation string!).

I must ask you to install the attached patch:

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: symbol trust-fully should be trust-full --]
[-- Type: text/x-patch, Size: 266 bytes --]

Index: lisp/mml2015.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/mml2015.el,v
retrieving revision 6.35
diff -r6.35 mml2015.el
67c67
<     (trust-fully     . t)
---
>     (trust-full      . t)

[-- Attachment #1.3: Type: text/plain, Size: 72 bytes --]


Thanks,
-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

[-- Attachment #2: Type: application/pgp-signature, Size: 231 bytes --]

Re: gpg.el: Signatures from trusted/untrusted keys?

[ShengHuo ZHU]

Andreas Fuchs <asf@void.at> writes:

> On 2001-07-30, ShengHuo ZHU <zsh@cs.rochester.edu> wrote:
>> Andreas Fuchs <asf@void.at> writes:
>>> Hmm, I believe I can rewrite this patch as a seperate .el which just
>>> overwrites mml2015-gpg-extract-from (advice is out of the question, I
>>> think) and sets the variables to the right values.
>> 
>> I've installed the patch with minor modifications.
> 
> Argh, it seems that I sent you a patch which contained a typo (and
> what's worse, it isn't in a comment or a documentation string!).
> 
> I must ask you to install the attached patch:

Installed.

ShengHuo

Re: gpg.el: Signatures from trusted/untrusted keys?

[Florian Weimer]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

>> I fear not. It heavily depends on gpg being called with --status-fd
>> set to 1 (or 2, if stderr isn't redirected, I didn't check).
> 
> Maybe the gpg.el maintainers would be willing to incorporate the
> change in their version?

One of the motivations for gpg.el was the fact that the copyright
status of Mailcrypt is a bit murky and makes it impossible to include
it in the GNU Emacs distribution. So my initial wish was that the
copyright status auf gpg.el should remained as simple as possible.

However, the FSF has not been very cooperative in assignment contract
negotiations with my employer (in fact, RMS didn't negotiate at all
and we had a hard time to convince him that there was a big, big
problem with the assignment contract), so this question doesn't
matter now anymore, I think.  (I'm going to start one last attempt at
assigning the copyright, this time via the FSF Europe, but after that,
maybe I'm turning to XEmacs or whatever.)