Re: /srv/bzr/emacs/trunk r105466: epa-mail.el handles GnuPG groups.

Re: /srv/bzr/emacs/trunk r105466: epa-mail.el handles GnuPG groups.

[Daiki Ueno]

Richard Stallman <rms@gnu.org> writes:

>     There is already a function `epg-expand-group' to parse group
>     definitions.  With that, the change could be rewritten to:
>
> Would you please make the improvement you suggested?

Done.

> Parsing gpg.conf is necessary because epa tries to check the
> recipients itself before passing them to gpg.  Is there a good reason
> to check them?  Why not just pass them to gpg (first giving the user
> an opportunity to edit the list, as mailcrypt-encrypt does), then let
> gpg reject any that are not valid?

epa has a nice feature to select keys interactively, which is based on
(group-expanded) key information in elisp level.  Try:

C-u M-x epa-mail-encrypt

and you will see the list of keys which will be used to encrypt, before
doing actual encryption.  This is useful for careful users who don't
want to encrypt emails with untrusted/unwanted keys.

> This way, epa would not need to expand the groups, or know about them.
> And maybe a lot of other code could be deleted too.

The amount of code to be removed wouldn't be that much because
`epg-expand-group' uses parsed groups info provided by:

gpg --list-config --with-config

Regards,
-- 
Daiki Ueno

Re: /srv/bzr/emacs/trunk r105466: epa-mail.el handles GnuPG groups.

[Richard Stallman]

    epa has a nice feature to select keys interactively, which is based on
    (group-expanded) key information in elisp level.  Try:

    C-u M-x epa-mail-encrypt

    and you will see the list of keys which will be used to encrypt, before
    doing actual encryption.  This is useful for careful users who don't
    want to encrypt emails with untrusted/unwanted keys.

I have nothing against it; but when C-u is not used, why check the keys?
Why not just pass the specified recipients to GPG and let it check them?

    > This way, epa would not need to expand the groups, or know about them.
    > And maybe a lot of other code could be deleted too.

    The amount of code to be removed wouldn't be that much because
    `epg-expand-group' uses parsed groups info provided by:

    gpg --list-config --with-config

I think we are talking about different code.  I was talking about
the code to check the keys.  I thought all that could be deleted
by making epa not check the keys.

However, if that code is needed for the C-u case, then it could not be
deleted.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: /srv/bzr/emacs/trunk r105466: epa-mail.el handles GnuPG groups.

[Daiki Ueno]

Richard Stallman <rms@gnu.org> writes:

>     epa has a nice feature to select keys interactively, which is based on
>     (group-expanded) key information in elisp level.  Try:
>
>     C-u M-x epa-mail-encrypt
>
>     and you will see the list of keys which will be used to encrypt, before
>     doing actual encryption.  This is useful for careful users who don't
>     want to encrypt emails with untrusted/unwanted keys.
>
> I have nothing against it; but when C-u is not used, why check the keys?
> Why not just pass the specified recipients to GPG and let it check them?

It could be possible but it does not help simplifying the code.  Now the
behavior is identical to what GPG does and I see no reason to add a
special case when C-u is not used.

> I think we are talking about different code.  I was talking about
> the code to check the keys.  I thought all that could be deleted
> by making epa not check the keys.
>
> However, if that code is needed for the C-u case, then it could not be
> deleted.

Yes, it is needed for the C-u case and also for encrypting files (not
emails), importing/exporting keys, etc.

Regards,
-- 
Daiki Ueno