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.

OK, still the whole usage stuff screams for a flag style api IMO. With all the canX then reduced to checking for the according flags internally.
@werner I am assigning this to you for triage. Basically set it to wontfix or whishlist if you think it would be worthwhile or not for future canHazCheezeburger things

But shouldn't we then rather rename the shortcut of Kleopatra to: GnuPG VS-Desktop - Kleopatra ? That would make it discoverable under both names.

werner I strongly disagree here. There is no need for this for our software on Windows and that is definitely not the Windows way, esp. with our current feature set. Do you really think a user wants to start "GnuPG VS-Desktop" to then have a selection between Okular, Outlook, and Kleopatra? That is not how this works at all. Definitely not High priority for us if you think Kleopatra is too hard to discover then we could add another start menu entry for Kleopatra called "GnuPG VS-Desktop" but a starter that only offers to switch between Okular and Kleopatra currently does _not_ have high priority, For windows this is solved with the windows registry, If you want to make Okular - GnuPG Edition your default PDF reader you can, similarly for Kleopatra and please also keep in mind that a user wants to "Encrypt" or "Decrypt" a file. And does not necessarily care about Kleopatra.

I do not find this that important because while users tend to repeat actions to ensure that they are _really_ done (e.g. my nephew always saves games twice to ensure that it really was saved) no real harm is done here.

without understanding more of your setup, which user starts it with which rights and when and so on we cannot really help you here. This is a classical support question. You might want to check the permissions on the lock file. Maybe they are created by a user with higher privileges e.g. to interactively manage the keys, and then the batch user comes along and does not have the permission to obtain or create the lock file. My suggestion would indeed be to use the --homedir parameter in the batch script and ensure that the user has full access rights to that folder and no "Adminstrator" messes with the files / permissions in there.

While the DBus problem is interesting and I want to further investigate this, I think the real question or feature we need to have here is to attach multiple "UI Processes" to an AppImage environment. So that you can have an Okular, KMail and Kleopatra running in your VSD environment without going through the console.

I am pretty sure what I want to do here. There is no way around .desktop files if we want to have proper linux integration. Otherwise you cannot for example have okular gnupg in the "start with" menu. It is something like the Windows registry integration. Or make KMail with GnuPG Desktop your default Mail client etc.

This fix was pretty minimal and I could test:

This works now for me and all the examples I have for the customer. With https://dev.gnupg.org/rO0fc4b87a946dd634d4b61d4e8cb0ad6164faa83c it looks to me in KMail like KMime might handle the transition between different encodings / languages not correctly in continued parameters.

werner do you have any idea based on the information from the original report where we could start looking for this?

I also see this from time to time, mostly when the keyring is empty or very small. But never was able to reproduce it. I thought this might be fixed with keyboxd but if you say that scdaemon might be the culprit then I might misunderstood the issue and it is not the keyring loading that is stuck but maybe rather our configuration initialization which queries the config of each component and is also part of the "Loading certificate cache.."

Thank you. I think it is good that we have now the time to attack some of these more difficult problems :) I don't understand the code there so don't expect a review from me.

Oh wait. That shows a Problem in our side. We should include the full chain in our signature. I am renaming your task and will at least investigate if we do or if that maybe changed the last time we updated the certificate. Which might have been after 4.0.3

I won't go so far to try to fully implement RFC2231 in the rfc822parse. But I have an idea how to implement this in a secure and robust manner in rfc822parse without touching the parser or the token stuff. My idea is to treat them as seperate TOKEN and then combine them in query parameter just for name and filename values.

this is not true. Our installers are always signed, even the included binaries are mostly signed.

Right, I had briefly uploaded a "GnuPG-Desktop" appimage but then realized that for the gnupg.org download site the "GnuPG-Foo" was actually the correct version. Werner and me discussed the future of that version and there will be some changes for future releases which I won't go in there. But functionally it is the same, only the VERSION file differs.

From my side this can be closed. In Kleopatra we can maybe check for some more MIME types and then use GPGME_ENCRYPT_NO_COMPRESS but that is unreleated.

@ikloecker I think your logs contain only false positives, I do not know that we use any defines created by config.h. Maybe for gpgme_off_t but even so when I moved gpgme++ and qgpgme from kdepimlibs into the GPGME repo I did not add any defines to configure for that.

Fixed with c6e16e403744ca39a24a38f38264865019c0cb93

Hi Carl,
yes I saw that test case. Btw. I don't really think that this comes from Outlook itself otherwise I would have seen this much earlier, the current MIME Parser in our Outlook Plugin is about 8 years old. Currently this comes through some kind of AppleMail (server?) application to the customer.

I realized again how bad the current implementation is last week when Alexander managed to send a mail to me encrypted with a completely unrelated key.
a) It was not clear to him that he encrypted to a totally different key because it only displays the keyid
b) He somehow managed to store that key for me in the addressbook
c) He again selected something like "always encrypt to this user" in the dialog without realizing the consequences. This created a contact for me in his personal address book (invisible to him because he said he does not use the addressbook and in there all sources were unselcted) which had the wrong keyid (again only the fingerprint there) and the setting "always encrypt to this user"