Ok. Thanks for testing. That confirms my suspicion. rOdd3ff8397aaf62e58fa9405ddc5397cb6bcfdc29 is to blame here with the setReadFlag line as the specific cause. Because it is intended to trigger a save back. The problem was that we had circumstances where other addins changed the mail and really wanted it to be saved back to the server. So we call "save" before decrypting the mail to ensure that these changes are saved and then we decrypt, put in our temporary plaintext and ensure that the plaintext never is saved.

Do you know if this is something new that started to happen with 4.2.0 for the first time or did it happen with 4.1.0, too?

My question would be, should we try to improve KConfig in some way which makes it easy for us to do this? I think we should, if this is a common problem for many applications. Maybe a task for sune?

Yes, since we also don't have a ton of "temporary" changes (except for window geometries) such a behavior would make the most sense.
Does it even make sense for us in these places to use KSharedConfig?

In T5903#174528, @ikloecker wrote:

OpenPGP keys are now also updated via WKD, but only for user IDs which were originally retrieved via WKD (i.e. which have origin WKD).

Importing certificates now raises the mainwindow the same way as previously "--import-certificates" would have done. To have it raised even before the job is started gives the widget a bit of a backdrop with the progress and result.

Ah and we should remove the help button in case the PDF Group config help is not available (e.g. on normal linux systems) because opening the kleopatra handbook does not make sense when there is no documentation about groups in there :)

I am giving this wishlist priority for now.

For the record I tested it on Windows that this now saves the config when logging out.

No problem ;) Sorry for my snarky reply. Hope it worked for you now.

Noticed this issue was still open. This was resolved.

I think that fixes the biggest issue here as long as kleo is not just killed it should save the current configuration state. Maybe we should add it in some more places explicitly, too where many things are stored in the config, like with the certifydialog?

😂 Skandal! Ein BUG!: "Möchten Sie die Installation ohne Administrator-Rechte fortfahren?" und Sie sagen "Nein". Ja dann brechen wir ab weil sie eben *nicht* fortfahren wollen.

This could have something to do with our changes to g4wihelp.c to adapt to the new plugin API.

You can install Gpg4win without admin rights. It requests "Highest available" rights by default to be installed into the protected Program Files (x86) folder. When you are not in the Administrators group It will install into your home directory much like firefox does. Any maybe if you don't want to leave a footprint installing Gpg4win on the System (without admin rights) where you don't have admin rights is kind of beside the point. You either leave a footprint by the installation or you could just use the installed Gpg4win there.

Regarding PIN, they should be set first.

1. A temporary Admin / User PIN is be generated and stored in gpg-agent.
2. Then the keys are created as mentioned above.
3. The user is asked to set a new PIN and Admin PIN for the card.
4. Optionally set a RESET CODE

For generate new keys we see four use cases

1. Create card and backup card. -> Creates at least two cards with the same keys. Keys might be stored in ram: TODO: Add subtask
2. Full backup of all keys - Allows for copied cards at a later time.
3. Only backup encryption Key. - There is a backup of the encryption key on the computer.
4. No backup - Keys will be generated on the card.

Yes i think we need something like that, maybe shorter like this message is (VS-NfD compliant) encrypted and this message was (VS-NfD compliant) signed by "user.name@foo.bar" as a single line each, with "Details" available. And then in details show some more information like who the message was also encrypted to, ideally with the user ids when we have the keys in the keyring already and not the fingerprints of the keys. Or maybe just a status indication icon like we have in GpgOL which provides more information when you click it or as a tooltip. At the very least we need to make sure that this cannot be faked by e.g. HTML Mails :) so it needs to be removed a bit from the actual mail body.

I would like it if we could show the result list widgets above or below the message contents in the message viewer. Maybe shortened to a single line and then you can expand it to see the details.

A bit related: T6656 when I look at the web interface of an account that uses GpgOL I see these files everywhere. And they should then also be handled by kleopatra but for that they need some file extension that I can link to kleopatra.

Oh, then its back to the backlog

In T6085#162923, @ikloecker wrote:

In T6085#162918, @ebo wrote:

well, when creating openPGP keys with kleopatra I did not see any hints. I do not think that the issue would be vaild for password based encryption. There the common usecase is autogeneration, anyway

Autogeneration isn't viable if an organization has stupid password constraints that the autogenerated passwords do not satisfy. In particular, the autogenerated passwords do not contain any non-alphanumeric characters, but many password policies require such a character.

Eva this was still in the backlog. But I think it is fixed. Can you check please?

Shouldn't this be ok to merge now that our GnuPG builds on CI are fine?

I think that might have been some idea we had before we added --require-compliance and proper display of non compliant signatures in KMail and Kleopatra and wanted to ensure that non compliant signatures are not "Green".
But since this is not a regression we might even consider not changing this in 2.2 anymore but instead do some relaxation how we treat non compliant signatures both for creation and verification in 2.4 I see T6644 as related.

I added my script to find icons, used in our packaging file. It is extremely stupid as it just greps the source for each icon and takes quite a while but it works for me and I can simply run it in the background. This was just a hacky "worksforme" solution, and we probably want to do it differently. Using a single expression for all the icons would already be a large improvement but I just did not care about that. It also does not really generate the -inst files and requires manual work. But since we probably will do it differently in the future anyway I just commited what I have right now. It does not take care of icon removals and so on. So we might need something with a bit more development put into it.

On a related note in T6645 it was raised that it is currently impossible for the user to see if an exported group only contains local signatures which might decrease the value of the export and not be the intention of the person doing the export. Maybe we should combine a check for that with this feature so that you are asked when exporting a group if you really want to confirm all these identities.

Thinking about this, I don't think offering the information exportable or not will help users much. The concept of "exportable or local signatures" should be a technical details that we should not require our users to understand. The intention of defaulting to local signatures and hiding the export under "Advanced" was to give users a way to basically use "Trust on first use" to certify a key for their personal use and honestly without checking the fingerprint. Even though they "should" not do that. If this makes sense for GnuPG VSD is arguable since we have now better spelled it out what "certification trust (ownertrust)" means. So maybe exportable signatures should become the default for GnuPG VS-D? With the classical SKS style keyservers in Gpg4win I tend to keep local signatures the default.

Well better to wishlist this. As a user might still import a bulk of S/MIME certificates.

Yes this is no longer required since we use a script now.

Mmh, ok this does not seem like a regression, at least if I go back to one of my oldest appimages with 3.1.21 I still get ERRSIG.

Since I am not sure if this was really a problem in the first place I resolve it directly.

Yes, I remembered that too when I encountered it in a different place.

Not really, the GnuPG System configuration settings are generated from gpgconf output and there is no tooltip mechanism for that.

Yes I agree, that might be nice to have.

Yes I think that can be safely backported to gpg4win/23.07

Yes I think that can be safely backported to gpg4win/23.07

This won't go into the next release it is too invasive and needs to be very thought through and announced to users. This also needs to be deployed in a Gpg4win first to get user feedback. GpgOL is pretty much done for the summer release of GnuPG VS-Desktop.

I have the website repo now filtered and ready to be pushed but the write access to repos only hosted on phabricator does not work. We probably need repos on playfair.gnupg.org and only then mirror them here. Since werner is currently busy and I need him for that I will do that tomorrow or wednesday. As tomorrow I am on the road.

I have created the repo now. https://dev.gnupg.org/source/gpg4win-compendium/

That was not me. I would much prefer to have the website in its own repo with its own contributors and so on. Maybe we could also do this then.

Ok cool, I think then you can mostly use git-filter-repo to filter out the history of the manual subfolder into a new git empty repo. Just give the word and I can create one here on dev.gnupg.org where you can then push to.
I am not sure what autoconf -o does though? How are the replacements handled which were defined in confiugure.ac etc?

I am reopening this at least for testing as we have reports that another client is facing the issue with recent versions and also with verified mails .

I spent my afternoon with git-filter-repo and while that worked nicely I failed to come up with a new build system for the compendium that worked, I tried to do the full autotools shebang but in the evening I realized that a simple static Makefile would probably be better like with the website branch. But I leave that to someone else. I will now tag gpg4win-4.2.0 as "the-last-compendium" and include the pdfs from that version from now on and just remove the compendium from master.

Works for me.