Bug#947425: incron crashes in IncronTabEntry::GetSafePath due to use-after-free bug

[Willi Mann]

Package: incron
Version: 0.5.12-1
Severity: grave
Tags: security patch upstream

Hi,

incron crashes for me frequently. As incron runs as root, but is controllable
by users, this bug might be security-relevant, so I'm reporting it a severity
grave and tagging it security.  Please downgrade if you can rule out this
concern.

Further investigation shows that the problem is caused by the creation of new
directories within watched paths: these trigger a reload of the inotify watch
target, rendering the old watch structure invalid. Only after the reload,
potential commands are executed. This may require to get path of the event, but
the corresponding pointer is invalid after the reload.

Attached is a patch that extracts the path before the reload, making this
problem disappear for me. Note that the patch assumes that LOOPER is not
defined, which seems to be the case for the Debian package.

Backtrace for reference:

bt full
#0  0x004ba484 in IncronTabEntry::GetSafePath (rPath=) at /usr/include/c++/8/bits/basic_string.h:1046
i = 0
stream = 
len = 1919509615
#1  0x004c43f3 in UserTable::OnEvent (this=, rEvt=...) at 
inotify-cxx.h:428
px = 40
pW = 0x1fbde40
pE = 0x1fbc920
events = "IN_CREATE,IN_ISDIR"
cmd = "/home/user/autoscripts/imageresize.sh "
cs = "/home/user/autoscripts/imageresize.sh $@/$# $# $%"
pos = 39
oldpos = 0
len = 
pid = 
#2  0x004c4767 in EventDispatcher::ProcessEvents (this=) at 
usertable.cpp:110
pIn = 0x1fc7d24
it = {first = 1702521203, second = 0x1fc0072}
i = 2
pipe = false
evt = {m_uMask = 1073742080, m_uCookie = 0, m_name = "Neuer Ordner", 
m_pWatch = 0x1fbde40}
#3  0x004b8650 in main (argc=, argv=) at 
icd-main.cpp:458
res = 
wm = 10184
in = {m_fd = 6, m_watches = std::map with 2 elements = {[1] = 
0xbfc8ab40, [2] = 0xbfc8ab68}, m_paths = std::map with 2 elements = {
["/etc/incron.d"] = 0xbfc8ab40, ["/var/spool/incron"] = 
0xbfc8ab68}, m_buf = '\000' ..., m_events = std::deque 
with 0 elements}
stw = {m_path = "/etc/incron.d", m_uMask = 10184, m_wd = 1, m_pInotify 
= 0xbfc8ab90, m_fEnabled = true}
utw = {m_path = "/var/spool/incron", m_uMask = 10184, m_wd = 2, 
m_pInotify = 0xbfc8ab90, m_fEnabled = true}
ed = {m_iPipeFd = 4, m_iMgmtFd = 6, m_pIn = 0xbfc8ab90, m_pSys = 
0xbfc8ab40, m_pUser = 0xbfc8ab68, m_maps = std::map with 1 element = {[8] = 
0x1fc7d20}, 
  m_size = 3, m_pPoll = 0x1fbe080}
cfg = "/etc/incron.conf"
lckdir = "/var/run"
lckfile = "incrond"
app = {m_path = "/var/run/incrond.pid", m_fLocked = true}
ret = 0
sysBase = "/etc/incron.d"
userBase = "/var/spool/incron"

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-6-686-pae (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages incron depends on:
ii  adduser  3.118
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libstdc++6   8.3.0-6
ii  lsb-base 10.2019051400

incron recommends no packages.

incron suggests no packages.

-- Configuration Files:
/etc/incron.allow [Errno 13] Keine Berechtigung: '/etc/incron.allow'
/etc/incron.deny [Errno 13] Keine Berechtigung: '/etc/incron.deny'

-- no debconf information
diff --git a/usertable.cpp b/usertable.cpp
index 3f1ef4a..bdc7f29 100644
--- a/usertable.cpp
+++ b/usertable.cpp
@@ -370,6 +370,8 @@ void UserTable::OnEvent(InotifyEvent& rEvt)
 {
   InotifyWatch* pW = rEvt.GetWatch();
   IncronTabEntry* pE = FindEntry(pW);
+
+  std::string pWPath = pW->GetPath();
 
   // no entry found - this shouldn't occur
   if (pE == NULL)
@@ -422,7 +424,7 @@ void UserTable::OnEvent(InotifyEvent& rEvt)
   else {
 cmd.append(cs.substr(oldpos, pos-oldpos));
 if (cs[px] == '@') {  // base path
-  cmd.append(IncronTabEntry::GetSafePath(pW->GetPath()));
+  cmd.append(IncronTabEntry::GetSafePath(pWPath));
   oldpos = pos + 2;
 }
 else if (cs[px] == '#') { // file name

Bug#921198: testing also affected

[Willi Mann]

Hi,

as the problem is not new, I've marked the version in testing as
affected and I changed the title of the bug accordingly.

Willi

Bug#921198: hard to track down

[Willi Mann]

Hi,

just for the record, I tried to reproduce the build failure on eller
(mipsel porterbox), but it builds fine there. I'm wondering whether the
timeout set on line 232 of tests/srp.c (40 seconds) is too short for
slower build hosts.

Willi

Bug#852931: closing this bug

[Willi Mann]

Control: close -1

Hi,

I'm closing this bug as the problem was caused by a user-supplied regex.

Willi

Bug#871473: logwatch: Logwatch email messages fail with vanilla exim4 install: message is too big (transport limit = 1)

[Willi Mann]

Hi Peter,

Am 08.08.17 um 11:41 schrieb Peter Collinson:
>  Alternative and better solution: I added --encode=base64 to
>  00logwatch in cron.daily, after ensuring that libmime-tools-perl
>  was installed. Line wrapping is no longer a problem.

the problem with the base64 option is that it bloats the e-mail in size
(factor 1.33), so I don't think that this is a general solution. I think
I will solve this problem by documenting it in README.Debian.

Willi

Bug#907319: logwatch has erroneous mdadm device detection

[Willi Mann]

Hi,

does the patch really work for you? I'm surprised because you used \S
which means "all non-whitespace characters", but I think you intended
otherwise.

Willi

Am 26.08.18 um 14:44 schrieb Reco:
> Package: logwatch
> Version: 7.4.3+git20161207-2
> Severity: normal
> 
> Dear Maintainer,
> 
> Perl script /usr/share/logwatch/scripts/services/mdadm provided by
> logwatch package uses faulty regex (^ARRAY) to parse
> /etc/mdadm/mdadm.conf.
> Said regex does not take into the account the possibiliy of excluding
> md array from the kernel by using "ARRAY " as outlined at
> mdadm.conf(5).
> The script does not even try to validate parsed device names, and feeds
> them to this line:
> 
> open(MDADM,"mdadm --misc --detail $dev 2>&1 |");
> 
> which in turn invokes /bin/sh -c "mdadm --misc --detail  2>&1"
> Which, of course, fails with "redirection unexpected".
> 
> Suggested fix is attached to this bug report.
> 
> Sincerely yours, Reco
> 
> -- System Information:
> Debian Release: 9.5
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages logwatch depends on:
> ii  exim4-daemon-light [mail-transport-agent]  4.89-2+deb9u3
> ii  perl   5.24.1-3+deb9u4
> 
> Versions of packages logwatch recommends:
> ii  libdate-manip-perl   6.57-1
> pn  libsys-cpu-perl  
> pn  libsys-meminfo-perl  
> 
> Versions of packages logwatch suggests:
> ii  fortune-mod  1:1.99.1-7+b1
> 
> -- Configuration Files:
> /etc/cron.daily/00logwatch
> 
> -- no debconf information
> 

Bug#816570: fix uploaded to DELAYED

[Willi Mann]

Hi,

I uploaded a fix for this bug to DELAYED/10. debdiff attached.

Willi
diff -Nru mrtrix-0.2.12/debian/changelog mrtrix-0.2.12/debian/changelog
--- mrtrix-0.2.12/debian/changelog	2015-12-29 18:21:14.0 +0100
+++ mrtrix-0.2.12/debian/changelog	2017-10-21 16:22:07.0 +0200
@@ -1,3 +1,10 @@
+mrtrix (0.2.12-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix build error with ambigous call to round (closes: #816570)
+
+ -- Willi Mann   Sat, 21 Oct 2017 16:22:07 +0200
+
 mrtrix (0.2.12-2) unstable; urgency=medium
 
   * Add patch to include  to fix FTBFS due to missing size_t.
diff -Nru mrtrix-0.2.12/debian/patches/fix-build-error-round mrtrix-0.2.12/debian/patches/fix-build-error-round
--- mrtrix-0.2.12/debian/patches/fix-build-error-round	1970-01-01 01:00:00.0 +0100
+++ mrtrix-0.2.12/debian/patches/fix-build-error-round	2017-10-21 16:22:03.0 +0200
@@ -0,0 +1,17 @@
+Index: mrtrix-0.2.12/cmd/tracks2prob.cpp
+===
+--- mrtrix-0.2.12.orig/cmd/tracks2prob.cpp
 mrtrix-0.2.12/cmd/tracks2prob.cpp
+@@ -127,9 +127,9 @@ class Voxel
+   z (_z_) { }
+ 
+ Voxel (const Point& p) :
+-  x (round (p[0])),
+-  y (round (p[1])),
+-  z (round (p[2]))
++  x (MR::round (p[0])),
++  y (MR::round (p[1])),
++  z (MR::round (p[2]))
+ { 
+   assert (gsl_finite (p[0]) && gsl_finite (p[1]) && gsl_finite (p[2]));
+ }
diff -Nru mrtrix-0.2.12/debian/patches/series mrtrix-0.2.12/debian/patches/series
--- mrtrix-0.2.12/debian/patches/series	2015-12-29 17:17:10.0 +0100
+++ mrtrix-0.2.12/debian/patches/series	2017-10-21 16:20:03.0 +0200
@@ -1,3 +1,4 @@
 debian_build_cfg
 glib-single-include.patch
 size_t-ftbfs
+fix-build-error-round

Bug#875696: patch

[Willi Mann]

Control: tag -1 + patch

Hi,

attached is a patch that fixes the problem with the @piddir@. Note
however, that by default, the LISTS variable in the config file is
empty. As long as LISTS is empty, the webmlm will still not start.

Bye
Willi
Index: courier-0.76.3/courier/configure.ac
===
--- courier-0.76.3.orig/courier/configure.ac
+++ courier-0.76.3/courier/configure.ac
@@ -112,6 +112,9 @@ AC_ARG_WITH(transport,
 
 AC_SUBST(transport)
 
+AC_ARG_WITH(piddir, [  --with-piddir Directory where PID files are located ], piddir="$withval", piddir=/var/run)
+AC_SUBST(piddir)
+
 AC_MSG_CHECKING(for modules to compile)
 
 dirlist=""

Bug#875954: there should be patch somewhere...

[Willi Mann]

Hi,

according to the previous maintainer, this bug was fixed in version
0.75.0-15. However, I never verified that (I reported the bug back then)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812235

Bye
Willi

Bug#795296: "You are not allowed to save the configuration" (both root and ordinary user)

[Willi Mann]

Hi Maxy,

Am 2017-04-06 um 19:24 schrieb Maximiliano Curia:

> El 2017-03-31 a las 21:25 +0200, Willi Mann escribió:
>> Am 2017-03-31 um 18:25 schrieb Maximiliano Curia:
> 
>>> Do you have another session started as root? Do you have another X
>>> session started with your user?
> 
>> There is no other session running as root, except for an SSH session.
>> And I have no keyboard or mouse attached to this machine, I'm using
>> synergy instead.
> 
> I've seen synergy do some weird things, but somehow I don't think we can
> blame synergy here.

Just to make sure, I tried it with a keyboard connected and synergy not
started. Does not change anything.

Bye
Willi

Bug#795296: "You are not allowed to save the configuration" (both root and ordinary user)

[Willi Mann]

Hi Maxy,

Am 2017-03-31 um 18:25 schrieb Maximiliano Curia:
> 
>> in the SDDM settings window, it tells me the same as when I try it as
>> ordinary user (I'm not allowed to save the configuration, transl. from
>> German).
> 
>>> The changes made as root weren't applied to the /etc/sddm.conf file?
> 
>> Unfortunately not.
> 
> As mentioned writting this change as root don't need an interaction with
> the agent so this should work, otherwise it's policykit at fault, not
> the agent. (also, you don't have an agent running as root).
> 
> Mmh, are you using apparmor with a particular configuration?

no, apparmor is not installed.
> 
> Do you have another session started as root?
> Do you have another X session started with your user?

There is no other session running as root, except for an SSH session.
And I have no keyboard or mouse attached to this machine, I'm using
synergy instead.

>>> (assuming that you tested this with the sddm kcm)
> 
> Do you have the polkit-kde-authentication-agent-1 service running?
> 
 I have such a process running, under the desktop's user uid.
> 
> Well, any agent should be replaceable, you can kill it and start a
> different one, let's say lxqt-policykit's lxqt-policykit-agent.
> 
> You can test this with pkexec bash to avoid mudding the test with the
> kcm authhelper, if it works with lxqt-policykit-agent then the issue is
> in the kde agent, otherwise, please reassign the issue to policykit-1

I used the gnome one. pkexec bash then works. However, the problem with
configuring sddm persists - it still says I'm not allowed to save the
configuration.

Apart from that, I made another strange observation:

If I recompile policykit-1=0.105-17 (directly on the system, without
clean chroot) and install it and the KDE policykit agent is running,
pkexec bash does ask for a password on the command line:


% pkexec bash
 AUTHENTICATING FOR org.freedesktop.policykit.exec ===
Authentication is needed to run `/bin/bash' as the super user
Authenticating as: root
Password:
polkit-agent-helper-1: error response to PolicyKit daemon:
GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
 AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized

This incident has been reported.


The password was correct, but it fails on some other issue. The
dependencies of the two package versions are the same. ldd also reports
no differences on the polkitd and pkexec binaries' dependencies.

thanks
Willi

Bug#795296: "You are not allowed to save the configuration" (both root and ordinary user)

[Willi Mann]

Hi Maxy!

> El 2017-03-22 a las 19:52 +0100, Willi Mann escribió:
>> Am 2017-03-21 um 10:58 schrieb Maximiliano Curia:
>>> El 2017-03-20 a las 19:22 +0100, Willi Mann escribió:
>>>> the problem still exists. Let me know if you any idea how to track
>>>> this down.
> 
>>> Sorry, I can't reproduce the issue here, the message seems to be
>>> related to a rule rejecting the request for your users, (even root?).
>>> Do you have a specific policykit setup?
> 
>> I don't have a specific setup. The system runs testing for some years,
>> though. So it could be an upgrade bug. The problem also occurs with
>> root and a clean account I just created for testing.
> 
> There is something here, as root policykit doesn't need to talk with the
> agent, so that rules out polkit-kde-agent-1. The issue should be on the
> policykit side.

> Just to be sure, how was the root plasma session started?

did

% su
# export $(dbus-launch)
# systemsettings5

in the SDDM settings window, it tells me the same as when I try it as
ordinary user (I'm not allowed to save the configuration, transl. from
German).

> The changes made as root weren't applied to the /etc/sddm.conf file?

Unfortunately not.

> (assuming that you tested this with the sddm kcm)
> 
>>> Do you have the polkit-kde-authentication-agent-1 service running?
> 
>> I have such a process running, under the desktop's user uid.
> 
>>> What's the result of running: pkexec bash in a terminal with your user?
> 
>> This hangs, i.e. it does not return but also does not produce any
>> output. However, it works fine when I run "pkexec bash" as root.
>> System dbus log during the execution of this command attached.
> 
> pkexec bash as root doesn't need to talk with the agent, so it should
> always work.
> 
>> method call time=1490208186.877616 sender=:1.73 -> destination=:1.7
>> serial=9 path=/org/freedesktop/PolicyKit1/Authority;
>> interface=org.freedesktop.PolicyKit1.Authority;
>> member=CheckAuthorization   string "org.freedesktop.policykit.exec"  
>> array [  dict entry( string "program" string
>> "/bin/bash"  ) method call time=1490208186.878006 sender=:1.7 ->
>> destination=org.freedesktop.DBus serial=139
>> path=/org/freedesktop/DBus; interface=org.freedesktop.DBus;
>> member=GetConnectionUnixUser   string ":1.73" method return
>> time=1490208186.878028 sender=org.freedesktop.DBus -> destination=:1.7
>> serial=78 reply_serial=139   uint32 0 method call
>> time=1490208186.878052 sender=:1.7 -> destination=org.freedesktop.DBus
>> serial=140 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus;
>> member=GetConnectionUnixProcessID   string ":1.73" method return
>> time=1490208186.878076 sender=org.freedesktop.DBus -> destination=:1.7
>> serial=79 reply_serial=140   uint32 2828 method call
>> time=1490208186.878100 sender=:1.7 -> destination=:1.42 serial=141
>> path=/org/kde/PolicyKit1/AuthenticationAgent;
>> interface=org.freedesktop.PolicyKit1.AuthenticationAgent;
>> member=BeginAuthentication   string "org.freedesktop.policykit.exec"  
>> string "Authentication is needed to run `/bin/bash' as the super user"
>>   string ""   array [  dict entry( string
>> "polkit.caller-pid" string "2828"  ) signal
>> time=1490208211.280956 sender=:1.28 -> destination=(null destination)
>> serial=41 path=/org/freedesktop/ConsoleKit/Session4;
>> interface=org.freedesktop.ConsoleKit.Session; member=IdleHintChanged  
>> boolean true
> 
> After these the agent request an EnumerateActions and ends up showing
> the window, in my test system. This may indicate that the agent is in a
> non-responsive state, which somewhat contradicts what's indicated a
> couple of paragraphs before. Was this the complete output?

Yes, there is nothing more until I hit Ctrl+C to kill the hanging pkexec
bash command.

> It might be useful to attach an strace to the agent with:
> sudo strace -vf -p $(pidof polkit-kde-authentication-agent-1) | tee
> /tmp/polkit-agent.log
> 
> or something like that. The generated file would be quite large, with a
> lot of noise, so it might be better not to send it to a pastebin like
> https://paste.debian.net.

The file has 12 KB, so I'm attaching it to this mail. The command I ran was

# strace -o /tmp/polkit-agent.log -vf -p $(pidof
polkit-kde-authentication-agent-1)

I started it before executing pkexec bash and stopped it with Ctrl+C
after I Ctrl+Ced the pkexec command.

Bug#795296: "You are not allowed to save the configuration" (both root and ordinary user)

[Willi Mann]

Control: tag -1 - moreinfo

Am 2017-03-21 um 10:58 schrieb Maximiliano Curia:
> 
> ¡Hola Willi!
> 
> El 2017-03-20 a las 19:22 +0100, Willi Mann escribió:
>> the problem still exists. Let me know if you any idea how to track
>> this down.
> 
> Sorry, I can't reproduce the issue here, the message seems to be related
> to a rule rejecting the request for your users, (even root?). Do you have a
> specific policykit setup?

I don't have a specific setup. The system runs testing for some years,
though. So it could be an upgrade bug. The problem also occurs with root
and a clean account I just created for testing.

> Do you have the polkit-kde-authentication-agent-1 service running?

I have such a process running, under the desktop's user uid.

> What's the result of running: pkexec bash
> in a terminal with your user?

This hangs, i.e. it does not return but also does not produce any
output. However, it works fine when I run "pkexec bash" as root. System
dbus log during the execution of this command attached.

Willi
method call time=1490208186.836839 sender=:1.73 -> destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello
method return time=1490208186.836871 sender=org.freedesktop.DBus -> destination=:1.73 serial=1 reply_serial=1
   string ":1.73"
signal time=1490208186.836888 sender=org.freedesktop.DBus -> destination=(null destination) serial=29 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.73"
   string ""
   string ":1.73"
signal time=1490208186.836915 sender=org.freedesktop.DBus -> destination=:1.73 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.73"
method call time=1490208186.838139 sender=:1.73 -> destination=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.freedesktop.PolicyKit1',interface='org.freedesktop.DBus.Properties',member='PropertiesChanged',path='/org/freedesktop/PolicyKit1/Authority',arg0='org.freedesktop.PolicyKit1.Authority'"
method return time=1490208186.838172 sender=org.freedesktop.DBus -> destination=:1.73 serial=3 reply_serial=2
method call time=1490208186.838225 sender=:1.73 -> destination=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.freedesktop.PolicyKit1',interface='org.freedesktop.PolicyKit1.Authority',path='/org/freedesktop/PolicyKit1/Authority'"
method return time=1490208186.838240 sender=org.freedesktop.DBus -> destination=:1.73 serial=4 reply_serial=3
method call time=1490208186.838331 sender=:1.73 -> destination=org.freedesktop.DBus serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',path='/org/freedesktop/DBus',arg0='org.freedesktop.PolicyKit1'"
method return time=1490208186.838345 sender=org.freedesktop.DBus -> destination=:1.73 serial=5 reply_serial=4
method call time=1490208186.838456 sender=:1.73 -> destination=org.freedesktop.DBus serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=StartServiceByName
   string "org.freedesktop.PolicyKit1"
   uint32 0
method return time=1490208186.838475 sender=org.freedesktop.DBus -> destination=:1.73 serial=6 reply_serial=5
   uint32 2
method call time=1490208186.840024 sender=:1.73 -> destination=org.freedesktop.DBus serial=6 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetNameOwner
   string "org.freedesktop.PolicyKit1"
method return time=1490208186.840063 sender=org.freedesktop.DBus -> destination=:1.73 serial=7 reply_serial=6
   string ":1.7"
method call time=1490208186.840910 sender=:1.73 -> destination=:1.7 serial=7 path=/org/freedesktop/PolicyKit1/Authority; interface=org.freedesktop.DBus.Properties; member=GetAll
   string "org.freedesktop.PolicyKit1.Authority"
method return time=1490208186.841665 sender=:1.7 -> destination=:1.73 serial=137 reply_serial=7
   array [
  dict entry(
 string "BackendName"
 variant string "local"
  )
  dict entry(
 string "BackendVersion"
 variant string "0.105"
  )
  dict entry(
 string "BackendFeatures"
 variant uint32 1
  )
   ]
method call time=1490208186.842487 sender=:1.73 -> destinatio

Bug#795296: "You are not allowed to save the configuration" (both root and ordinary user)

[Willi Mann]

Control: reopen -1

Hi Maxy,

the problem still exists. Let me know if you any idea how to track this
down.

Willi

Am 2017-03-16 um 20:11 schrieb Maximiliano Curia:
> ¡Hola Willi!
> 
> El 2015-08-12 a las 20:11 +0200, Willi Mann escribió:
>> Package: kde-config-sddm Version: 4:5.3.2-1 Severity: normal
> 
>> I get the message in the subject when I go to the SDDM config unit. It
>> happens both when I go there as ordinary user and as root. Let me know
>> whether I can provide further information to resolve this bug.
> 
> Sorry that it took so long to get back to you.
> 
> 4:5.3.2-1 was the release of plasma-desktop that added the runtime
> dependency against polkit-kde-agent-1 which in turn is needed for the
> kde-config-sddm kcm module to be able to request the permissions. I'm
> assuming that the issue was caused by either a partial upgrade or using
> the recently installed kde-config-sddm in already running
> plasma-desktop. I'll close the issue based on this assumption, please,
> if you can still reproduce the issue, reopen this bug.
> 
> Happy hacking,

Bug#856230: ITP: python-django-progressbarupload -- Progress bar for Django (Python 2)

[Willi Mann]

Package: wnpp
Severity: wishlist
Owner: Willi Mann 

* Package name: python-django-progressbarupload
  Version : 0.1.7
  Upstream Author : Samuel Goldszmidt
* URL : https://github.com/ouhouhsami/django-progressbarupload
* License : BSD
  Programming Lang: Python
  Description : Progress bar for Django

 This package provides a progress bar for file upload forms in Django, a web
 development framework written Python. The progress bar is implemented on the
 server side via a special view that provides the progress information and
 JavaScript on the client side to poll this view in short intervals. If
 JavaScript is disabled, uploads still work, but there is no progress bar.

As far as I can tell, there is no Django extension so far in Debian that
supports upload progress reporting. I'm using this package already for a
student work submission system.

Bug#849531: Possible security problem, new logwatch sends mails with charset UTF-8

[Willi Mann]

Hi,

Am 2016-12-28 um 10:09 schrieb Klaus Ethgen:
> Package: logwatch
> Version: 7.4.3+git20161207-1
> Severity: critical
> 
> Current logwatch did change from sending mails with charset iso-8859-1
> to UTF-8. This openes up a potential security hole as UTF-8 is not able
> to display all 8bit data.

in order to fix this bug for stretch (next Debian stable release), I
will upload a version of logwatch that reverts the change from
iso-8859-1 to utf-8 for mails sent by logwatch. This is not my preferred
way to fix this issue, but any better fix I can imagine will require
some new configuration options, which I don't want to introduce in
Debian before they are committed upstream.

Bye
Willi

Bug#849531: [Logwatch-devel] Bug#849531: Possible security problem, new logwatch sends mails with charset UTF-8

[Willi Mann]

Hi Klaus,

Am 2017-01-15 um 17:43 schrieb Klaus Ethgen:
> Hi Willi,
> 
> Am Sa den 14. Jan 2017 um 16:43 schrieb Willi Mann:
>> in order to come closer to a fix for this issue, I propose the following
>> two patches:
> 
> 
>> 0001-Add-outputencoding-parameter.patch
> 
>> This patch allows to configure the value for the charset in the
>> Content-Type line in mail output. This should address Klaus Ethgen's
>> original concern.
> 
> Well, partly. It will, in fact, let me configure it the way, that it
> solves my issue.
> 
> However, It does not fix the issue itself as it does not ensure that the
> output in mail is that charset. As I mentioned before, this is exactly
> the issue. The mail could be easily in UTF-8. But then there has to be
> logic to keep sure that the mail is in that charset. Without, you could
> still end with logical incorrect mails that are (partly) in different
> charsets that is illegal for UTF-8.

I understand that the illegal UTF-8 is bad. But I have to admit that I'm
not yet sure why it is bad in terms of security, especially since we are
talking about mail - and anyone could send you an e-mail with illegal
UTF-8 sequences.

>> Since most people use UTF-8, I left the default at UTF-8.
> 
> No objection about that. But you cannot be sure that log stuff is in the
> same charset.

Yeah, that I'm aware of.

>> 0002-Use-pager-on-stdout-output-to-terminal.patch
> [...]
>> Let me know what you think about these patches.
> 
> Patches looks good for me for fixing the bug partly. Nevertheless I
> would expect some use of iconv for really ensure the choosed charset.
> Maybe even encguess can come to use for guessing the input.

Does anybody have a good idea on how to implement this? Concerning the
second part (guessing the input encoding), I'm not really sure at
what point logwatch should try to guess and assume a particular charset.
Especially for the first part, does anybody know some example code?
Maybe some other project that had to solve the same issue in Perl?

Willi

Bug#849531: [Logwatch-devel] Bug#849531: Bug#849531: Possible security problem, new logwatch sends mails with charset UTF-8

[Willi Mann]

Hi,

Am 2017-01-14 um 16:48 schrieb Mike Tremaine:
> 
>> 0002-Use-pager-on-stdout-output-to-terminal.patch
>>
>> Use pager less if output is on terminal. This should address the issues
>> associated with escape sequences in logs that may mess with your
>> terminal. Less seems to be good at filtering these escape sequences.
> 
> 
> Sounds good, but I’d make it a config switch and leave the default as is. 
> Some “lazy” destro's let cron handle terminal output to mail directly… :/ 

But, then "-t STDOUT" is false (see patch) - in this case, the pager
will not be invoked. I also made the pager configurable and it can be
set to am empty string to disable). I updated the help text in the
second patch to document that better.

Willi
>From 162f8b2e7fae134e65761dc64e0a8d29c9c172d4 Mon Sep 17 00:00:00 2001
From: Willi Mann 
Date: Sat, 14 Jan 2017 15:32:39 +0100
Subject: [PATCH 1/2] Add outputencoding parameter

---
 conf/logwatch.conf  | 8 
 scripts/logwatch.pl | 8 +---
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/conf/logwatch.conf b/conf/logwatch.conf
index 2b61ec6..0d0e31b 100644
--- a/conf/logwatch.conf
+++ b/conf/logwatch.conf
@@ -126,4 +126,12 @@ mailer = "/usr/sbin/sendmail -t"
 #
 #HostLimit = myhost
 
+#
+# With this option, the output encoding for mail headers can be set. It
+# defaults to utf-8. Be aware that the default value may change to autodetect
+# (take the system's encoding). Note that the configured value will be
+# upper-cased.
+#
+# OutputEncoding = utf-8
+
 # vi: shiftwidth=3 tabstop=3 et
diff --git a/scripts/logwatch.pl b/scripts/logwatch.pl
index 0167755..0cff511 100755
--- a/scripts/logwatch.pl
+++ b/scripts/logwatch.pl
@@ -90,6 +90,7 @@ $Config{'pathtobzcat'} = "bzcat";
 $Config{'output'} = "stdout"; #8.0
 $Config{'format'} = "text"; #8.0
 $Config{'encode'} = "none"; #8.0
+$Config{'outputencoding'} = "utf-8";
 $Config{'hostformat'} = "none"; #8.0
 $Config{'html_wrap'} = 80;
 $Config{'supress_ignores'} = 0;
@@ -1160,11 +1161,12 @@ sub initprint {
  } else {
 $out_mime .= "Content-Transfer-Encoding: 7bit\n";
  }
- #Config{output} html
+ #Config{output} html, Config{outputenconding}
+ my $encoding = uc($Config{outputencoding});
  if ( $Config{'format'} eq "html" ) {
-$out_mime .= "Content-Type: text/html; charset=\"UTF-8\"\n\n";
+$out_mime .= "Content-Type: text/html; charset=\"$encoding\"\n\n";
  } else {
-$out_mime .= "Content-Type: text/plain; charset=\"UTF-8\"\n\n";
+$out_mime .= "Content-Type: text/plain; charset=\"$encoding\"\n\n";
  }
 
  if ($Config{'hostformat'} eq "split") { #8.0 check hostlimit also? or ne none?
-- 
2.1.4

>From 0f52b6b4a35e8aa33d2827f90d515491c15a3d41 Mon Sep 17 00:00:00 2001
From: Willi Mann 
Date: Sat, 14 Jan 2017 16:25:30 +0100
Subject: [PATCH 2/2] Use pager on stdout output to terminal

---
 conf/logwatch.conf  | 5 +
 scripts/logwatch.pl | 7 ++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/conf/logwatch.conf b/conf/logwatch.conf
index 0d0e31b..c46b5d6 100644
--- a/conf/logwatch.conf
+++ b/conf/logwatch.conf
@@ -134,4 +134,9 @@ mailer = "/usr/sbin/sendmail -t"
 #
 # OutputEncoding = utf-8
 
+#
+# For output type stdout, logwatch uses the pager Pager if STDOUT is a terminal.
+# Am empty string disables the pager.
+#Pager = /usr/bin/less
+
 # vi: shiftwidth=3 tabstop=3 et
diff --git a/scripts/logwatch.pl b/scripts/logwatch.pl
index 0cff511..f053cb3 100755
--- a/scripts/logwatch.pl
+++ b/scripts/logwatch.pl
@@ -88,6 +88,7 @@ $Config{'pathtocat'} = "cat";
 $Config{'pathtozcat'} = "zcat";
 $Config{'pathtobzcat'} = "bzcat";
 $Config{'output'} = "stdout"; #8.0
+$Config{'pager'} = "/usr/bin/less"; #8.0
 $Config{'format'} = "text"; #8.0
 $Config{'encode'} = "none"; #8.0
 $Config{'outputencoding'} = "utf-8";
@@ -1127,7 +1128,11 @@ sub initprint {
$OStitle = "Solaris" if ($OSname eq "SunOS" && $release >= 2);
 
if ($Config{'output'} eq "stdout") { #8.0 start with others?
-  *OUTFILE = *STDOUT;
+  if($Config{'pager'} and -t STDOUT) {
+ open(OUTFILE,"|$Config{'pager'}") or die "could not open pager: $Config{'pager'} $!";
+  } else {
+ *OUTFILE = *STDOUT;
+  }
} elsif ($Config{'output'} eq "file") {
   open(OUTFILE,">>" . $Config{'filename'}) or die "Can't open output file: $Config{'filename'} $!\n";
} else {
-- 
2.1.4

Bug#849531: [Logwatch-devel] Bug#849531: Possible security problem, new logwatch sends mails with charset UTF-8

[Willi Mann]

Hi,

in order to come closer to a fix for this issue, I propose the following
two patches:


0001-Add-outputencoding-parameter.patch

This patch allows to configure the value for the charset in the
Content-Type line in mail output. This should address Klaus Ethgen's
original concern. Since most people use UTF-8, I left the default at UTF-8.

0002-Use-pager-on-stdout-output-to-terminal.patch

Use pager less if output is on terminal. This should address the issues
associated with escape sequences in logs that may mess with your
terminal. Less seems to be good at filtering these escape sequences.


Let me know what you think about these patches.

Willi

Am 2017-01-01 um 23:01 schrieb Mike Tremaine:
> 
>>
>> The fail-safe default before was ISO-8859-1. So I suggest to use it
>> again.
>>
> 
> 
> If stream converted output it s require please consider making it a 
> configurable module in the code base that can be turned on and off and 
> modified (the module) as needed. Leave the default as is, that way DESTRO’s 
> and users can configure to their liking. But it will work as intended all the 
> way back to the stone-age tools that we started this project with. (I’m 
> looking at you Solaris 7/8)
> 
> 
> -Mike
> 

>From 162f8b2e7fae134e65761dc64e0a8d29c9c172d4 Mon Sep 17 00:00:00 2001
From: Willi Mann 
Date: Sat, 14 Jan 2017 15:32:39 +0100
Subject: [PATCH 1/2] Add outputencoding parameter

---
 conf/logwatch.conf  | 8 
 scripts/logwatch.pl | 8 +---
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/conf/logwatch.conf b/conf/logwatch.conf
index 2b61ec6..0d0e31b 100644
--- a/conf/logwatch.conf
+++ b/conf/logwatch.conf
@@ -126,4 +126,12 @@ mailer = "/usr/sbin/sendmail -t"
 #
 #HostLimit = myhost
 
+#
+# With this option, the output encoding for mail headers can be set. It
+# defaults to utf-8. Be aware that the default value may change to autodetect
+# (take the system's encoding). Note that the configured value will be
+# upper-cased.
+#
+# OutputEncoding = utf-8
+
 # vi: shiftwidth=3 tabstop=3 et
diff --git a/scripts/logwatch.pl b/scripts/logwatch.pl
index 0167755..0cff511 100755
--- a/scripts/logwatch.pl
+++ b/scripts/logwatch.pl
@@ -90,6 +90,7 @@ $Config{'pathtobzcat'} = "bzcat";
 $Config{'output'} = "stdout"; #8.0
 $Config{'format'} = "text"; #8.0
 $Config{'encode'} = "none"; #8.0
+$Config{'outputencoding'} = "utf-8";
 $Config{'hostformat'} = "none"; #8.0
 $Config{'html_wrap'} = 80;
 $Config{'supress_ignores'} = 0;
@@ -1160,11 +1161,12 @@ sub initprint {
  } else {
 $out_mime .= "Content-Transfer-Encoding: 7bit\n";
  }
- #Config{output} html
+ #Config{output} html, Config{outputenconding}
+ my $encoding = uc($Config{outputencoding});
  if ( $Config{'format'} eq "html" ) {
-$out_mime .= "Content-Type: text/html; charset=\"UTF-8\"\n\n";
+$out_mime .= "Content-Type: text/html; charset=\"$encoding\"\n\n";
  } else {
-$out_mime .= "Content-Type: text/plain; charset=\"UTF-8\"\n\n";
+$out_mime .= "Content-Type: text/plain; charset=\"$encoding\"\n\n";
  }
 
  if ($Config{'hostformat'} eq "split") { #8.0 check hostlimit also? or ne none?
-- 
2.1.4

>From 4e2579f41f1b94db97d265a72f67309cbf1737fa Mon Sep 17 00:00:00 2001
From: Willi Mann 
Date: Sat, 14 Jan 2017 16:25:30 +0100
Subject: [PATCH 2/2] Use pager on stdout output to terminal

---
 conf/logwatch.conf  | 4 
 scripts/logwatch.pl | 7 ++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/conf/logwatch.conf b/conf/logwatch.conf
index 0d0e31b..e15ed3b 100644
--- a/conf/logwatch.conf
+++ b/conf/logwatch.conf
@@ -134,4 +134,8 @@ mailer = "/usr/sbin/sendmail -t"
 #
 # OutputEncoding = utf-8
 
+#
+# For output type stdout, use pager if the stdout is a terminal.
+#Pager = /usr/bin/less
+
 # vi: shiftwidth=3 tabstop=3 et
diff --git a/scripts/logwatch.pl b/scripts/logwatch.pl
index 0cff511..f053cb3 100755
--- a/scripts/logwatch.pl
+++ b/scripts/logwatch.pl
@@ -88,6 +88,7 @@ $Config{'pathtocat'} = "cat";
 $Config{'pathtozcat'} = "zcat";
 $Config{'pathtobzcat'} = "bzcat";
 $Config{'output'} = "stdout"; #8.0
+$Config{'pager'} = "/usr/bin/less"; #8.0
 $Config{'format'} = "text"; #8.0
 $Config{'encode'} = "none"; #8.0
 $Config{'outputencoding'} = "utf-8";
@@ -1127,7 +1128,11 @@ sub initprint {
$OStitle = "Solaris" if ($OSname eq "SunOS" && $release >= 2);
 
if ($Config{'output'} eq "stdout") { #8.0 start with others?
-  *OUTFILE = *STDOUT;
+  if($Config{'pager'} and -t STDOUT) {
+ open(OUTFILE,"|$Config{'pager'}") or die "could not open pager: $Config{'pager'} $!";
+  } else {
+ *OUTFILE = *STDOUT;
+  }
} elsif ($Config{'output'} eq "file") {
   open(OUTFILE,">>" . $Config{'filename'}) or die "Can't open output file: $Config{'filename'} $!\n";
} else {
-- 
2.1.4

Bug#849869: jessie-pu: package unrtf/0.21.5-3

[Willi Mann]

> Uploaded. Unfortunately, I realized after the upload that the debdiff
> got bloated by my pbuilder build. I guess because unapply-patches is not
> set. Let me know whether I should fix that.

False alarm- the diff is still fine. It just wasn't a good idea to
compare the 2 unpacked versions of the source tree instead of using
debdiff...

Willi

Bug#849869: jessie-pu: package unrtf/0.21.5-3

[Willi Mann]

Hi,

Am 2017-01-05 um 20:55 schrieb Adam D. Barratt:

>> The changelog is:
>> unrtf (0.21.5-3+deb8u1) stable; urgency=medium
>>
>>   * Add patch from upstream to fix CVE-2016-10091 (buffer overflow in various
>> cmd_ functions) closes: 849705
> 
> Please go ahead.

Uploaded. Unfortunately, I realized after the upload that the debdiff
got bloated by my pbuilder build. I guess because unapply-patches is not
set. Let me know whether I should fix that.

Willi

Bug#849869: jessie-pu: package unrtf/0.21.5-3

[Willi Mann]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

As per request of the security team, I intend to upload a security fix 
(CVE-2016-10091) of the unrtf package for the next jessie point release.

The changelog is:
unrtf (0.21.5-3+deb8u1) stable; urgency=medium

  * Add patch from upstream to fix CVE-2016-10091 (buffer overflow in various
cmd_ functions) closes: 849705

 -- Willi Mann   Sun, 01 Jan 2017 19:50:41 +0100

debdiff attached.

Let me know whether this intended upload is fine with you.

Willi

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru unrtf-0.21.5/debian/changelog unrtf-0.21.5/debian/changelog
--- unrtf-0.21.5/debian/changelog	2015-01-27 20:50:01.0 +0100
+++ unrtf-0.21.5/debian/changelog	2017-01-01 19:51:52.0 +0100
@@ -1,3 +1,10 @@
+unrtf (0.21.5-3+deb8u1) stable; urgency=medium
+
+  * Add patch from upstream to fix CVE-2016-10091 (buffer overflow in various
+cmd_ functions) closes: 849705
+
+ -- Willi Mann   Sun, 01 Jan 2017 19:50:41 +0100
+
 unrtf (0.21.5-3) unstable; urgency=medium
 
   [ Salvatore Bonaccorso ]
diff -Nru unrtf-0.21.5/debian/patches/0009-Replace-all-instances-of-sprintf-with-snprintf-and-a.patch unrtf-0.21.5/debian/patches/0009-Replace-all-instances-of-sprintf-with-snprintf-and-a.patch
--- unrtf-0.21.5/debian/patches/0009-Replace-all-instances-of-sprintf-with-snprintf-and-a.patch	1970-01-01 01:00:00.0 +0100
+++ unrtf-0.21.5/debian/patches/0009-Replace-all-instances-of-sprintf-with-snprintf-and-a.patch	2017-01-01 19:49:05.0 +0100
@@ -0,0 +1,179 @@
+From: Jean-Francois Dockes 
+Date: Sat, 31 Dec 2016 20:25:19 +0100
+Subject: Replace all instances of sprintf with snprintf and adjust size of
+ integer field in some cases
+
+This fixes CVE-2016-10091
+
+Bug-Debian: https://bugs.debian.org/849705
+---
+ src/attr.c|  4 ++--
+ src/convert.c | 28 ++--
+ src/output.c  |  4 ++--
+ 3 files changed, 18 insertions(+), 18 deletions(-)
+
+diff --git a/src/attr.c b/src/attr.c
+index 0337fd0..aea2a69 100644
+--- a/src/attr.c
 b/src/attr.c
+@@ -743,7 +743,7 @@ char *
+ assemble_string(char *string, int nr)
+ {
+ 
+-	char *s, tmp[12];/* Number of characters that can be in int type (including '\0') - AF */
++	char *s, tmp[20];
+ 	int i = 0, j = 0;
+ 
+ 	if (string == NULL)
+@@ -759,7 +759,7 @@ assemble_string(char *string, int nr)
+ 		}
+ 
+ 		if (string[i] != '\0') {
+-			sprintf(tmp, "%d", nr);
++			snprintf(tmp, 20, "%d", nr);
+ 			strcpy(&s[j], tmp);
+ 			j = j + strlen(tmp);
+ 		}
+diff --git a/src/convert.c b/src/convert.c
+index d22a2f9..62355be 100644
+--- a/src/convert.c
 b/src/convert.c
+@@ -448,7 +448,7 @@ static const int fcharsetparmtocp(int parm)
+ }
+ 
+ // Translate code page to encoding name hopefully suitable as iconv input
+-static char *cptoencoding(parm)
++static char *cptoencoding(int parm)
+ {
+ // Note that CP0 is supposed to mean current system default, which does
+ // not make any sense as a stored value, we don't handle it.
+@@ -935,7 +935,7 @@ cmd_cf (Word *w, int align, char has_param, int num) {
+ 	}
+ 	else
+ 	{
+-		sprintf(str,"#%02x%02x%02x",
++		snprintf(str, 40, "#%02x%02x%02x",
+ 			color_table[num].r,
+ 			color_table[num].g,
+ 			color_table[num].b);
+@@ -962,7 +962,7 @@ cmd_cb (Word *w, int align, char has_param, int num) {
+ 	}
+ 	else
+ 	{
+-		sprintf(str,"#%02x%02x%02x",
++		snprintf(str, 40, "#%02x%02x%02x",
+ 			color_table[num].r,
+ 			color_table[num].g,
+ 			color_table[num].b);
+@@ -987,7 +987,7 @@ cmd_fs (Word *w, int align, char has_param, int points) {
+ 	/* Note, fs20 means 10pt */
+ 	points /= 2;
+ 
+-	sprintf(str,"%d",points);
++	snprintf(str, 20, "%d", points);
+ 	attr_push(ATTR_FONTSIZE,str);
+ 
+ 	return FALSE;
+@@ -1118,7 +1118,7 @@ cmd_f (Word *w, int align, char has_param, int num)
+ {
+ // TOBEDONE: WHAT'S THIS ???
+ name = my_malloc(12);
+-sprintf(name, "%d", num);
++			snprintf(name, 12, "%d", num);
+ }
+ 
+ /* we are going to output entities, so should not output font */
+@@ -1169,7 +1169,7 @@ cmd_highlight (Word *w, int align, char has_param, int num)
+ 	}
+ 	else
+ 	{
+-		sprintf(str,"#%02x%02x%02x",
++		snprintf(str, 40, "#%02x%02x%02x",
+ 			color_table[num].r,
+ 			color_table[num].g,
+ 			color_table[num].b);
+@@ -1324,9 +1324,9 @@ cmd_ftech (Word *w, int align, char has_param, int param) {
+ 
+ static int 
+ cmd_expand (Word *w, int ali

Bug#849531: [Logwatch-devel] Bug#849531: Possible security problem,new logwatch sends mails with charset UTF-8

[Willi Mann]

Hi,

Am 2017-01-01 um 00:20 schrieb Jason Pyeron:
> Not exactly a valid test, besides it works for me. The issue is internal 
> ascii data being written as ascii but instructing consumers
> it is uft8. 
> 
> $ cat utf8_test.pl
> #!/usr/bin/perl
> #
> use strict;
> use File::Slurp;
> 
> my $inputfile = @ARGV[0];
> my $logfilecontent = read_file($inputfile);
> binmode(STDOUT, ":utf8");
> print $logfilecontent;
> 
> $ ./utf8_test.pl testlog.txt
> übersät
> 
> $ ./utf8_test.pl testlog.txt | hexdump -C
>   c3 bc 62 65 72 73 c3 a4  74 0a|..bers..t.|
> 000a
> 
> $ hexdump.exe -C testlog.txt
>   fc 62 65 72 73 e4 74 0a   |.bers.t.|
> 0008

What do you want to say with that? Your input is not in UTF-8.

Just for the record, the output what I posted originally:

% ./utf8_test.pl testlog
übersät
% ./utf8_test.pl testlog | hexdump -C
  c3 83 c2 bc 62 65 72 73  c3 83 c2 a4 74 0a|berst.|
000e
% hexdump -C testlog
  c3 bc 62 65 72 73 c3 a4  74 0a|..bers..t.|
000a

Bye
Willi

Bug#849855: unblock: unrtf/0.21.9-clean-3

[Willi Mann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock


Please lower the testing migration delay for package unrtf. It fixes
CVE-2016-10091 (buffer overflow).  Debdiff attached. Note that the changes to
import-orig.sh in the debdiff can be ignored. They are only relevant for
packaging the next upstream release.

unblock unrtf/0.21.9-clean-3

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#849705: unrtf: Stack buffer overflow

[Willi Mann]

Hi,

> Not sure yet if that would warrant a DSA, possibly it could be updated
> via the upcoming point release as well.

I pushed a jessie branch to the git repository with the patch from
upstream (some hunks had to be ignored). I also uploaded a patched
version to unstable.

https://anonscm.debian.org/cgit/collab-maint/unrtf.git/log/?h=jessie

Let me know how I should proceed for jessie.

Bye
Willi

Bug#849531: Possible security problem, new logwatch sends mails with charset UTF-8

[Willi Mann]

Dear Security Team,

I would like to get your input on bug #849531 [1]. A short summary:

Logwatch is a log summarizer that parses various logfiles and reports a
summary, either via e-mail or to stdout. Parts of the input are copied
verbatim w.r.t. to their encoding to the output (e.g., usernames, URLs,
etc.)  However, e-mails were sent with a hard-coded Content-Type: ...
encoding=ISO-8859-1. This meant that non-ascii UTF-8 characters were not
displayed correctly.

As part of a recent change that is already in Debian testing/unstable,
the Content-Type line was modified to say that the encoding is UTF-8,
obviously to ensure that utf-8 characters are displayed correctly.
However, logwatch does not ensure that the output is correct utf-8, and
that is claimed to be a security problem.

So my question is: Is it a security issue if a script sends e-mails with
encoding=utf-8, but potentially containing invalid utf-8 strings? If
yes, what would be the (minimum) requirements to address this problem?

thank you for your time
Willi

[1] https://bugs.debian.org/849531

Bug#849705: unrtf: Stack buffer overflow

[Willi Mann]

Hi Jean-Francois,

Are you fine with attached patch? I saw that two other cmd_ functions
follow the same pattern, so they are probably also vulnerable, right?

thanks
Willi

Am 2016-12-30 um 19:16 schrieb Jean-Francois Dockes:
> Willi Mann writes:
>  > Hi Dave,
>  > Hi Jean-Francois,
>  > 
>  > I got the following bug report, apparrently describing a buffer overflow
>  > in unrtf - which I can reproduce. Do you have a suggestion for a fix?
>  > 
>  > I'm also CCing debian's security team.
>  > 
>  > WM
> 
> I guess that you can just add a package patch to increate the str[] buffer
> size, something like
> 
> - char str[10];
> + char str[15];
> 
> (I'm sure that you could get by with less than 15 but I don't see the
> point).
> 
> For completeness, sprintf() could be changed to snprintf(), but maybe this
> can be left for the next release?
> 
> attr_push() does an strdup of the 2nd parameter, so the increased size
> should not be an issue there.
> 
> I've not tested the change, but I'm foolishly confident that it should fix the
> issue. I'll give it a better look in the following days (and also look for
> possible other instances of the problem).
> 
> jf
> 
> 
>  > Am 2016-12-30 um 01:44 schrieb Skylake:
>  > > Package: unrtf
>  > > Version: 0.21.9-clean-2
>  > > 
>  > > I've found a Stack-based buffer overflow in unrtf 0.21.9, which affects 
> three 
>  > > functions including: cmd_expand, cmd_emboss and cmd_engrave.
>  > > 
>  > > # convert.c
>  > > 
>  > > static int
>  > > cmd_expand (Word *w, int align, char has_param, int param) {
>  > >  char str[10];
>  > >  if (has_param) {
>  > >  sprintf(str, "%d", param/4); // Overflow, 9-digit negative 
> value 
>  > > triggers the bug
>  > >  if (!param)
>  > >  attr_pop(ATTR_EXPAND);
>  > >  else
>  > >  attr_push(ATTR_EXPAND, str);
>  > >  }
>  > >  return FALSE;
>  > > }
>  > > 
>  > > Apparently writing a negative integer to the buffer can trigger the 
> overflow 
>  > > (Minus sign needs an extra byte).
>  > > 
>  > > * How to trigger the bug *
>  > > 
>  > > $ echo "\expnd-4" > poc
>  > > $ unrtf poc
>  > > 
>  > > 
>  > > 
>  > > 
>  > > 
>  > > 
>  > > *** buffer overflow detected ***: unrtf terminated
>  > > === Backtrace: =
>  > > /lib/i386-linux-gnu/libc.so.6(+0x6737a)[0xb764f37a]
>  > > /lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x37)[0xb76dfe07]
>  > > /lib/i386-linux-gnu/libc.so.6(+0xf60a8)[0xb76de0a8]
>  > > /lib/i386-linux-gnu/libc.so.6(+0xf58b8)[0xb76dd8b8]
>  > > /lib/i386-linux-gnu/libc.so.6(_IO_default_xsputn+0xa6)[0xb7653bf6]
>  > > /lib/i386-linux-gnu/libc.so.6(_IO_vfprintf+0xf66)[0xb762b1d6]
>  > > /lib/i386-linux-gnu/libc.so.6(__vsprintf_chk+0x90)[0xb76dd950]
>  > > /lib/i386-linux-gnu/libc.so.6(__sprintf_chk+0x20)[0xb76dd8a0]
>  > > unrtf[0x804c7b8]
>  > > unrtf[0x804f77d]
>  > > unrtf[0x804f9e7]
>  > > unrtf[0x804920b]
>  > > /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6)[0xb7600276]
>  > > unrtf[0x804953c]
>  > > === Memory map: 
>  > > 08048000-0805b000 r-xp  08:01 405354 /usr/bin/unrtf
>  > > 0805b000-0805c000 r--p 00012000 08:01 405354 /usr/bin/unrtf
>  > > 0805c000-0805d000 rw-p 00013000 08:01 405354 /usr/bin/unrtf
>  > > 0805d000-08085000 rw-p  00:00 0
>  > > 0952d000-0954e000 rw-p  00:00 0  [heap]
>  > > b75ca000-b75e6000 r-xp  08:01 393233 
>  > > /usr/lib/i386-linux-gnu/libgcc_s.so.1
>  > > b75e6000-b75e7000 r--p 0001b000 08:01 393233 
>  > > /usr/lib/i386-linux-gnu/libgcc_s.so.1
>  > > b75e7000-b75e8000 rw-p 0001c000 08:01 393233 
>  > > /usr/lib/i386-linux-gnu/libgcc_s.so.1
>  > > b75e8000-b7799000 r-xp  08:01 395818 
>  > > /usr/lib/i386-linux-gnu/libc-2.24.so
>  > > b7799000-b779b000 r--p 001b 08:01 395818 
>  > > /usr/lib/i386-linux-gnu/libc-2.24.so
>  > > b779b000-b779c000 rw-p 001b2000 08:01 395818 
>  > > /usr/lib/i386-linux-gnu/libc-2.24.so
>  > > b779c000-b779f000 rw-p  00:00 0
>  > > b77a3000-b77a6000 rw-p 0000 00:00 0
>  > > b77a6000-b77a8000 r--p  00:00 0

Bug#849531: [Logwatch-devel] Bug#849531: Possible security problem,new logwatch sends mails with charset UTF-8

[Willi Mann]

Hi Jason,

thanks for your test cases. However, I don't think that binmode provides
an acceptable solution, at least not alone. While it ensures that the
strings are valid utf-8 strings, it will convert any valid utf-8
character to two "garbage" characters. Try

$ ./utf8_test.pl testlog

(see attached files)

I'm not really sure what a proper solution is. But I'm actually not yet
fully convinced that there is a problem logwatch should solve. I will
ask Debian's security team for advice.

WM



Am 2016-12-30 um 20:26 schrieb Jason Pyeron:
> A very rudimentary test:
> 
> /projects/logwatch
> $ perl -e 'for ($i=0; $i<256; ++$i) {print chr($i);}' | hexdump.exe -C
>   00 01 02 03 04 05 06 07  08 09 0a 0b 0c 0d 0e 0f  ||
> 0010  10 11 12 13 14 15 16 17  18 19 1a 1b 1c 1d 1e 1f  ||
> 0020  20 21 22 23 24 25 26 27  28 29 2a 2b 2c 2d 2e 2f  | !"#$%&'()*+,-./|
> 0030  30 31 32 33 34 35 36 37  38 39 3a 3b 3c 3d 3e 3f  |0123456789:;<=>?|
> 0040  40 41 42 43 44 45 46 47  48 49 4a 4b 4c 4d 4e 4f  |@ABCDEFGHIJKLMNO|
> 0050  50 51 52 53 54 55 56 57  58 59 5a 5b 5c 5d 5e 5f  |PQRSTUVWXYZ[\]^_|
> 0060  60 61 62 63 64 65 66 67  68 69 6a 6b 6c 6d 6e 6f  |`abcdefghijklmno|
> 0070  70 71 72 73 74 75 76 77  78 79 7a 7b 7c 7d 7e 7f  |pqrstuvwxyz{|}~.|
> 0080  80 81 82 83 84 85 86 87  88 89 8a 8b 8c 8d 8e 8f  ||
> 0090  90 91 92 93 94 95 96 97  98 99 9a 9b 9c 9d 9e 9f  ||
> 00a0  a0 a1 a2 a3 a4 a5 a6 a7  a8 a9 aa ab ac ad ae af  ||
> 00b0  b0 b1 b2 b3 b4 b5 b6 b7  b8 b9 ba bb bc bd be bf  ||
> 00c0  c0 c1 c2 c3 c4 c5 c6 c7  c8 c9 ca cb cc cd ce cf  ||
> 00d0  d0 d1 d2 d3 d4 d5 d6 d7  d8 d9 da db dc dd de df  ||
> 00e0  e0 e1 e2 e3 e4 e5 e6 e7  e8 e9 ea eb ec ed ee ef  ||
> 00f0  f0 f1 f2 f3 f4 f5 f6 f7  f8 f9 fa fb fc fd fe ff  ||
> 0100
> 
> /projects/logwatch
> $ perl -e 'binmode(STDOUT, ":utf8"); for ($i=0; $i<256; ++$i) {print STDOUT 
> chr($i);}' | hexdump.exe -C
>   00 01 02 03 04 05 06 07  08 09 0a 0b 0c 0d 0e 0f  ||
> 0010  10 11 12 13 14 15 16 17  18 19 1a 1b 1c 1d 1e 1f  ||
> 0020  20 21 22 23 24 25 26 27  28 29 2a 2b 2c 2d 2e 2f  | !"#$%&'()*+,-./|
> 0030  30 31 32 33 34 35 36 37  38 39 3a 3b 3c 3d 3e 3f  |0123456789:;<=>?|
> 0040  40 41 42 43 44 45 46 47  48 49 4a 4b 4c 4d 4e 4f  |@ABCDEFGHIJKLMNO|
> 0050  50 51 52 53 54 55 56 57  58 59 5a 5b 5c 5d 5e 5f  |PQRSTUVWXYZ[\]^_|
> 0060  60 61 62 63 64 65 66 67  68 69 6a 6b 6c 6d 6e 6f  |`abcdefghijklmno|
> 0070  70 71 72 73 74 75 76 77  78 79 7a 7b 7c 7d 7e 7f  |pqrstuvwxyz{|}~.|
> 0080  c2 80 c2 81 c2 82 c2 83  c2 84 c2 85 c2 86 c2 87  ||
> 0090  c2 88 c2 89 c2 8a c2 8b  c2 8c c2 8d c2 8e c2 8f  ||
> 00a0  c2 90 c2 91 c2 92 c2 93  c2 94 c2 95 c2 96 c2 97  ||
> 00b0  c2 98 c2 99 c2 9a c2 9b  c2 9c c2 9d c2 9e c2 9f  ||
> 00c0  c2 a0 c2 a1 c2 a2 c2 a3  c2 a4 c2 a5 c2 a6 c2 a7  ||
> 00d0  c2 a8 c2 a9 c2 aa c2 ab  c2 ac c2 ad c2 ae c2 af  ||
> 00e0  c2 b0 c2 b1 c2 b2 c2 b3  c2 b4 c2 b5 c2 b6 c2 b7  ||
> 00f0  c2 b8 c2 b9 c2 ba c2 bb  c2 bc c2 bd c2 be c2 bf  ||
> 0100  c3 80 c3 81 c3 82 c3 83  c3 84 c3 85 c3 86 c3 87  ||
> 0110  c3 88 c3 89 c3 8a c3 8b  c3 8c c3 8d c3 8e c3 8f  ||
> 0120  c3 90 c3 91 c3 92 c3 93  c3 94 c3 95 c3 96 c3 97  ||
> 0130  c3 98 c3 99 c3 9a c3 9b  c3 9c c3 9d c3 9e c3 9f  ||
> 0140  c3 a0 c3 a1 c3 a2 c3 a3  c3 a4 c3 a5 c3 a6 c3 a7  ||
> 0150  c3 a8 c3 a9 c3 aa c3 ab  c3 ac c3 ad c3 ae c3 af  ||
> 0160  c3 b0 c3 b1 c3 b2 c3 b3  c3 b4 c3 b5 c3 b6 c3 b7  ||
> 0170  c3 b8 c3 b9 c3 ba c3 bb  c3 bc c3 bd c3 be c3 bf  |....|
> 0180
>  
> This confirms that binmode utf8 is needed to print out the full ASCII range.
> 
>> -Original Message-
>> From: Jason Pyeron [mailto:jpye...@pdinc.us] 
>> Sent: Friday, December 30, 2016 14:03
>> To: Jason Pyeron; 'Willi Mann'; logwatch-de...@lists.sourceforge.net
>> Cc: 849...@bugs.debian.org; 849531-forwar...@bugs.debian.org; 
>> 'Klaus Ethgen'
>> Subject: RE: [Logwatch-devel] Bug#849531: Possible security 
>> problem,new logwatch sends mails with charset UTF-8
>>
>> I have opened https://sourceforge.net/p/logwatch/bugs/56/ .
>>
>> I am working a test 

Bug#849531: Possible security problem, new logwatch sends mails with charset UTF-8

[Willi Mann]

Hi Klaus,

Am 2016-12-30 um 18:36 schrieb Klaus Ethgen:
> Hi Willi,
> 
> Am Fr den 30. Dez 2016 um 18:18 schrieb Willi Mann:
>> can you elaborate how this could be exploited?
> 
> Well, log principally contains untrusted data that could be injected
> from untrusted source. That is no security hole itself.
> 
> But when that data gets displayed with the wrong charset, that can
> trigger problems in window managers (for example). See xterm which can
> be controlled via ansii sequences. Even more, it could trigger stream
> conversion problems if the UTF-8 implementation is not really fully
> tested with broken streams.

OK, I understand that text from untrusted sources is dangerous and could
be harmful to your terminal - and that it is better to assume logfiles
to be such an untrusted source. However, the change only affects
mailers, right? For mailers, I would expect them to not trust any mails
they get, and therefore to remove any dangerous byte sequences.
Otherwise, the mailer contains the security hole - and an attacker does
not need to go via logfiles and logwatch, he just sends you mail.

When running logwatch such that it writes its output to the terminal,
the change does not have any effect on the security, right?. If there is
a security issue with untrusted data, it was already there before.

So far, I cannot see that the change you mentioned would be problematic.
What I do see is that it might be wise to sanitize the output of
logwatch. A possible way to go might be to remove any byte with value <
0x20 - unless it is a newline or tab. But that is independent of the
ISO-8859-15 to utf-8 change.

Bye
Willi

Bug#849705: unrtf: Stack buffer overflow

[Willi Mann]

Hi Dave,
Hi Jean-Francois,

I got the following bug report, apparrently describing a buffer overflow
in unrtf - which I can reproduce. Do you have a suggestion for a fix?

I'm also CCing debian's security team.

WM

Am 2016-12-30 um 01:44 schrieb Skylake:
> Package: unrtf
> Version: 0.21.9-clean-2
> 
> I've found a Stack-based buffer overflow in unrtf 0.21.9, which affects three 
> functions including: cmd_expand, cmd_emboss and cmd_engrave.
> 
> # convert.c
> 
> static int
> cmd_expand (Word *w, int align, char has_param, int param) {
>  char str[10];
>  if (has_param) {
>  sprintf(str, "%d", param/4); // Overflow, 9-digit negative value 
> triggers the bug
>  if (!param)
>  attr_pop(ATTR_EXPAND);
>  else
>  attr_push(ATTR_EXPAND, str);
>  }
>  return FALSE;
> }
> 
> Apparently writing a negative integer to the buffer can trigger the overflow 
> (Minus sign needs an extra byte).
> 
> * How to trigger the bug *
> 
> $ echo "\expnd-4" > poc
> $ unrtf poc
> 
> 
> 
> 
> 
> 
> *** buffer overflow detected ***: unrtf terminated
> === Backtrace: =
> /lib/i386-linux-gnu/libc.so.6(+0x6737a)[0xb764f37a]
> /lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x37)[0xb76dfe07]
> /lib/i386-linux-gnu/libc.so.6(+0xf60a8)[0xb76de0a8]
> /lib/i386-linux-gnu/libc.so.6(+0xf58b8)[0xb76dd8b8]
> /lib/i386-linux-gnu/libc.so.6(_IO_default_xsputn+0xa6)[0xb7653bf6]
> /lib/i386-linux-gnu/libc.so.6(_IO_vfprintf+0xf66)[0xb762b1d6]
> /lib/i386-linux-gnu/libc.so.6(__vsprintf_chk+0x90)[0xb76dd950]
> /lib/i386-linux-gnu/libc.so.6(__sprintf_chk+0x20)[0xb76dd8a0]
> unrtf[0x804c7b8]
> unrtf[0x804f77d]
> unrtf[0x804f9e7]
> unrtf[0x804920b]
> /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6)[0xb7600276]
> unrtf[0x804953c]
> === Memory map: 
> 08048000-0805b000 r-xp  08:01 405354 /usr/bin/unrtf
> 0805b000-0805c000 r--p 00012000 08:01 405354 /usr/bin/unrtf
> 0805c000-0805d000 rw-p 00013000 08:01 405354 /usr/bin/unrtf
> 0805d000-08085000 rw-p  00:00 0
> 0952d000-0954e000 rw-p  00:00 0  [heap]
> b75ca000-b75e6000 r-xp  08:01 393233 
> /usr/lib/i386-linux-gnu/libgcc_s.so.1
> b75e6000-b75e7000 r--p 0001b000 08:01 393233 
> /usr/lib/i386-linux-gnu/libgcc_s.so.1
> b75e7000-b75e8000 rw-p 0001c000 08:01 393233 
> /usr/lib/i386-linux-gnu/libgcc_s.so.1
> b75e8000-b7799000 r-xp  08:01 395818 
> /usr/lib/i386-linux-gnu/libc-2.24.so
> b7799000-b779b000 r--p 001b 08:01 395818 
> /usr/lib/i386-linux-gnu/libc-2.24.so
> b779b000-b779c000 rw-p 001b2000 08:01 395818 
> /usr/lib/i386-linux-gnu/libc-2.24.so
> b779c000-b779f000 rw-p  00:00 0
> b77a3000-b77a6000 rw-p  00:00 0
> b77a6000-b77a8000 r--p  00:00 0  [vvar]
> b77a8000-b77aa000 r-xp  00:00 0  [vdso]
> b77aa000-b77cc000 r-xp  08:01 393914 
> /usr/lib/i386-linux-gnu/ld-2.24.so
> b77cc000-b77cd000 rw-p  00:00 0
> b77cd000-b77ce000 r--p 00022000 08:01 393914 
> /usr/lib/i386-linux-gnu/ld-2.24.so
> b77ce000-b77cf000 rw-p 00023000 08:01 393914 
> /usr/lib/i386-linux-gnu/ld-2.24.so
> bf992000-bf9b3000 rw-p  00:00 0  [stack]
> Aborted
> 
> * Test environment *
> 
> Linux debian 4.7.0-1-686-pae #1 SMP Debian 4.7.8-1 (2016-10-19) i686 GNU/Linux
> libc6 2.24-8
> 
> Regards,
> Amir
> 
> Sent with ProtonMail  Secure Email.
> 

Bug#849531: Possible security problem, new logwatch sends mails with charset UTF-8

[Willi Mann]

Hi Klaus,

can you elaborate how this could be exploited? What would be your
suggested fix?

I'm including the upstream mailing list in the conversation.

thanks you
Willi

Am 2016-12-28 um 10:09 schrieb Klaus Ethgen:
> Package: logwatch
> Version: 7.4.3+git20161207-1
> Severity: critical
> 
> Current logwatch did change from sending mails with charset iso-8859-1
> to UTF-8. This openes up a potential security hole as UTF-8 is not able
> to display all 8bit data.
> 
> This is especially true as the output from logwatch is from untrusted
> source where there could easily put some malicious content in. Logwatch
> does nothing to cleanup the mail content or convert it from the native
> charset to UTF-8.
> 
> Note that this bug went in recently as 7.4.0 did not have this bug
> (neither does 7.4.1). I do not find any upstream changelog in the
> package and when I download it from upstream directly, I cannot find any
> note of this breaking change.
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.7.10 (SMP w/8 CPU cores)
> Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages logwatch depends on:
> ii  exim4-daemon-light [mail-transport-agent]  4.88~RC6-2
> pn  perl:any   
> 
> Versions of packages logwatch recommends:
> ii  libdate-manip-perl   6.56-1
> ii  libsys-cpu-perl  0.61-2+b1
> pn  libsys-meminfo-perl  
> 
> Versions of packages logwatch suggests:
> ii  fortune-mod  1:1.99.1-7
> 
> -- no debconf information
> 
> 

Bug#841925: latexmk 4.48 in Debian

[Willi Mann]

Dear Ohura,

I really would like to see latexmk 4.48 in stretch. I prepared an 
updated package for latexmk. It is available from


https://publish.willi.space/2016-11-24-pL0GZHx4VTk/

Feel free to take it and upload it if you are fine with it. I can also 
do an upload if you want.


Let me know what your plans for the package are.

Bye
Willi

Bug#841925: new upstream version 4.48 is available

[Willi Mann]

Package: latexmk
Version: 1:4.41-1
Severity: wishlist

Hi, 

It would be great if you could package version 4.48 of latexmk.

thanks
Willi

Bug#834971: Acknowledgement (hash-slinger: 2.7 versions should depend on python-m2crypto (>= 0.24.0))

[Willi Mann]

Hi,

m2crypto has now been accepted to jessie-backports:

https://tracker.debian.org/news/792433

Bye
Willi

Bug#834971: hash-slinger: 2.7 versions should depend on python-m2crypto (>= 0.24.0)

[Willi Mann]

Package: hash-slinger
Version: 2.7-1~bpo8+1
Severity: normal

Hi,

the SNI functionality in the tlsa tool requires a python-m2crypto version that
is more recent than the version in jessie - the testing/unstable version
pf python-m2crypto works. This is especially problematic for the hash-slinger
version in backports (with python-m2crypto from jessie):

% tlsa --create publish.willi.space
Warning: initial query using resolver config file was not secure (try option 
--resolvconf="").
Unable to resolve publish.willi.space.: Unsuccessful DNS lookup or no data 
returned for rrtype  (28).
Could not set SNI (old M2Crypto version?)
Got a certificate with Subject: /CN=wserver.wm1.at
_443._tcp.publish.willi.space. IN TLSA 3 0 1 
021a934d464223122257b4bb726d4a7c6eb14dd68971334e04e62ecd8f3e93a6

So I uploaded a backport of python-m2crypto that is currently sitting in
backports-NEW. It would be great if you could fix the dependency in unstable
and jessie-backports (the latter once the backport has been accepted).

thanks
Willi


-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages hash-slinger depends on:
ii  ca-certificates20141019+deb8u1
ii  dns-root-data  2014060201+2
ii  libpython2.7-stdlib [python-argparse]  2.7.9-2
ii  openssh-client 1:6.7p1-5+deb8u3
ii  python 2.7.9-1
ii  python-dnspython   1.12.0-1
ii  python-gnupg   0.3.6-1
ii  python-ipaddr  2.1.11-2
ii  python-m2crypto0.21.1-3
ii  python-unbound 1.5.9-1~bpo8+1

hash-slinger recommends no packages.

hash-slinger suggests no packages.

-- no debconf information

Bug#819572: PATCH for amavis (Fwd: Bug#819572: logwatch: redundant argument in sprintf at .../amavis line 1338, <> line 321 message)

[Willi Mann]

Hi,

Am 2016-07-29 um 05:11 schrieb Nayr:
> Willi,
>   Sorry that I wasn't clearer, but your patch was missing a line 
> break. I added a '\n' to the patch when I posted my reply.  So my
> previously attached amavis.path file is different from what you
> submitted.

thanks for pointing this out - I thought first that you had to fix the
patch to apply properly...

I fixed it slightly differently than what you sent me, because you only
added the \n in case of $extra evaluating to true:

https://anonscm.debian.org/cgit/collab-maint/logwatch.git/tree/debian/patches/0007-s-s-amavis-Fix-perl-warning-redundant-argument-in-sp.patch

Let me know if you think this is still wrong.

WM

Bug#819572: PATCH for amavis (Fwd: Bug#819572: logwatch: redundant argument in sprintf at .../amavis line 1338, <> line 321 message)

[Willi Mann]

Hi,

attached is patch to fix a perl 5.22 (?) warning about parameters to
sprintf in the amavis script.

The full bug report can be found at

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819572

WM


 Weitergeleitete Nachricht 
Betreff: Bug#819572: logwatch: redundant argument in sprintf at
.../amavis line 1338, <> line 321 message
Weitersenden-Datum: Wed, 30 Mar 2016 16:27:01 +
Weitersenden-Von: Nayr 
Weitersenden-An: debian-bugs-dist@lists.debian.org
Weitersenden-CC: Willi Mann 
Datum: Wed, 30 Mar 2016 11:34:48 -0400
Von: Nayr 
Antwort an: Nayr , 819...@bugs.debian.org
An: Debian Bug Tracking System 

Package: logwatch
Version: 7.4.2-1
Severity: normal

Dear Maintainer,

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored:
LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages logwatch depends on:
ii  nullmailer [mail-transport-agent]  1:1.13-1+b1
ii  perl   5.22.1-9

Versions of packages logwatch recommends:
ii  libdate-manip-perl   6.52-1
ii  libsys-cpu-perl  0.61-1+b2
ii  libsys-meminfo-perl  0.98-1+b1

Versions of packages logwatch suggests:
ii  fortune-mod  1:1.99.1-7

-- no debconf information

--- /usr/share/logwatch/scripts/services/amavis	2016-03-30 23:32:34.0 +0200
+++ amavis	2016-07-27 20:53:23.913506745 +0200
@@ -1334,8 +1334,11 @@
  $$divisor == $Totals{$keyname} ? 100.00 : $Totals{$keyname} * 100 / $$divisor;
 }
 else {
-   push @{$lines[$cur_level]}, 
-  sprintf "$fmt  %-23s $extra\n", $total, $desc, commify ($Totals{$keyname});
+	   my $out = sprintf "$fmt  %-23s", $total, $desc;
+	   if ($extra) {
+	  $out .= sprintf " $extra", commify ($Totals{$keyname});
+	   }
+   push @{$lines[$cur_level]}, $out;
 }
  }
   }

Bug#819572: logwatch: redundant argument in sprintf at .../amavis line 1338, <> line 321 message

[Willi Mann]

Hi,

thanks for your fast reply.

Could you try attached patch and let me know whether it works for you?

In case you don't know how to apply the patch (as root):

patch /usr/share/logwatch/scripts/services/amavis < /tmp/amavis.patch

thanks
Willi
--- /usr/share/logwatch/scripts/services/amavis	2016-03-30 23:32:34.0 +0200
+++ amavis	2016-07-27 20:53:23.913506745 +0200
@@ -1334,8 +1334,11 @@
  $$divisor == $Totals{$keyname} ? 100.00 : $Totals{$keyname} * 100 / $$divisor;
 }
 else {
-   push @{$lines[$cur_level]}, 
-  sprintf "$fmt  %-23s $extra\n", $total, $desc, commify ($Totals{$keyname});
+	   my $out = sprintf "$fmt  %-23s", $total, $desc;
+	   if ($extra) {
+	  $out .= sprintf " $extra", commify ($Totals{$keyname});
+	   }
+   push @{$lines[$cur_level]}, $out;
 }
  }
   }

Bug#819572: logwatch: redundant argument in sprintf at .../amavis line 1338, <> line 321 message

[Willi Mann]

Hi,

any chance that you send me a logfile that demonstrates this problem? I
don't have access to any machine running amavis...

thanks
WM

Am 2016-03-30 um 17:34 schrieb Nayr:
> Package: logwatch
> Version: 7.4.2-1
> Severity: normal
> 
> Dear Maintainer,
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages logwatch depends on:
> ii  nullmailer [mail-transport-agent]  1:1.13-1+b1
> ii  perl   5.22.1-9
> 
> Versions of packages logwatch recommends:
> ii  libdate-manip-perl   6.52-1
> ii  libsys-cpu-perl  0.61-1+b2
> ii  libsys-meminfo-perl  0.98-1+b1
> 
> Versions of packages logwatch suggests:
> ii  fortune-mod  1:1.99.1-7
> 
> -- no debconf information
> 

Bug#824034: Fwd: Bug#824034: $ignore_services breaks on close parentheses

[Willi Mann]

Hi,

here is a bug report with a proposed patch concerning the specification
of services to ignore in the secure script.

Bye
Willi


 Weitergeleitete Nachricht 
Betreff: Bug#824034: $ignore_services breaks on close parentheses
Weitersenden-Datum: Wed, 11 May 2016 15:15:02 +
Weitersenden-Von: Jonny Lamb 
Weitersenden-An: debian-bugs-dist@lists.debian.org
Weitersenden-CC: Willi Mann 
Datum: Wed, 11 May 2016 16:12:53 +0100
Von: Jonny Lamb 
Antwort an: Jonny Lamb , 824...@bugs.debian.org
An: sub...@bugs.debian.org

Package: logwatch
Version: 7.4.3-1
Severity: normal
Tags: patch

The "secure" script's $ignore_services option is space separated but
uses \b to match items, which breaks when a service name ends in a close
parenthesis (such as "wordpress(example.com)").

Here's a patch that fixes the problem here. Use a different approach if
you fancy.

Cheerio,
-- 
Jonny Lamb

diff --git a/scripts/services/secure b/scripts/services/secure
index 31f7ba6..387f5fd 100755
--- a/scripts/services/secure
+++ b/scripts/services/secure
@@ -190,7 +190,7 @@ while (defined($ThisLine = )) {
$ThisLine =~ s/\[ID [0-9]+ [a-z]+\.[a-z]+\] //;
my $temp = $ThisLine;
$temp =~ s/^([^[:]+).*/$1/;
-   if ($Ignore =~ /\b\Q$temp\E\b/i) { next; }
+   if ($Ignore =~ /(\s|^)\Q$temp\E(\s|$)/i) { next; }
 
#current sarge
if ($ThisLine =~ /^[^ :]*:( [0-9:\[\]\.]+|) \(pam_(unix|securetty)\)/i ) 
{next; }

Bug#812528: Redundant argument in sprintf for postfix script

[Willi Mann]

Hi Eric,

Am 2016-01-24 um 18:54 schrieb Eric Dorland:
> Package: logwatch
> Version: 7.4.1+svn20151218rev302-1
> Severity: minor
>
> I'm getting the following warning when the postfix script runs:

could you verify whether attached version of the postfix script fixes
this issue? (unpack and Copy it to
/usr/share/logwatch/scripts/services/postfix)

Bye
Willi



postfix.xz
Description: application/xz

Bug#812528: Redundant argument in sprintf for postfix script

[Willi Mann]

Hi Eric,

Am 2016-01-24 um 18:54 schrieb Eric Dorland:
> Package: logwatch
> Version: 7.4.1+svn20151218rev302-1
> Severity: minor
>
> I'm getting the following warning when the postfix script runs:

could you verify whether attached version of the postfix script fixes
this issue? (unpack and Copy it to
/usr/share/logwatch/scripts/services/postfix)

thanks
Willi



postfix.xz
Description: application/xz

Bug#812393: logwatch has iptables, but not ip6tables

[Willi Mann]

Control: tag -1 upstream ipv6

Hi,

> I am using logwatch on dualstack system (IPv4 & IPv6). Logwatch has
> section for iptables which only manages IPv4.
> 
> I believe logwatch shuld also include ip6tables as I am only seeing
> traffic with one internet protocol instead of the two that are used by
> my system.

I forwarded your report to the upstream developers.

WM

Bug#812235: /usr/sbin/sendmail: setuid/setgid: Operation not permitted

[Willi Mann]

Package: courier-mta
Version: 0.75.0-10
Severity: important
Tags: patch

Hi Ondřej,

When I try to execute /usr/sbin/sendmail, I get
# sendmail
setuid/setgid: Operation not permitted

Changing the permission from 4755 to 2755 (setgid instead of setuid bit) solves 
the issue.

Patch attached (untested, but fix seems obvious). I can push to collab-maint 
if you approve the patch.

Bye
Willi

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages courier-mta depends on:
ii  courier-authlib0.66.4-2
ii  courier-base   0.75.0-10
ii  debconf [debconf-2.0]  1.5.58
ii  libc6  2.21-6
ii  libcourier-unicode11.4-1
ii  libgcc11:5.3.1-5
ii  libgdbm3   1.8.3-13.1
ii  libidn11   1.32-3
ii  libnet-cidr-perl   0.17-1
ii  libperl5.225.22.1-4
ii  libstdc++6 5.3.1-5

courier-mta recommends no packages.

Versions of packages courier-mta suggests:
ii  bsd-mailx [mail-reader]  8.1.2-0.20150408cvs-1
pn  courier-doc  
pn  courier-filter-perl  
pn  couriergrey  
ii  evolution [mail-reader]  3.18.3-1
ii  icedove [mail-reader]38.5.0-1+b1
ii  kmail [mail-reader]  4:4.14.10-2
ii  mutt [mail-reader]   1.5.24-1

>From cead264474c0fdaa1723fa2b6a30bd839b1505d4 Mon Sep 17 00:00:00 2001
From: Willi Mann 
Date: Thu, 21 Jan 2016 20:40:42 +0100
Subject: [PATCH] Set permissions of /usr/sbin/sendmail to 2755

---
 debian/courier-mta.postinst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/courier-mta.postinst b/debian/courier-mta.postinst
index a26128a..c8062e4 100644
--- a/debian/courier-mta.postinst
+++ b/debian/courier-mta.postinst
@@ -61,7 +61,7 @@ if [ "$1" = "configure" ]; then
 add_override courier courier 4755 /usr/sbin/rmail
 add_override courier courier 2755 /usr/bin/mailq
 add_override courier courier 4755 /usr/bin/cancelmsg
-add_override courier courier 4755 /usr/sbin/sendmail
+add_override courier courier 2755 /usr/sbin/sendmail
 add_override courier courier 4750 /usr/lib/courier/courier/submitmkdir
 
 for dir in allfilters filters msgq msgs track; do
-- 
2.1.4

Bug#809756: Clarification

[Willi Mann]

Am 2016-01-20 um 09:13 schrieb Mobile Perpetuum:
> Hi, I confirm this bug in version 7.4.1+svn20151218rev302-1

Just for the record: what Mobile Perpetuum reports is not the same bug.
It is another problem with postfix that appears to require to execute a
specific printf call in order to occur.

WM

Bug#805030: libssh: newer upstream versions?

[Willi Mann]

Hi Chris,

I did some testing on the reverse dependencies of libssh-4 (not
libssh-gcrypt-4) for basic functionality with libssh where this appeared
to be feasible (see attachment). From what I've seen so far, I'm
confident that we won't cause big breakage. Of course, ibssh-gcrypt-4
should also be tested.

I think once we finalize the package, we should ask Laurent or Mike for
a review, but then we can upload directly to unstable.

Bye
Willi
gnugk:
libssh needed for SSH - secured status port
NOT TESTED
hydra:
test: attacking my own hosts on ssh
OK
kio-extras:
test: sftp, copy operation in dolphin with sftp:// protocol
OK
kodi:
probably for sftp-ing other services
NOT TESTED
libguac-client-ssh0:
plugin for the guacamode proxy daemon
NOT TESTED
remmina:
test: SSH connection to another local user (+ SFTP) using Public Key 
auth
OK
remmina-plugin-nx:
no NX setup available
NOT TESTED
tmate:
looks OK - ssh session could be established
x2goclient, x2goplugin:
I don't have an x2go server
NOT TESTED
yafc:
SFTP connection
OK

Bug#805030: libssh: newer upstream versions?

[Willi Mann]

Hi,

Am 2016-01-09 um 02:46 schrieb Chris Knadle:
> At DebConf15 there was discussion of movement away from Alioth for a number
> of reasons, including Alioth being considered "too full".  I don't have an
> objection to hosting Debian-related work in a Debian git repository -- but
> Alioth isn't controlled by Debian.  For existing projects on Alioth I don't
> mind making a request to join them, but I'd rather put repos for new
> projects somewhere else.

Well, currently there is nothing "more Debian" for git hosting, right?
So let's use what exists and what allows easy collaboration with other
developers.

> Sure -- I can either pull from your repo or you could send patches as
> attachments in email via git format-patch.

Attached are two patches. One fixes one of the lintian warning (the
patch adapts to the new library version), the other removes the -dbg
package as they are now built automatically.

Bye
Willi
From 2792f1aa02aaac6aaf1570c3d16d17e13241bad4 Mon Sep 17 00:00:00 2001
From: Willi Mann 
Date: Sat, 9 Jan 2016 16:37:49 +0100
Subject: [PATCH 1/2] debian/libssh-gcrypt-4.lintian-overrides: Adapt override
 for 4.4.0 version

---
 debian/libssh-gcrypt-4.lintian-overrides | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/libssh-gcrypt-4.lintian-overrides b/debian/libssh-gcrypt-4.lintian-overrides
index 86ae299..54d6044 100644
--- a/debian/libssh-gcrypt-4.lintian-overrides
+++ b/debian/libssh-gcrypt-4.lintian-overrides
@@ -1,4 +1,4 @@
 libssh-gcrypt-4: package-name-doesnt-match-sonames libssh-gcrypt4 libssh-gcrypt-threads4
 # The development symlink is not renamed to add the "-gcrypt" suffix
-libssh-gcrypt-4: dev-pkg-without-shlib-symlink usr/lib/x86_64-linux-gnu/libssh-gcrypt.so.4.4.1 usr/lib/x86_64-linux-gnu/libssh-gcrypt.so
-libssh-gcrypt-4: dev-pkg-without-shlib-symlink usr/lib/x86_64-linux-gnu/libssh-gcrypt_threads.so.4.4.1 usr/lib/x86_64-linux-gnu/libssh-gcrypt_threads.so
+libssh-gcrypt-4: dev-pkg-without-shlib-symlink usr/lib/x86_64-linux-gnu/libssh-gcrypt.so.4.4.0 usr/lib/x86_64-linux-gnu/libssh-gcrypt.so
+libssh-gcrypt-4: dev-pkg-without-shlib-symlink usr/lib/x86_64-linux-gnu/libssh-gcrypt_threads.so.4.4.0 usr/lib/x86_64-linux-gnu/libssh-gcrypt_threads.so
-- 
2.6.4

From e1ef8c2ca55f7bd7e81b5b84267a975541fe1721 Mon Sep 17 00:00:00 2001
From: Willi Mann 
Date: Sat, 9 Jan 2016 16:40:17 +0100
Subject: [PATCH 2/2] debian/control,debian/rules: Remove libssh-dbg package

---
 debian/control | 16 
 debian/rules   |  3 ---
 2 files changed, 19 deletions(-)

diff --git a/debian/control b/debian/control
index 0b9576c..028e6a3 100644
--- a/debian/control
+++ b/debian/control
@@ -84,22 +84,6 @@ Description: tiny C SSH library. Development files (gcrypt flavor)
  .
  This package contains development files to build the gcrypt flavor.
 
-Package: libssh-dbg
-Priority: extra
-Section: debug
-Architecture: any
-Depends: libssh-4 (= ${binary:Version}) | libssh-gcrypt-4 (= ${binary:Version}),
- ${misc:Depends}
-Multi-Arch: same
-Description: tiny C SSH library. Debug symbols
- The ssh library was designed to be used by programmers needing a working SSH
- implementation by the mean of a library. The complete control of the client
- is made by the programmer. With libssh, you can remotely execute programs,
- transfer files, use a secure and transparent tunnel for your remote programs.
- With its SFTP implementation, you can play with remote files easily.
- .
- This package contains debug symbols.
-
 Package: libssh-doc
 Section: doc
 Architecture: all
diff --git a/debian/rules b/debian/rules
index 3dd509f..3fab5d9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -46,8 +46,5 @@ override_dh_install:
 	dh_install -plibssh-gcrypt-4 -plibssh-gcrypt-dev --sourcedir=debian/tmp-gcrypt
 	dh_install --remaining-packages
 
-override_dh_strip:
-	dh_strip --dbg-package=libssh-dbg
-
 get-orig-source:
 	uscan --noconf --force-download --rename --download-current-version --destdir=..
-- 
2.6.4

Bug#805030: libssh: newer upstream versions?

[Willi Mann]

Hi Chris,

Am 2016-01-08 um 07:57 schrieb Chris Knadle:
> Willi Mann:
>>
>> Could you make the git repo somewhere available?
> 
>git clone git://git.coredump.us/debian/libssh.git
> 
> I use git-buildpackage and pristine-tar, and the clone will contain all that
> plus default to the '0.7.2' branch that contains all the commits I've done
> on the package.

I think it would be good to rebase your work onto the repository in
collab-maint. Do you already have write access there? If not, could you
apply for it?

https://lists.debian.org/debian-devel-announce/2012/01/msg6.html

In the meantime, it is probably better to work with your repository.
Once I will make commits, I'll send you a link to my clone of the repo.

Bye
Willi

Bug#805030: libssh: newer upstream versions?

[Willi Mann]

Hi,

sorry I did not find time to answer earlier.

Am 2015-12-02 um 01:22 schrieb Chris Knadle:
> Mike Gabriel:
>> Hi Willi, hi Laurent,
>>
>> On  Sa 28 Nov 2015 19:29:01 CET, Willi Mann wrote:
>>
>>> Hi Laurent, Hi Mike,
>>>
>>> is there a particular reason why libssh wasn't updated to newer upstream
>>> versions?
>>>
>>> Bye
>>> Willi
>>
>> from my side, this has not happened, because Laurent ist the primary
>> maintainer of libssh. Also, I currently have repetetive ENOTIME states here.
>>
>> For a libssh upstream bump, it actually requires some tests with
>> libssh-dependent packages and then filing a library transition bug.
>>
>> Do you think you can help with libssh testing? All applications
>> (apt-rdepends is your friend here) linking against libssh should be built
>> and runtime-tested against libssh 0.7.

> I think rebuilding and runtime testing /every/ application using libssh is a
> burden nobody wants -- I don't think that's a realistic expectation.

I can certainly do some testing, but I also don't think it is realistic
to runtime test all reverse dependencies ourselves.

I think it would be a good first step to bring a new version to git and
then upload it to experimental. Does anybody already have sources of
0.7.2 that could be pushed to git and get uploaded?

Bye
Willi

Bug#752337: setools: Logwatch script in wrong location, produces error when package is removed but not purged

[Willi Mann]

Hi,

Am 2015-12-28 um 13:07 schrieb Laurent Bigonville:
> Le 28/12/15 09:55, Willi Mann a écrit :
>> Hi,
>>
>> Am 2015-12-28 um 01:28 schrieb Laurent Bigonville:
>>> On Sun, 22 Jun 2014 21:14:55 +0200 Willi Mann  wrote:
>>>> Hi,
>>>>
>>>> I think the script
>>>> /etc/logwatch/scripts/services/seaudit-report-service
>>>> should be shipped in /usr/share/logwatch/scripts/services, unless it
>>> is really
>>>> expected to be modified by the user like a configuration file.
>> ...
>>> Shouldn't all the files in /etc/logwatch be moved to
>>> /usr/share/logwatch?
>> The logwatch package curretnly does not ship any files in /etc/logwatch,
>> only the directory structure to allow users to override scripts and
>> config files. Do you know any other package that ships files in
>> /etc/logwatch?
> I was more thinking about the 2 other files that setools is shipping in
> addition to the script:
> 
> /etc/logwatch/conf/logfiles/seaudit-report-group.conf
> /etc/logwatch/conf/services/seaudit-report-service.conf

I think it is better to keep those files there for now. I might actually
decide to ship configuration files for the logwatch package again in
/etc/logwatch in the future as it tends to confuse people - some modify
the *.conf files in /usr/share/logwatch.

Bye
Willi

Bug#752337: setools: Logwatch script in wrong location, produces error when package is removed but not purged

[Willi Mann]

Hi,

Am 2015-12-28 um 01:28 schrieb Laurent Bigonville:
> On Sun, 22 Jun 2014 21:14:55 +0200 Willi Mann  wrote:
>>
>> Hi,
>>
>> I think the script /etc/logwatch/scripts/services/seaudit-report-service
>> should be shipped in /usr/share/logwatch/scripts/services, unless it
> is really
>> expected to be modified by the user like a configuration file.
> 
...
> Shouldn't all the files in /etc/logwatch be moved to /usr/share/logwatch?

The logwatch package curretnly does not ship any files in /etc/logwatch,
only the directory structure to allow users to override scripts and
config files. Do you know any other package that ships files in
/etc/logwatch?

Bye
Willi

Bug#805030: libssh: newer upstream versions?

[Willi Mann]

Hi Laurent, Hi Mike,

is there a particular reason why libssh wasn't updated to newer upstream
versions?

Bye
Willi



signature.asc
Description: OpenPGP digital signature

Bug#800468: crashes in liblmdb on start-up

[Willi Mann]

Am 2015-10-03 um 19:42 schrieb Felix Geyer:
> Hi,
> 
> On Sat, 03 Oct 2015 15:58:34 +0200 Mario Blättermann 
>  wrote:
>> Same behavior on a freshly installed Stretch. The gdb output:
>>
>> (gdb) run
>> Starting program: /usr/bin/dolphin
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> [New Thread 0x7fffe235a700 (LWP 14801)]
>> [New Thread 0x7fffdafbd700 (LWP 14802)]
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x7fffead34960 in mdb_txn_begin ()
>> from /usr/lib/x86_64-linux-gnu/liblmdb.so.0
>>
>> It happened after I tried to config Dolphin to let the preview sidebar 
>> appear.
> 
> Could you please test if upgrading libkf5baloo5 and libkf5balooengine5 to 
> 5.14.0-2 (unstable)
> fixes the crash?

Yes, upgrading these packages fixes the problem.

thanks
Willi

Bug#800468: crashes in liblmdb on start-up

[Willi Mann]

Package: dolphin
Version: 4:15.08.1-1
Severity: grave

Hi,

dolphin crashes on every attempt to start (i.e. it shows the window with the
directory content for a second and then segfaults) with the following
backtrace:

bt full
#0  mdb_txn_begin (env=0x0, parent=0x0, flags=131072, ret=0x7fffcd574788) at 
mdb.c:2650
txn = 
ntxn = 
rc = 
size = 
tsize = 136
#1  0x7f374b62ca1c in Baloo::File::load() () from 
/usr/lib/x86_64-linux-gnu/libKF5Baloo.so.5
No symbol table info available.
#2  0x7f374bbc2cb6 in Baloo::FileFetchJob::doStart (this=0x277ce30) at 
../../src/filefetchjob.cpp:58
file = {d = 0x294f500}
comment = {static null = {}, d = 0x0}
prop = {d = 0x23b4500}
md = 
tags = {> = {> = {}, {p = {static shared_null = {ref = {atomic = {_q_value = -1}}, alloc = 
0, 
  begin = 0, end = 0, array = {0x0}}, d = 0x240a540}, d = 
0x240a540}}, }
rating = 
__for_range = 
#3  0x7f37488b41c1 in QObject::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#4  0x7f3749360b8c in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#5  0x7f3749366230 in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#6  0x7f3748882a8b in QCoreApplication::notifyInternal(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#7  0x7f3748884bc7 in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#8  0x7f37488d73b2 in 
QEventDispatcherUNIX::processEvents(QFlags) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#9  0x7f373a05c8ed in ?? () from 
/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
No symbol table info available.
#10 0x7f37488802ca in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#11 0x7f3748887e3c in QCoreApplication::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
No symbol table info available.
#12 0x7f374db55294 in kdemain () from 
/usr/lib/x86_64-linux-gnu/libkdeinit5_dolphin.so
No symbol table info available.
#13 0x7f374d76fb45 in __libc_start_main (main=0x400730 , argc=1, 
argv=0x7fffcd575068, init=, fini=, 
rtld_fini=, 
stack_end=0x7fffcd575058) at libc-start.c:287
result = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -6800447105095750550, 
4196149, 140736638439520, 0, 0, 6800558367846640746, 6913429561201208426}, 
  mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x400840 
<__libc_csu_init>, 0x7fffcd575068}, data = {prev = 0x0, cleanup = 0x0, 
canceltype = 4196416}}}
not_first_call = 
#14 0x0040075e in _start ()

mdb_txn_begin appears to not being able to deal with env==NULL.

I can install more *dbg packages if needed for a better backtrace. Just let me
know.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.1.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages dolphin depends on:
ii  libc6  2.19-22
ii  libdolphinvcs5 4:15.08.1-1
ii  libkf5baloo5   5.14.0-1
ii  libkf5baloowidgets515.08.0-2
ii  libkf5bookmarks5   5.14.0-1
ii  libkf5codecs5  5.14.0-1
ii  libkf5completion5  5.14.0-1
ii  libkf5configcore5  5.14.0-1
ii  libkf5configgui5   5.14.0-1
ii  libkf5configwidgets5   5.14.0-1
ii  libkf5coreaddons5  5.14.0-1
ii  libkf5dbusaddons5  5.14.0-1
ii  libkf5filemetadata35.14.0-1
ii  libkf5i18n55.14.0-1
ii  libkf5iconthemes5  5.14.0-1
ii  libkf5itemviews5   5.14.0-1
ii  libkf5jobwidgets5  5.14.0-1
ii  libkf5kcmutils55.14.0-1
ii  libkf5kiocore5 5.14.0-1
ii  libkf5kiofilewidgets5  5.14.0-1
ii  libkf5kiowidgets5  5.14.0-1
ii  libkf5newstuff55.14.0-1
ii  libkf5notifications5   5.14.0-1
ii  libkf5parts5   5.14.0-1
ii  libkf5service5 5.14.0-1
ii  libkf5solid5   5.14.0-2
ii  libkf5textwidgets5 5.14.0-1
ii  libkf5widgetsaddons5   5.14.0-1
ii  libkf5windowsystem55.14.0-1
ii  libkf5xmlgui5  5.14.0-1
ii  libphonon4qt5-44:4.8.3-2
ii  libqt5core5a   5.4.2+dfsg-9
ii  libqt5dbus55.4.2+dfsg-9
ii  libqt5gui5 5.4.2+dfsg-9
ii  libqt5widgets5 5.4.2+dfsg-9
ii  libqt5xml5 5.4.2+dfsg-9
ii  libstdc++6  

Bug#797817: linklint: does not support HTTP 307 (temporary redirect) status code

[Willi Mann]

Package: linklint
Version: 2.3.5-5
Severity: normal
Tags: patch

linklint does not support the HTTP 307 (temporary redirect) status code. When a
server answers with 307, linklint reports an "unknown error". This is easy to
fix - see attached patch.

Please consider adding this patch to the debian package.

thanks
Willi

-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -u linklint-2.3.5/linklint-2.3.5 linklint-2.3.5/linklint-2.3.5
--- linklint-2.3.5/linklint-2.3.5
+++ linklint-2.3.5/linklint-2.3.5
@@ -3118,6 +3118,7 @@
 %FlagMoved = (
 301, 'moved permanently (301)',
 302, 'moved temporarily (302)',
+307, 'temporary redirect (307)',
   -3003, 'redirected',
 );
 
diff -u linklint-2.3.5/debian/changelog linklint-2.3.5/debian/changelog

Bug#795296: "You are not allowed to save the configuration" (both root and ordinary user)

[Willi Mann]

Package: kde-config-sddm
Version: 4:5.3.2-1
Severity: normal

Hi,

I get the message in the subject when I go to the SDDM config unit. It happens
both when I go there as ordinary user and as root. Let me know whether I can
provide further information to resolve this bug.

thanks
Willi


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.0.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages kde-config-sddm depends on:
ii  libc6 2.19-19
ii  libkf5auth5   5.12.0-1
ii  libkf5configcore5 5.12.0-1
ii  libkf5configwidgets5  5.12.0-1
ii  libkf5coreaddons5 5.12.0-1
ii  libkf5i18n5   5.12.0-1
ii  libkf5kiowidgets5 5.12.0-1
ii  libqt5core5a  5.4.2+dfsg-5
ii  libqt5gui55.4.2+dfsg-5
ii  libqt5quickwidgets5   5.4.2-4
ii  libqt5widgets55.4.2+dfsg-5
ii  libqt5x11extras5  5.4.2-2+b1
ii  libstdc++65.1.1-14
ii  libx11-6  2:1.6.3-1
ii  libxcursor1   1:1.1.14-1+b1

kde-config-sddm recommends no packages.

kde-config-sddm suggests no packages.

-- no debconf information

Bug#792915: Logwatch fails to parse log statements

[Willi Mann]

Hi,

--archives is the default, which solves most of the problems you
describe. The only known problem that remains is support for alternative
compression methods (gz and bzip2 are supported, but xz is not supported).

If you report bugs, please use reportbug, as the upstream version only
makes it hard to know whether we talk about the same package version.

Bye
Willi

Am 2015-07-20 um 05:29 schrieb Jane D:
> Package: logwatch
> Version: 7.4.1
> 
> SYMPTOM
> Log statements for the first hours of yesterday are ignored and not
> processed by logwatch.
> 
> CAUSE
> The configuration for syslog uses files /var/log/syslog and
> /var/log/syslog.1. Because log rotation does not occur exactly at
> midnight, the first portion of yesterday's log statements are in
> syslog.2, and logwatch does not process this file.
> 
> GET-AROUND FOR SYSLOG ONLY
> sudo mkdir --parents /etc/logwatch/conf/logfiles; sudo echo "LogFile =
> syslog.2" | sudo tee /etc/logwatch/conf/logfiles/syslog.conf
>> /dev/null
> 
> 
> BIGGER PROBLEM 1
> The way of locating logs does not take in account the logrotate rotate
> directive or the period of which logs are rotated. logwatch would need
> to scan every log until a too old modification date is found.
> Since logs can be rotated when reaching a certain size, which can be
> hundreds of times daily. Therefore, every index number up to
> logrotate's rotate setting must be scanned.
> Say a log has rotate 100 and is rotated every hour dues ot its size or
> configuration. Logwatch would then need to examine file indexes up to
> 48 (2 x 24 hours), ie. put 48 "LogFile=
>…" statements in the log configuration file. The logwatch
> architecture is lacking.
> 
> 
> BIGGER PROBLEM 2
> The compressed extension is assumed to be .gz. Today, it is more
> likely to be .xz but can be anything, really. Logwatch should examine
> any file by stemming the original log filename, eg. look for syslog*
> and test the result against common file compress methods.
> 
> 
> BIGGER PROBLEM 3
> If logrotate delaycompress is used, syslog.2 will be compressed and
> logwatch will not look in it. ie. every run would need the --archives
> option, and this is not the default.
> 
> 
> DATA
> When are logs rotated? maybe 6:25 am
> grep /etc/cron.daily /etc/crontab
> 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts
> --report /etc/cron.daily )
> 
> Add a service that echoes all processed syslog lines
> sudo mkdir --parents /etc/logwatch/conf/services
> /etc/logwatch/scripts/services; echo -e "Title = \"All
> syslog\"\nLogFile = syslog" | sudo tee
> /etc/logwatch/conf/services/allsyslog.conf >/dev/null; Y="!"; echo -e
> "#$Y/bin/bash -eu\ncat" | sudo tee
> /etc/logwatch/scripts/services/allsyslog >/dev/null
> 
> logwatch --service allsyslog | less
> 
> delete the service
> sudo rm /etc/logwatch/conf/services/allsyslog.conf
> /etc/logwatch/scripts/services/allsyslog
> 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#782653: openmpi: (non-)reproducibility of build failure

[Willi Mann]

Hi!

Am 2015-04-19 um 00:29 schrieb Mario Lang:
> Willi Mann  writes:
> 
>> was anybody of you able to reproduce this build failure in a clear
>> chroot environment?
> 
> No.
> 
>> I failed to reproduce it in a jessie pbuilder environment, and also on
>> an another machine (mixed jessie/wheezy).
> 
> Hmm, for me, it works in a clean pbuilder, but fails on every "normal"
> installation box (sid and jessie) I tried (I tried three, two sid and
> one jessie box).  Simon tried a fresh VirutalBox jessie install, which
> also fails.  I am guessing we are missing a Build-Conflicts.  But I
> haven't been able to identify it yet.
>

It seems that the problem is that timestamp on the libtool.m4 file is
too old. My guess is that in MET, the timestamp somehow underflows. By
setting the timestamp to 1980 (instead of 1970) the problem disappears,
at least on my machine.

In clean pbuilder environments, you probably do not have the timezone
set, so the 1970 timestamp does not underflow...

Attached patch fixes the problem for me. Mario, Simon, can you confirm?

WM


diff --git a/debian/patches/ompi_autogen_sh.patch b/debian/patches/ompi_autogen_sh.patch
index 0429388..7c655f3 100644
--- a/debian/patches/ompi_autogen_sh.patch
+++ b/debian/patches/ompi_autogen_sh.patch
@@ -5,7 +5,7 @@
  fi
  
 +# Ensure libtool.m4 is very old so that make does not rebuild aclocal.m4
-+touch -t 19700101.00 config/libtool.m4
++touch -t 19800101.00 config/libtool.m4
 +
  run_and_check $ompi_autoconf
  


signature.asc
Description: OpenPGP digital signature

Bug#782033: kexec-tools: bug only when sysvinit is used

[Willi Mann]

Hi,

I could only reproduce this bug with sysvinit as init system. I think
one could use runlevel (if it exists) to detect whether a real shutdown
is running. Maybe something like the attached patch could fix the
problem (not yet tested).

WM
diff --git a/debian/kexec-load.init.d b/debian/kexec-load.init.d
index 28306a7..f4de112 100644
--- a/debian/kexec-load.init.d
+++ b/debian/kexec-load.init.d
@@ -109,6 +109,9 @@ case "$1" in
 			exit 0
 		fi
 	fi
+	if [ -x /sbin/runlevel -a "$(runlevel | awk '{ print $2 }')" != "6" ]; then 
+		exit 0
+	fi
 	do_stop
 	;;
   *)


signature.asc
Description: OpenPGP digital signature

Bug#782669: enigmail: Can't decrypt messages vom "OpenPGP für Windows Phone"

[Willi Mann]

Hi,

Am 2015-04-15 um 23:46 schrieb derMaria:
> whenever I get a mail from someone who encrypted the Message with "OpenPGP für
> Windows Phone" from Christoph Müller  de/store/app/openpgp-f%C3%BCr-windows-phone/0a1906e2-eb48-4cdb-bbab-
> 30ea308b9065> I cannot decrypt the message. That program seems to encrypt only
> attached files, not the mail body. When I click "decrypt and open file" in
> Icedove 31.6.0 it creates a 0 Byte textfile and opens it in my texteditor.

Hmm, is there any change you could get someone with this App to send me
an encrypted test message? I don't have any access to a Windows-based
smartphone.

You could also try the enigmail version from experimental (1.8.2-1),
maybe it fixes the problem.

thanks
Willi




signature.asc
Description: OpenPGP digital signature

Bug#782653: openmpi: (non-)reproducibility of build failure

[Willi Mann]

Hi,

was anybody of you able to reproduce this build failure in a clear
chroot environment? I failed to reproduce it in a jessie pbuilder
environment, and also on an another machine (mixed jessie/wheezy).

WM



signature.asc
Description: OpenPGP digital signature

Bug#755722: should be fixed in jessie

[Willi Mann]

Hi,

I think this bug should get fixed for jessie. I don't want to raise the
severity of this bug myself as it was already lowered once, but please
fix this bug before the release.

thanks
Willi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#745195: fixed, but more testing intended

[Willi Mann]

Just a status update on this bug: The upload of unrtf 0.21.5-3 fixes
this bug, but I intend to do more testing before asking for an unblock.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#745195: status

[Willi Mann]

Control: tag -1 + pending

I've upgraded this bug to RC status because it is a regression from
wheezy. It is especially bad because it may bite some reverse
dependencies that use unrtf as part of a processing chain.

Salvatore Bonaccorso has already proposed a fix for this bug, based on
the upstream fix in newer versions.

WM


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#775933: enigmail: calls 'gpg --list-keys' before encrypting. This is slow, esp. with gpg2

[Willi Mann]

Hi,

Am 2015-01-21 um 18:42 schrieb Daniel Kahn Gillmor:
> On Wed 2015-01-21 12:25:13 -0500, Andrew Gallagher wrote:
> 
>> Is this all really necessary? It would be hundreds of times faster to call 
>> 'gpg --list-keys $email' for each recipient in turn. 
> 
> This is likely true if you have a large keyring and a few recipients,
> but might not be the case if you have a small keyring and many
> recipients :/

You could call 'gpg --list-keys $email1 $email2 ...' . I would be
surprised if there is a case where this is not the fastest method.

Bye
Willi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#772811: unrtf: fixes for stable (CVE-2014-9274 CVE-2014-9275)

[Willi Mann]

Hi,

Just in order to avoid duplicate effort: I have prepared (but not yet
tested) an upload for wheezy-security of unrtf, fixing CVE-2014-9274
CVE-2014-9275. It is available in the alioth git repository:

http://anonscm.debian.org/cgit/collab-maint/unrtf.git/

Bye
Willi



signature.asc
Description: OpenPGP digital signature

Bug#773748: unblock: unrtf/0.21.5-2

[Willi Mann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package unrtf

It fixes two security holes reported in #772811, CVE-2014-9274 and
CVE-2014-9275. Additionally, it fixes an access to already freed memory (these
two patches, 0004 and 0005 have to go together).

debdiff attached.

unblock unrtf/0.21.5-2

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (990, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru unrtf-0.21.5/debian/changelog unrtf-0.21.5/debian/changelog
--- unrtf-0.21.5/debian/changelog	2013-11-30 12:30:28.0 +0100
+++ unrtf-0.21.5/debian/changelog	2014-12-22 20:20:50.0 +0100
@@ -1,3 +1,14 @@
+unrtf (0.21.5-2) unstable; urgency=medium
+
+  * Security fixes, closes: #772811
+- Fix CVE-2014-9274: check that accesses to color table stay within bounds
+- Fix CVE-2014-9275: various crashes
+  * possible security fixes:
+- Fix Invalid read of size 4 in attr_get_param
+- attr_get_param(): Silence a warning message again
+
+ -- Willi Mann   Mon, 22 Dec 2014 20:20:33 +0100
+
 unrtf (0.21.5-1) unstable; urgency=low
 
   * Imported Upstream version 0.21.5
diff -Nru unrtf-0.21.5/debian/patches/0001-check-that-accesses-to-color-table-stay-within-bound.patch unrtf-0.21.5/debian/patches/0001-check-that-accesses-to-color-table-stay-within-bound.patch
--- unrtf-0.21.5/debian/patches/0001-check-that-accesses-to-color-table-stay-within-bound.patch	1970-01-01 01:00:00.0 +0100
+++ unrtf-0.21.5/debian/patches/0001-check-that-accesses-to-color-table-stay-within-bound.patch	2014-12-21 22:04:20.0 +0100
@@ -0,0 +1,55 @@
+From: Jean-Francois Dockes 
+Date: Sun, 21 Dec 2014 10:08:26 +0100
+Subject: check that accesses to color table stay within bounds,
+ esp that the color number is positive. This fixes {\cb-999} crashing
+ unrtf
+
+This fixes CVE-2014-9274, according to http://www.openwall.com/lists/oss-security/2014/12/04/15
+
+Origin: https://bitbucket.org/medoc/unrtf-int/commits/b0cef89a170a66bc48f8dd288ce562ea8ca91f7a/raw/
+Bug-Debian: http://bugs.debian.org/772811
+---
+ src/convert.c | 9 ++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+diff --git a/src/convert.c b/src/convert.c
+index e563473..96bf438 100644
+--- a/src/convert.c
 b/src/convert.c
+@@ -868,6 +868,9 @@ process_color_table (Word *w)
+ 	r=g=b=0;
+ 
+ 	while(w) {
++if (total_colors >= MAX_COLORS) {
++break;
++}
+ 		char *s = word_string (w);
+ 
+ 		if (!strncmp("\\red",s,4)) {
+@@ -921,7 +924,7 @@ static int
+ cmd_cf (Word *w, int align, char has_param, int num) {
+ 	char str[40];
+ 
+-	if (!has_param || num>=total_colors) {
++	if (!has_param || num < 0 || num>=total_colors) {
+ 		warning_handler ("font color change attempted is invalid");
+ 	}
+ 	else
+@@ -948,7 +951,7 @@ static int
+ cmd_cb (Word *w, int align, char has_param, int num) {
+ 	char str[40];
+ 
+-	if (!has_param || num>=total_colors) {
++	if (!has_param || num < 0 || num>=total_colors) {
+ 		warning_handler ("font color change attempted is invalid");
+ 	}
+ 	else
+@@ -1153,7 +1156,7 @@ cmd_highlight (Word *w, int align, char has_param, int num)
+ {
+ 	char str[40];
+ 
+-	if (!has_param || num>=total_colors) {
++	if (!has_param || num < 0 || num>=total_colors) {
+ 		warning_handler ("font background color change attempted is invalid");
+ 	}
+ 	else
diff -Nru unrtf-0.21.5/debian/patches/0002-Need-to-process-word-chars-as-unsigned.-Else-char-wi.patch unrtf-0.21.5/debian/patches/0002-Need-to-process-word-chars-as-unsigned.-Else-char-wi.patch
--- unrtf-0.21.5/debian/patches/0002-Need-to-process-word-chars-as-unsigned.-Else-char-wi.patch	1970-01-01 01:00:00.0 +0100
+++ unrtf-0.21.5/debian/patches/0002-Need-to-process-word-chars-as-unsigned.-Else-char-wi.patch	2014-12-21 22:04:20.0 +0100
@@ -0,0 +1,29 @@
+From: Jean-Francois Dockes 
+Date: Sun, 21 Dec 2014 10:47:03 +0100
+Subject: Need to process word chars as unsigned. Else char with hi bit set
+ can crash program
+
+Partially fixes CVE-2014-9275, according to
+https://lists.gnu.org/archive/html/bug-unrtf/2014-12/msg1.html
+
+Origin: https://bitbucket.org/medoc/unrtf-int/commits/1df886f2e65f7c512a6217588ae8d94d4bcbc63d/raw/
+Bug-Debian: http://bugs.debian.org/772811
+---
+ src/hash.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/hash.c b/src/hash.c
+index b886d1e..67c6a25 100644
+--- a/src/hash.c
 b/src/hash.c
+@@ -133,8 +133,8 @@ hashitem_new (char *str)
+ 
+ 	hi->str = my_strdup(str);
+ 
+-	i = *str;
+-	if (i=='\\') i=str[1];
++	i = (unsigned char)*str;
++

Bug#772811: unrtf: CVE-2014-9274 CVE-2014-9275

[Willi Mann]

Hi Salvatore,

we were working in parallel unfortunately, as I prepared the same
patches in the morning. However, I also added 2 patches by
Fabian Keil. I'll upload tomorrow in the evening, you can have a look  at

http://anonscm.debian.org/cgit/collab-maint/unrtf.git/

comments welcome.

thanks
Willi

Am 2014-12-21 um 15:32 schrieb Salvatore Bonaccorso:
> Control: tags -1 + patch
> 
> Hi Willi
> 
> Attached are two patches separated per CVEs.
> 
> Regards,
> Salvatore
> 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#772811: unrtf: CVE-2014-9274 CVE-2014-9275

[Willi Mann]

Hi Dave,

does 0.21.7 solve both security issues reported? If yes, could point
send me the individual patches that fix these issues? The Debian branch
for the next stable distribution is already frozen, so I cannot fix
these bugs with new upstream versions.

thanks
Willi

Am 2014-12-11 um 12:16 schrieb Moritz Muehlenhoff:
> Package: unrtf
> Severity: grave
> Tags: security
> 
> Please see http://www.openwall.com/lists/oss-security/2014/12/03/4
> for more information and references to patches.
> 
> Cheers,
> Moritz
> 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#771399: unblock: enigmail/2:1.7.2-3

[Willi Mann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package enigmail

This upload finally fixes FTBFS on ppc64el: configure requires an updated
config.sub on ppc64el, but autotools-dev does not provide it in the clean
target. Therefore we replace the call to configure in the clean target by
creating a stub of the file that is required to make dh_auto_clean not fail.

Additionally, we fix the XPCOM ABI name on ppc64el (otherwise, icedove would
show enigmail as disabled on this arch, without any explanation why)

unblock enigmail/2:1.7.2-3

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru enigmail-1.7.2/debian/changelog enigmail-1.7.2/debian/changelog
--- enigmail-1.7.2/debian/changelog	2014-11-02 19:14:42.0 +0100
+++ enigmail-1.7.2/debian/changelog	2014-11-23 15:52:04.0 +0100
@@ -1,3 +1,11 @@
+enigmail (2:1.7.2-3) unstable; urgency=medium
+
+  * d/rules - clean: Fake config/autoconf.mk if it doesn't exist, don't call
+configure. Fixes FTBFS on ppc64el. closes: #760845
+  * Make enigmail use the right XPCOM_TARGET name on ppc64 archs.
+
+ -- Willi Mann   Sun, 23 Nov 2014 15:47:07 +0100
+
 enigmail (2:1.7.2-2) unstable; urgency=medium
 
   * Update config.* files by using autotools-dev. closes: #760845
diff -Nru enigmail-1.7.2/debian/patches/0005-fix-target-os-ppc64.patch enigmail-1.7.2/debian/patches/0005-fix-target-os-ppc64.patch
--- enigmail-1.7.2/debian/patches/0005-fix-target-os-ppc64.patch	1970-01-01 01:00:00.0 +0100
+++ enigmail-1.7.2/debian/patches/0005-fix-target-os-ppc64.patch	2014-11-16 15:44:15.0 +0100
@@ -0,0 +1,14 @@
+Description: Fix XPCOM ABI name on ppc64el and ppc64
+Author: Willi Mann 
+--- enigmail-1.7.2.orig/config/getOsTarget.pl
 enigmail-1.7.2/config/getOsTarget.pl
+@@ -76,6 +76,9 @@ if ($srcCpu =~ /x86[_-]64/i) {
+ elsif ($srcCpu =~ /i[3456]86/i) {
+   $targetCpu = "x86";
+ }
++elsif ($srcCpu =~ /p(?:ower)?pc64/i) {
++  $targetCpu = "ppc64";
++}
+ elsif ($srcCpu =~ /ppc/i) {
+   $targetCpu = "ppc";
+ }
diff -Nru enigmail-1.7.2/debian/patches/series enigmail-1.7.2/debian/patches/series
--- enigmail-1.7.2/debian/patches/series	2014-11-02 18:59:40.0 +0100
+++ enigmail-1.7.2/debian/patches/series	2014-11-16 15:32:44.0 +0100
@@ -1,2 +1,3 @@
 0003-default-to-PGP-MIME.patch
 0004-fix_target-os.patch
+0005-fix-target-os-ppc64.patch
diff -Nru enigmail-1.7.2/debian/rules enigmail-1.7.2/debian/rules
--- enigmail-1.7.2/debian/rules	2014-11-02 18:55:36.0 +0100
+++ enigmail-1.7.2/debian/rules	2014-11-16 15:26:23.0 +0100
@@ -10,7 +10,11 @@
 override_dh_install:
 	install-xpi -penigmail build/*.xpi
 
-# ./configure is needed to create config/autoconf.mk when building from the git sources.
 override_dh_auto_clean:
-	./configure
+	# if config/autoconf.mk is not present, create stub of it, such that make distclean works
+	if [ ! -f config/autoconf.mk ]; then \
+		echo 'DIST = $$(DEPTH)/build/dist' > config/autoconf.mk; \
+		echo 'BUILD = $$(DEPTH)/build' >> config/autoconf.mk; \
+	fi
+
 	dh_auto_clean

Bug#769311: unblock: logwatch/7.4.1-2

[Willi Mann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package logwatch

This upload fixes a regression that was introduced in the latest upstream
release, and that completely disables reporting on fail2ban log messages.
The patch simply reverts the "config" file where the problem was introduced
to its state before the problematic change.

debdiff attached.

unblock logwatch/7.4.1-2

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru logwatch-7.4.1/debian/changelog logwatch-7.4.1/debian/changelog
--- logwatch-7.4.1/debian/changelog	2014-10-08 19:32:36.0 +0200
+++ logwatch-7.4.1/debian/changelog	2014-11-03 20:02:44.0 +0100
@@ -1,3 +1,10 @@
+logwatch (7.4.1-2) unstable; urgency=medium
+
+  * Revert upstream change on fail2ban service config. This makes fail2ban
+reporting work again. Closes: #766901
+
+ -- Willi Mann   Mon, 03 Nov 2014 20:02:30 +0100
+
 logwatch (7.4.1-1) unstable; urgency=medium
 
   * Imported Upstream version 7.4.1 (svn rev 242)
diff -Nru logwatch-7.4.1/debian/patches/0006-Revert-upstream-change-on-fail2ban-service-config.patch logwatch-7.4.1/debian/patches/0006-Revert-upstream-change-on-fail2ban-service-config.patch
--- logwatch-7.4.1/debian/patches/0006-Revert-upstream-change-on-fail2ban-service-config.patch	1970-01-01 01:00:00.0 +0100
+++ logwatch-7.4.1/debian/patches/0006-Revert-upstream-change-on-fail2ban-service-config.patch	2014-11-03 19:55:06.00000 +0100
@@ -0,0 +1,33 @@
+From: Willi Mann 
+Date: Mon, 3 Nov 2014 19:45:20 +0100
+Subject: Revert upstream change on fail2ban service config
+
+Upstream started to use OnlyService and RemoveHeaders in fail2ban conf.
+Unfortunately, this does not work with fail2ban because it uses a different
+"header" format in log entries as compared to syslog.
+---
+ conf/services/fail2ban.conf | 9 ++---
+ 1 file changed, 2 insertions(+), 7 deletions(-)
+
+diff --git a/conf/services/fail2ban.conf b/conf/services/fail2ban.conf
+index 4326a52..b74236f 100644
+--- a/conf/services/fail2ban.conf
 b/conf/services/fail2ban.conf
+@@ -1,5 +1,5 @@
+ ###
+-# $Id: fail2ban.conf 205 2014-09-08 19:15:49Z stefjakobs $
++# $Id: fail2ban.conf 149 2013-06-18 22:18:12Z mtremaine $
+ ###
+ # $Log: fail2ban.conf,v $
+ # Revision 1.1  2006/05/30 19:04:26  bjorn
+@@ -22,9 +22,4 @@ Title = fail2ban-messages
+ # Which logfile group...
+ LogFile = fail2ban
+ 
+-# Only give lines pertaining to the fail2ban service...
+-# Note: fail2ban logs using "service" names fail2ban, fail2ban.jail,
+-# fail2ban.filter, and many more.  We want to exclude fail2ban-client
+-# so we accept either fail2ban or fail2ban\..+
+-*OnlyService = fail2ban(|\..+)
+-*RemoveHeaders
++
diff -Nru logwatch-7.4.1/debian/patches/series logwatch-7.4.1/debian/patches/series
--- logwatch-7.4.1/debian/patches/series	2014-10-06 19:45:49.0 +0200
+++ logwatch-7.4.1/debian/patches/series	2014-11-03 19:55:06.0 +0100
@@ -3,3 +3,4 @@
 0003-Bug-656806-Support-alternative-OoM-kernel-message-in.patch
 0004-logfiles-vsftpd.conf-Use-custom-pattern-for-applystd.patch
 0005-Deb-specific-Print-full-path-to-freshclam-log.patch
+0006-Revert-upstream-change-on-fail2ban-service-config.patch

Bug#769165: unblock: enigmail/2:1.7.2-2

[Willi Mann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package enigmail. It fixes a regression concerning architecture
support: Enigmail 1.7.2-1 does not work at all on 4 architectures (arm{el,hf},
mipsel, powerpc) Additionally, there is a first step to fix FTBFS on
ppc64el included (update of config.sub), and update of Standards-Version. (This
only got included because I started to prepare the upload much earlier, and I
didn't want to back out this change. I hope this is Ok.)

unblock enigmail/2:1.7.2-2

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru enigmail-1.7.2/debian/changelog enigmail-1.7.2/debian/changelog
--- enigmail-1.7.2/debian/changelog	2014-08-31 18:28:12.0 +0200
+++ enigmail-1.7.2/debian/changelog	2014-11-02 19:14:42.0 +0100
@@ -1,3 +1,12 @@
+enigmail (2:1.7.2-2) unstable; urgency=medium
+
+  * Update config.* files by using autotools-dev. closes: #760845
+  * Update Standards-Version 3.9.5 -> 3.9.6
+  * Make enigmail use the right XPCOM_TARGET name on arm{el,hf}, powerpc, and
+mipsel. Closes: #765937 (hopefully)
+
+ -- Willi Mann   Sun, 02 Nov 2014 19:12:49 +0100
+
 enigmail (2:1.7.2-1) unstable; urgency=medium
 
   * Imported Upstream version 1.7.2
diff -Nru enigmail-1.7.2/debian/control enigmail-1.7.2/debian/control
--- enigmail-1.7.2/debian/control	2014-08-31 17:11:00.0 +0200
+++ enigmail-1.7.2/debian/control	2014-11-02 18:55:36.0 +0100
@@ -9,8 +9,9 @@
  mozilla-devscripts,
  zip,
  perl,
- python
-Standards-Version: 3.9.5
+ python,
+ autotools-dev
+Standards-Version: 3.9.6
 Homepage: https://www.enigmail.net/
 Vcs-Git: git://git.debian.org/pkg-mozext/enigmail.git
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-mozext/enigmail.git
diff -Nru enigmail-1.7.2/debian/patches/0004-fix_target-os.patch enigmail-1.7.2/debian/patches/0004-fix_target-os.patch
--- enigmail-1.7.2/debian/patches/0004-fix_target-os.patch	1970-01-01 01:00:00.0 +0100
+++ enigmail-1.7.2/debian/patches/0004-fix_target-os.patch	2014-11-02 19:03:02.0 +0100
@@ -0,0 +1,24 @@
+--- a/config/getOsTarget.pl
 b/config/getOsTarget.pl
+@@ -79,6 +79,9 @@
+ elsif ($srcCpu =~ /ppc/i) {
+   $targetCpu = "ppc";
+ }
++elsif ($srcCpu =~ /powerpc/i) {
++  $targetCpu = "ppc";
++}
+ elsif ($srcCpu =~ /alpha/i) {
+   $targetCpu = "Alpha";
+ }
+@@ -89,7 +92,10 @@
+   $targetCpu = "ia64";
+ }
+ elsif ($srcCpu =~ /arm/i) {
+-  $targetCpu = "arm";
++  $targetCpu = "arm-eabi";
++}
++elsif ($srcCpu =~ /mips/i) {
++  $targetCpu = "mips";
+ }
+ else {
+   $targetCpu = $srcCpu;
diff -Nru enigmail-1.7.2/debian/patches/series enigmail-1.7.2/debian/patches/series
--- enigmail-1.7.2/debian/patches/series	2014-08-31 17:46:14.0 +0200
+++ enigmail-1.7.2/debian/patches/series	2014-11-02 18:59:40.0 +0100
@@ -1 +1,2 @@
 0003-default-to-PGP-MIME.patch
+0004-fix_target-os.patch
diff -Nru enigmail-1.7.2/debian/rules enigmail-1.7.2/debian/rules
--- enigmail-1.7.2/debian/rules	2014-08-31 17:11:00.0 +0200
+++ enigmail-1.7.2/debian/rules	2014-11-02 18:55:36.0 +0100
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 XPI_MODULE_VERS = $(shell dpkg-parsechangelog  | grep ^Version: | cut -f2 -d\ )
 %:
-	dh $@ --with xul-ext
+	dh $@ --with xul-ext --with autotools-dev
 
 override_dh_auto_build:
 	dh_auto_build

Bug#749886: Processed: bug 749886 is forwarded to https://sourceforge.net/p/enigmail/bugs/361

[Willi Mann]

Control: tag -1 + fixed-upstream

Hi Gabriele,

please close the upstream bug report, the patch has already been included.

http://sourceforge.net/p/enigmail/source/ci/7132d0b43068ff8dbeb386dcec879090cc934c33/

thanks
Willi


Am 2014-11-04 um 02:09 schrieb Debian Bug Tracking System:
> Processing commands for cont...@bugs.debian.org:
> 
>> forwarded 749886 https://sourceforge.net/p/enigmail/bugs/361
> Bug #749886 [enigmail] enigmail: FTBFS on hurd-i386
> Set Bug forwarded-to-address to 'https://sourceforge.net/p/enigmail/bugs/361'.
>> thanks
> Stopping processing here.
> 
> Please contact me if you need assistance.
> 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#765937: [enigmail] Incompatible with armhf

[Willi Mann]

Hi,

> last known-working versions on armel are for me
> 
> Icedove 24.5.0-2
> Enigmail  1.6-4

could you test enigmail 1.7.2-2? It is currently available from

http://incoming.debian.org/debian-buildd/pool/main/e/enigmail/

Tomorrow, it will be available from unstable. I don't know whether it
fixes the problem - I could not test it before the upload.

thanks
Willi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#760845: reopen - needs more care

[Willi Mann]

Control: found -1 2:1.7.2-2

Bug is still there, missed the actual problem.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#765937: [enigmail] Incompatible with armhf

[Willi Mann]

Hi,

Am 2014-10-19 um 13:44 schrieb Thomas Maass:
> Package: enigmail
> Version: 2:1.7.2-1

> Depends (Version) | Installed
> ===-+-
> libc6 (>= 2.4) | 2.19-11
> icedove (>= 24.0) | 31.0-3

do you know whether this is a new problem? Did it work with icedove 24?
Did previous versions of enigmail work on armel/armhf?

thanks
WM


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#752391: enigmail: icedove crashes with SIGSEGV when sending emails unencrypted while for one recpient a key is present

[Willi Mann]

Thank you anyway for this bug report. It helps to decide how to handle
enigmail for the upcoming icedove major upgrade in stable.

WM

Am 2014-10-21 um 19:19 schrieb Michael Strobel:
> The bug can be closed since it doesn't occur in version 1.7 of enigmail.
> 
> Cheers
> Michael
> 
> On 06/23/2014 11:53 AM, Michael Strobel wrote:
>> Package: enigmail
>> Version: 2:1.6+git0.20140323-2
>> Severity: important
>>
>> Dear Maintainer,
>>
>> after upgrading to icedove 31 it crashed when sending an email to a person 
>> who
>> has a gpg key and one who has not. The dialog about key management pops up 
>> and
>> after some time icedove crashed. I tried disabling all extensions and ran
>> icedove only with enigmail. I'll add a gdb trackeback.
>>
>> Best
>> Michael
>>
>>
>> -- System Information:
>> Debian Release: jessie/sid
>>   APT prefers unstable
>>   APT policy: (500, 'unstable')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>>
>> Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>>
>> Versions of packages enigmail depends on:
>> ii  gnupg1.4.16-1.1
>> ii  icedove  31.0~b1-2
>> ii  libc62.19-3
>>
>> Versions of packages enigmail recommends:
>> ii  gnupg-agent  2.0.23-1
>>
>> enigmail suggests no packages.
>>
>> -- no debconf information
>>
>> *** /home/michael/icedove.log
>> michael@debian ~ $ /usr/lib/icedove/run-mozilla.sh -g 
>> /usr/lib/icedove/icedove-
>> bin
>> MOZILLA_FIVE_HOME=/usr/lib/icedove
>>   LD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove/plugins:/usr/lib/icedove
>> DISPLAY=:0
>> DYLD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove
>>  LIBRARY_PATH=
>>SHLIB_PATH=/usr/lib/icedove:/usr/lib/icedove
>>   LIBPATH=/usr/lib/icedove:/usr/lib/icedove
>>ADDON_PATH=
>>   MOZ_PROGRAM=/usr/lib/icedove/icedove-bin
>>   MOZ_TOOLKIT=
>> moz_debug=1
>>  moz_debugger=
>> moz_debugger_args=
>> /usr/bin/gdb  --args /usr/lib/icedove/icedove-bin
>> GNU gdb (Debian 7.7.1-2) 7.7.1
>> Copyright (C) 2014 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later 
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-linux-gnu".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> .
>> Find the GDB manual and other documentation resources online at:
>> .
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from /usr/lib/icedove/icedove-bin...Reading symbols from
>> /usr/lib/debug//usr/lib/icedove/icedove-bin...done.
>> done.
>> (gdb) run
>> Starting program: /usr/lib/icedove/icedove-bin
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>
>> (process:9929): GLib-CRITICAL **: g_slice_set_config: assertion 
>> 'sys_page_size
>> == 0' failed
>>
>> (icedove:9929): GLib-GObject-WARNING **: Attempt to add property GnomeProgram
>> ::sm-connect after class was initialised
>>
>> (icedove:9929): GLib-GObject-WARNING **: Attempt to add property GnomeProgram
>> ::show-crash-dialog after class was initialised
>>
>> (icedove:9929): GLib-GObject-WARNING **: Attempt to add property
>> GnomeProgram::display after class was initialised
>>
>> (icedove:9929): GLib-GObject-WARNING **: Attempt to add property GnomeProgram
>> ::default-icon after class was initialised
>> warning: Corrupted shared library list: 0x7fffe5a21000 != 0x7fffe5a15000
>> [New Thread 0x7fffe2d8c700 (LWP 9935)]
>> [New Thread 0x7fffe16ff700 (LWP 9936)]
>> [New Thread 0x7fffe07f2700 (LWP 9937)]
>> [New Thread 0x7fffdfff1700 (LWP 9938)]
>> [New Thread 0x7fffdf133700 (LWP 9939)]
>> [New Thread 0x7fffddf32700 (LWP 9942)]
>> [New Thread 0x7fffdd731700 (LWP 9943)]
>> [New Thread 0x76da6700 (LWP 9944)]
>> [New Thread 0x7fffdccff700 (LWP 9945)]
>> [New Thread 0x7fffdbbff700 (LWP 9946)]
>> [calBackendLoader] Using libical backend at
>> /usr/lib/icedove/extensions/{e2fda1a4-762b-4020-b5ad-
>> a41df1933103}/components/libical.manifest
>> enigmail.js: Registered components
>> [New Thread 0x7fffb49ff700 (LWP 9947)]
>> [New Thread 0x7fffb43ff700 (LWP 9948)]
>> [New Thread 0x7fffb3bfe700 (LWP 9949)]
>> [New Thread 0x7fffb33fd700 (LWP 9950)]
>> [New Thread 0x7fffb22ff700 (LWP 9951)]
>> [New Thread 0x7fffe0e9e700 (LWP 9952)]
>> [New Thread 0x7fffdf7f0700 (LWP 9953)]
>> [New Thread 0x7fffdc4fe700 (LWP 9954)]
>> [New Thread 0x7fffdb3fe700 (LWP 9955)]
>> [Thread 0x7fffdbbff700 (LWP 9946) exited]
>> [Thread 0x7fffb33fd700 (LWP 9950) exited]
>> [New Thread 0x7fffb13ff700 (LWP 9956)]
>> [New Thread 0x7fffdbbff700 (LWP 9957)]
>> [New 

Bug#764515: ITP: libsys-meminfo-perl -- Perl module to query the total free and used physical memory

[Willi Mann]

Package: wnpp
Severity: wishlist
Owner: Willi Mann 

* Package name: libsys-meminfo-perl
  Version : 0.98
  Upstream Author : Sylvain Cresto >
* URL : http://search.cpan.org/~scresto/Sys-MemInfo/MemInfo.pm
* License : "same as Perl"
  Programming Lang: Perl, C
  Description : Perl module to query the total free and used physical memory

Sys::MemInfo provides a platform-independent way to query the total amount of
free and used physical memory, and the free and used swap space. Virtually all
current operating systems are supported.


This package is a dependency of a logwatch script (zz-sys). I'll talk to the
Debian Perl Group before really starting to package it.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#761399: Adding suggestion to libsys-cpu-perl

[Willi Mann]

Control: retitle -1 zz-sys depends on Sys::MemInfo which is not packaged

Bug just got partially fixed, therefore I'm retitleing it.


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 08 Oct 2014 19:32:13 +0200
Source: logwatch
Binary: logwatch
Architecture: source all
Version: 7.4.1-1
Distribution: unstable
Urgency: medium
Maintainer: Willi Mann 
Changed-By: Willi Mann 
Description:
 logwatch   - log analyser with nice output written in Perl
Closes: 710146
Changes:
 logwatch (7.4.1-1) unstable; urgency=medium
 .
   * Imported Upstream version 7.4.1 (svn rev 242)
 - patches merged upstream:
   + Change-spamassassin-to-use-maillog-config.patch
   + s-sshd-ignore-PAM-service-sshd-ignoring-max-retries-.patch
   + s-s-exim-Fix-wrong-regex.patch
   + s-s-sshd-Support-fatal-Write-failed-Connection-reset.patch
   + s-s-dovecot-Recognize-and-report-Server-shutting-dow.patch
   + s-s-pam_unix-Fix-two-unknown-entries.patch
 - bugs fixed upstream:
   + Unmatched entries for AppArmor, closes: 710146
   * Add Recommends on libsys-cpu-perl, needed by zz-sys script (which is
 disabled by default). Spotted in #761399. Since zz-sys would also need
 perl module Sys::MemInfo, we do not close this bug.)
Checksums-Sha1:
 e815f3ada56d5e19919ee9732534ba4acb14c5b8 1822 logwatch_7.4.1-1.dsc
 e671e26c3a972a9603f3ddf44b7290ae0eee4c5e 464970 logwatch_7.4.1.orig.tar.gz
 ecdcf8a1f42b1239f6ff23fe0352a2ebb484a9fa 16404
logwatch_7.4.1-1.debian.tar.xz
 882383a79cee631677884d85beea05dec3976457 365208 logwatch_7.4.1-1_all.deb
Checksums-Sha256:
 7dfceee6a3f4eea748d54aa8b45c69e0076716626c945efcb8441ffac8245f3a 1822
logwatch_7.4.1-1.dsc
 35ec31f9fe981aaa727b144ab3ff2eb655997d8ccabaf66586458f5dfc3a56eb 464970
logwatch_7.4.1.orig.tar.gz
 0b9a1026ddc8307db979b9192b30cea210446e2300c5183ed67112a9cb7e677c 16404
logwatch_7.4.1-1.debian.tar.xz
 aaf464847f35b0d135a809075f05b8a8855ec134d5070a92b0f9f148ffb7fa86 365208
logwatch_7.4.1-1_all.deb
Files:
 48ff5d95027075861858d2e5b087a83f 365208 admin optional
logwatch_7.4.1-1_all.deb
 cd29055ad63468fffee9823a6435a9ef 1822 admin optional logwatch_7.4.1-1.dsc
 a0c3d8721f877bdcd4a9089eb1b4691b 464970 admin optional
logwatch_7.4.1.orig.tar.gz
 dbfdd569f6ecf36180aa9ec265a697e5 16404 admin optional
logwatch_7.4.1-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJUNXVqAAoJEIy+IZx0V22Bv50P/As1y30xmBT1C8BgV0hksEx7
jtOGH77UrRfEzURrBbdwTI119qSgtgsnFo68l/oWyAGXURGe1vOlr7fsEaoxmsB6
M7NU8q/HTTWNGjF80PQhIpHjIrxAypULnY6qwAO6sOuct//L2alKlGQ55ve5JBPb
6gVsf8NnzVTN8GWYWyPTwXUIb6mj6+KCas8sHJWQGIGIJB3lRM4uslBvSrwnpb4S
G8/PJEqi8Vf17QIUKxiGnAILGmp+i5K/aadhifWPm46wwbcUMWAa1jfrvmvu1JDX
pTzO+1HdBfhiGcDKvBNyxLpzlMC3Q9SwdF2PNvj7QxYiAnLRiaRiiSVEBkPUz398
zU9BRq6YIlNlXRHX0THiNzlky79cS/01He94Gund4V1PR0aFADBXcaEE/0cEnP83
wawaK9fPQhN8JJ5L8bUO/+CRAnZpdy3RfLdeIVguflvVIfOz5ow3B7Swo3uPSMwm
G8IaRH/APhnt9k91rSANoPRDHpT5VI+rw48CJtKRwn6Zd9gh4nDYE8G84n41YFKB
TbnZ6HXPEyJIw0UT4cAi/JdmiJHGOSk0NKcePKgMHkvNp30Jg2nx91sc48V6dE9F
TG72IHfekDrofl5HlwbEnkYeQaF0cgUdtiI8s3lq4s96DGCaXNCtchZZQEd6AJ7I
FK53ZBidCblcCCBv4EZ2
=5nLc
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#710146: Unmatched entries for apparmo

[Willi Mann]

Control: tag -1 + upstream

Am 2014-09-13 um 16:32 schrieb Chris:
> Hi,
> 
> just for the records. The attached patch was included in upstream rev223
> 
> https://sourceforge.net/p/logwatch/patches/31/
> 
> With the next sync of this package against upstream this bug can be closed.

thank you for pointing this out.

WM


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#756186: logwatch: Uninitialized variable ($bb) in logwatch exim script.

[Willi Mann]

Am 2014-08-07 11:28, schrieb Jeremiah C. Foster:
> On Thu, Aug 07, 2014 at 06:52:48AM +0200, Willi Mann wrote:
>> Sorry I didn't see this earlier, but I think the fix is to change line
>> 478 in /usr/share/logwatch/scripts/services/exim from
>>
>> ( $bb ) = ($ThisOne =~ m/\@\[^>]+/);
>> to
>> ( $bb ) = ($ThisOne =~ m/\@[^>]+/);
>>
>> Could you try whether this fixes the problem?
> 
> Yes, this fixes the problem! 
> 
> Thanks,
> 
> Jeremiah

thank you for your cooperation, the fix will be included in my next upload.
Willi


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#756186: logwatch: Uninitialized variable ($bb) in logwatch exim script.

[Willi Mann]

Am 2014-08-02 22:21, schrieb Jeremiah C. Foster:

Hi Jeremiah,

>>> Logwatch is mailing reports which contain the line; 
>>>
>>> Use of uninitialized value $bb in concatenation (.) or string at 
>>> /usr/share/logwatch/scripts/services/exim line 490,  line 3480.
>>>
>>> This looks to be an error in initializing the $bb variable. Further 
>>> investigation is likely necessary.
>>
>> What I would need are the log lines that caused this meesage to occur. 
> 
> It looks as if it is coming from ;
> 
> "Use of uninitialized value $bb in concatenation (.) or string at 
> /usr/share/logwatch/scripts/services/exim line 489,  line 4611."

The core logwatch script sends the logfiles preprocessed to the service
reporters on STDIN. Unfortunately, the error occurs in the phase where
the logfile already has been parsed completly, so the line number
reported is just the number of lines the script received.

>> I
>> would guess that it is either yet another format of IPv6 addresses that
>> the IP-Address regex does not cover or a line that matches
>>
>> /remote host address is the local host/
>>
>> but not
>>
>> /\@\[^>]+/
>>
>> (lines 476-478)

> I have a suspicion you're right. :-)
> 
> To follow up completely, should I send you a copy of the exim log? 

That would be the easiest option, except for the possible privacy
problems this might cause. In order to minimize the impact, you could
encrypt it, though (you can verify the authenticity of my key via the
debian-keyring package).

Another option would be to just send me the lines matching the /remote
host address is the local host/ regex, because they are probably enough
to reproduce the problem.

thanks
Willi



signature.asc
Description: OpenPGP digital signature

Bug#756186: logwatch: Uninitialized variable ($bb) in logwatch exim script.

[Willi Mann]

Hi,

> Dear Maintainer,
> 
> Logwatch is mailing reports which contain the line; 
> 
> Use of uninitialized value $bb in concatenation (.) or string at 
> /usr/share/logwatch/scripts/services/exim line 490,  line 3480.
> 
> This looks to be an error in initializing the $bb variable. Further 
> investigation is likely necessary.

What I would need are the log lines that caused this meesage to occur. I
would guess that it is either yet another format of IPv6 addresses that
the IP-Address regex does not cover or a line that matches

/remote host address is the local host/

but not

/\@\[^>]+/

(lines 476-478)

thanks
WM


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#590150: logwatch: Logwatch doesn't detect freshclam.log

[Willi Mann]

Hi,

can you please tell me whether this problem is still reproducible? I
could not reproduce it with the logwatch version version in wheezy.

thanks
WM

Am 2010-07-24 11:24, schrieb Aniruddha:
> Package: logwatch
> Version: 7.3.6.cvs20080702-2
> Severity: normal
> 
> 
> Logwatch gives the following message in the reports. I tried adding 'LogFile 
> = /var/log/clamav/freshclam.log' to 
> '/usr/share/logwatch/dist.conf/logfiles/clam-update.conf' 
> and '/etc/logwatch/conf/logfiles/clam-update.conf'
> 
> I think that the problem is that logwatch searches in the wrong directory:
> 
> grep  /var/log/clam-update 
> /usr/share/logwatch/default.conf/logfiles/clam-update.conf 
> # /var/log/clam-update
>  
> 
> 
> - clam-update Begin  
> 
>  
>  No updates detected in the log for the freshclam daemon (the
>  ClamAV update process).  If the freshclam daemon is not running,
>  you may need to restart it.  Other options:
>  
>  A. If you no longer wish to run freshclam, deleting the log file
> (default is freshclam.log) will suppress this error message.
>  
>  B. If you use a different log file, update the appropriate
> configuration file.  For example:
>echo "LogFile = log_file" >> 
> /etc/logwatch/conf/logfiles/clam-update.conf
> where log_file is the filename of the freshclam log file.
>  
>  C. If you are logging using syslog, you need to indicate that your
> log file uses the syslog format.  For example:
>echo "*OnlyService = freshclam" >> 
> /etc/logwatch/conf/logfiles/clam-update.conf
>echo "*RemoveHeaders" >> /etc/logwatch/conf/logfiles/clam-update.conf
> 
> 
> 
> 
> -- System Information:
> Debian Release: 5.0.5
>   APT prefers stable
>   APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 2.6.30-bpo.1-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/bash
> 
> Versions of packages logwatch depends on:
> ii  perl 5.10.0-19lenny2 Larry Wall's Practical 
> Extraction 
> ii  postfix [mail-transport- 2.5.5-1.1   High-performance mail transport 
> ag
> 
> Versions of packages logwatch recommends:
> ii  libdate-manip-perl5.54-1 a perl library for manipulating 
> da
> 
> Versions of packages logwatch suggests:
> pn  fortune-mod(no description available)
> 
> -- no debconf information
> 
> 
> 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#611205: logwatch: hostlimit doesn't work

[Willi Mann]

Hi,

Am 2011-01-26 18:48, schrieb Tony Lill:
> setting hostlimit=yes has no effect, for two reasons
> 
> 1) The documentations and comments in the config file says to set
> hostlimit = yes, but in actuality, you have to set it to the
> hostname
> 
> 2) Even if you do this, a bug in the code that handles the
> nohostlimit override allways nulls out the LOGWATCH_HOST_LIMIT
> environment variable.

the manpage was fixed, and the code also changed. Could you please tell
me whether this bug is fixed for you (at least in the version of
logwatch available from unstable)?

thanks
WM


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#552309: reports unmatched entries for clamav-milter

[Willi Mann]

Hi,

this bug seems to got fixed in upstream SVN revision 53, which would be
some upload between squeeze and wheezy. Can you confirm that this bug is
no longer reproducible?

thanks
WM

Am 2009-10-25 13:15, schrieb Bartosz Fenski aka fEnIo:
> Package: logwatch
> Version: 7.3.6.cvs20090906-1
> Severity: normal
> 
> Hello.
> 
> I've just installed clamav-milter to scan my emails through clamav.
> Logwatch reports many unmatched entries, but as far as I can see it should
> count mails infected and print it in reports.
> 
> Here is an example line from /var/log/clamav/clamav-milter.log:
> 
> Fri Oct 23 08:19:02 2009 -> Message from  to 
>  infected by Email.Trojan-123
> 
> Would be great to match these lines and make some useful raport basing on
> that.
> 
> regards
> fEnIo
> 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#755834: Fails to install if interface list is empty

[Willi Mann]

Package: isc-dhcp-server
Version: 4.3.0+dfsg-1
Severity: serious

Hi,

with systemd installed, isc-dhcp-server fails to install because starting the
daemon fails. This must have worked (in the sense that the postinst script 
succeeded) with sysvinit as I have the same (non-)setup of isc-dhcp-server
since ages. It's only installed because it is a dependency of fai-quickstart.
So the bug might need to be reassigned to systemd.


Setting up isc-dhcp-server (4.3.0+dfsg-1) ...
Job for isc-dhcp-server.service failed. See 'systemctl status 
isc-dhcp-server.service' and 'journalctl -xn' for details.
invoke-rc.d: initscript isc-dhcp-server, action "start" failed.
dpkg: error processing package isc-dhcp-server (--configure):


# cat /etc/default/isc-dhcp-server
# Defaults for dhcp initscript
# sourced by /etc/init.d/dhcp
# installed at /etc/default/isc-dhcp-server by the maintainer scripts

#
# This is a POSIX shell fragment
#

# On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
#   Separate multiple interfaces with spaces, e.g. "eth0 eth1".
INTERFACES=""
---snip---


The config file /etc/dhcpd/dhcpd.conf is identical to what's shipped in the
package (apart from commented lines)


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages isc-dhcp-server depends on:
ii  debconf [debconf-2.0]  1.5.53
ii  debianutils4.4
ii  isc-dhcp-common4.3.0+dfsg-1
ii  libc6  2.19-7
ii  lsb-base   4.1+Debian13

isc-dhcp-server recommends no packages.

Versions of packages isc-dhcp-server suggests:
pn  isc-dhcp-server-ldap  

-- Configuration Files:
/etc/dhcp/dhcpd.conf changed:
ddns-update-style none;
option domain-name "example.org";
option domain-name-servers ns1.example.org, ns2.example.org;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;


-- debconf information:
  isc-dhcp-server/interfaces:
  isc-dhcp-server/config_warn:


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#754538: sqwebmail fails to install due to non-existant /var/www directory

[Willi Mann]

>> Should be easy to fix - I guess (but am not sure) the most proper way to fix
>> this is to ship /var/www as part of the sqwebmail package. If you create it
>> in the maintainer script, it is problematic to decide whether to delete it
>> on package removal.
>>
> 
> It is quite likely that nowadays a different directory is used for installing 
> web
> applications, can you please check policy / file system standard?

Policy:

https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-web-appl

I would read that as to for now still use /var/www. (There are
discussions to use a subdirectory of /var/www as the real root, and some
people propose completely different locations, see e.g.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730382

)

Bye
WM


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#754538: sqwebmail fails to install due to non-existant /var/www directory

[Willi Mann]

Package: sqwebmail
Version: 0.73.1-1.2
Severity: serious
Justification: fails to install

Hi Racke,

sqwebmail fails to install if the directory /var/www does not exist (which 
apparently does not exist if nginx is installed as httpd-cgi):

Entpacken von sqwebmail (0.73.1-1.2) ...
Trigger für man-db (2.6.7.1-1) werden verarbeitet ...
sqwebmail (0.73.1-1.2) wird eingerichtet ...
ln: die symbolische Verknüpfung „/var/www/sqwebmail“ konnte nicht angelegt 
werden: Datei oder Verzeichnis nicht gefunden
dpkg: Fehler beim Bearbeiten des Paketes sqwebmail (--configure):
 Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
 sqwebmail

Should be easy to fix - I guess (but am not sure) the most proper way to fix
this is to ship /var/www as part of the sqwebmail package. If you create it
in the maintainer script, it is problematic to decide whether to delete it
on package removal.

Bye
Willi


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages sqwebmail depends on:
ii  courier-authlib 0.66.1-1
ii  courier-base0.73.1-1.2
ii  courier-maildrop0.73.1-1.2
ii  cron3.0pl1-124.1
ii  debconf [debconf-2.0]   1.5.53
ii  expect  5.45-5
ii  ingerman [ispell-dictionary]20131206-5
ii  ispell  3.3.02-6
ii  libc6   2.19-4
ii  libfam0 2.7.0-17.1
ii  libgdbm31.8.3-12+b1
ii  libldap-2.4-2   2.4.39-1
ii  libpcre31:8.31-5
ii  nginx-full [httpd-cgi]  1.6.0-1
ii  postfix [mail-transport-agent]  2.11.1-1

sqwebmail recommends no packages.

Versions of packages sqwebmail suggests:
pn  courier-doc  
pn  courier-pcp  
ii  gnupg1.4.16-1.2

-- debconf information:
  sqwebmail/install-www-backup: symlink
  sqwebmail/install-www: symlink
  sqwebmail/calendarmode: local
  sqwebmail/dictionary: default


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#754211: logwatch reports false positive kernel errors

[Willi Mann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Control: tag -1 + fixed-upstream

Hi,

thank you for your report. The ERST message is fixed in upstream svn
revision 117 (so you can get it via logwatch from testing), the mount
option problem is fixed in svn revision 183, which is not yet uploaded.

Bye
WM
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTvESFAAoJEIy+IZx0V22BkPAP/3EcXZ9/LZQcq/Z4cf7l86CM
IbDanvKl2qSokhWc8PQ3QlHboKbmcoPwhN4pgnorrea3oTIF8/ynQ9Aaixk36Tgf
i5lFsBYF1qR80Lw7ZqH/iZlhS93qD1NnA+41ao3rHP+n1m8pmLzLBMG4i6MqKQ/A
jK5Rd5N9aNYYNODy2vFSc88Tol+3Sj7rz2WUl997ac5F+NiS2Nh4d9F+APTbBMB8
B8nUVMdObZ3i0BWbTZ01cc5/17tAQKOa/tZVcUbyKs+I/lOC9+/4qttzMYqZCwdd
cD/yRvMIoNHPANREICGItlfh8s8KcTNT97qACXHdNqPa/Aw/hW5Ns+kwn87gU5TS
D7lHX7AnHKd6sLJWilkAZiXyV3p50avvmy9RKhFie+7wn6HX3KemeeSve/N1QwZT
JObM3s+iZXsRmG2kFPixx30kCZgJcFQ5BB/3ILnVc9agjaQbuK3P/VLX3HKyncJK
4EvvdXeVCW+Eyp3ybK5GyIYkDV4O/Rh/uFklaTOz8KNP2QVPmyKJvjloKz9TVAsQ
zszvE4Pz6kgghvFH2UUcDCAVveC9bsSRV7RsWoHSwPt0l4FdS7gIFoLZ7RwRPEqA
KTLBEMAXLtFUjSoAxsfWOv1TYH/hHdIr98Wwn4NFMe0Rv3TGzR7Hf6t4PNKZvP0Y
IHVKDKWkIa9S0bciAJzX
=4LHT
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#745195: Fwd: Bug#745195: unrtf 0.21 outputs hex.junk to stdout

[Willi Mann]

Hi Dave,

I got attached bug report. It seems there is a bigger problem with the
handling of images, since the test case, pict.rtf, also does not produce
any image in the working directory. At least, the test case does not get
unrtf to produce output garbage as demonstrated in this bug report.

Additionally, there is a memory handling problem:

% valgrind unrtf FUNDS\ RELEASE\ FORM..rtf > /tmp/output
==19089== Memcheck, a memory error detector
==19089== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==19089== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==19089== Command: unrtf FUNDS\ RELEASE\ FORM..rtf
==19089==
==19089== Invalid read of size 4
==19089==at 0x401C2C: ??? (in /usr/bin/unrtf)
==19089==by 0x40750D: ??? (in /usr/bin/unrtf)
==19089==by 0x408041: ??? (in /usr/bin/unrtf)
==19089==by 0x4017CD: ??? (in /usr/bin/unrtf)
==19089==by 0x4E54B44: (below main) (libc-start.c:287)
==19089==  Address 0x5bef5a0 is 90,000 bytes inside a block of size
90,016 free'd
==19089==at 0x4C29730: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19089==by 0x4074D1: ??? (in /usr/bin/unrtf)
==19089==by 0x408041: ??? (in /usr/bin/unrtf)
==19089==by 0x4017CD: ??? (in /usr/bin/unrtf)
==19089==by 0x4E54B44: (below main) (libc-start.c:287)
==19089==
==19089==
==19089== HEAP SUMMARY:
==19089== in use at exit: 2,488,733 bytes in 3,274 blocks
==19089==   total heap usage: 19,992 allocs, 16,718 frees, 29,549,989
bytes allocated
==19089==
==19089== LEAK SUMMARY:
==19089==definitely lost: 5,972 bytes in 596 blocks
==19089==indirectly lost: 0 bytes in 0 blocks
==19089==  possibly lost: 0 bytes in 0 blocks
==19089==still reachable: 2,482,761 bytes in 2,678 blocks
==19089== suppressed: 0 bytes in 0 blocks
==19089== Rerun with --leak-check=full to see details of leaked memory
==19089==
==19089== For counts of detected and suppressed errors, rerun with: -v


thanks
Willi

PS: Did you get my previously forwarded bug reports? I haven't received
an answer.


 Original-Nachricht 
Betreff: Bug#745195: unrtf 0.21 outputs hex.junk to stdout
Weitersenden-Datum: Fri, 18 Apr 2014 19:00:02 +
Weitersenden-Von: Matus UHLAR - fantomas 
Weitersenden-An: debian-bugs-dist@lists.debian.org
Weitersenden-CC: Willi Mann 
Datum: Fri, 18 Apr 2014 20:48:51 +0200
Von: Matus UHLAR - fantomas 
Antwort an: Matus UHLAR - fantomas ,
745...@bugs.debian.org
An: sub...@bugs.debian.org

Package: unrtf
Version: 0.21.5-1

when converting RTF file with images attached to text, unrtf 0.21.5 outputs
huge amount of text (looks like image data in hex) to output, where unrtf
0.19.2 present in wheezy shows at the same place something like:

### picture data found, WMF type is MM_ANISOTROPIC, picture dimensions
are 7842 by 2125, depth 1


you can see the example RTF file and output from both unrtf versions on:
http://test.fantomas.sk/unrtf/

-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
- Have you got anything without Spam in it?
- Well, there's Spam egg sausage and Spam, that's not got much Spam in it.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749129: possible fix

[Willi Mann]

Control: tag -1 + patch

Attached is a possible fix for this bug. I would like to get
maintainer's feedback before uploading it because it is quite intrusive
for an NMU.

The patch changes upstream's mkesmtpdcert, which is used by the
currently failing maintainer script, to allow specification of the
filename for the certificate.

The maintainer script is changed to create the certificate in a
temporary directory, to avoid idempotency problems (interrupt when
mkesmptdcert is run).

WM
diff --git a/courier/module.esmtp/mkesmtpdcert.in b/courier/module.esmtp/mkesmtpdcert.in
index 03b055e..f61d8cf 100644
--- a/courier/module.esmtp/mkesmtpdcert.in
+++ b/courier/module.esmtp/mkesmtpdcert.in
@@ -8,6 +8,12 @@
 # ESMTP STARTTLS.  Normally this script would get called by an automatic
 # package installation routine.
 
+PEMFILE="$1"
+
+if [ -z "$PEMFILE" ]; then
+	PEMFILE=@mydatadir@/esmtpd.pem
+fi
+
 if test "@ssllib@" = "openssl"
 then
 	test -x @OPENSSL@ || exit 0
@@ -15,17 +21,17 @@ else
 	test -x @CERTTOOL@ || exit 0
 fi
 
-if test -f @mydatadir@/esmtpd.pem
+if test -f "$PEMFILE"
 then
-	echo "@mydatadir@/esmtpd.pem already exists."
+	echo "$PEMFILE already exists."
 	exit 1
 fi
 
 cleanup() {
-	rm -f @mydatadir@/esmtpd.rand
-	rm -f @mydatadir@/esmtpd.pem
-	rm -f @mydatadir@/esmtpd.key
-	rm -f @mydatadir@/esmtpd.cert
+	rm -f "$PEMFILE".rand
+	rm -f "$PEMFILE"
+	rm -f "$PEMFILE".key
+	rm -f "$PEMFILE".cert
 	exit 1
 }
 
@@ -36,16 +42,19 @@ set -e
 
 if test "@ssllib@" = "openssl"
 then
-	cp /dev/null @mydatadir@/esmtpd.pem
-	chmod 600 @mydatadir@/esmtpd.pem
-	chown @mailuser@ @mydatadir@/esmtpd.pem
-	dd if=@RANDOMV@ of=@mydatadir@/esmtpd.rand count=1 2>/dev/null
+	cp /dev/null "$PEMFILE"
+	chmod 600 "$PEMFILE"
+	chown @mailuser@ "$PEMFILE"
+	dd if=@RANDOMV@ of="$PEMFILE".rand count=1 2>/dev/null
 	@OPENSSL@ req -new -x509 -days 365 -nodes \
-		  -config @sysconfdir@/esmtpd.cnf -out @mydatadir@/esmtpd.pem -keyout @mydatadir@/esmtpd.pem || cleanup
-	@OPENSSL@ gendh -rand @mydatadir@/esmtpd.rand 512 >>@mydatadir@/esmtpd.pem || cleanup
-	@OPENSSL@ x509 -subject -dates -fingerprint -noout -in @mydatadir@/esmtpd.pem || cleanup
-	rm -f @mydatadir@/esmtpd.rand
+		  -config @sysconfdir@/esmtpd.cnf -out "$PEMFILE" -keyout "$PEMFILE" || cleanup
+	@OPENSSL@ gendh -rand "$PEMFILE".rand 512 >>"$PEMFILE" || cleanup
+	@OPENSSL@ x509 -subject -dates -fingerprint -noout -in "$PEMFILE" || cleanup
+	rm -f "$PEMFILE".rand
 else
+	echo "@CERTTOOL@ is not supported in debian"
+	exit 1
+
 	if test "$BITS" = ""
 	then
 		BITS="high"
diff --git a/debian/changelog b/debian/changelog
index 25d4cce..b78158e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+courier (0.73.1-1.2) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Change mkesmptdcert to make cert-filename controllable by parameter.
+  * Create esmptd.pem in temporary path and then move it to /etc/courier.
+This way, mkesmptdcert no longer has to work on an dangling symlink as
+destination. (closes: #749129)
+
+ -- Willi Mann   Mon, 26 May 2014 18:23:21 +0200
+
 courier (0.73.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload in coordination with maintainer.
diff --git a/debian/correctpermissions.pl b/debian/correctpermissions.pl
old mode 100644
new mode 100755
diff --git a/debian/courier-mta-ssl.postinst b/debian/courier-mta-ssl.postinst
index 89c967e..ae3cce9 100644
--- a/debian/courier-mta-ssl.postinst
+++ b/debian/courier-mta-ssl.postinst
@@ -27,8 +27,19 @@ if [ "$1" = "configure" ]; then
 		ln -s /etc/courier/emtspd.pem /usr/lib/courier/emtspd.pem
 	fi
 	if [ ! -f /etc/courier/esmtpd.pem ]; then
-		mkesmtpdcert
-		chown daemon /etc/courier/esmtpd.pem
+
+		# create pem file in temporary directory, for full idempotency
+		TMPDIR=$(mktemp -d)
+		ESMTPDPEM="$TMPDIR/esmtpd.pem"
+
+		# call patched mkesmtpdcert which allows to specify the filename as first paramter
+		mkesmtpdcert "$ESMTPDPEM"
+
+		chown daemon "$ESMTPDPEM"
+		mv "$ESMTPDPEM" /etc/courier/esmtpd.pem
+
+		# clean up
+		rm -fr "$TMPDIR"
 	fi
 fi
 
diff --git a/debian/courier_perms b/debian/courier_perms
old mode 100644
new mode 100755
diff --git a/debian/fixlinks b/debian/fixlinks
old mode 100644
new mode 100755

Bug#752620: enigmail can't be installed anymore after icedove update from 2014-06-25

[Willi Mann]

Hi,

thank you for your report. Please post the output of

apt-cache policy enigmail

thanks
WM


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#752337: setools: Logwatch script in wrong location, produces error when package is removed but not purged

[Willi Mann]

Package: setools-gui
Version: 3.3.8-3
Severity: normal

Hi,

I think the script /etc/logwatch/scripts/services/seaudit-report-service 
should be shipped in /usr/share/logwatch/scripts/services, unless it is really
expected to be modified by the user like a configuration file.

Additionally, the script should exit silently if /usr/bin/seaudit-report does 
not exist. This is especially bad as long as the script sits in /etc, since a
removal without purge of setools-gui will lead to an error message being 
included in the logwatch output:

- seaudit-report Begin  

 Date Range: yesterday
 Detail Level: 0
 Temp Dir: /tmp/logwatch.mTpaZLGy/
 Debug Level: 0
 /etc/logwatch/scripts/services/seaudit-report-service: line 14: 
/usr/bin/seaudit-report: No such file or directory
 Failed while executing seaudit-report.\n
 
 -- seaudit-report End - 

thanks
Willi
(with my logwatch maintainer's hat on)

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749931: ijsgutenprint: Fails on upgrade, with wheezy dpkg

[Willi Mann]

Package: ijsgutenprint
Version: 5.2.10-1
Severity: grave

Hi,

On upgrade, ijsgutenprint fails on wheezy:

Vorbereitung zum Ersetzen von ijsgutenprint 5.2.9-1 (durch 
.../ijsgutenprint_5.2.10-1_amd64.deb) ...
dpkg-maintscript-helper: error: command dir_to_symlink is unknown
Hint: upgrading dpkg to a newer version might help.

Usage: dpkg-maintscript-helper  ... -- 
...

Commands:
  supports 
Returns 0 (success) if the given command is supported, 1 otherwise.
  rm_conffile  [ []]
Remove obsolete conffile. Must be called in preinst, postinst and
postrm.
  mv_conffile   [ []]
Rename a conffile. Must be called in preinst, postinst and postrm.
  help
Display this usage information.
dpkg: Fehler beim Bearbeiten von 
/var/cache/apt/archives/ijsgutenprint_5.2.10-1_amd64.deb (--unpack):
 Unterprozess neues pre-installation-Skript gab den Fehlerwert 1 zurÃŒck
dpkg-maintscript-helper: error: command dir_to_symlink is unknown
Hint: upgrading dpkg to a newer version might help.

Usage: dpkg-maintscript-helper  ... -- 
...

Commands:
  supports 
Returns 0 (success) if the given command is supported, 1 otherwise.
  rm_conffile  [ []]
Remove obsolete conffile. Must be called in preinst, postinst and
postrm.
  mv_conffile   [ []]
Rename a conffile. Must be called in preinst, postinst and postrm.
  help
Display this usage information.
dpkg: Fehler beim AufrÀumen:
 Unterprozess neues post-removal-Skript gab den Fehlerwert 1 zurÃŒck


(Sorry for the partial german locale)

Since this might bite many users on upgrade from wheezy to jessie, I set the 
severity to grave.

-- System Information:
Debian Release: 7.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ijsgutenprint depends on:
ii  ghostscript 9.05~dfsg-6.3+deb7u1
ii  libc6   2.18-5
iu  libgutenprint2  5.2.10-1
ii  libijs-0.35 0.35-8

Versions of packages ijsgutenprint recommends:
iu  foomatic-db-gutenprint  5.2.10-1

ijsgutenprint suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749129: courier-mta-ssl: fails to install

[Willi Mann]

Hi Racke,

>   Selecting previously unselected package courier-mta-ssl.
>   (Reading database ... 8752 files and directories currently installed.)
>   Preparing to unpack .../courier-mta-ssl_0.73.1-1.1_amd64.deb ...
>   Unpacking courier-mta-ssl (0.73.1-1.1) ...
>   Setting up courier-mta-ssl (0.73.1-1.1) ...
>   cp: not writing through dangling symlink '/usr/lib/courier/esmtpd.pem'

Which comes from mkesmtpdcert. I've looked at whether this could be
fixed easily by changing the maintainer script. Unfortunately, this is
not possible - or at least, I do not see it.

The easiest way would probably be to fix mkesmtdcert to work again with
/usr/lib/courier/esmtpd.pem being a dangling symlink.

Unfortunately, there is another problem: mkesmtpcert is not idempotent:
Since creating the certificate is a multi-command process, an interrupt
at one of those commands would mean that an bogus cert file gets
created. Further invocations would not detect that the cert is bogus. So
a real fix would be to create the certificate in a temporary place -
which would require even bigger modifications to mkesmtpdcert.

WM


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#602690: massif-visualizer: state of packaging?

[Willi Mann]

Hi,

you are the current owner of the ITP of massif-visualizer. What is the
current state? Do you need help? I would really like to see
massif-visualizer in jessie.

WM



signature.asc
Description: OpenPGP digital signature

Bug#741620: patches for RC-bugs

[Willi Mann]

tag 741620 + patch
thanks

Hi Racke,

I've created patches for the two RC-bugs against courier. The patch to
fix the STARTTLS problem is really tested, and fixed the problem in my
test setup. The patch to fix maildrop delivery mode really makes
maildrop to be linked against libcourierauth.so again, but I did not
test whether it fixes the whole problem (and the patch is not that
beautiful either, which are the two reasons  I'm not adding the patch
tag there).

Do you currently have time to prepare an upload? Otherwise, I would do
an NMU (after verifying that the second patch is also OK), but not
before Thursday.

Bye
Willi
From 43a0424d6de39643036c421dc185fae0086c44c2 Mon Sep 17 00:00:00 2001
From: Willi Mann 
Date: Sun, 27 Apr 2014 14:56:48 +0200
Subject: [PATCH 1/3] Fix maildrop to build against courier authlib

---
 debian/rules|1 +
 libs/maildrop/configure |7 ---
 2 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/debian/rules b/debian/rules
index e3b1652..f8bbc9a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -50,6 +50,7 @@ COMMON_CONFOPTS=--prefix=/usr --mandir=\$${prefix}/share/man \
 		--with-calendardir=/var/run/courier/calendar \
 		--with-certsdir=/etc/courier \
 		--with-webadmindir=/usr/share/courier/webadmin \
+		--enable-authlib \
 		--enable-userdb \
 		--enable-syslog=1 \
 		--enable-unicode \
diff --git a/libs/maildrop/configure b/libs/maildrop/configure
index 0a600f1..c5f4433 100755
--- a/libs/maildrop/configure
+++ b/libs/maildrop/configure
@@ -16300,13 +16300,6 @@ fi
 done
 
 
-# When we're a part of the Courier build, we let Courier do the authlib stuff
-
-if test -d ${srcdir}/../../courier
-then
-	COURIERAUTHCONFIG=""
-fi
-
 # Check whether --enable-authlib was given.
 if test "${enable_authlib+set}" = set; then :
   enableval=$enable_authlib;
-- 
1.7.10.4

From 66c08f5188192c5825dde9d9264b9d95a56664d8 Mon Sep 17 00:00:00 2001
From: Willi Mann 
Date: Sun, 27 Apr 2014 15:02:05 +0200
Subject: [PATCH 2/3] Create dhparams in postinst

---
 debian/courier-ssl.postinst |7 +++
 debian/courier-ssl.postrm   |1 +
 2 files changed, 8 insertions(+)

diff --git a/debian/courier-ssl.postinst b/debian/courier-ssl.postinst
index 48e29b9..c09f6ae 100644
--- a/debian/courier-ssl.postinst
+++ b/debian/courier-ssl.postinst
@@ -20,4 +20,11 @@
 # Source debconf library
 . /usr/share/debconf/confmodule
 
+if [ "$1" = "configure" ]; then
+	test -d /etc/courier || mkdir /etc/courier
+	if [ ! -f /etc/courier/dhparams.pem ]; then
+		mkdhparams
+	fi
+fi
+
 #DEBHELPER#
diff --git a/debian/courier-ssl.postrm b/debian/courier-ssl.postrm
index 48a6965..5c065f8 100644
--- a/debian/courier-ssl.postrm
+++ b/debian/courier-ssl.postrm
@@ -19,6 +19,7 @@
 
 if [ "$1" = "purge" ]; then
 	rm -rf /var/lib/courier/couriersslcache
+	rm -rf /etc/courier/dhparams.pem
 fi
 
 #DEBHELPER#
-- 
1.7.10.4



signature.asc
Description: OpenPGP digital signature

Bug#741620: dhparams.pem missing...

[Willi Mann]

Apparently, the reason for this bug is that courier-imap now needs a
dhparams.pem. At least, I could reproduce this bug (using offlineimap),
and found the following message in network dump:

MEAE2 NO STARTTLS failed: couriertls: /etc/courier/dhparams.pem:
error:02001002:system library:fopen:No such file or directory\x0a

After creating a /etc/courier/dhparams.pem by

openssl dhparam -out dhparams.pem 2048

offlineimap was able to successfully download messages.

WM


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#740602: marking pending

[Willi Mann]

tag 740602 + pending
thanks

Marking this bug as pending as a fix is in pkgs repository:

http://anonscm.debian.org/gitweb/?p=pkg-games/deng.git;a=commitdiff;h=f7ffda75d23d1e471cf6a42f21d42e991a2172d3;hp=9b14820b38c3e1ea99b686bbc469a42c9bbef9b8

Greetings from Salzburg BSP
WM


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org