thanks for following up on this. It does work as designed for a local file that I just tried (see OK1-3), but does not with a file that I receive every month from my mobile provider (see FAIL1-3). It looks like a standard ZIP file though and after removing the „ 2.pgp“ from the filename, double-clicking the file starts the unarchiver.
addendum: I just notice that the file I receive has a .PGP extension instead of .GPG. This used to work though even with the PGP extension.
If I change it to .GPG, the decrypt process also removes the .GPG.
So it comes down to the suite handling the .PGP extension differently now than before.
Luke Le on 21 Mar, 2018 07:17 PM
unfortunately in this case GPG Services does what it is supposed to do, which is used the filename which is recorded in the GPG data. There seems to be a problem with the tool the sender is using. When the sender is encrypting a file, their GPG app will include the original filename in the GPG data. The advantage of this method is, that they could then assign a completely random name to the file (in order not to reveal the content) and when you decrypt it, the decrypted file will be name like the filename of the unencrypted version. In this case it appears, that for some reason the GPG app of the sender recorded the wrong filename.
the handling does make sense if you ignore the fact that .pgp is a special extension since it is the granddaddy of the GPG suite, if you like. I would like to see that compatibility between the two kept.
I get these PGP-encrypted files since years and GPG used to decrypt them back to the original extension of the file instead of keeping the .pgp extension.