that's really cool :) .. I tested now with a mail whole having the Warning message, I press "Show Mail" and it indeed open .. see the pic.
very nice feature indeed.

Meanwhile, can you please share how to use the new feature "open the mail from the Kleopatra menu" would be nice to test it.

Thanks a lot Andre ... I believe it's solved.

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.

I disable all Addons (see screenshots) and restarted the Outlook, but still getting the same warning when trying to open the email.

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.

this is what I'm getting when trying to open the mail then the attachment. Am i missing something?

strange, your test mail in the attachment decrypted for me, too. What happens if you now use the "Show EMail" button?

With Gpg4win-4.2.1-beta31 I can no longer import the secret part of the edward.tester@demo.gnupg.com.p12 Testkey. Error is "Invalid object".

I've installed the Beta version, but issue still exist !!
My encrypted mails are readable by the other party, while I can't read his mail giving the same error msg "Decryption succeeded ......... Note: you cannot be sure who encrypted this message as it is not signed" , while I can read my sent encrypted mails.
see attached.
Any suggestions?

Thanks .. will try it now

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.

Hi Andre,

Thanks Andre for your response..

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.

I tested once more with another person, issue confirmed, he can read my encrypted mail (as you did), however, I can NOT read his emails (with the same error: you cannot be sure who encrypted this message as it is not signed)

Yes, I can decrypt my sent mails, in my Sent folder

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.

I sent the test encrypted email

Thanks once more... and appreciate your swift response.

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

Thank you for your reply.

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.

Hi, it would be great to make Kleopatra remember the last used settings.

Thank you for your time and your answer, we really do appreciate your work. We invested in this in hope to help make the software better. Please try it, so you will see how it works. We were able to reproduce the problem the way I described. When installed as a normal user it won't work. Installed as an Administrator user it works. So the more secure way does not work currently.

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.

this works now:

@ebo: I just a did a test build: gnupg-vs-desktop-3.2.0-beta178-x86_64.AppImage in my directory

That should be easy on Unix but on Windows we have the nul nul: and iirc also /dev/nul.

ack

In T6556#175399, @werner wrote:

@iklocker: Which gpg bug to you mean?

@werner: What do you mean by "We have a fix for now"? Are you referring to @gniibe's patch?

We have a fix for now and thus I lower the priority. Given that EasyPG mimics the GPGME API we should here also use another pipe to convey the passphrase (e.g. for symmetric encryption).

@iklocker: Which gpg bug to you mean?

This is hopefully resolved. Setting to done because the fix cannot be verified with our builds of Kleopatra.

It also doesn't occur with the AppImage (Do we build a debug or unoptimized build for the AppImage?).

The problem doesn't occur with the development build. It also doesn't seem to occur with our Windows build.

Well 5.4.2 o.O and we on Tumbleweed are at 13.x gcc

I found this in the change log of Qt 5.4.2:

- On x86 and x86-64 systems with ELF binaries (especially Linux), due to
  a new optimization in GCC 5.x in combination with a recent version of
  GNU binutils, compiling Qt applications with -fPIE is no longer
  enough with GCC 5.x. Applications now need to be compiled with
  the -fPIC option if Qt's option "reduce relocations" is active. For
  backward compatibility only, Qt accepts the use of -fPIE for GCC 4.x
  versions.
  Note that Clang is known to generate incompatible code even with -fPIC if
  the -flto option is active.

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.

I found this related to that: https://sourceware.org/bugzilla/show_bug.cgi?id=28875

I have analyzed this. In the ribbon we get a mailitem OOM object as reference, but that can be a different pointer then the one we used for decryption / verification. Our trick for this was to assign mailitems a custom uuid property and then look for that from the riboon pointer so that we can update accoringly with our internal Mail object representation.

Fixed. I'll copy the ideas in comment T6698#175165 to a separate task.

At least GnuPG only shows the most recent key signature tag. So if we leave it out when adding another signature then we remove this.

Yes remove this / leave this empty. I think the idea was that if you certify lots of users and wanted to have the same tag. But I guess that would be covered by bulk signing anyway and can actually be more trouble if you accidentally use the wrong tag.

Compiles for me, too with Qt 6.5.2 from tumbleweed.

Fixed. Backport? (Depends on first preparations for bulk certification and is probably not really relevant for VSD.)

The official build for Arch Linux doesn't seem to run into this problem. The Qt6 build is configured with

./configure \
  --prefix=/usr \
  --disable-fd-passing \
  --disable-static \
  --disable-gpgsm-test \
  --enable-languages=cpp,qt6

See https://archlinux.org/packages/core/x86_64/gpgme/

Thanks. For the record, done at https://lists.gnupg.org/pipermail/gnupg-users/2023-August/066692.html.

BTW. you should use gpg --quick-set-expire FINGERPRINT 5y this is easier for scripting. Using
--export-options no-export-clean should keep the old signatures.

gpg only uses the latest self-signatures and ignores old one. Thus I do not understand your problem.

Changed the task description to easier find it

Hi,
This is a classical support question. Please use one of the community channels under:
https://www.gpg4win.de/community.html
for this.

Fixed. Removing Gentoo tag because it's not Gentoo-specific.

It may be better to open a separate issue for the issue in gpg, so that it's not overlooked/forgotten when the issue in gpgtar is fixed.

That is intentional. If we are able to remove a file we do it. Solution for you is easy: gpg .... -o - </dev/null >/dev/null

That is intentional. If we are able to remove a file we do it. Solution for you is easy: gpg .... -o - </dev/null >/dev/null

This looks like the same problem I encountered in Gentoo's Portage. To unlock the binary package signing key, Portage will run the equivalent of gpg --homedir ... --digest-algo ... --local-user ... --output /dev/null /dev/null. If unlocking fails (due to e.g. wrong password), /dev/null is removed: https://bugs.gentoo.org/912808

Needs to be checked for 2.4 - no backport to 2.2, though.

Needs to be checked again with stable. No backport to 2..2, though.

Won't be backported to 2.2 once we got something in 2.4.

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.

I testet it with 4.10 and GggOL 2.5.6. The file isn't changed if I open it. So it seems the change happend in 4.2.0.