• To configure a keyserver none I have now T6950: Kleopatra: Usability improvements for directory services configuration
• For tarball naming I created T6952: Gpg4win build system: Include commit hash in tarballs from gen-tarball.sh
• For the about dialog I have T6953: Kleopatra: show commit id in about dialog

In T6946#181608, @werner wrote:

The min-rsa option was introduced due because the de-vs compliance allowed 2048 bit until the end of 2023 and we used a trick in our configuration file to switch that relaxed handling off with this year. I don't think that the --ciompliance option is really useful becuase it would also disallow ed25519.

A better option would be an --assert-algo option similar to the --assert-signer which we already have in gpg.

But thanks for reporting! I really like feature requests so please do not feel discouraged to request more features.

Sorry, but this is a "Wontfix" we do not support this by choice. We think that adding photos to certificates both gives a wrong sense like "I know that picture, iit must be this person" and also increases the sizes of the certificates a lot. It is in our opinion a misfeature in the OpnePGP specificationl.

I noticed the Debian bug and was about to answer but a feature request is also a good thing.

In T6708#181592, @werner wrote:

I would also suggest that we show the git last git commit in Kleo's About dialog. That makes it far easier to see what we are testing. The Kleo version numbers are a bit arbitrary.

I would also suggest that we show the git last git commit in Kleo's About dialog. That makes it far easier to see what we are testing. The Kleo version numbers are a bit arbitrary.

Sorry, it was my fault building the test installer.

To be clear: This ticket is only about GnuPG (more precisely dirmngr) and the changes are included in VSD and Gpg4win.

Hi, ebo I would still think this is resolved. Because it was never meant that the user manually enters the value of "none" because there is no hint for the user that "none" is a reserved word. It should either be administratively configured which does not make much sense for Gpg4win or provided by the distribution. If left empty the default of GnuPG should be used. If we really want users to deactivate keyserver access by using "none" in the dirmngr.conf a much better solution would be a checkbox for this. In that case I would open a new issue.

The fix was not included in the Testbuid...

Does not work in Gpg4win-4.2.1-beta178

Example output:

Interesting. I need to look closer at it. I scheduled it for 2.4 but it won't be in the forthcoming 2.4.4. There are still other interesting things on the short list (e.g. timestamping support) but we may do that only in 2.6.

Thanks for the report. It comes right in time for the next release. It might already be fixed due to a lot of changes in the pkcs#12 parser.

I think this is resolved now.

Now you can untar and run

The extra option --debug-allow-pin-logging was implemented with commit rGe43bd2a7a78.

Yeah we should do an ntbtls release. As a core library it does no matter much which workboard we use. Let's remove it the vsd tag.

thats great news! I will test the keyword with Archlinux's Builds System (and Fakeroot) as soon as possible!

I sued the done column because we have not assigned it to any milestone.

Fixed a long time ago.

With rG239c1fdc28dcd0dc7aa5341be7c966da2231642a we now have a socketdir keyword for gpgconf.ctl. man gpgconf and look for that file. Will be released with 2.4.4.

Note that we now have also an option instead of the workaround from 2015

GnuPG 2.2 and 2.4 now have --pcsc-shared option for a user who can control his action in detail.
So, closing this bug report.

@aheinecke as promised, attached some test vectors:

This has always worked on the client site since we implemented keyserver access.

I see no problem to return only revocation packets. Clients must verify them anyway against their public keys and the fingerprint makes this easy. Verification against a primary key delivered along the revocation is more or less useless because that primary key must anyway been looked up in the client's keyring and th local existance of a primary key is anyway required to ask a keyserver for a revocation.

The trick here is that during import gpg tracks those invalid signatures and then tries to apply them to other keys.

Appended. Yes, it is considered an invalid signature and ignored. Anyone can insert an invalid signature. The trick here is that during import gpg tracks those invalid signatures and then tries to apply them to other keys. The use case here is this:

If you need the fingerprint, why don't you take it from the revocation certificate - for many years it is in subpacket 33.

In T6900#180549, @andrewgdotcom wrote:

Hi, Andre.
...

Thanks for the explanation. To me this sounds very reasonable and I think that I am starting to better understand your use case in Hockeypuck.
Having a test example key + the intended revocation update would help at least me to dig into it a bit and see how this might conflict with RFC4880.

I'm curious about the parsing implications of this bit:

Well, the quoted paragraph ended with a

Individual UID revocation sigs are not particularly useful, because they cannot be validated without the original UID. Such things are out of scope.

Hi,
so I talked to werner about this, and of course GnuPG accepts minimal revocations.
A revocation certificate. So that was my point. As he understood you, you wanted to revoke not the whole key but only a single user id but without the user id packet? Sorry I am not really the protocol expert. But for me a revoked key without any user ids sounds to me just like a "standard" revocation certificate revoking the whole key. And as said, that is well within the the Standard and accepted, and even used by GnuPG. E.g. in case of a keyrollover we attach such a minimal revocation certificate to WKD keys when we deliver key updates.

From a technical standpoint I think the most minimal revocations which are technically possible should be accepted and thus I endorse the feature request.

In any case this is technically required

Actually the public key is personalized data as much as a mail address. In any case this is technically required and users take an informed decisions when they distribute their public key to a site not controlled by them.

Just to clarify, above ticket does not reflect my Opinion. It is a direct quote from a different ticket. It is my expert opinion that a combination of "Name <email> + Cryptographic Data" is not a personalised dataset since anyone can create it. But let us please not argue about that.

In T4393#180500, @andrewgdotcom wrote:

Perhaps we need to open a new issue for this, to keep the discussion more focused?

@bernhard Following up on discussion elsewhere:

Werner and Tobias are both correct. If a new subkey is generated from scratch then gpg uses the current time as key creation time and sets the expiration date (in the internal in-memory representation of a public key) to the key creation time plus the expiration value.

Sorry, I should have been more precise in my description of the problem. Specifically with --quick-addkey, gpg's behavior seems to be that the expiration, when given using seconds=... is treated as seconds from now.

FWIW, when updating the expiration time gpg does this:

My explanation of gpgme's behavior was not quite correct: Specifically in the QGpgMEQuickJobs for creating (sub)keys, the API uses QDateTimes, which are then converted to seconds since epoch.

That's both not correct. gpg takes the expiration time in seconds since creation time. For a new key this is close to the corrent time but not really. For an prolonging an expiration, this is of course different - the creation time of the key needs to be taken in account. I recall that we once had a discussion and agreed to keep it at time after the creation of the key. This avoids problems with the expiration going negative.

We could also use this for T6874: Kleopatra subkey management improvements

I think this works as intended now with the new certify interface. Also if you grant a key full ownertrust as now is the only option the self certification automatically becomes valid so this then shows as certified.

Just my five cents:

This is a generic parent task and does not require workboards for specific branches.

So as a replacement for what we have in Kleopatra this would work.

So with my ryzen 9 on tumbleweed:

For a very long time i would have agreed with you. But i now understand the usecase. You misunderstand that feature just like i had. It is not about checksum verification or checking. It is for detecting changes in folder trees so that you know when to reencrypt and update your encrypted archive of that tree. Yes this could be done somewhere else but the usecase is valid for kleopatra.

I would rather like to see the checksum stuff be ripped out of Kleopatra into a simple standalone app. It's complete overkill to start the Kleopatra battleship if the user just wants to calculate or verify a checksum of a downloaded file. The UI of the checksum tool in Kleopatra is anyway still not accessible (T6099: Kleopatra: Make checksum verification accessible). How about we redesign the UI from scratch with accessibility in mind from the start?

The tobias/gpgsum branch in gnupg now contains my implementation of this. Together with the attached patches to kleopatra and libkleo, it can properly handle unicode filenames on windows. I'll put those patches up for review at KDE in the next days.