[pmg-devel] [PATCH pmg-api] fix #2525: encode notifications in UTF-8

[Stoiko Ivanov]

the Notify action is one of the places where we already encode the data as
UTF-8, before writing it to the DB (and decoding it when reading).

as laid out in rt.cpan.org [0] Mime::Body does expect encoded bytes, and not
perl characters.

Tested by creating a notification with the body supplied in #2591 (which is a
duplicate of #2525) and additionally with cyrillic characters in the subject.

A minimal test case is a body consisting of a Euro sign (since its Unicode
codepoint is larger than one byte).

Should the table contain invalid UTF-8 sequences (AFAIU only possible by
direct DB-manipulation) the byte gets replaced with \x{fffd} (Unicode
replacement character).

[0] https://rt.cpan.org/Public/Bug/Display.html?id=105377#txn-1762112

Signed-off-by: Stoiko Ivanov <s.ivanov at proxmox.com>
---
I considered simply dropping the decoding of the body and subject, when reading
it from the DB - but since it gets read in multiple locations - chose this
approach

 src/PMG/RuleDB/Notify.pm | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/PMG/RuleDB/Notify.pm b/src/PMG/RuleDB/Notify.pm
index 860b5ce..ec18a7e 100644
--- a/src/PMG/RuleDB/Notify.pm
+++ b/src/PMG/RuleDB/Notify.pm
@@ -224,10 +224,12 @@ sub execute {
     $to =~ s/\s+/,/g;
 
     my $top = MIME::Entity->build(
+	Encoding    => 'quoted-printable',
+	Charset => 'UTF-8',
 	From    => $from,
 	To      => $to,
-	Subject => $subject,
-	Data => $body);
+	Subject => encode('UTF-8', $subject),
+	Data => encode('UTF-8', $body));
 
     if ($self->{attach} eq 'O') {
 	# attach original mail
-- 
2.20.1