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.
Description
Description
Details
Details
- Version
- 2.5.8.38743
Revisions and Commits
Revisions and Commits
| rGTO Gpg4win-Tools | |||
| rGTO1021a2900de3 Add new debug option noSaveBeforeDecrypt | |||
| rO GpgOL | |||
| rO46b7ddbc97a8 Add new option noSaveBeforeDecrypt | |||
Related Objects
Related Objects
- Mentioned In
- T7207: GpgOL: Handle incompatible addins better
- Mentioned Here
- rOdd3ff8397aaf: Extend protection against plaintext syncs
Event Timeline
Comment Actions
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.
Comment Actions
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.
Comment Actions
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.
Comment Actions
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.
Comment Actions
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.
Comment Actions
The debug/workaround option works: When the option is checked, opening the msg file will not change its date.
Comment Actions
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.