https://bugs.kde.org/show_bug.cgi?id=248058
--- Comment #9 from Sandro Knauß <skna...@kde.org> --- (In reply to Thorsten Glaser from comment #8) > (In reply to Andre Heinecke from comment #7) > > > PGP Inline is perfectly fine standardised: the display agent has to use > > > the charset indicated by the PGP > > > message, and discard any charset/encoding information of the surrounding > > > message. > > > > No it's not. Especially the Encoding handling is very problematic and not > > standardised. See: https://debian-administration.org/users/dkg/weblog/108 ( > > It is, and especially the encoding is trivial. It’s just often misunderstood > or implemented wrong. > Citing someone who doesn’t fully understand it doesn’t help (I knew that > posting). dkg and andre know what about they are talking - search for references in the internet and what they do inside the openpg project. You will find a lot references to them. > > Inline PGP is easy: the MIME-level encoding is valid for the “outer” part of > the message; for > example, if MIME says quoted-printable then those ‘=’ in the ASCII armour of > the PGP message > are encoded as “=3D”. > In your comment you mix often differnent encodings. in the mail context we have two: - content-transfer-encoding - this is the encoding how the text (that is not ascii 7bit encoded) is modified to be 7bit. This is quoted-printablem base64 or plain. It is out of question, that we have first do decode this before entering the content. This is the "=3D" -> "=" the encoding of the text is more problematic :) We have one field, where we can set the encoing of the mimepart that is the content-type header for a mime part with the charset setting: Content-Type: text/plain; charset="UTF-8" the problem is now, that you are arguing, that gnupg have a defined in/output charset, so that we should ignore the charset setting of the mimepart after we piped the content through gnupg. But this is not true. gnupg only parsing bytestream and do charset handling at all. The only thing, is that gnupg suggest that you SHOULD use utf-8, but do not force this. It only works for you, because alpine is a cmdline mua, that puts it output to your console, and your console using utf-8 encoding, but if you would switch to something else, you couldn't read the text successfully. > The “inner” part of the message, i.e. the output of pgp/gpg decrypting it, > is *completely* independent of the MIME message surrounding it, and for > displaying it, *only* the rules that the command-line utilities use are > valid; this means, that the OpenPGP-level encoding is used (which is always > 8bit not quoted-printable or base64, and in absence of an explicit charset > selection is UTF-8). Well, the problem is that there is no "OpenPGP-level encoding". There is no API to ask gnupg about the encoding ( if there would be a api Andre would know this, because he is one of the authors fof the gnupg apis :) . > The reason for this is easy: Inline PGP works, basically (i.e. without > explicit MUA support), by someone writing a plaintext file, throwing that > through pgp or gpg, and copy/pasting that into their MUA’s composer. > Anything an MUA does to integrate Inline PGP support *must* behave *exactly > the same*. Make the experiment - change the charset of you konsole/ and use a text document with a different encoding and encrypt it and look at the output in your normal console ( utf-8). You will see that this is broken. This all works for you because you have a consistent utf8 environment. But for mails we can't say, what is the encoding of the sender, we can only guess here. > > GnuPG / GPGME itself does not do any reencoding it just decrypts the "bytes" > > of the message. > > It does *record* the charset of the message. But maybe all are wrong and you are right - give me the link to the documentation or a script/snippset, how It detect the correct charset of the decrypted mail i'll fix this instantly in kmail. Okay here is my console test: % LANG=C luit -encoding ISO-8859-15 gpg --encrypt -a -o test.enc You did not specify a user ID. (you may use "-r") Current recipients: Enter the user ID. End with an empty line: 0x36FD5E35D1D8EFD2 gpg: 0x36FD5E35D1D8EFD2: There is no assurance this key belongs to the named user pub 1024R/0x36FD5E35D1D8EFD2 2014-08-18 Test for Mozilla bug#1054187 Primary key fingerprint: 8D15 3316 76F4 6081 1A99 DB56 36FD 5E35 D1D8 EFD2 It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. Use this key anyway? (y/N) y Current recipients: 1024R/0x36FD5E35D1D8EFD2 2014-08-18 "Test for Mozilla bug#1054187" Enter the user ID. End with an empty line: test äöü test % LANG=C luit -encoding ISO-8859-15 gpg -d test.enc You need a passphrase to unlock the secret key for user: "Test for Mozilla bug#1054187" 1024-bit RSA key, ID 0x36FD5E35D1D8EFD2, created 2014-08-18 gpg: encrypted with 1024-bit RSA key, ID 0x36FD5E35D1D8EFD2, created 2014-08-18 "Test for Mozilla bug#1054187" test äöü test ^^ yeah that matches :D % LANG=C gpg -d test.enc You need a passphrase to unlock the secret key for user: "Test for Mozilla bug#1054187" 1024-bit RSA key, ID 0x36FD5E35D1D8EFD2, created 2014-08-18 gpg: encrypted with 1024-bit RSA key, ID 0x36FD5E35D1D8EFD2, created 2014-08-18 "Test for Mozilla bug#1054187" test test ^^ argh this is not what I enterted - and you see here, that gnupg on the commandline has no handling for encoding - it just using the default encoding of the console. The information, that the output has to be interpresed as ISO-8859-15 is lost. -- You are receiving this mail because: You are watching all bug changes.
