Page MenuHome GnuPG

GgpOL: Signed Mails from Filesystem are modified when opened
Closed, ResolvedPublic

Description

Greetings,
as I opened a msg-File from the filesystem, which was signed with GpgOL days ago, the msg-File was changed and got a new change date. The problem is that I develop an application which is using an filewatcher to detect filechanges und compares the filehashes. By opening the Mail and nothing in the mail has changed, the mail on the filesystem changes. I don't know if this is intended, because if you open an mail by mistake, the mail will get a new changedate and a new hash.

Details

Version
2.5.8.38743

Event Timeline

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?

There was a slight change in 4.2.0 that we always call "save" before decrypting the message to additionally prevent it from syncing changes made during the temporary decryption. If that is the case we could maybe workaround this when we detect that the mail is in the filesystem. But if it was also present in 4.1.0 I do not think there is much that we can do to fix this.

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.

aheinecke triaged this task as Normal priority.
aheinecke added a project: Restricted Project.

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.

Now I need to find a way to check if the mail is in a synced folder or a file system and then only conditionally call this, should be doable. But of course only for the next release there is no chance to change that behavior through configuration.

aheinecke renamed this task from Opening GgpOL-Signed Mails from Filesystem to GgpOL: Signed Mails from Filesystem are modified when opened.Aug 28 2023, 7:05 AM

Changed the task description to easier find it

aheinecke mentioned this in Unknown Object (Event).Aug 28 2023, 7:20 AM
aheinecke raised the priority of this task from Normal to High.Sep 11 2023, 8:59 AM
aheinecke moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

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.

aheinecke mentioned this in Unknown Object (Event).Sep 11 2023, 9:02 AM
aheinecke mentioned this in Unknown Object (Event).Sep 18 2023, 9:12 AM
aheinecke changed the task status from Open to Testing.Sep 20 2023, 4:38 PM

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.

So I have now added an option in the debug menu of the GpgOL settings to revert to the old behavior if this creates more problems for you or other then it solves.

aheinecke mentioned this in Unknown Object (Event).Sep 25 2023, 8:52 AM
ebo moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Oct 16 2023, 1:10 PM

The debug/workaround option works: When the option is checked, opening the msg file will not change its date.

Ok then we can resolve this. Because I don't want to change the code there too much since it is about a plaintext leak which we cannot reliably reproduce so any change there we cannot really test if it brings up the plaintext leak again. And for users that have problems with the changing of the mail we can point them to the workaround.

ebo moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Nov 15 2023, 11:09 AM