Follow up for Q1 is T8166: Kleopatra: Add "Save Secret Team Key" button to success message after creation of "Team Key"

FYI: We had a VSD support case today where the user complained that they thought the Admin PIN would work because of the tooltip text but it was not accepted. They needed to give the PUK, which is consistent with the state given in this ticket.

So this is all done, then. As for the open issue there is T7565: Kleopatra: Add tooltips in sign/encrypt window if an encryption type is greyed out

Looks almost good to me on gpg4win-5.0.2-beta2 @ win11.

I've made the above ticket for Q2. Regarding Q3 we leave it as is, if customers should complain we could then consider changing that.
Regarding Q1: we should talk about that next week. But I'll close this ticket.

Looks good to me on gpg4win-5.0.2-beta2 @ win11.

@ikloecker said (paraphrased by me):

Looks good to me on gpg4win-5.0.2-beta2 @ win11:

Looks good to me on gpg4win-5.0.2-beta2 @ win11:

Looks good to me on gpg4win-5.0.2-beta2 @ win11:

Looks good to me on gpg4win-5.0.2-beta2 @ win11:

Looks good to me on gpg4win-5.0.2-beta2 @ win11:

Tested with Gpg4win-5.0.2-beta2

config file: Sorry, I got confused, it has to be %APPDATA%\GnuPG VS-Desktop\kleopatrarc in this case (VS-Desktop-4.0.90.1203-Beta), of course. And this one works.
Registry entry SOFTWARE\GnuPG VS-Desktop\Kleopatra\CMS\SaveCSRAsPEM does not work, though. But this is a separate issue, seems all Registry entries do not work in that build.

• config file: According to T7717: Location of qt-application config files %APPDATA%/Gpg4win/kleopatrarc should work.
• registry: According to T5707: Kleopatra: Use windows registry additionally to config files this should be SOFTWARE\Gpg4win\Kleopatra\CMS\SaveCSRAsPEM now

Works with VS-Desktop-4.0.90.1203-Beta when putting this in C:\Program Files\GnuPG VS-Desktop\share\kleopatrarc
CSR is then saved as .pem file with ascii-armored content.

Also backported for VSD 3.4.

Now also available in Gpg4win 5.

Ready for testing in VSD 3.3

What about always using PEM for all generated CSRs? As far as I can see, gpgsm command line always uses PEM when generating CSRs.

I haven't tested it, but it looks good

Like this patch?

Meanwhile all executables are signed.

Investigating GNU ld, I learned that there is no easy way (~= no way) to suppress the warnings (other than 2>/dev/null). It was implemented by the special section named gnu.warning.SYM where SYM is a symbol. I think that this is not-so-good for glibc to notify its users about possible static link problem, by gnu.warning.SYM.

Sorry for the ambiguity. The request was only about mentioning (bpX) for the first two choices, not to add more combinations.

Physical experiment feature support should better not be widely used.

Although it is technicall possible to use all combinations, we should limit in the menu them to those as listed above. Too many algorithms pose an interop problem. Thus we provide brainpool because it is required in Germany and the two IETF curves for the general internet (for those who are playing mitigation against against physical experiments).

Note: In vsd it must be restricted to the bp algorithms then

The blue Kleopatra icon is now used for the Windows builds of Gpg4win and GPD and for the corresponding AppImages.

Thanks. Will go int the next version.

Done and backported for VSD 3.4

I misunderstood this, the mail can be forwarded with attachment if you first deselect the mail and then select it again. So the workaround is OK.

We decided to still use the term "Valid" (with description/tooltip "Certificates that are neither expired nor revoked (except disabled ones)"). This matches the use of the term "invalid" for expired and revoked certificates as in "Certificates that are invalid because they have expired (except disabled ones)".

Backported for VSD 3.4

Done. Example (with default text in English and German translation):

[Welcome]
welcome-text[$i]=<h2>Hello, World!</h2>
welcome-text[$i][de]=<h2>Hallo, Welt!</h2>

TL;DR
This ticket was created because building static-linked gpgv shows warnings from glibc for getpwnam and getpwuid.
Basically, we can/should ignore the warnings from glibc at link time (for normal use cases), because it is irrelevant.

Current state in gpg4win-5.0.0:

Let us mark this as a feature requests. gepwnam(3) is a standard libc function and if glibc does not support it; this is more likely a glibc bug than a bug in an application.