Yesterday
Thu, Sep 21
Not sure yes If I rather fix this or do: T6331
No need for QA on build issues.
This is a release blocker for me.
Ingo can you investigate? This is very important because this is a regression caused by the change to pass filenames directly. I wonder if we pass this as UTF-8 and gpgtar needs a fix or if we pass it somehow else.
Wed, Sep 20
There has been another report on the Gpg4win Forum which might be related that mails now cause endless syncs and might even break further when they are saved back to the same exchange server as there is no MAPI to MIME conversion done anymore and other clients cannot read the mime structure.
As eva wrote the problem is that if you decrypt only the archive and not immediately extract it, which is an option for our users this results in a broken extension. And it also looks wrong even at first glance so it does not look like we intended this. Also wouldn't we then need mime types for the tar.p7m tar.p7s, too and tar.pgp?
Tue, Sep 19
Meanwhile, can you please share how to use the new feature "open the mail from the Kleopatra menu" would be nice to test it.
The most difficult thing here was to actually support the case where the user then sees the keyresolver dialog and selects "yes i do not wish to sign" this never worked.
Now when I try to encrypt to expired certificate this message comes up:
So the default error is now:
Yes I think this makes sense and a little safeguard from weird situtations where users won't know how to resolve a problem. I think we should also check for that when ever a group is opened that it does not contain such keys. In case someone "revoked" there encryption key or more commonly the encryption subkey expired. In that case a message box might make sense telling the user which key / keys are not suitable for decryption.
Mon, Sep 18
Maybe its not a com addin but one of the New JavaScript webapi addins? They have a different menu to disable. Definetly not an outlook feature its this protectit thingy. But have you now Trierdto open the mail from the Kleopatra menu? That is the cool New feature we are currently working on.
Ah wait, in the first of your screenshots it is obvious which addin is modifying your mail so that we don't see it as an encrypted mail anymore. It is that warning text from the protection Addin that you should report that mail if you are unsure where it came from. That would cause such problems because when it inserts this text the type of the mail is changed and it is no longer detected as an encrypted mail.
There in the last screenshot on the right. Btw. since the mail you sent me with the ZIP archive looked also fine to me, there might be another problem here. Could you try disabling your other Addons in Outlook temporarily and check if that might solve the issue? Other addons are also often a cause for some unusual client behavior. You can do that if you go to File -> Options -> Add-Ins -> Manage COM Addins, and then unselect others just for a test.
strange, your test mail in the attachment decrypted for me, too. What happens if you now use the "Show EMail" button?
Please try the following beta: https://files.gpg4win.org/Beta/gpg4win-4.2.1-beta55/gpg4win-4.2.1-beta55.exe This should solve your problem. And if not you can now open the encrypted attachments with Kleopatra and it will show your mail.
Please try: https://files.gpg4win.org/Beta/gpg4win-4.2.1-beta55/gpg4win-4.2.1-beta55.exe This should solve your problem. And if not you can now open the encrypted attachments with Kleopatra and it will show your mail.
Working on both. Beta will come later today, I had one on friday but did not upload it yet and need to recompile it first.
Fri, Sep 15
Thu, Sep 14
I am pretty sure that we can fix that issue and have a beta for you maybe even today or tomorrow. But afterwards we should talk about your company actually using a product with professional support (which you are getting right now from me) like GnuPG Desktop. Gpg4win is basically only "goodwill" support.
Wed, Sep 13
Hi Dan,
Tue, Sep 12
To say this differently, the problem fixed recently which Relaxed detection of encrypted mails might still fix your problem. But the "corruption" of the mail which makes it harder to detect as a crypto mail for GpgOL does not happen when you send a mail, it appears to happen when you receive a mail.
Received, but it is not the same problem at least on your side. Your mail looks perfect. It would have been handled by any version of GpgOL on my side. So I think it is the receiving side meaning your incoming crypto mails are modfied by some middleware in a way that GpgOL does not detect them as crypto mails anymore. But before we debug more here with logs for you, let me finish up some other work on GpgOL and I can probably give you and some others in the tracker here a beta this week where we can then confirm if its already fixed. I'm currently actively working on GpgOL.
Yes the resolution in that issue is "I have fixed this, you need to wait for the next update." The comments above explain the problem, the mail is modified in transit, if you change something there then you can maybe workaround in the meantime. The exact comment I linked gave the instructions on how to assist with analyizing this issue. If you would follow them I could also tell you for sure weather or not this is your problem. https://dev.gnupg.org/T6686#174856
This sounds a bit more like you would maybe better suited with a batch script or command line usage anyway if you always want to encrypt in the same way you don't really need a fancy GUI for that.
Ok. Let me unpack this for you. I think your problem is that now since you switched to your new domain the mails in Outlook are no longer directly decrypted, then you open the attachment and get this message.
I am closing this, for now as this issue lacks actionable details, we would need an example mail or debug data. So my intent is just to close it and reopen if the issue still occurs with Gpg4win-4.2.1
Noticed this issue while searching for a different one.
I think this could be fixed with T6686 if it has not already been fixed by a previous change that relaxed the detection of the encrypted message part better.
Mon, Sep 11
Nah sorry, that sounds a bit too much like you are messing with administrator rights. The way how you install it can have nothing to do with that, it must be a different issue, but it sounds to me like you are messing with privileges a bit too much. Did you ever receive the warning of Kleopatra that you are running it as Administrator and that will mess up the rights in your GnuPG folder? Be honest. :)
You mean if you right click on a file and select sign & encrypt or if you choose the action from Kleopatra?
For another user this change caused endless syncs. Since I do not yet see a way to fix this without risking again that the plaintext leaks to the server under some circumstances, because the problem is that I still do not know how to reproduce these circumstances, my plan is to at least add an option in the debug tab of Kleopatra to disable this "save back" feature.
Fri, Sep 8
This looks to me like the typical thing where you also do not get the "Diagnostics" button viewed. Because log-file is set in the various .conf files and the stderr does not get back to GPGME / Kleopatra so we have nothing to show there because the actual error ended up in a log file.
Btw. if the keyserver is set to "none" or whatever the new value is worded we should remove all the publishing options from the UI. But that is a different issue, I just noticed this while talking about this ticket.
If I revoke a certificcation I am asked to "publish revocation".
When certifying there is the checkbox to publish.
Tested with current version. Works.
Thu, Sep 7
Wed, Sep 6
I misunderstood the issue. When I created the GnuPG VS-Desktop package I did not wrote a qt.conf file which thanks to our patch https://dev.gnupg.org/source/gpg4win/browse/master/patches/qtbase/0001-Gpg4win-qstandardpaths-patch.patch caused all config files for Gpg4win to be placed under %APPDATA%\kleopatra. This was by accident since it uses NSIS FileWrite and FileWrite is not supported in our NSIS to MSI packaging.
/home/aheinecke/dev/main/src/gpg4win/src/playground/build/libkleo-202309061056/src/utils/gnupg.cpp: In function 'QString Kleo::stringFromGpgOutput(const QByteArray&)':
/home/aheinecke/dev/main/src/gpg4win/src/playground/build/libkleo-202309061056/src/utils/gnupg.cpp:573:53: error: passing 'const QByteArray' as 'this' argument discards qualifiers [-fpermissive]
573 | const auto s = fromEncoding(cpno, ba.replace("\r\n", "\n").constData());
| ~~~~~~~~~~^~~~~~~~~~~~~~
In file included from /home/aheinecke/dev/main/src/gpg4win/src/playground/install/include/QtCore/qstring.h:50,
from /home/aheinecke/dev/main/src/gpg4win/src/playground/install/include/QtCore/qhashfunctions.h:44,
from /home/aheinecke/dev/main/src/gpg4win/src/playground/install/include/QtCore/qlist.h:47,
from /home/aheinecke/dev/main/src/gpg4win/src/playground/install/include/QtCore/qstringlist.h:41,
from /home/aheinecke/dev/main/src/gpg4win/src/playground/install/include/QtCore/QStringList:1,
from /home/aheinecke/dev/main/src/gpg4win/src/playground/build/libkleo-202309061056/src/utils/gnupg.h:16,
from /home/aheinecke/dev/main/src/gpg4win/src/playground/build/libkleo-202309061056/src/utils/gnupg.cpp:18:
/home/aheinecke/dev/main/src/gpg4win/src/playground/install/include/QtCore/qbytearray.h:738:20: note: in call to 'QByteArray& QByteArray::replace(const char*, const char*)'
738 | inline QByteArray &QByteArray::replace(const char *before, const char *after)Mon, Sep 4
Well 5.4.2 o.O and we on Tumbleweed are at 13.x gcc
So I think that the problem here is that ArchLinux either does not build Qt6 with -fPIC or it does and others don't and that our check for wether or not to add -fPIC is not really working as it should. When compiling executables we should also add -fPIE instead of -fPIC.