Hi,

Thanks for your report. With gpg4win-2.3.2 we addressed that problem. See also
issue2319 which was also about this problem.

Please let us know if you still have that problem with 2.3.2 I could reproduce
it in testing and with the fix it no longer happens so I'm hopeful this can be
resolved :-)

Regards,
Andre

Duplicate of T2319

With 2.3.2 the fix was released.

With 2.3.2 we've fixed another bug that sent mails were still handled by gpgol
even when s/mime was disabled.

So far I know of no other problems -> Resolved.

Fix for the difference in detection of armored vs. binary detached signatures
was trivial so I've pushed it with rev. 570bf2a

Looks good to me know. I'll start using it in Kleopatra and we will see what
breaks :-)

Have not tested different S/MIME messages yet.

Talked to werner about it. The way something like trust-model should be
switchable would be best to handle with profiles.

There is at least one profile planned for EasyGPG. Something like "Silent" or
automated. Riseup and VSNFD will probably also want to create profiles.

I think apply-defaults could be extended for this with a defaults file for each
profile.
Then something like:

gpgconf --list-defaults

    List all available default files.

Where the output format could be similar to list-components.
name:description:filename:

filename is the path to the config file.

Then --apply-defaults could be extended to take an optional filename as an
argument. (Like --list-config, --check-config)

With --dry-run it should only check if all the settings marked as no-change are
set correctly and indicate it through the return code.

For EasyGPG I think a config file could be:

• gpg-agent max-cache-ttl [change] 30758400 gpg-agent default-cache-ttl [change] 30758400 gpg trust-model [no-change] tofu+pgp gpg auto-key-retrieve [change] gpg auto-key-locate [change] local,wkd,dane,pka,cert,keyserver

Fix commited to master with rev 643575f

Thanks.

I've created some examples to test it. They are all done with alfa@example.com
test key. Found an issue through that.

-ba (detached ascii armored signature) is detected as PGP-Signed and not as
PGP-Signature.

examples/plain.txt.asc: PGP-signed

A discussion about KMail handling PGP/Inline encodings [1] also makes me wonder
if data_identfiy should also return the output charset of text messages if it is
provided in the Armor Header. Afaik there is currently no API in gpgme to check
this and semantically It would make sense to me to parse this in identify, too.
But this is more of a question wether or not you think it makes sense to do this
directly. I'm not strongly opinionated about this.

1: https://bugs.kde.org/show_bug.cgi?id=248058

Would it be possible to also detect if data should be decrypt_verified or just
verified?

I'm having trouble with PGP MESSAGES that can be either encrypted or Opaque
Signed, or nothing.

If I do a decrypt_verify I get a No Data error in the result because decryption
failed. Should I just ignore No Data error and check for the status of the
signatures in that case?

Thanks for applying them.

@bernhard
I did not change it to LDAPv3 first to be conservative regarding maximum
compatibility with the least regression risk. And because I don't have a v2 Only
server available against which I could test.

Afaik LDAPv2 vs. v3 is pretty much irrelevant for the calls Dirmngr does.

Imo once OpenLDAP client libraries change behavior to use V3 by default this
should be enough for dirmngr.

D373: 849_0002-dirmngr-Try-ldap-protocol-V3-as-fallback.patch

D374: 848_0001-dirmngr-Print-ldap-error-if-bind-fails.patch

I've analyzed the Problem dirmngr_ldap failed with a Protocol Error which was
hidden because the error output used errno instead of the ldap error.

Attached patch fixes the error output.

The Protocol error was because:
"historical protocol version requested, use LDAPv3 instead"

I'm not sure if dirmngr should try LDAPv3 first and fall back to LDAPv2 but the
Patch I'll attach in the next message adds a fallback to LDAPv3 if the ldap_bind
with the default protocol leads to a protocol error.

The endless activity / failing to notice that the dirmngr_ldap has already died
after the failure I leave for someone else (another issue I guess) as I've
already failed to fix this once :-)

Just noticed this issue as it was mentioned in T2359 which is "my" issue
about this topic ;-)
I've actually implemented the algorithm outlined in T1143 (dkg on Sep 23 2009, 06:53 PM / Roundup) in libkleo/ QGgpME
for a better opportunistic encryption support in kmail (
https://phabricator.kde.org/T2520 )

Werner told me that something like that will be done in GnuPG itself. Afaik the
current plan is to have --locate-keys use a similar algorithm to return exactly
one "best" key if a mailbox is given. And if I understood werner correctly this
would then also be the key used when you would do a "gpg -er <mailbox>"

Should this be closed as Superseded?

Replacing revoked keys made me wonder if we actually need an auto-refresh key.
If we try to return one valid key with --locate-keys wouldn't it make more sense
semantically if we use the auto-key-locate mechanisms with locate-keys when a
key is expired in the local store?

This would also work better for revoked keys where a Parcimonie style auto
refresh would pick up the revocation and locate-keys would then look for a new key.

How do you plan to handle the case that "local" lookup only yields expired or
revoked keys. Will GnuPG then automatically fall back to other locate-keys methods?
This would be my wish so that a MUA / User of that command does not have to care
about that case :-)

Hi, thanks for testing master.

I can semi reproduce this. For me it works the first time but a second call to
getpin fails.

$ ./pinentry-gtk-2
OK Pleased to meet you
getpin
D hello
OK
getpin

• (pinentry-gtk-2:29090): CRITICAL **: could not grab keyboard

ERR 83886179 Operation cancelled <Pinentry>

And indeed this goes away with f4b5049c68a79d5e4faba06447db5440936cefeb~1

Looking at the code I don't see a reason for this. Maybe the dialog?
The code without the dialog 71b51e02cf20174ba7144765e985f7e889eaa429 also allows
me to repeatedly call getpin.

Werner: Any idea? I'm a bit clueless which change in the patch could have caused
that.

Ok,
Let me summarize how I understand the workflow is supposed to be:

• Generate a Key with the limited batch keygen.
• After key creation add subkeys as wanted with --quick-addkey
• Add additional UID's with --quick-adduid

I think I can work with that.
For full flexibility T2364 would be nice so that one could create a certify
only key this way and subkeys for everything else.

But yeah thats icing on the cake.

Still does not solve the Problem how to figure out which algrithms with which
parameters / capabilities are supportet but meh, I guess you can't have everything..

No, I'll do a Version check in for the GnuPG Version in Kleo master and I won't
backport any changes to the KDE4 / Gpg4win stable variant.

I'm assigning testing to me, I'll test it by using it in Kleo :-)

The best solution I can see is to keep CURENT and TOTAL in gpg below 2^31.

Ok, this would work for me, too.

CRL detection is not really important. But detection of binary data is so that I
can properly handle .pgp and .gpg file extensions.

Detached signatures are also important so that I can look / guess for the signed
data and setup the verify operation accordingly or handle it in the GUI if no
Data is found. Maybe we can use flags for this so we don't break the current
behaviror that does not distinguish between detached signatures?

Tracked at: https://bugs.kde.org/show_bug.cgi?id=363309

The algorithm I'm using now to detect the best key from a locate-keys result is
(Q_FOREACH just means "iterate over all elements in this list"):

Key keyC; /* The key candidate */
UserID uidC; /* The uid candidate */
Q_FOREACH (const Key k, keys) {

if (canEncrypt && !k.canEncrypt()) {
    continue;
}
/* First get the uid that matches the mailbox */
Q_FOREACH (const UserID u, k.userIDs()) {
    if (QString::fromUtf8(u.email()).toLower() == mailbox.toLower()) {
        if (uidC.isNull()) {
            keyC = k;
            uidC = u;
        } else if ((!uidIsOk(uidC) && uidIsOk(u)) || uidC.validity() <

u.validity()) {

            /* Validity of the new key is better. */
            uidC = u;
            keyC = k;
        } else if (uidC.validity() == u.validity() && uidIsOk(u)) {
            /* Both are the same check which one is newer. */
            time_t oldTime = 0;
            Q_FOREACH (const Subkey s, keyC.subkeys()) {
                if ((canEncrypt && s.canEncrypt()) && subkeyIsOk(s)) {
                    oldTime = s.creationTime();
                }
            }
            time_t newTime = 0;
            Q_FOREACH (const Subkey s, k.subkeys()) {
                if ((canEncrypt && s.canEncrypt()) && subkeyIsOk(s)) {
                    newTime = s.creationTime();
                }
            }
            if (newTime > oldTime) {
                uidC = u;
                keyC = k;
            }
        }
    }
}

}

The helper functions to check if a key / subkey / uid is ok are just:

static bool keyIsOk(const Key k)
{

return !k.isExpired() && !k.isRevoked() && !k.isInvalid() && !k.isDisabled();

}

static bool uidIsOk(const UserID uid)
{

return keyIsOk(uid.parent()) && !uid.isRevoked() && !uid.isInvalid();

}

static bool subkeyIsOk(const Subkey s)
{

return !s.isRevoked() && !s.isInvalid() && !s.isDisabled();

}

Ah nevermind. I think myself that this is nobug and current behavior is correct.
There is a mechanism for the redundant setup that we want to have already and we
need to use it instead of doing something undefined.

D364: 829_0001-Dirmngr-Treat-multiple-crlDPs-as-redundancies.patch

Ah, the world of S/MIME related RFCs,.. Fun.

From RFC 5280 4.2.1.13. CRL Distribution Points:
If the DistributionPointName contains multiple values, each name
describes a different mechanism to obtain the same CRL. For example,
the same CRL could be available for retrieval through both LDAP and
HTTP.

So the short Answer is. Intevation's certificate is bad. If we want to mark that
our Certificate Revocation lists are Redundant then we should have used a list
in the crlDP and not multiple crlDPs. This GnuPG would handle correctly.

Before I noticed beforementioned bit I've tried to fix it in GnuPG. And I think
it might be an improval as the same section also says:

If the DistributionPoint omits the reasons field, the CRL MUST
include revocation information for all reasons. This profile
RECOMMENDS against segmenting CRLs by reason code. When a conforming
CA includes a cRLDistributionPoints extension in a certificate, it
MUST include at least one DistributionPoint that points to a CRL that
covers the certificate for all reasons.

So If we have one such list we don't have to fetch all crlDP's and error out if
one can't be obtained.

I've attached a patch for that but I can fully understand If you don't think
this should be applied as the current behavior is mature and conforms to the RFC
already. In that case you can resolve this as "nobug".

Thanks for the clarification. I'll ignore it in QGpgME then, too.

And after grepping for KEYEXPIRED in doc I have now found the DETAILS
documentation of which I was unaware until now. :-)

D366: 825_fix-in-gpgmepp.patch

Note to self.

The problem is that editinteractor in edit_interactor_callback_impl checks
status_to_error before the GpgSignKeyEditInteractor::nextState implementation
has the chance to ignore that status with needsNoResponse.

A fix in GpgMEpp could be to ignore the error if the state machine was not
started. E.g. we have not yet send any command.

Attached patch fixes the problem. But I'm not sure that this does not cause
regressions e.g. when trying to add a uid to an expired key or trying to
actually sign expired uid's. :-/

I can make "a" problem (not sure if it is "the" problem) reproducible with the
following command (as root):

AUTHFILE="/sys/bus/usb/devices/4-1.2/authorized" ; echo 0 > "$AUTHFILE" ; sleep
1 ; echo 1 > "$AUTHFILE"

This was based on:
http://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line/61165#61165

where 4-1.2 is the id of my reader. The error message in scdaemon log is
slightly different but the behavior is the same. It's in an error state until I
kill it.

Just as a note, this bug is for the "MIME Aware" interface with event driven
sign / encrypt.

I don't have a test setup for that. Kleopatra currently polls gpg-agent if a
smartcard is available.

According to Gniibe this might be causing this problem. I'm planning to change
that to switch to looking for readerstatus files that are created when a
smartcard becomes known. But this still might cause the smartcard to be locked
by scdaemon? I'm not sure.

I've now also mentioned that the current one is used since April 2016 and listed
the previous certificates.

Indeed, thanks for the report, I've updated the information for our new
certificate that we've used for 2.3.1

Sorry for the confusion caused by missing that in the first place.

I've now pushed a patch to the GTK variant based on werner's original work with
the message box and the string button labels.

I was unable to get the tab order working correctly so that the visibility
button comes last in GTK. I've tried it with gtk_container_set_focus_chain but
it did not work as expected. When set on the wvbox it disabled tab changes
altogether. When set on the cbbox or bbbox it somewhat worked (e.g. when I
removed a widget from my list it was no longer tabbable) but it would not add
the repeat edit and the visibility toggle button although both were part of my list.
Probably a problem because of the sublayouts?

I noted this in the code so if someone wants to change that you are welcome :-)

I know your first draft.

But from the discussion here and back then I took that draft to be no longer up
to date and that the MessageBox Question approach with small icon buttons is not
wanted.

I also don't know where we agreed that an Eye icon is a bad idea for this action.
This icon in similar to the one of the Windows Login screen and the same one
used in KDE. So it is recognizable for this action.

If you strongly favor the Message box variant I can change it to that.