It worked again, attaching the screenshot. Unfortunately had disabled the logging and hence no log info.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 2 2020
No plans to work on this.
Long since resolved.
For linking the MSI installer we already need a windows host and a windows sign host. The binaries inside that package we also sign usign the signhost / signkey which can be included in an optional / custom sign.mk during the build process. By default the path to the included sign.mk is gnupg-vsd/sign.mk in the src repo. But that can be changed of course.
Ah no, this is about the sending part, where we only encrypt to online validated keys, that is not mitigated at all. Disregard my last comment.
This is resolved with the preview feature in GpgOL-2.4.6 Gpg4win-3.1.12
I could find no issue with the error handling for verify errors.
Nov 11 2020
Released with GpgOL 2.4.6 ang gpg4win 3.1.12
Oct 6 2020
Hi Zetrick,
Hi Zetrick,
Sep 4 2020
Sep 2 2020
Aug 12 2020
Further analysis shows that this only happens when async crypt is enabled.
Aug 7 2020
Aug 6 2020
To be honest I have not tried that but it should work because then it has another 50 tries to find a name like "attachment_51.txt" because we stay in the loop.
I'm not sure what to do with the issue. For further analysis we would need to figure out what third party software breaks the MIME structure of the mail. That is more something for a support contract and not for the general issue tracker. This issue is very specific to your setup and so I'm not surprised that Microsoft says it can't help.
3.1.12 was released with this.
Jul 27 2020
Still an issue, just noticed that with the 3.1.12 release announcement, it really looks ugly.
Jul 20 2020
Dear gnupg developers.
I have contacted the Microsoft to get their analysis as well.
A Case #:20812681 has been registered. Where Microsoft stated that third party developers of plugins like GpgOL have their channels and should contact Microsoft directly in cases like this. Further analysis has been denied to me.
Jul 16 2020
Jul 14 2020
Thank you very much for working on this issue.
I think there might be a problem with your fix, if there is a mail arriving with
more than 1 attachment with invalid filenames. I expect all but the last
processed attachment with invalid filename will be overriden by this fix. I
think this will happen very rarely but maybe it is worth consider this also.
Of course I may be totally wrong with my thoughts as I'm not a programmer and
don't know how gpgol is handling attachments in mails.
kind regards
Helmut Häfner
I can reproduce the issue. GpgOL creates a temporary file using the original filename and that fails because the pipe is one of the invalid filename characters on Windows / NTFS.
Jul 9 2020
Jul 3 2020
Jul 2 2020
Thanks,
I edited the task and now you can edit it too.
Hi,
could you please change the edit policy back to all users so that I can change the status of this task?
Jun 5 2020
MAPI Namespace has a pickFolder method which can be used here.
Jun 2 2020
The problem is with the code for T3656
Thanks for the report. I can reproduce this by replying to S/MIME enc & sign mails.
May 19 2020
This was implemented 0d2db8b81ab24e2ab02d7ba6832cabd07b72f852 in Gpg4win-3.1.11 but does not work reliably.
Closing with Info Needed.
I'm moving this from testing to open again. Especially the deletion is an issue. I had a report that even for a sent mail Outlook.com also stores an unencrypted variant in the "Trash Bin".
May 18 2020
May 15 2020
Thought of a way to at least mitigate it. When a mail is closed we know it's not printing.
After looking at this for 4h I could not see a way to detect it better when a print job is done. So we now treat every ItemLoad of a mail after we have seen the BeforePrint event as a print.
Outlook is a bit nasty here:
May 8 2020
I'm not sure what to do here. The problem is that all users in clients without PGP/MIME Support will see the attachment names. That is why we use the names as they are.
hello
thanks for the feedback
it s indeed exchange 2007 (migration planned on long term)
we will try the imap workaround
There was a similar Problem in the past reported on our mailing list:
From the commit message:
Thanks, I can reproduce the problem. I'll look into it, printing mails is important for some ;-)
Does it decrypt then?
This is not the first report I have gotten about mailstore problems. My suspicion here is that the mail is opened read only or somehow got the wrong properties from mailstore.
Apr 17 2020
Apr 7 2020
Mar 25 2020
FWIW, a log of the decryption process will always show the sender's key because a message is usually also encrypted to that one (--encrypt-to).
Mar 20 2020
Done in master
Mar 14 2020
I think that this chnage is useful enough to be backported to 2.2. Done that.
Mar 13 2020
You can test it now out using GnuPG master: Just add --include-key-block and you can then verify using an empty keyring. Currently --auto-key-retrieve is not needed but we need to think on how we can enable or disable this during verification.
Mar 11 2020
This is now implemented
Mar 10 2020
ftr, here is the thread I had in mind but couldn't recall above. @aheinecke is that your thinking, or a more pgp/mime bound mechanism as @dkg assumed?
@wiktor-k, "just extend the spec" doesn't necessarily work with existing clients, which might be surprised to find unexpected packets in the signature section of an e-mail. It seems more likely to me that they'd be able to handle (meaning: ignore) an unknown subpacket (as long as it's well-formed) than to handle additional packets. But all of these surmises require testing with existing clients, of course. Has anyone done any of that testing?
This is a nice idea and although it overlaps with Autocrypt it has other uses too: for example verification of signed files that can be vastly simplified (just get the file and the signature, no key fetching needed, downside: the key attached to the signature could be stale).
Ah, thanks for pointing out the subpacket option (i guess it could be hashed or unhashed). i don't think any of the subpackets currently defined in RFC4880 supports this use case -- but i guess you could mint a new one, or use a notation.
Werner said that it's possible in OpenPGP to also put the pubkey into the signature. (...) The nice advantage is that this will also work for files.
Mar 9 2020
Hi @aheinecke, thanks for thinking about this, and thanks for tagging me here too. I'm definitely interested.
Mar 4 2020
Feb 27 2020
For the split OpenPGP / SMIME it's not intended to only work for BCC, its just the same mechanism I use internally.
Feb 26 2020
I think this is a great feature to have. Thanks for working on it, @aheinecke .
The idea of the implementation is that BCC recpients will get a mail with no other recipients. Because Exchange / Outlook handles the sending we can't do it more low level. We use the "Protected-headers" scheme to transfer the original To / CC headers.
Feb 5 2020
I renamed the ticket so that others don't think we generally don't support Office2019 because I use it myself and it works for me.
Thank you for the detailed report.
I remember that I tested inline content-disposition handling in Outlook without GpgOL and try to do the same handling as Outlook would handle them. But then at the very least It should be shown as an attachment and not hidden.