Bug#985464: Libpst converts filename to rfc2231 format in outputted .msg files: reported upstream
Tags: upstream Reported upstream.
Bug#985464: Libpst converts filename to rfc2231 format in outputted .msg files
Ok, thanks, I will forward to him. It’s true it breaks the ABI, but of a function that seems to be sort of pointless as an external function. But I’ll take your suggestion and forward to the upstream maintainer. > On Mar 18, 2021, at 7:44 PM, Paul Wise wrote: > > Control: tags -1 upstream > > On Thu, 2021-03-18 at 12:05 -0400, Stuart C. Naifeh wrote: > >> I suggest encoding the filename to rfc2231 into a separate temporary >> buffer, rather than in place, so that the internal attachment >> structure maintains the original, utf-8 encoded file name for use >> when saving the .msg file. Patch attached. > > By changing the API and behaviour of an existing libpst function the > patch breaks the ABI of libpst so it isn't suitable for inclusion. > > I would suggest you handle this with a new pst_convert_rfc2231 > function, deprecating the old pst_rfc2231 function and making them both > wrappers for a private static function to avoid code duplication, or > making the old function a wrapper for the new one if possible. > > I found at least one GitHub project that uses the pst_rfc2231 function, > it is a (presumably modified) copy of readpst though. > > https://github.com/overview/overview-convert-pst > >> This is probably really an upstream bug, but the libpst website, such >> as it is, does not provide for bug reports, and it looks like the >> Debian maintainer has made relatively recent commits to the upstream >> codebase, so I’m filing here. > > I don't have access to the upstream Mercurial repository, I can only > commit via the upstream maintainer, so please contact them. Here is > their email address in case you haven't been able to find it. Please > note that they are fairly busy so may take some time to reply. > > Carl Byington > > Once the bug is forwarded and once the patch has been accepted, > please either update the bug metadata or let me know so I can. > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise
Bug#985464: Libpst converts filename to rfc2231 format in outputted .msg files
Package: readpst, libpst4 Version: 0.6.75 Tags: patch Source: libpst When extracting an email with attachments from a pst to .eml and .msg files, the PR_ATTACH_LONG_FILENAME property for the attachments in the .msg file is encoded as a UTF-8 string in rfc2231 format (i.e., it’s prefixed with “utf-8’’”), which it shouldn’t be. The reason is that when saving the MIME format .eml file, the pst_item_attach.filename2 field (the internal representation of the PR_ATTACH_LONG_FILENAME) is converted to rfc2231 in place before the attachment is encoded into a MIME part (the package seems to do a lot of in-place string conversions, which is a bad idea unless you really know you’re never going to need the original string again). When the .msg file is subsequently created, it saves that previously rfc2231 encoded filename2 string in the attachment’s PR_ATTACH_LONG_FILENAME property. I suggest encoding the filename to rfc2231 into a separate temporary buffer, rather than in place, so that the internal attachment structure maintains the original, utf-8 encoded file name for use when saving the .msg file. Patch attached. This impacts both the readpst package, which is where the .eml and .msg files are created, and libpst4, which contains the rfc2231 conversion function (not sure why, since it only appears to be used from readpst). This is probably really an upstream bug, but the libpst website, such as it is, does not provide for bug reports, and it looks like the Debian maintainer has made relatively recent commits to the upstream codebase, so I’m filing here. pst-utils.patch Description: Binary data
Bug#775111: logwatch: unmatched entries from apparmor (lines without partent="...")
Package: logwatch
Version: 7.4.1-2
Severity: normal
Tags: patch
Dear Maintainer,
I am getting a number of unmatched entries in logwatch related to
apparmor. Specifically, the are entries where apparmor is allowing
access (apparmor="ALLOWED") and there is no "parent=..." in the log
entry. The existing relevant regexp in scripts/services/audit matches only when
the line contains 'parent="\d+" ' before 'profile=...'. I have a number
oenteries every day where there is no parent= in the log entry. It
looks like they all come from the dovecot package (the imap process,
managesieve process, dovecot-lda, etc.). Making the 'parent=...' part
of the line optional, as in the attached patch, clears it us for me.
The fix for bug #710146 resolved a similar issue, but did not catch all
of the related unmatched entries identified in this bug report.
-- System Information:
Debian Release: 8.0
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages logwatch depends on:
ii perl5.20.1-4
ii postfix [mail-transport-agent] 2.11.3-1
Versions of packages logwatch recommends:
ii libdate-manip-perl 6.47-1
ii libsys-cpu-perl 0.61-1+b1
Versions of packages logwatch suggests:
pn fortune-mod
-- no debconf information
--- /usr/share/logwatch/scripts/services/audit.old 2014-11-03 14:03:18.0 -0500
+++ /usr/share/logwatch/scripts/services/audit 2015-01-11 09:44:33.210362455 -0500
@@ -168,7 +168,7 @@
# type=1400 audit(1314853822.672:33649): apparmor="DENIED" operation="mknod" parent=27250 profile="/usr/lib/apache2/mpm-prefork/apache2//example.com" name="/usr/share/wordpress/1114140474e5f13bea68a4.tmp" pid=27289 comm="apache2" requested_mask="c" denied_mask="c" fsuid=33 ouid=33
# type=1400 audit(1315353795.331:33657): apparmor="DENIED" operation="exec" parent=14952 profile="/usr/lib/apache2/mpm-prefork/apache2//example.com" name="/usr/lib/sm.bin/sendmail" pid=14953 comm="sh" requested_mask="x" denied_mask="x" fsuid=33 ouid=0
$denials{$1.' '.$3.' ('.$2.' via '.$4 . ')'}++;
-} elsif ( $ThisLine =~ /apparmor="ALLOWED" operation="([^"]+)" (info="([^"]+)" )?(error=[+-]?\d+ )?parent=\d+ profile="([^"]+)" (name="([^"]+)" )?pid=\d+ comm="([^"]+)"/ ) {
+} elsif ( $ThisLine =~ /apparmor="ALLOWED" operation="([^"]+)" (info="([^"]+)" )?(error=[+-]?\d+ )?(parent=\d+ )?profile="([^"]+)" (name="([^"]+)" )?pid=\d+ comm="([^"]+)"/ ) {
# type=1400 audit(1369519203.141:259049): apparmor="ALLOWED" operation="exec" parent=3733 profile="/usr/sbin/dovecot//null-1c//null-1d" name="/usr/lib/dovecot/pop3-login" pid=24634 comm="dovecot" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 target="/usr/sbin/dovecot//null-1c//null-1d//null-d12"
# type=1400 audit(1369627891.522:447576): apparmor="ALLOWED" operation="capable" parent=1 profile="/usr/sbin/dovecot//null-1c//null-1d" pid=3733 comm="dovecot" capability=5 capname="kill"
# type=1400 audit(1369823965.682:824587): apparmor="ALLOWED" operation="getattr" info="Failed name lookup - deleted entry" error=-2 parent=1 profile="/usr/sbin/dovecot//null-1c//null-1d" name="/var/lib/dovecot/.temp.3733.d786c1fcaaa73248" pid=3733 comm="dovecot" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
