#1693 new

gpg key groups not resolved

Reported by Dieter | February 15th, 2017 @ 04:39 PM


I'm trying to send emails to an email list which get resolved on the server, but required keys to be resolved via local "group" definitions in the "gpg.conf" file.

Here an example:

I have the public keys of 3 recipients ( userA - userC ) in my keyring: 0xAABBCCDD 0xBBCCDDEE 0xCCDDEEFF

On the email server I have an alias group1@domain.com: userA userB userC

In my gpg.conf I have the following entry:

group group1@domain.com=0xAABBCCDD 0xBBCCDDEE 0xCCDDEEFF

Now, when sending an email to "group1@domain.com" I'm getting an popup saying:

  INV_RECP 1 <group1@domain.com>
  FAILURE encrypt 9

Any idea what I'm doing wrong ? It's working fine on Apple pre Sierra Mail.app with GPGtools.

I'm running MailMate 1.9.6 ( 5344)

Many thanks for you help

Comments and changes to this ticket

  • benny

    benny February 15th, 2017 @ 08:24 PM

    Maybe this requires MailMate to somehow call gpg2 differently. It's not something I've tried myself. You can get debug output (how MailMate calls gpg2) by doing like this in a Terminal window:

    defaults write com.freron.MailMate MmDebugSecurity -bool YES

    You can read more about the gpg2 error codes here.

    Let me know if you think something needs to be changed in MailMate.

  • Dieter

    Dieter February 16th, 2017 @ 09:51 AM

    Thanks Benny.

    So this is what I get on the console:

    type: multipart/encrypted  
    encrypting based on history: 23066  
     gpg2 --no-verbose --batch --no-tty --openpgp --status-fd 2 --textmode --armor --recipient "<hostmaster@domain.com>" --recipient "<dieter@domain.com>" --encrypt
     Input string (49): "Content-Type: text/plain; markup=markdown\r\n\r\n"
     Result: Failure
     Output string (0): ""
     Detail: gpg: <hostmaster@domain.com>: skipped: No public key
     Detail: [GNUPG:] INV_RECP 1 <hostmaster@domain.com>
     Detail: [GNUPG:] FAILURE encrypt 9
     Detail: gpg: [stdin]: encryption failed: No public key

    then i tried removing the <> from my address ...

    dieter$ gpg2 --no-verbose --batch --no-tty --openpgp --status-fd 2 --textmode --armor --recipient "<hostmaster@domain.com>" --recipient "dieter@domain.com" --encrypt  
    gpg: <hostmaster@domain.com>: skipped: No public key  
    [GNUPG:] INV_RECP 1 <hostmaster@domain.com>
    [GNUPG:] FAILURE encrypt 9
    gpg: [stdin]: encryption failed: No public key

    so that failed too

    then i tried removing the <> from the group address too:

    dieter$ gpg2 --no-verbose --batch --no-tty --openpgp --status-fd 2 --textmode --armor --recipient "hostmaster@domain.com" --recipient "dieter@domain.com" --encrypt  
    -----BEGIN PGP MESSAGE-----

    bingo.. that worked !!

    so when resolving groups, addresses wrapped in <> do not match existing group entries !!

    any idea how to get that fixed ?


  • benny

    benny February 16th, 2017 @ 09:59 AM

    What if you include the <> in the group name in gpg.conf?

    MailMate doesn't know that it's a group email address and cannot know that it should call gpg2 differently. In other words, I don't currently see how this works in Apple Mail.

    We can probably hack something, but it seems like there's something I haven't understood or am doing wrong.

  • Dieter

    Dieter February 16th, 2017 @ 02:56 PM

    Well, if I put the "<>" around the group names inside gpg.conf, then it works.

    But... the whole company is encrypting their emails and so all email lists are defined in everybody's gpg.conf and because of the global scope, the group definitions are generated for the whole company. Thunderbird and GPGMail seem to be able to deal with it. Not sure how they call gpg2 though.

    Also the documentation of the "group" definitions does not mention the "<>" at all.

    Only this:

    # Group names may be defined like this:
    #   group mynames = paige 0x12345678 joe patti
    # Any time "mynames" is a recipient (-r or --recipient), it will be
    # expanded to the names "paige", "joe", and "patti", and the key ID
    # "0x12345678".  Note there is only one level of expansion - you
    # cannot make an group that points to another group.  Note also that
    # if there are spaces in the recipient name, this will appear as two
    # recipients.  In these cases it is better to use the key ID.
    #group mynames = paige 0x12345678 joe patti

    I assume you have had issues with matching the right key in cases where the given address possibly matches another substring ( i.e. "win@domain.com" would match "darwin@domain.com", if you're not using the "<>" to define the beginning and end of the string).

    I'm not sure how Thunderbird and GPGMail is doing it, but adding the "<>" to the generated group files could possible break things somewhere else.

    Is it possible to configure MailMate to call a script instead of "gpg2" ? I might be able to sort thing there and at the end call gpg2 from it. Just a thought.


  • benny

    benny February 17th, 2017 @ 10:28 AM

    I don't think I'm using <>, because I had a specific issue with a wrongly matched key, but I think the documentation clearly states that I should use <> when I know it's an email address.

    It's tricky how to best handle this. I don't think I should drop the <>. A quick test shows that both of these give the same result:

    --recipient "feedback@freron.com"
    --recipient "mm-feedback@freron.com"

    It might not often be a problem, but it could be a big problem when it does happen.

    You could replace the gpg2 command with a script, but it would of course be better if we could come up with a solution that would work in general.

  • Dieter

    Dieter February 17th, 2017 @ 10:45 AM

    Yes, exactly. We have seen similar things happen and therefor generate the groups using the key-ID instead the email address.

    Also I agree to not drop the <> because I'm sure it will cause more trouble than it fixes.

    In order to understand why this has stopped working on the recent GPGMail beta for Sierra, I have added a bunch of "print" statements to the code and compiled it. They seem to read the groups from the gpg.conf file to a internal array when the app starts and so "know" the defined groups. So it would be then possible to pass groups without <> to gpg2. Maybe a doable approach ?

  • benny

    benny February 17th, 2017 @ 10:49 AM

    Yes, I considered this. This would be a “safe” solution. Googling I found out that I could get the list like this:

    gpg2 --with-colons --list-config group

    It's just a bit annoying that such a workaround is necessary when group names could just include <> :)

    You can also use <> in the group lists. I don't think you need to use key-IDs (but it's of course safer if you want a specific key for each email address).

  • Dieter

    Dieter February 17th, 2017 @ 11:04 AM

    I have to support a heterogeneous environment and as far as I remember using <> inside the group definitions did not work on all clients. So we went to use the KeyIDs instead.

    Right now I generate 3 lines for each group:

    ( faked example ) dieter$ grep hostmaster gpg.conf
    #group hostmaster@domain.com=dieter@domain.com johndoe@domain.com group hostmaster@domain.com=0x12233445 0x45566778
    group hostmaster@domain.com=0x1223445 0x45566778

    One as comment, one for most of the clients and one for MailMate :)

    Which makes the gpg.conf 60kb large :-/

    Would be cool if I could get rid of the 3rd line.

  • Alex Veer

    Alex Veer March 1st, 2024 @ 06:42 AM

    The mindfulness and meditation practices at our Noida rehabilitation center promote mental clarity and emotional well-being. nasha mukti kendra in noida

  • Alex Veer

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Mac OS X email client.

Shared Ticket Bins

People watching this ticket