Bug#1000068: libapache2-mod-auth-cas: depends on obsolete pcre3 library

2024-01-17 Thread Thijs Kinkhorst
Hi,

> Your package still depends on the old, obsolete PCRE3[0] libraries
> (i.e. libpcre3-dev).

Thanks for the report. Indeed there's work ongoing upstream to fix this.
I'm monitoring this and we hope to get a working version well in time for
trixie.


Kind regards,
Thijs



Bug#996010: ttf-mscorefonts-installer: Updating the copyright file to reflect recent changes in dir/file names and licensing stuff

2023-01-04 Thread Thijs Kinkhorst
Dear Abhishek,

On Sun, October 10, 2021 04:46, Abhishek Deshpande wrote:
> recent changes in filenames, and locations. For example, the READ_ME!.gz
> file that has the licensing terms of font files themselves,
> does not exist in recent package versions.

Thanks for reporting. The file does in fact exist (after download), but
you are correct that Debian's copyright file referenced the wrong directory.
I'll fix that now in the next upload to point people to the correct
directory where this file can be found (after download).


Cheers,
Thijs



Bug#1025647: buster-pu: package libapache2-mod-auth-mellon/0.14.2-1+deb10u1

2022-12-06 Thread Thijs Kinkhorst
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi,

I propose this upload to buster to fix a relatively minor security issue
(open redirect) in libapache2-mod-auth-mellon.

The changes are already in sid and bookworm for a longer time, and in
bullseye for the first part.


Cheers,
Thijs
diff -Nru libapache2-mod-auth-mellon-0.14.2/debian/changelog 
libapache2-mod-auth-mellon-0.14.2/debian/changelog
--- libapache2-mod-auth-mellon-0.14.2/debian/changelog  2019-03-22 
12:10:11.0 +
+++ libapache2-mod-auth-mellon-0.14.2/debian/changelog  2022-12-06 
15:39:13.0 +
@@ -1,3 +1,10 @@
+libapache2-mod-auth-mellon (0.14.2-1+deb10u1) buster; urgency=high
+
+  * Upload to fix security issues:
+- Open redirect in logout endpoint (CVE-2019-13038 CVE-2021-3639)
+
+ -- Thijs Kinkhorst   Tue, 06 Dec 2022 15:39:13 +
+
 libapache2-mod-auth-mellon (0.14.2-1) unstable; urgency=high
 
   * New upstream security release. (closes: #925197)
diff -Nru libapache2-mod-auth-mellon-0.14.2/debian/patches/CVE-2019-13038.patch 
libapache2-mod-auth-mellon-0.14.2/debian/patches/CVE-2019-13038.patch
--- libapache2-mod-auth-mellon-0.14.2/debian/patches/CVE-2019-13038.patch   
1970-01-01 00:00:00.0 +
+++ libapache2-mod-auth-mellon-0.14.2/debian/patches/CVE-2019-13038.patch   
2022-12-06 15:36:36.0 +
@@ -0,0 +1,29 @@
+From a52645391d08739a6a96df21e2506d3e57b888dc Mon Sep 17 00:00:00 2001
+From: Valentin 
+Date: Fri, 6 Sep 2019 13:30:36 +0300
+Subject: [PATCH] Fix open redirect CVE-2019-13038
+
+Resolves:
+https://github.com/latchset/mod_auth_mellon/issues/2
+
+The original reported redirect attack was:
+https://application.com/mellon/login?ReturnTo=http:www.malicious.com
+---
+ auth_mellon_util.c | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/auth_mellon_util.c b/auth_mellon_util.c
+index fd442f9..e53a98f 100644
+--- a/auth_mellon_util.c
 b/auth_mellon_util.c
+@@ -116,6 +116,10 @@ int am_validate_redirect_url(request_rec *r, const char 
*url)
+ 
+ /* Sanity check of the scheme of the domain. We only allow http and 
https. */
+ if (uri.scheme) {
++/* http and https schemes without hostname are invalid. */
++if (!uri.hostname) {
++return HTTP_BAD_REQUEST;
++}
+ if (strcasecmp(uri.scheme, "http")
+ && strcasecmp(uri.scheme, "https")) {
+ AM_LOG_RERROR(APLOG_MARK, APLOG_ERR, 0, r,
diff -Nru libapache2-mod-auth-mellon-0.14.2/debian/patches/CVE-2021-3639.patch 
libapache2-mod-auth-mellon-0.14.2/debian/patches/CVE-2021-3639.patch
--- libapache2-mod-auth-mellon-0.14.2/debian/patches/CVE-2021-3639.patch
1970-01-01 00:00:00.0 +
+++ libapache2-mod-auth-mellon-0.14.2/debian/patches/CVE-2021-3639.patch
2022-12-06 15:38:26.0 +
@@ -0,0 +1,44 @@
+From 42a11261b9dad2e48d70bdff7c53dd57a12db6f5 Mon Sep 17 00:00:00 2001
+From: AIMOTO Norihito 
+Date: Tue, 6 Jul 2021 22:57:24 +0200
+Subject: [PATCH] Prevent redirect to URLs that begin with '///'
+
+Visiting a logout URL like this:
+
https://rp.example.co.jp/mellon/logout?ReturnTo=///fishing-site.example.com/logout.html
+would have redirected the user to fishing-site.example.com
+
+With the patch, this URL would be rejected.
+
+Fixes: CVE-2021-3639
+---
+ auth_mellon_util.c | 10 ++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/auth_mellon_util.c b/auth_mellon_util.c
+index 2f8c9c3..6a686db 100644
+--- a/auth_mellon_util.c
 b/auth_mellon_util.c
+@@ -927,6 +927,10 @@ int am_check_url(request_rec *r, const char *url)
+ {
+ const char *i;
+ 
++if (url == NULL) {
++return HTTP_BAD_REQUEST;
++}
++
+ for (i = url; *i; i++) {
+ if (*i >= 0 && *i < ' ') {
+ /* Deny all control-characters. */
+@@ -943,6 +947,12 @@ int am_check_url(request_rec *r, const char *url)
+ }
+ }
+ 
++if (strstr(url, "///") == url) {
++AM_LOG_RERROR(APLOG_MARK, APLOG_ERR, HTTP_BAD_REQUEST, r,
++  "URL starts with '///'");
++return HTTP_BAD_REQUEST;
++}
++
+ return OK;
+ }
+ 
diff -Nru libapache2-mod-auth-mellon-0.14.2/debian/patches/series 
libapache2-mod-auth-mellon-0.14.2/debian/patches/series
--- libapache2-mod-auth-mellon-0.14.2/debian/patches/series 2018-01-06 
12:58:18.0 +
+++ libapache2-mod-auth-mellon-0.14.2/debian/patches/series 2022-12-06 
15:39:01.0 +
@@ -0,0 +1,2 @@
+CVE-2019-13038.patch
+CVE-2021-3639.patch


Bug#1025646: bullseye-pu: package libapache2-mod-auth-mellon/0.17.0-1+deb11u1

2022-12-06 Thread Thijs Kinkhorst
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

Hi,

I propose this upload to bullseye to fix a relatively minor security issue
(open redirect) in libapache2-mod-auth-mellon.

The changes are already in sid and bookworm for a longer time.


Cheers,
Thijs
diff -Nru libapache2-mod-auth-mellon-0.17.0/debian/changelog 
libapache2-mod-auth-mellon-0.17.0/debian/changelog
--- libapache2-mod-auth-mellon-0.17.0/debian/changelog  2020-09-08 
12:56:41.0 +0200
+++ libapache2-mod-auth-mellon-0.17.0/debian/changelog  2022-12-06 
20:12:37.0 +0100
@@ -1,3 +1,10 @@
+libapache2-mod-auth-mellon (0.17.0-1+deb11u1) bullseye; urgency=medium
+
+  * Upload to fix security issue:
+- Open redirect in logout endpoint (CVE-2021-3639)
+
+ -- Thijs Kinkhorst   Tue, 06 Dec 2022 20:12:37 +0100
+
 libapache2-mod-auth-mellon (0.17.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libapache2-mod-auth-mellon-0.17.0/debian/patches/CVE-2021-3639.patch 
libapache2-mod-auth-mellon-0.17.0/debian/patches/CVE-2021-3639.patch
--- libapache2-mod-auth-mellon-0.17.0/debian/patches/CVE-2021-3639.patch
1970-01-01 01:00:00.0 +0100
+++ libapache2-mod-auth-mellon-0.17.0/debian/patches/CVE-2021-3639.patch
2022-12-06 20:12:37.0 +0100
@@ -0,0 +1,44 @@
+From 42a11261b9dad2e48d70bdff7c53dd57a12db6f5 Mon Sep 17 00:00:00 2001
+From: AIMOTO Norihito 
+Date: Tue, 6 Jul 2021 22:57:24 +0200
+Subject: [PATCH] Prevent redirect to URLs that begin with '///'
+
+Visiting a logout URL like this:
+
https://rp.example.co.jp/mellon/logout?ReturnTo=///fishing-site.example.com/logout.html
+would have redirected the user to fishing-site.example.com
+
+With the patch, this URL would be rejected.
+
+Fixes: CVE-2021-3639
+---
+ auth_mellon_util.c | 10 ++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/auth_mellon_util.c b/auth_mellon_util.c
+index 2f8c9c3..6a686db 100644
+--- a/auth_mellon_util.c
 b/auth_mellon_util.c
+@@ -927,6 +927,10 @@ int am_check_url(request_rec *r, const char *url)
+ {
+ const char *i;
+ 
++if (url == NULL) {
++return HTTP_BAD_REQUEST;
++}
++
+ for (i = url; *i; i++) {
+ if (*i >= 0 && *i < ' ') {
+ /* Deny all control-characters. */
+@@ -943,6 +947,12 @@ int am_check_url(request_rec *r, const char *url)
+ }
+ }
+ 
++if (strstr(url, "///") == url) {
++AM_LOG_RERROR(APLOG_MARK, APLOG_ERR, HTTP_BAD_REQUEST, r,
++  "URL starts with '///'");
++return HTTP_BAD_REQUEST;
++}
++
+ return OK;
+ }
+ 
diff -Nru libapache2-mod-auth-mellon-0.17.0/debian/patches/series 
libapache2-mod-auth-mellon-0.17.0/debian/patches/series
--- libapache2-mod-auth-mellon-0.17.0/debian/patches/series 2020-01-27 
14:32:39.0 +0100
+++ libapache2-mod-auth-mellon-0.17.0/debian/patches/series 2022-12-06 
20:12:37.0 +0100
@@ -0,0 +1 @@
+CVE-2021-3639.patch


Bug#1010011: Periodically vacuum database to prevent it growing endlessly

2022-04-22 Thread Thijs Kinkhorst
Package: fail2ban
Version: 0.11.2-6
Severity: normal
Tags: patch

Hi,

fail2ban (since 0.11) automatically cleans up stale entries in its
database, by default daily. However, the sqlite database is not
vacuum'ed so the file size on disk is not reduced after this. On one of
my systems, the database file was > 1 GB in size while after vacuum only
a 1 M remained, so it really was growing way to large.

The attached patch installs a weekly cronjob to perform the vacuum.
I've also submitted it as a merge request on salsa.


Kind regards,
Thijs Kinkhorst
diff -Nru fail2ban-0.11.2/debian/control fail2ban-0.11.2/debian/control
--- fail2ban-0.11.2/debian/control  2022-03-10 21:52:59.0 +
+++ fail2ban-0.11.2/debian/control  2022-04-22 09:14:01.0 +
@@ -21,8 +21,8 @@
 Package: fail2ban
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}, lsb-base
-Recommends: nftables | iptables, whois, python3-pyinotify, python3-systemd
-Suggests: mailx, system-log-daemon, monit, sqlite3
+Recommends: nftables | iptables, whois, sqlite3, python3-pyinotify, 
python3-systemd
+Suggests: mailx, system-log-daemon, monit
 Description: ban hosts that cause multiple authentication errors
  Fail2ban monitors log files (e.g. /var/log/auth.log,
  /var/log/apache/access.log) and temporarily or persistently bans
diff -Nru fail2ban-0.11.2/debian/cron.weekly fail2ban-0.11.2/debian/cron.weekly
--- fail2ban-0.11.2/debian/cron.weekly  1970-01-01 00:00:00.0 +
+++ fail2ban-0.11.2/debian/cron.weekly  2022-04-22 09:13:51.0 +
@@ -0,0 +1,8 @@
+#!/bin/sh
+
+sqlite="/usr/bin/sqlite3"
+database="/var/lib/fail2ban/fail2ban.sqlite3"
+
+[ -x $sqlite ] && [ -f $database ] || exit 0
+
+$sqlite $database "VACUUM;"


Bug#991730: libapache2-mod-auth-mellon: CVE-2021-3639: open redirect vulnerability

2021-08-06 Thread Thijs Kinkhorst
Hi Salvatore,

> CVE-2021-3639[0]:
> | Prevent redirect to URLs that begin with '///'

I have a fixed package prepared and tested for sid but can only upload
this next week when I return from holiday.

I consider this (open redirect in general) a minor issue so I don't think
it's needed to expediate this.


Kind regards,
Thijs



Bug#985859: cpqarrayd - ship with bullseye? - no driver support

2021-04-06 Thread Thijs Kinkhorst
Hi Chris,

On Thu, March 25, 2021 02:42, Chris Hofstaedtler wrote:
> Source: cpqarrayd
> Version: 2.3.6
> Severity: serious
>
> Linux upstream has removed the "cciss" driver in 4.14-rc1. cpqarrayd
> needs the cciss driver to function.
>
> I imagine we shouldn't ship software that did not work with buster's
> kernel in bullseye.

As the previous maintainer of cpqarrayd, I fully agree. Since nothing
happened since we orphaned the package 3 years ago, I think it's safe to
just request removal. I have just done so in #986483.


Kind regards,
Thijs



Bug#986483: RM: cpqarrayd -- RoQA; no longer usable, obsolete

2021-04-06 Thread Thijs Kinkhorst
Package: ftp.debian.org
Severity: normal

Dear FTP-masters,

Please remove cpqarrayd from unstable.

As noted in #985859, the Linux kernel driver it needs has been removed
from the upstream kernel. The package has also been orphaned for 3 years
with no activity since.

Kind regards,
Thijs Kinkhorst
previous maintainer



Bug#939763: sphinxsearch: Still maintained (same version since stretch)?

2021-04-05 Thread Thijs Kinkhorst
severity 939763 serious
thanks

Hi,

Salvatore Bonaccorso wrote:
> Is sphinxsearch still of use or should it be removed from unstable and
> not included in bullseye?

I'm raising this to serious because I think the situation of the
sphinxsearch package is not good and we would need to explicitly want to
decide to _do_ ship the package in bullseye.

A summary of the issues: the package is the same version since stretch (no
uploads since 2017). It has several important issues, most notably that it
crashes everytime you restart it (e.g. after logrotate). This bug has been
raised two years ago without any maintainer comment.

Fixing the package is also unlikely since upstream has gone closed source.
So even if there's interest in fixing this, it would be by packaging the
free alternative (fork) that has been suggested in this thread.


Kind regards,
Thijs



Bug#963000: systemd-analyze unit-paths erroneously reports /usr/lib/systemd/system/

2020-06-18 Thread Thijs Kinkhorst
Hi Michael,

On Wed, June 17, 2020 22:48, Michael Biebl wrote:
> Systemd itself does indeed search /usr/lib/systemd/system . Our
> internal/Debian tooling though
> (dh_installsystemd/invoke-rc.d/service/...) currently only handles files
> from /lib/systemd (mostly for historical reasons where a /usr on a
> separate partition mounted during late boot was still supported).
>
> So, theoretically, you can install unit files in /usr/lib/systemd/system
> and systemd will process them. What you don't get is full Debian
> integration.

Well, I'm quite sure in the sense that I had a unit file in
/usr/lib/systemd/system but indeed commands like "service" did not work. I
find it unexpected behaviour that systemd reports that it searches the
directory but at the same time something like "service x start" does not
work.

Also I found
https://lintian.debian.org/tags/systemd-service-file-outside-lib.html
which explicitly says: "Systemd in Debian searches for unit files in
/lib/systemd/system/ and /etc/systemd/system. Notably, it does not look in
/usr/lib/systemd/system/ for service files."

So I think the most clear way forward is either that it does not report
this directory as being searched, or all the tools do in fact work with
this directory. A mid way where some things work and others do not, is
confusing to me at least.

Cheers,
Thijs



Bug#963000: systemd-analyze unit-paths erroneously reports /usr/lib/systemd/system/

2020-06-17 Thread Thijs Kinkhorst
Package: systemd
Version: 245.6-1
Severity: normal

Hi,

This is the output of 'systemd-analyze unit-paths' on my system:

# systemd-analyze unit-paths
/etc/systemd/system.control
/run/systemd/system.control
/run/systemd/transient
/run/systemd/generator.early
/etc/systemd/system
/etc/systemd/system.attached
/run/systemd/system
/run/systemd/system.attached
/run/systemd/generator
/usr/local/lib/systemd/system
/lib/systemd/system
/usr/lib/systemd/system
/run/systemd/generator.late

Howeverm it seems /usr/lib/systemd/system, despite being in the list, is
not actually searched. It was confirmed by other documentation that in
Debian this is indeed the case.

It seems that the output of this command is therefore not helpful (and seems
not actually based on the used paths?).


Kind regards,
Thijs

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser3.118
ii  libacl12.2.53-8
ii  libapparmor1   2.13.4-2
ii  libaudit1  1:2.8.5-3+b1
ii  libblkid1  2.35.2-2
ii  libc6  2.30-8
ii  libcap21:2.34-2
ii  libcrypt1  1:4.4.16-1
ii  libcryptsetup122:2.3.3-1
ii  libgcrypt201.8.5-5
ii  libgnutls303.6.14-2
ii  libgpg-error0  1.38-1
ii  libidn2-0  2.3.0-1
ii  libip4tc2  1.8.5-1
ii  libkmod2   27+20200310-2
ii  liblz4-1   1.9.2-2
ii  liblzma5   5.2.4-1+b1
ii  libmount1  2.35.2-2
ii  libpam0g   1.3.1-5
ii  libpcre2-8-0   10.34-7
ii  libseccomp22.4.3-1+b1
ii  libselinux13.0-1+b3
ii  libsystemd0245.6-1
ii  mount  2.35.2-2
ii  ntp [time-daemon]  1:4.2.8p14+dfsg-2
ii  util-linux 2.35.2-2

Versions of packages systemd recommends:
ii  dbus  1.12.18-1

Versions of packages systemd suggests:
pn  policykit-1
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.137
ii  libnss-systemd   245.6-1
ii  libpam-systemd   245.6-1
ii  udev 245.6-1

-- no debconf information



Bug#960571: Missing dependency on fontconfig

2020-05-13 Thread Thijs Kinkhorst
Package: rst2pdf
Version: 0.93-7
Severity: serious

Hi,

rst2pdf calls fc-match in findfonts.py, but does not list a dependency
on fontconfig. If you don't have it installed, building the document
will succeed but the document itself is empty.


Cheers,
Thijs



Bug#903115: msttcorefonts: Debian package source repository links are all 404 not found

2020-04-26 Thread Thijs Kinkhorst
Hi Laurence,

Thanks for the feedback.

On Fri, July 6, 2018 12:47, Laurence Alexander Hurst wrote:
>* What led up to the situation?
> I've been asked to install this on a business system, so was trying to
> find licence terms for the fonts to see if I can, legally, before
> proceeding.  The copyright files says to see READ_ME!.gz but that does not
> appear to be in the package or the source tarball, so I was trying to go
> upstream but the upstream sources are all 404.

The file is installed on your system after installation indeed. As you
might have noticed, the package is rather special in that it needs to
download de fonts and then extract the .exe's they're contained in, for
license reasons.

>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Looked in sources for file referred to in 'copyright' file.  It did not
> exist, so tried to go upstream and discovered upstream 404s.
>
>* What was the outcome of this action?
> 404 not found

I don't think there's an URL in the package I could update.

However, the project's URL still exists here:
http://corefonts.sourceforge.net/


Kind regards,
Thijs



Bug#953376: [Pkg-mailman-hackers] Bug#953376: Mailman 2 will be removed from Debian

2020-04-21 Thread Thijs Kinkhorst
On Tue, April 21, 2020 18:02, Andrew Hodgson wrote:
> Thijs Kinkhorst wrote:
>>On Sun, March 8, 2020 20:01, Scott Kitterman wrote:
>>> Package: src:mailman
>>> Version: 1:2.1.29-1
>>> Severity: serious
>>> Justification: Policy 2.2.1
>>>
>>> This package Depends/Build-Depends on python-dnspython which is an NBS
>>> cruft package.  Please update your package to use python3-dnspython,
>>> which is still provided (if the package will be ported to python3).
>
>>Mailman 2.1.x is Python 2 only.
>
>>Upstream has explicitly indicated there will be no effort to port it to
>> Python 3:
>>https://mail.python.org/pipermail/mailman-users/2019-April/084333.html
>
>>So it seems the time has come to remove Mailman 2 from Debian, and let
>> people migrate to Mailman 3.
>
> I thought this may be the case. I was looking at the possibility of
> whether I could build 2.1.30 even if it was to go in backports until the
> eventual removal of the package on the next Debian version, but would this
> removal cause problems for this?

This is indeed not possible, because Backports requires package versions
to come from testing and mailman is already no longer in testing.

Continued support for any mailman 2.x packages needs to be outside of the
Debian archive since Debian will have removed Python 2 both from stable
and testing/unstable starting from the next release.


Cheers,
Thijs

Cheers,
Thijs



Bug#953376: Mailman 2 will be removed from Debian

2020-04-21 Thread Thijs Kinkhorst
Hi,

On Sun, March 8, 2020 20:01, Scott Kitterman wrote:
> Package: src:mailman
> Version: 1:2.1.29-1
> Severity: serious
> Justification: Policy 2.2.1
>
> This package Depends/Build-Depends on python-dnspython which is an NBS
> cruft package.  Please update your package to use python3-dnspython, which
> is still provided (if the package will be ported to python3).

Mailman 2.1.x is Python 2 only.

Upstream has explicitly indicated there will be no effort to port it to
Python 3:
https://mail.python.org/pipermail/mailman-users/2019-April/084333.html

So it seems the time has come to remove Mailman 2 from Debian, and let
people migrate to Mailman 3.


Cheers,
Thijs



Bug#955354: liblasso3: crashes on parsing AuthnContextDecl

2020-03-30 Thread Thijs Kinkhorst
Package: liblasso3
Version: 2.6.0-2+b2
Severity: important
Tags: fixed-upstream

Hi,

We're using lasso with libapache2-mod-auth-mellon and it crashes every
time an IdP sends a (valid) AuthnContextDecl.

This has been fixed meanwhile upstream, which I've verified solves the
problem: https://dev.entrouvert.org/issues/25640

There is however not a new Lasso release yet (or has been for a while
now). Can you incorporate the required patch in Debian so mellon does
not crash on these IdPs?



Thanks,
Thijs

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

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

Versions of packages liblasso3 depends on:
ii  libc6   2.28-10
ii  libglib2.0-02.58.3-2+deb10u2
ii  libssl1.1   1.1.1d-0+deb10u2
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libxmlsec1  1.2.27-2
ii  libxmlsec1-openssl  1.2.27-2
ii  libxslt1.1  1.1.32-2.2~deb10u1
ii  zlib1g  1:1.2.11.dfsg-1

liblasso3 recommends no packages.

liblasso3 suggests no packages.

-- no debconf information



Bug#946841: buster-pu: package simplesamlphp/1.16.3-1+deb10u2

2019-12-16 Thread Thijs Kinkhorst
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi,

The simpleSAMLphp package in buster suffers from an incompatibility with
PHP 7.3 (also shipped in buster) that can be fixed with a one character
change.

The bug report is at https://bugs.debian.org/944820

This was missed during the release cycle because the already existing
and working simplesamlphp package was not fully re-tested when PHP 7.3
was introduced into buster.

Please see attached debdiff for a proposed fix for buster.


Thanks,
Thijs
diff -Nru simplesamlphp-1.16.3/debian/changelog 
simplesamlphp-1.16.3/debian/changelog
--- simplesamlphp-1.16.3/debian/changelog   2019-11-03 06:46:13.0 
+0100
+++ simplesamlphp-1.16.3/debian/changelog   2019-12-16 14:15:00.0 
+0100
@@ -1,3 +1,9 @@
+simplesamlphp (1.16.3-1+deb10u2) buster; urgency=medium
+
+  * Fix incompatibility with PHP 7.3 (closes: #944820).
+
+ -- Thijs Kinkhorst   Mon, 16 Dec 2019 14:15:00 +0100
+
 simplesamlphp (1.16.3-1+deb10u1) buster-security; urgency=high
 
   * Fix security issue CVE-2019-3465.
diff -Nru simplesamlphp-1.16.3/debian/patches/fix-xmlseclibs-php73.patch 
simplesamlphp-1.16.3/debian/patches/fix-xmlseclibs-php73.patch
--- simplesamlphp-1.16.3/debian/patches/fix-xmlseclibs-php73.patch  
1970-01-01 01:00:00.0 +0100
+++ simplesamlphp-1.16.3/debian/patches/fix-xmlseclibs-php73.patch  
2019-12-16 14:15:00.0 +0100
@@ -0,0 +1,24 @@
+From: Stefan Winter 
+Date: Thu, 18 Oct 2018 07:24:07 +0200
+Subject: [PATCH] make regex PCRE2 compliant
+
+PHP7.3 makes a hard switch from PCRE to PCRE2, where the hyphen needs to be 
escaped. I've tested and confirmed that with PHP 7.3rc3
+- the code as was before this PR breaks with a PHP error about unable to 
compile the regex
+- the code with this one-character PR applied works just fine
+---
+ src/Utils/XPath.php | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/Utils/XPath.php b/src/Utils/XPath.php
+index 11e51fb..8cdc48e 100644
+--- a/vendor/robrichards/xmlseclibs/src/Utils/XPath.php
 b/vendor/robrichards/xmlseclibs/src/Utils/XPath.php
+@@ -7,7 +7,7 @@ class XPath
+ const ALPHANUMERIC = '\w\d';
+ const NUMERIC = '\d';
+ const LETTERS = '\w';
+-const EXTENDED_ALPHANUMERIC = '\w\d\s-_:\.';
++const EXTENDED_ALPHANUMERIC = '\w\d\s\-_:\.';
+ 
+ const SINGLE_QUOTE = '\'';
+ const DOUBLE_QUOTE = '"';
diff -Nru simplesamlphp-1.16.3/debian/patches/series 
simplesamlphp-1.16.3/debian/patches/series
--- simplesamlphp-1.16.3/debian/patches/series  2019-11-03 06:44:18.0 
+0100
+++ simplesamlphp-1.16.3/debian/patches/series  2019-12-16 14:15:00.0 
+0100
@@ -1,2 +1,3 @@
 debian_config.patch
 CVE-2019-3465.patch
+fix-xmlseclibs-php73.patch


Bug#944820: SimpleSAMLphp fails when consuming assertion

2019-12-16 Thread Thijs Kinkhorst
Hoi Jorn,

> When SimpleSAMLphp consumes an assertion, it will fail and log the
> following:

Can you confirm that this update fixes the problem for you?

https://people.debian.org/~thijs/ssp/


Cheers,
Thijs



Bug#940477: stretch-pu: package tmpreaper/1.6.13+nmu1+deb9u2

2019-09-16 Thread Thijs Kinkhorst
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi,

tmpreaper will clean up PrivateTmp dirs of processes that systemd
started, leading to those services periodically crashing (and it's
usually hard to diagnose that tmpreaper was the culprit here).

This update adds those dirs to tmpreapers' whitelist.

Kind regards,
Thijs

-- System Information:
Debian Release: 9.11
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8), 
LANGUAGE=nl_NL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
diff -Nru tmpreaper-1.6.13+nmu1+deb9u1/ChangeLog 
tmpreaper-1.6.13+nmu1+deb9u2/ChangeLog
--- tmpreaper-1.6.13+nmu1+deb9u1/ChangeLog  2019-01-05 16:25:06.0 
+0100
+++ tmpreaper-1.6.13+nmu1+deb9u2/ChangeLog  2019-09-16 09:39:51.0 
+0200
@@ -1,3 +1,11 @@
+tmpreaper (1.6.13+nmu1+deb9u2) stretch; urgency=medium
+
+  * Non-maintainer upload with maintainer approval.
+  * Add `--protect '/tmp/systemd-private*/*'` to cron job to prevent
+breaking systemd services that have PrivateTmp=true (closes: #881725).
+
+ -- Thijs Kinkhorst   Mon, 16 Sep 2019 09:39:51 +0200
+
 tmpreaper (1.6.13+nmu1+deb9u1) stretch-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru tmpreaper-1.6.13+nmu1+deb9u1/debian/changelog 
tmpreaper-1.6.13+nmu1+deb9u2/debian/changelog
--- tmpreaper-1.6.13+nmu1+deb9u1/debian/changelog   2019-01-05 
16:25:06.0 +0100
+++ tmpreaper-1.6.13+nmu1+deb9u2/debian/changelog   2019-09-16 
09:39:51.0 +0200
@@ -1,3 +1,11 @@
+tmpreaper (1.6.13+nmu1+deb9u2) stretch; urgency=medium
+
+  * Non-maintainer upload with maintainer approval.
+  * Add `--protect '/tmp/systemd-private*/*'` to cron job to prevent
+breaking systemd services that have PrivateTmp=true (closes: #881725).
+
+ -- Thijs Kinkhorst   Mon, 16 Sep 2019 09:39:51 +0200
+
 tmpreaper (1.6.13+nmu1+deb9u1) stretch-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru tmpreaper-1.6.13+nmu1+deb9u1/debian/cron.daily 
tmpreaper-1.6.13+nmu1+deb9u2/debian/cron.daily
--- tmpreaper-1.6.13+nmu1+deb9u1/debian/cron.daily  2008-05-19 
19:10:16.0 +0200
+++ tmpreaper-1.6.13+nmu1+deb9u2/debian/cron.daily  2019-09-16 
09:39:51.0 +0200
@@ -105,5 +105,6 @@
   --protect '/tmp/lost+found' \
   --protect '/tmp/journal.dat' \
   --protect '/tmp/quota.{user,group}' \
+  --protect '/tmp/systemd-private*/*' \
   `for i in $TMPREAPER_PROTECT_EXTRA; do echo --protect "$i"; done` \
   $TMPREAPER_DIRS


Bug#940476: buster-pu: package tmpreaper/1.6.14+deb10u1

2019-09-16 Thread Thijs Kinkhorst
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi,

tmpreaper will clean up PrivateTmp dirs of processes that systemd
started, leading to those services periodically crashing (and it's
usually hard to diagnose that tmpreaper was the culprit here).

This update adds those dirs to tmpreapers' whitelist.

The problem has existed for a longer time but seems aggravated since
buster, likely because more services have started to use PrivateTmp.


Kind regards,
Thijs

-- System Information:
Debian Release: 9.11
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8), 
LANGUAGE=nl_NL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
diff -Nru tmpreaper-1.6.14/ChangeLog tmpreaper-1.6.14+deb10u1/ChangeLog
--- tmpreaper-1.6.14/ChangeLog  2019-01-11 13:27:15.0 +0100
+++ tmpreaper-1.6.14+deb10u1/ChangeLog  2019-09-16 09:15:24.0 +0200
@@ -1,3 +1,11 @@
+tmpreaper (1.6.14+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload with maintainer approval.
+  * Add `--protect '/tmp/systemd-private*/*'` to cron job to prevent
+breaking systemd services that have PrivateTmp=true (closes: #881725).
+
+ -- Thijs Kinkhorst   Mon, 16 Sep 2019 07:15:24 +
+
 tmpreaper (1.6.14) unstable; urgency=medium
 
   * Upload to unstable to fix the race condition described in CVE-2019-3461:
diff -Nru tmpreaper-1.6.14/debian/changelog 
tmpreaper-1.6.14+deb10u1/debian/changelog
--- tmpreaper-1.6.14/debian/changelog   2019-01-11 13:27:15.0 +0100
+++ tmpreaper-1.6.14+deb10u1/debian/changelog   2019-09-16 09:15:24.0 
+0200
@@ -1,3 +1,11 @@
+tmpreaper (1.6.14+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload with maintainer approval.
+  * Add `--protect '/tmp/systemd-private*/*'` to cron job to prevent
+breaking systemd services that have PrivateTmp=true (closes: #881725).
+
+ -- Thijs Kinkhorst   Mon, 16 Sep 2019 07:15:24 +
+
 tmpreaper (1.6.14) unstable; urgency=medium
 
   * Upload to unstable to fix the race condition described in CVE-2019-3461:
diff -Nru tmpreaper-1.6.14/debian/cron.daily 
tmpreaper-1.6.14+deb10u1/debian/cron.daily
--- tmpreaper-1.6.14/debian/cron.daily  2008-05-19 19:10:16.0 +0200
+++ tmpreaper-1.6.14+deb10u1/debian/cron.daily  2019-09-16 09:15:24.0 
+0200
@@ -105,5 +105,6 @@
   --protect '/tmp/lost+found' \
   --protect '/tmp/journal.dat' \
   --protect '/tmp/quota.{user,group}' \
+  --protect '/tmp/systemd-private*/*' \
   `for i in $TMPREAPER_PROTECT_EXTRA; do echo --protect "$i"; done` \
   $TMPREAPER_DIRS


Bug#881725: NMU for tmpreaper

2019-09-06 Thread Thijs Kinkhorst
Hoi Paul,

As I already mentioned on IRC - we're running into this issue (Apache
stopped running periodically) and since a patch has been available for a
few months I took the liberty to schedule a NMU in DELAYED/5 with this fix.

Let me know if you object or even if you want me to go ahead without delay.

If this fix has no issues I'll also propose a fix for Buster since that is
what we're running.


Cheers,
Thijs
diff -Nru tmpreaper-1.6.14/ChangeLog tmpreaper-1.6.14+nmu1/ChangeLog
--- tmpreaper-1.6.14/ChangeLog	2019-01-11 12:27:15.0 +
+++ tmpreaper-1.6.14+nmu1/ChangeLog	2019-09-06 13:20:49.0 +
@@ -1,3 +1,11 @@
+tmpreaper (1.6.14+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add `--protect '/tmp/systemd-private*/*'` to cron job to prevent
+breaking systemd services that have PrivateTmp=true (closes: #881725).
+
+ -- Thijs Kinkhorst   Fri, 06 Sep 2019 13:20:49 +
+
 tmpreaper (1.6.14) unstable; urgency=medium
 
   * Upload to unstable to fix the race condition described in CVE-2019-3461:
diff -Nru tmpreaper-1.6.14/debian/changelog tmpreaper-1.6.14+nmu1/debian/changelog
--- tmpreaper-1.6.14/debian/changelog	2019-01-11 12:27:15.0 +
+++ tmpreaper-1.6.14+nmu1/debian/changelog	2019-09-06 13:20:49.0 +
@@ -1,3 +1,11 @@
+tmpreaper (1.6.14+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add `--protect '/tmp/systemd-private*/*'` to cron job to prevent
+breaking systemd services that have PrivateTmp=true (closes: #881725).
+
+ -- Thijs Kinkhorst   Fri, 06 Sep 2019 13:20:49 +
+
 tmpreaper (1.6.14) unstable; urgency=medium
 
   * Upload to unstable to fix the race condition described in CVE-2019-3461:
diff -Nru tmpreaper-1.6.14/debian/cron.daily tmpreaper-1.6.14+nmu1/debian/cron.daily
--- tmpreaper-1.6.14/debian/cron.daily	2008-05-19 17:10:16.0 +
+++ tmpreaper-1.6.14+nmu1/debian/cron.daily	2019-09-06 13:15:04.0 +
@@ -105,5 +105,6 @@
   --protect '/tmp/lost+found' \
   --protect '/tmp/journal.dat' \
   --protect '/tmp/quota.{user,group}' \
+  --protect '/tmp/systemd-private*/*' \
   `for i in $TMPREAPER_PROTECT_EXTRA; do echo --protect "$i"; done` \
   $TMPREAPER_DIRS
diff -Nru tmpreaper-1.6.14/.deps/tmpreaper.Po tmpreaper-1.6.14+nmu1/.deps/tmpreaper.Po
--- tmpreaper-1.6.14/.deps/tmpreaper.Po	2019-01-11 12:27:15.0 +
+++ tmpreaper-1.6.14+nmu1/.deps/tmpreaper.Po	2019-09-06 13:20:49.0 +
@@ -11,7 +11,7 @@
  /usr/include/x86_64-linux-gnu/bits/types/clockid_t.h \
  /usr/include/x86_64-linux-gnu/bits/types/time_t.h \
  /usr/include/x86_64-linux-gnu/bits/types/timer_t.h \
- /usr/lib/gcc/x86_64-linux-gnu/7/include/stddef.h \
+ /usr/lib/gcc/x86_64-linux-gnu/9/include/stddef.h \
  /usr/include/x86_64-linux-gnu/bits/stdint-intn.h /usr/include/endian.h \
  /usr/include/x86_64-linux-gnu/bits/endian.h \
  /usr/include/x86_64-linux-gnu/bits/byteswap.h \
@@ -56,14 +56,14 @@
  /usr/include/asm-generic/errno.h /usr/include/asm-generic/errno-base.h \
  /usr/include/x86_64-linux-gnu/bits/types/error_t.h getopt.h \
  /usr/include/glob.h \
- /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed/limits.h \
- /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed/syslimits.h \
+ /usr/lib/gcc/x86_64-linux-gnu/9/include-fixed/limits.h \
+ /usr/lib/gcc/x86_64-linux-gnu/9/include-fixed/syslimits.h \
  /usr/include/limits.h \
  /usr/include/x86_64-linux-gnu/bits/libc-header-start.h \
  /usr/include/x86_64-linux-gnu/bits/posix2_lim.h \
  /usr/include/x86_64-linux-gnu/bits/xopen_lim.h \
  /usr/include/x86_64-linux-gnu/bits/uio_lim.h \
- /usr/lib/gcc/x86_64-linux-gnu/7/include/stdarg.h /usr/include/stdio.h \
+ /usr/lib/gcc/x86_64-linux-gnu/9/include/stdarg.h /usr/include/stdio.h \
  /usr/include/x86_64-linux-gnu/bits/types/__fpos_t.h \
  /usr/include/x86_64-linux-gnu/bits/types/__mbstate_t.h \
  /usr/include/x86_64-linux-gnu/bits/types/__fpos64_t.h \
@@ -104,7 +104,7 @@
  /usr/include/x86_64-linux-gnu/bits/ioctl-types.h \
  /usr/include/x86_64-linux-gnu/sys/ttydefaults.h \
  /usr/include/ext2fs/ext2_fs.h /usr/include/ext2fs/ext2_types.h \
- /usr/lib/gcc/x86_64-linux-gnu/7/include/stdint.h /usr/include/stdint.h \
+ /usr/lib/gcc/x86_64-linux-gnu/9/include/stdint.h /usr/include/stdint.h \
  /usr/include/x86_64-linux-gnu/bits/wchar.h \
  /usr/include/x86_64-linux-gnu/bits/stdint-uintn.h /usr/include/utime.h \
  /usr/include/libmount/libmount.h /usr/include/mntent.h \
@@ -140,7 +140,7 @@
 
 /usr/include/x86_64-linux-gnu/bits/types/timer_t.h:
 
-/usr/lib/gcc/x86_64-linux-gnu/7/include/stddef.h:
+/usr/lib/gcc/x86_64-linux-gnu/9/include/stddef.h:
 
 /usr/include/x86_64-linux-gnu/bits/stdint-intn.h:
 
@@ -244,9 +244,9 @@
 
 /usr/include/glob.h:
 
-/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed/limits.h:
+/usr/lib/gcc/x86_64-linux-gnu/9/include-fixed/limits.h:
 
-/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed/syslimits.h:
+/usr/lib/gcc/x86_64-linux-gnu/9/include-fixed/syslimits.h:
 
 /usr/include/limits.h:
 
@@ -25

Bug#928164: backports work

2019-05-27 Thread Thijs Kinkhorst
On Wed, May 22, 2019 17:21, Frederic Peters wrote:
> Hi Thijs,
>
>> >> I would have been OK to have 2.6.0 of liblasso3 in stretch backports,
>> >> and I was in the believe that I had installed it. But when checking,
>> >> I'm still running 2.5.0-5+b1. Spooky
>>
>> > I'll see about uploading 2.6.0 to backports.
>>
>> That would be great. I have a backport of libapache2-mod-auth-mellon in
>> stretch, to allow to use SHA256 with mellon. But the signatures fail
>> because of https://dev.entrouvert.org/issues/10019
>>
>> That is fixed in lasso 2.5.1. So having a lasso >= 2.5.1 in backports
>> would really help us aswell.
>>
>> I can help out with the backport work if needed.
>
> Per https://backports.debian.org/Contribute/#index3h3 I asked to be
> added to the ACL but no news yet; as you are already in I'd suggest you
> go ahead and upload lasso (afaik there are no technical difficulties
> and I'm using a local backport at $dayjob).

FYI, I have done this yesterday and it's now queued for review:
https://ftp-master.debian.org/backports-new.html


Cheers,
Thijs



Bug#928164: backports work

2019-05-22 Thread Thijs Kinkhorst
Hi Frederic,

>> I would have been OK to have 2.6.0 of liblasso3 in stretch backports,
>> and I was in the believe that I had installed it. But when checking,
>> I'm still running 2.5.0-5+b1. Spooky

> I'll see about uploading 2.6.0 to backports.

That would be great. I have a backport of libapache2-mod-auth-mellon in
stretch, to allow to use SHA256 with mellon. But the signatures fail
because of https://dev.entrouvert.org/issues/10019

That is fixed in lasso 2.5.1. So having a lasso >= 2.5.1 in backports
would really help us aswell.

I can help out with the backport work if needed.


Thanks,
Thijs



signature.asc
Description: OpenPGP digital signature


Bug#928479: version number not properly reported

2019-05-05 Thread Thijs Kinkhorst
Source: dbconfig-common
Version: 2.0.11
Severity: minor

Version reporting in the usage message relies on SVN keywords which are
not interpolated (anymore):

dbconfig-load-include v$ 
copyright (c) 2005 sean finney 



Bug#925345: unblock: libapache2-mod-auth-mellon/0.14.2-1

2019-03-24 Thread Thijs Kinkhorst
On Sat, March 23, 2019 16:56, Jonathan Wiltshire wrote:
> On Sat, Mar 23, 2019 at 03:00:06PM +0100, Thijs Kinkhorst wrote:
>> Please unblock package libapache2-mod-auth-mellon
>>
>> The upload contains fixes for two security issues, it is a new
>> upstream that only contains these fixes.
>
> Unblocked; thanks.

Thanks, can you also age it? I assumed that "urgency=high" would do this,
but apparently it does not.


Cheers,
Thijs



Bug#925345: unblock: libapache2-mod-auth-mellon/0.14.2-1

2019-03-23 Thread Thijs Kinkhorst
11 @@
+libapache2-mod-auth-mellon (0.14.2-1) unstable; urgency=high
+
+  * New upstream security release. (closes: #925197)
+- Auth bypass when used with reverse proxy [CVE-2019-3878]
+- Open redirect vulnerability in logout [CVE-2019-3877]
+
+ -- Thijs Kinkhorst   Fri, 22 Mar 2019 12:10:11 +
+
 libapache2-mod-auth-mellon (0.14.1-1) unstable; urgency=medium
 
   [ Thijs Kinkhorst ]
diff -Nru libapache2-mod-auth-mellon-0.14.1/mod_auth_mellon.c 
libapache2-mod-auth-mellon-0.14.2/mod_auth_mellon.c
--- libapache2-mod-auth-mellon-0.14.1/mod_auth_mellon.c 2018-01-18 
17:32:59.0 +
+++ libapache2-mod-auth-mellon-0.14.2/mod_auth_mellon.c 2019-03-20 
07:29:50.0 +
@@ -207,6 +207,12 @@
 
 static void register_hooks(apr_pool_t *p)
 {
+/* Our handler needs to run before mod_proxy so that it can properly
+ * return ECP AuthnRequest messages when running as a reverse proxy.
+ * See: https://github.com/Uninett/mod_auth_mellon/pull/196
+ */
+static const char * const run_handler_before[]={ "mod_proxy.c", NULL };
+
 ap_hook_access_checker(am_auth_mellon_user, NULL, NULL, APR_HOOK_MIDDLE);
 ap_hook_check_user_id(am_check_uid, NULL, NULL, APR_HOOK_MIDDLE);
 ap_hook_post_config(am_global_init, NULL, NULL, APR_HOOK_MIDDLE);
@@ -222,7 +228,7 @@
  * Therefore this hook must run before any handler that may check
  * r->handler and decide that it is the only handler for this URL.
  */
-ap_hook_handler(am_handler, NULL, NULL, APR_HOOK_FIRST);
+ap_hook_handler(am_handler, NULL, run_handler_before, APR_HOOK_FIRST);
 
 #ifdef ENABLE_DIAGNOSTICS
 ap_hook_open_logs(am_diag_log_init,NULL,NULL,APR_HOOK_MIDDLE);
diff -Nru libapache2-mod-auth-mellon-0.14.1/NEWS 
libapache2-mod-auth-mellon-0.14.2/NEWS
--- libapache2-mod-auth-mellon-0.14.1/NEWS  2019-02-11 07:26:04.0 
+
+++ libapache2-mod-auth-mellon-0.14.2/NEWS  2019-03-21 13:58:27.0 
+
@@ -1,3 +1,48 @@
+Version 0.14.2
+---
+
+Security fixes:
+
+* [CVE-2019-3878] Authentication bypass when Apache is used as a
+  reverse proxy
+
+  If Apache is configured as a reverse proxy with mod_auth_mellon for
+  authentication, the authentication can be bypassed by adding SAML
+  2.0 ECP headers to the request.
+
+  This vulnerability affects mod_auth_mellon 0.11.0 and newer.
+
+  This vulnerability is due to both mod_auth_mellon and mod_proxy
+  registering as handlers for the requests, with the same
+  priority. When mod_auth_mellon handles the request first, it will
+  trigger a ECP authentication request. If mod_proxy handles it first,
+  it will forward it to the backend server.
+
+  Which module handles it first depends on the order modules are
+  loaded by Apache.
+
+  This vulnerability is fixes by specifically registering that the
+  mod_auth_mellon handler should run before mod_proxy.
+
+  Thanks to Jakub Hrozek and John Dennis at RedHat for fixing this
+  vulnerability.
+
+* [CVE-2019-3877] Redirect URL validation bypass
+
+  Version 0.14.1 and older of mod_auth_mellon allows the redirect URL
+  validation to be bypassed by specifying an URL with backslashes
+  instead of forward slashes. Browsers silently convert backslashes to
+  forward slashes, which allows an attacker to bypass the redirect URL
+  validation by using `%5c` in the ReturnTo-parameter. E.g.:
+
+
https://sp.example.org/mellon/logout?ReturnTo=https:%5c%5cmalicious.example.org/
+
+  This version fixes that issue by rejecting all URLs with
+  backslashes.
+
+  Thanks to Eric Chamberland for discovering this vulnerability.
+
+
 Version 0.14.1
 ---
 


Bug#912607: rule for 0.0.0.0/8 is added as 0.0.0.0/0

2018-11-01 Thread Thijs Kinkhorst
Package: iptables
Version: 1.8.1-2
Severity: important

Hi,

With iptables in sid, When specifying a rule for "0.0.0.0/8", it gets
added to the ruleset as "0.0.0.0/0". This broke things at my
systems since the latter means "anywhere".

The problem can be reproduced as follows:

# iptables -A  OUTPUT -s 127.0.0.1 -d 0.0.0.0/8 -j DROP

The following rule is then added to the OUTPUT chain:

DROP   all  --  127.0.0.10.0.0.0/0   

Until recently, and also still in stretch, the same command
resulted in:

DROP   all  --  127.0.0.10.0.0.0/8   


Cheers,
Thijs

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages iptables depends on:
ii  libc62.27-8
ii  libip4tc01.8.1-2
ii  libip6tc01.8.1-2
ii  libiptc0 1.8.1-2
ii  libmnl0  1.0.4-2
ii  libnetfilter-conntrack3  1.0.7-1
ii  libnfnetlink01.0.1-3+b1
ii  libnftnl71.1.1-1
ii  libxtables12 1.8.1-2

iptables recommends no packages.

Versions of packages iptables suggests:
ii  kmod  25-1

-- no debconf information



Bug#827373: [Pkg-mailman-hackers] Bug#827373: mailman should use cron.{daily, weekly, monthly}, not cron.d

2018-06-23 Thread Thijs Kinkhorst
On Wed, June 15, 2016 14:32, Ian Jackson wrote:
> Package: mailman
> Version: 1:2.1.18-2
>
> In (at least some) previous versions of the Debian mailman package,
> the regular tasks were done by dropping files into /etc/cron.monthly/
> and so on.

This has not been the case since at least 2006, likely much longer.

> Now, this is done by creating a file /etc/cron.d/mailman.
>
> Using cron.{monthly,weekly,daily} has the following advantages:
>
>  * The timing of regular cron jobs can be adjusted once by the system
>administrator by adjusting the timing of the run-parts invocations.
>
>  * Regular cron jobs are (generally) scheduled sequentially with
>other cron jobs, avoiding multiple cron jobs at once (which can be
>confusing and perhaps even cause lossage)
>
>  * There is less of a problem with conffile edit conflicts, as there
>isn't a single schedule file (cron.d/mailman) which is constantly
>edited and updated.
>
> Please can you switch this back the way it was ?

I understand the suggestion, but it's not like I could just undo some
recent change. Since mailman 2 packaging is only in maintenance mode I
don't see it as very opportune to be changing this part of the packaging
which has been working this way for over 12 years.


Cheers,
Thijs



Bug#895482: Bug#895473: Bug#895482: Fails to upgrade: installed ca-certificates package post-installation script subprocess returned error exit status 4

2018-06-06 Thread Thijs Kinkhorst
On Wed, May 30, 2018 20:22, Michael Shuler wrote:
> On 05/30/2018 12:46 PM, Sebastian Andrzej Siewior wrote:
>>
>> I've read about this bug (and the other one) on d-devel. I uploaded
>> recently a new version of openssl to unstable (1.1.0h-3)which changes
>> the exit code of "openssl rehash" to zero in case of a duplicate or if a
>> certificate can no be open.
>> I left this bug open in case the maintainer of this package wants to
>> investigate why there are duplicates or non-existing certificates.
>
> Thanks for the update, Sebastian.
>
> OpenSSL commit for my own reference and for others, if interested:
> https://github.com/openssl/openssl/commit/e6a833cb97ed762408b57ea3efa83bd10c1d2a78

Given that this openssl update is now in testing, should we close or at
least downgrade this bug so ca-certificates can migrate?


Cheers,
Thijs



Bug#900620: RM: iprint -- ROM; dead, trivial, many alternatives

2018-06-02 Thread Thijs Kinkhorst
Package: ftp.debian.org
Severity: normal

Hi,

Please remove the following package from unstable:
iprint - Trivial command-line integer print utility

The package is indeed trivial and the functionality is available
in many other ways. The contents of the package have not been
updated or changed since 2006 and the packaging has been last
updated in 2012. Popcon is very low.

The cost of keeping it in the archive and maintaining it is
in the maintainer's opinion not offset by the offered functionality
and use.

Kind regards,
Thijs



Bug#900559: O: cpqarrayd -- monitoring tool for HP (Compaq) SmartArray controllers

2018-06-01 Thread Thijs Kinkhorst
Package: wnpp
Severity: normal

The cpqarrayd package has been orphaned.

Both current maintainers do not use it anymore.

It provides support for specific HP hardware array controllers.

The package description is:
 cpqarrayd is a userspace monitoring daemon for HP (Compaq) SmartArray
 hardware RAID controllers.  These controllers usually come built-in to
 ProLiant, or as a PCI card for ProLiant or Integrity systems. This
 daemon reports status changes in the disk array to syslog and,
 optionally, to a snmp trap host.
 .
 The default is to only log to the syslog. You can specify traphosts
 with the -t parameter at the commandline. Multiple traphosts are
 allowed.
 .
 This tool works with the SmartArray drivers found in Linux kernels
 (cciss and ida drivers).



Bug#900482: release-notes: add information about Mailman 3 and Mailman 2

2018-05-31 Thread Thijs Kinkhorst
Package: release-notes
Severity: normal
Tags: patch buster

Hi,

I'd like to add the following to the "package-specific-issues" section
in issues.dbk of the Buster release notes. It describes the new mailman3
package since buster and the expectations for the mailman 2.x release.

  
Mailman version 3 available, version 2.1 deprecated

  New in this release is the availability of version 3 of the Mailman
  mailing list manager suite. Mailman has been split up into various
  components; the core is available in the package
  mailman3 and the full
  suite can be obtained via the
  mailman3-full metapackage.


  The legacy Mailman version 2.1 remains available in this release
  in the package mailman,
  so you can migrate any existing installations at your own pace.
  The Mailman 2.1 package will be kept in working order for the
  foreseeable future, but will not see any major changes or
  improvements. It will be removed from the first Debian release
  after Mailman upstream has stopped support for this branch.


  Everyone is encouraged to upgrade to Mailman 3, the modern
  release under active development.

  


Cheers,
Thijs



signature.asc
Description: OpenPGP digital signature


Bug#893957: libapache2-mod-auth-mellon: Add mellon_create_metadata.sh to the package

2018-05-30 Thread Thijs Kinkhorst
tags 893957 upstream
forwarded 893957 https://github.com/UNINETT/mod_auth_mellon/pull/172
severity 893957 wishlist
thanks

Hi Philipp,

On Sat, March 24, 2018 14:04, Philipp Kolmann wrote:
> to create the certificate and the metadata for the Service Provider, there
> is a shell script that helps the user. It is in the main repo at:
>
> https://github.com/UNINETT/mod_auth_mellon/blob/master/mellon_create_metadata.sh
>
> Could you please also include this into this package.

Good idea. It's however not included in the upstream tarballs we base our
package on. I've sent Olav a patch to fix that; we can install it when
that's merged and a new release is made.


Cheers,
Thijs



Bug#858992: [Pkg-cas-maintainers] Bug#858992: libapache2-mod-auth-cas: Please migrate to openssl1.1 in buster

2018-05-30 Thread Thijs Kinkhorst
On Tue, May 29, 2018 23:08, Moritz Muehlenhoff wrote:
> On Sat, Oct 14, 2017 at 08:03:27AM +0200, Thijs Kinkhorst wrote:
>> Hi,
>>
>> On Thu, October 12, 2017 23:44, Sebastian Andrzej Siewior wrote:
>> > this is a remainder about the openssl transition [0]. We really want
>> to
>> > remove libssl1.0-dev from unstable for Buster. I will raise the
>> severity
>> > of this bug to serious in a month. Please react before that happens.
>>
>> Thanks, I'm aware but this is currently blocked by curl.
>
> FWIW, curl is now resolved.

I saw that and am working on an update.


Thijs



Bug#669813: tag with patch

2018-04-25 Thread Thijs Kinkhorst
On Wed, April 25, 2018 15:57, Geert Stappers wrote:
> Control: tag -1 patch
>
> Hi,
>
> FWIW I also needed the patch describe
> in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669813#41
>
> So now tagging this BR with 'patch'

This specific configuration change has been made since Stretch (1:2.1.20-1).

So I don't think this bug report should be tagged 'patch', as the original
wish is not satisfied (and likely will not be because focus is on
Mailman3).


Cheers,
Thijs



Bug#889637: [Pkg-mailman-hackers] Bug#889637: mailman: please make the build reproducible

2018-04-08 Thread Thijs Kinkhorst
On Sat, April 7, 2018 20:51, Uwe Kleine-König wrote:
> Hallo Thijs,
>
> On Wed, Feb 07, 2018 at 09:27:06AM +0100, Thijs Kinkhorst wrote:
>> On Mon, February 5, 2018 09:50, Chris Lamb wrote:
>> > Whilst working on the Reproducible Builds effort [0], we noticed
>> > that mailman could not be built reproducibly as it includes
>> > a time/timezone/locale-varying timestamp .
>>
>> Thanks! Applied and will be part of the next upload.
>
> I looked at mailman.git[1] to debug a problem I have with mailman and
> noticed that in commit edea5c2c8b9ac4d3616ed640a70d511ace26c6e5 you
> added "92_reproducible_build.patch" to debian/patches/series, but this
> file wasn't added. Obviously this makes the package FTBFS.

Thanks, pushed it now.


Thijs



Bug#891411: Acknowledgement (mailman critically (and unnecessarily) linked to apache2 (and not nginx))

2018-02-26 Thread Thijs Kinkhorst
On Sun, February 25, 2018 12:13, Luke Kenneth Casson Leighton wrote:
> apologies, after downloading the source i noted that the debian/rules
> file lists several HTTP servers, and that apache2 is the "default if
> none are installed".
>
> i actually *had* nginx installed... but because of the difficulties
> associated with compiling nginx modules on debian had been forced to
> install nginx purely from source in /usr/local and *remove* the nginx
> debian package.  i've installed lighthttpd, disabled it, and thus
> "worked around" the "problem".

Maybe for a next time, you can use the "equivs" package if you want to
simulate that something is installed.


Cheers,
Thijs



Bug#889637: [Pkg-mailman-hackers] Bug#889637: mailman: please make the build reproducible

2018-02-07 Thread Thijs Kinkhorst
On Mon, February 5, 2018 09:50, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0], we noticed
> that mailman could not be built reproducibly as it includes
> a time/timezone/locale-varying timestamp .

Thanks! Applied and will be part of the next upload.


Cheers,
Thijs



Bug#888201: mailman: CVE-2018-5950

2018-02-01 Thread Thijs Kinkhorst
>> I plan to release Mailman 2.1.26 along with a patch for older releases
>> to fix this issue on Feb 4, 2018. At that time, full details of the
>> vulnerability will be public.

I've reserved time on Sunday to in any case to sid when the fix is
released, and depending on the details/severity look into a security
upload.


Thijs



Bug#867461: Bug#858539: should ca-certificates certdata.txt synchronize across all suites?

2018-01-12 Thread Thijs Kinkhorst
On Fri, January 12, 2018 10:24, Raphael Hertzog wrote:
> Hi,
>
> On Tue, 09 Jan 2018, Brian May wrote:
>> Raphael Hertzog  writes:
>>
>> > I think this mail went through the cracks as we haven't received a
>> reply
>> > from you so far. Can you let us know the status and whether we can
>> help to
>> > get the wheezy update out ?
>>
>> Hello Debian-LTS team:
>>
>> As we are lacking any response (yet) from Michael Shuler, I am wondering
>> if we should go ahead and upload the wheezy version anyway?
>
> Yes, please. I saw reports of failures on IRC due to missing CA
> certificates.

As co-maintainer of ca-certificates you have my ok for this change in
wheezy, indeed a good idea.


Cheers,
Thijs



Bug#865588: [Python-modules-team] Bug#865588: djangorestframework FTBFS with Django 1.11: ERROR collecting tests/test_fields.py

2018-01-09 Thread Thijs Kinkhorst
Hi Brian,

> Currently getting this error building the latest version - as in the
> Debian git package.
>
> Possibly this is because we depend on a package that needs updating -
> mostly likely mkdocs or jinja2 - but wonder which one?  Maybe we should
> just update both anyway.

We're half a year on, so has this now changed? (I tried to check out the
git repo and build it, but that had several problems so I might be missing
one or two pieces to quickly verify it).


Cheers,
Thijs



Bug#761032: pending

2018-01-07 Thread Thijs Kinkhorst
On Sun, January 7, 2018 13:36, Thijs Kinkhorst wrote:
> On Sun, January 7, 2018 13:25, Rene Engelhard wrote:
>> Hi,
>>
>> On Sun, Jan 07, 2018 at 01:18:17PM +0100, Thijs Kinkhorst wrote:
>>> On Sun, January 7, 2018 12:36, Rene Engelhard wrote:
>>> > since this is now on salsa in the Debian group (aka collab-maint) I
>>> went
>>> > forward and did
>>> >
>>> > https://salsa.debian.org/debian/dutch/commit/2d67054bebd5324eafb2ff24f56ad63d8e0de99d
>>>
>>> Great! That was actually my next step :-)
>>
>> Ah, sorry for stepping on your toes then, thought it was "just" a import
>> for now...
>
> No toes stepped, just work saved :-)
>
>>> Can this just be uploaded or is co-ordination with LO upload required?
>>
>> libreoffice-dictionaries needs to disable building hunspell-nl but that
>> can be done anytime later. Actually I alraedy did
>> https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice-dictionaries/commit/95160dd380bed9154a78b4334917aeb54c9ae869,
>> too :)
>>
>> So you can just upload.
>
> One final thing: hunspell-nl at libreoffice is now at version 1:5.4.3-1
> and dutch is at 1:2.10-6, so we probably need to bump our epoch to 2 to
> ensure people actually upgrade their packages, right? Not that I see any
> problem with that - it's just a number.

I see you already did that in your commit for just the hunspell package.
Good.

Thijs



Bug#761032: pending

2018-01-07 Thread Thijs Kinkhorst
On Sun, January 7, 2018 13:25, Rene Engelhard wrote:
> Hi,
>
> On Sun, Jan 07, 2018 at 01:18:17PM +0100, Thijs Kinkhorst wrote:
>> On Sun, January 7, 2018 12:36, Rene Engelhard wrote:
>> > since this is now on salsa in the Debian group (aka collab-maint) I
>> went
>> > forward and did
>> >
>> > https://salsa.debian.org/debian/dutch/commit/2d67054bebd5324eafb2ff24f56ad63d8e0de99d
>>
>> Great! That was actually my next step :-)
>
> Ah, sorry for stepping on your toes then, thought it was "just" a import
> for now...

No toes stepped, just work saved :-)

>> Can this just be uploaded or is co-ordination with LO upload required?
>
> libreoffice-dictionaries needs to disable building hunspell-nl but that
> can be done anytime later. Actually I alraedy did
> https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice-dictionaries/commit/95160dd380bed9154a78b4334917aeb54c9ae869,
> too :)
>
> So you can just upload.

One final thing: hunspell-nl at libreoffice is now at version 1:5.4.3-1
and dutch is at 1:2.10-6, so we probably need to bump our epoch to 2 to
ensure people actually upgrade their packages, right? Not that I see any
problem with that - it's just a number.


Cheers,
Thijs



Bug#761032: pending

2018-01-07 Thread Thijs Kinkhorst
Hi Rene,

On Sun, January 7, 2018 12:36, Rene Engelhard wrote:
> since this is now on salsa in the Debian group (aka collab-maint) I went
> forward and did
>
> https://salsa.debian.org/debian/dutch/commit/2d67054bebd5324eafb2ff24f56ad63d8e0de99d

Great! That was actually my next step :-)

Can this just be uploaded or is co-ordination with LO upload required?


Cheers,
Thijs



Bug#858992: [Pkg-cas-maintainers] Bug#858992: libapache2-mod-auth-cas: Please migrate to openssl1.1 in buster

2017-10-14 Thread Thijs Kinkhorst
Hi,

On Thu, October 12, 2017 23:44, Sebastian Andrzej Siewior wrote:
> this is a remainder about the openssl transition [0]. We really want to
> remove libssl1.0-dev from unstable for Buster. I will raise the severity
> of this bug to serious in a month. Please react before that happens.

Thanks, I'm aware but this is currently blocked by curl.


Thijs



Bug#875765: stretch-pu: package mailman/1:2.1.23-1+deb9u1

2017-09-14 Thread Thijs Kinkhorst
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi,

It was discovered that the SpamAssassin integration in Mailman (a Debian
specific piece of code) does not work in stretch. This is not enabled by
default but used often, and broke existing Mailman setups.

Attached patch rectifies the problem as confirmed by several users in
the bug reports. It is also in unstable and testing for a week without
reports of problems.

So please accept this stable update to fix this functionality.


Thanks,
Thijs
diff -Nru mailman-2.1.23/debian/changelog mailman-2.1.23/debian/changelog
--- mailman-2.1.23/debian/changelog 2016-09-13 18:01:59.0 +0200
+++ mailman-2.1.23/debian/changelog 2017-09-14 12:23:04.0 +0200
@@ -1,3 +1,10 @@
+mailman (1:2.1.23-1+deb9u1) stretch; urgency=medium
+
+  * Fixed broken dependencies in SpamAssassin.py (Closes: #838288).   
+Thanks Stephen Rothwell for the patch.
+
+ -- Thijs Kinkhorst <th...@debian.org>  Thu, 14 Sep 2017 12:23:04 +0200
+
 mailman (1:2.1.23-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru mailman-2.1.23/debian/contrib/SpamAssassin.py 
mailman-2.1.23/debian/contrib/SpamAssassin.py
--- mailman-2.1.23/debian/contrib/SpamAssassin.py   2016-09-13 
18:01:59.0 +0200
+++ mailman-2.1.23/debian/contrib/SpamAssassin.py   2017-09-14 
09:49:35.0 +0200
@@ -28,7 +28,6 @@
 from Mailman import Errors
 from Mailman.Logging.Syslog import syslog
 from Mailman.Handlers import Hold
-from Mailman.Handlers.Moderate import matches_p
 
 SPAMD_HOST= getattr(mm_cfg, 'SPAMASSASSIN_HOST', '')
 DISCARD_SCORE = getattr(mm_cfg, 'SPAMASSASSIN_DISCARD_SCORE', 10)
@@ -78,7 +77,7 @@
 if MEMBER_BONUS != 0:
 for sender in msg.get_senders():
 if mlist.isMember(sender) or \
-   matches_p(sender, mlist.accept_these_nonmembers, 
mlist.internal_name()):
+   mlist.GetPattern(sender, mlist.accept_these_nonmembers, 
at_list='accept_these_nonmembers'):
 score -= MEMBER_BONUS
 break
 


Bug#875427: [Pkg-mailman-hackers] Bug#875427: ITP: mailman3-django -- A common django base of tools for Mailman3's frontends Postorius and HyperKitty

2017-09-12 Thread Thijs Kinkhorst
On Mon, September 11, 2017 18:24, Pierre-Elliott Bécue wrote:
> Well, I asked on pkg-mailman-hackers to be added to the project on alioth
> one month ago, and for now I didn't get any answer. Would you accept to
> add me on it and maybe give me administration ACLs so I can add other
> developers that are interested in?

Sure. I added you as admin. Sorry for overlooking the initial request.


Cheers,
Thijs



Bug#875427: [Pkg-mailman-hackers] Bug#875427: ITP: mailman3-django -- A common django base of tools for Mailman3's frontends Postorius and HyperKitty

2017-09-11 Thread Thijs Kinkhorst
On Mon, September 11, 2017 12:10, Pierre-Elliott Bécue wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Pierre-Elliott Bécue 
>
> * Package name: mailman3-django
>   Version : 1.1.0
>   Upstream Author : Aurélien Bompard 
> * URL : http://list.org/
> * License : GPLv3
>   Programming Lang: Python
>   Description : A common django base of tools for Mailman3's frontends
> Postorius and HyperKitty
>
> This package contains libraries and templates for Django-based
> interfaces interacting with Mailman. In particular, it provides a common
> base for Postorius and HyperKitty to work.
>
> --
>
> This package is a necessary dependency to close bugs #799287 and
> #799285.
>
> I'm working on these packages with Mattia Rizzolo (mattia), Barry Warsaw
> (barry), and quite recently, Jonas Meurer (mejo) offered his help.

I might also be able to help.

I'm currently the only one doing any work on the mailman (2) package. My
intent is to keep it working (maintenance mode). If buster would contain a
mailman3 package, they can perhaps co-exist for one release. And we might
be able to remove mailman 2 the release after that.

Let me know if you need anything.


Cheers,
Thijs



Bug#874670: RM: ttytter -- ROM; abandoned upstream, alternatives exist

2017-09-08 Thread Thijs Kinkhorst
Package: ftp.debian.org
Severity: normal

Hi,

Please remove ttytter from unstable.

Upstream has abandoned the project and it is now unmaintained.
An alternative is now in Debian, oystter. It is not a drop-in
replacement so it does not Replace the old package.


Thanks,
Thijs



Bug#838288: [Pkg-mailman-hackers] Bug#838288: mailman: diff for NMU version 1:2.1.23-1.1

2017-09-05 Thread Thijs Kinkhorst
Hi all,

On Sat, September 2, 2017 18:10, fl...@florz.net wrote:
> Control: tags 838288 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for mailman (versioned as 1:2.1.23-1.1) and
> uploaded it to DELAYED/14. Please feel free to tell me if I
> should delay it longer.

Thanks for the help. I've merged this, together with a new upstream
release and uploaded to unstable.


Cheers,
Thijs



Bug#873505: [Pkg-mailman-hackers] Bug#873505: Acknowledgement (mailman: Runner crashes when processing incoming email)

2017-09-05 Thread Thijs Kinkhorst
forcemerge 838288 873505
thanks

On Wed, August 30, 2017 00:58, Pete Donnell wrote:
> Apologies, turns out that this is a duplicate of
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838288
>
> Applying the patch included there fixed it.

Thanks for the extra confirmation.

I've uploaded a fixed version to unstable, when that yields no problems
I'll prepare a stable update.


Cheers,
Thijs



Bug#761032: hunspell-nl

2017-08-31 Thread Thijs Kinkhorst
On Wed, August 30, 2017 21:54, Kurt Roeckx wrote:
> It seems that libreoffice-dictionaries started shipping an
> hunspell-nl package at some point and it's actually providing an
> older version of the dictionaries.
>
> I've talked to Rene about this, and he agreed we could take over
> this package.
>
> Anyway, the files we ship now require hunspell 1.3.1, so it should
> have been renamed ages ago.
>
> Thijs, do you have time to do this?

Not in the short term. Probably do sometime before testing becomes stable.


Cheers,
Thijs



Bug#818968: Long live Oysttyer

2017-08-29 Thread Thijs Kinkhorst
Hi Thorsten,

On Sat, August 26, 2017 16:44, Thorsten Alteholz wrote:
> Hi,
>
> I just wanted to tell everybody that oysttyer just entered unstable.
>
>   Thorsten

Thanks!

Do you think it would be useful if oysttyer would also provide a
transitional package ttytter, or should we remove ttytter wholesale now?


Cheers,
Thijs



Bug#867267: O: ttytter

2017-07-05 Thread Thijs Kinkhorst
Package: wnpp
Severity: normal

I no longer have an interest in maintaining TTYtter.

Anyone taking over this package should probably migrate it to the
active upstream Oystttyer, see #818968


Cheers,
Thijs



Bug#818968: ttytter: TTYtter is dead. Long live Oysttyer.

2017-07-05 Thread Thijs Kinkhorst
severity 818968 serious
thanks

On Tue, March 22, 2016 13:32, Cord Beermann wrote:
> Looks like ttytter has been abandoned. [1]
> But there is an endorsed replacement: Oysttyer [2]

I no longer have an interest in maintaining ttytter, so I'm orphaning the
package.

Of course I hope someone will pick this package up and migrate it to
Oysttyer. However, in the unfortunate event that that should not happen, I
believe it's not right to ship buster with TTYtter in current form. So to
ensure this does not happen I'm raising to this to serious.


Cheers,
Thijs



Bug#857712: unblock: libapache2-mod-auth-mellon/0.12.0-2

2017-03-14 Thread Thijs Kinkhorst
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package libapache2-mod-auth-mellon.

It fixes two security issues:
- Fix a denial of service attack in the logout handler.
- Fix a cross-site session transfer vulnerability
  [CVE-2017-6807].

unblock libapache2-mod-auth-mellon/0.12.0-2

Thanks,
Thijs
diff -Nru libapache2-mod-auth-mellon-0.12.0/debian/changelog 
libapache2-mod-auth-mellon-0.12.0/debian/changelog
--- libapache2-mod-auth-mellon-0.12.0/debian/changelog  2016-03-09 
10:14:01.0 +
+++ libapache2-mod-auth-mellon-0.12.0/debian/changelog  2017-03-13 
13:06:19.0 +
@@ -1,3 +1,11 @@
+libapache2-mod-auth-mellon (0.12.0-2) unstable; urgency=high
+
+  * Backport upstream patches for security issues:
+- Fix a denial of service attack in the logout handler.
+- Fix a cross-site session transfer vulnerability [CVE-2017-6807]. 
+
+ -- Thijs Kinkhorst <th...@debian.org>  Mon, 13 Mar 2017 13:06:19 +
+
 libapache2-mod-auth-mellon (0.12.0-1) unstable; urgency=high
 
   * New upstream release.
diff -Nru 
libapache2-mod-auth-mellon-0.12.0/debian/patches/01_logout_segfault.patch 
libapache2-mod-auth-mellon-0.12.0/debian/patches/01_logout_segfault.patch
--- libapache2-mod-auth-mellon-0.12.0/debian/patches/01_logout_segfault.patch   
1970-01-01 00:00:00.0 +
+++ libapache2-mod-auth-mellon-0.12.0/debian/patches/01_logout_segfault.patch   
2017-03-13 13:06:19.0 +
@@ -0,0 +1,39 @@
+From 6bdda9170a8f1757dabc5b109958657417728018 Mon Sep 17 00:00:00 2001
+From: Olav Morken <olav.mor...@uninett.no>
+Date: Tue, 24 May 2016 10:29:38 +0200
+Subject: [PATCH] Fix segmentation fault when receiving badly formed logout
+ message.
+
+If the logout message is badly formed, we won't get the entityID in
+`logout->parent.remote_providerID`. If we call `apr_hash_get()` with a
+null pointer, it will cause a segmentation fault.
+
+Add a check to validate that the entityID is correctly set.
+---
+ auth_mellon_handler.c | 6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/auth_mellon_handler.c b/auth_mellon_handler.c
+index ffc7ff7..748ec45 100644
+--- a/auth_mellon_handler.c
 b/auth_mellon_handler.c
+@@ -678,7 +678,8 @@ static int am_handle_logout_request(request_rec *r,
+ /* Process the logout message. Ignore missing signature. */
+ res = lasso_logout_process_request_msg(logout, msg);
+ #ifdef HAVE_lasso_profile_set_signature_verify_hint
+-if(res != 0 && res != LASSO_DS_ERROR_SIGNATURE_NOT_FOUND) {
++if(res != 0 && res != LASSO_DS_ERROR_SIGNATURE_NOT_FOUND &&
++   logout->parent.remote_providerID != NULL) {
+ if (apr_hash_get(cfg->do_not_verify_logout_signature,
+  logout->parent.remote_providerID,
+  APR_HASH_KEY_STRING)) {
+@@ -787,7 +788,8 @@ static int am_handle_logout_response(request_rec *r, 
LassoLogout *logout)
+ 
+ res = lasso_logout_process_response_msg(logout, r->args);
+ #ifdef HAVE_lasso_profile_set_signature_verify_hint
+-if(res != 0 && res != LASSO_DS_ERROR_SIGNATURE_NOT_FOUND) {
++if(res != 0 && res != LASSO_DS_ERROR_SIGNATURE_NOT_FOUND &&
++   logout->parent.remote_providerID != NULL) {
+ if (apr_hash_get(cfg->do_not_verify_logout_signature,
+  logout->parent.remote_providerID,
+  APR_HASH_KEY_STRING)) {
diff -Nru 
libapache2-mod-auth-mellon-0.12.0/debian/patches/02_session_transfer_vulnerability_CVE-2017-6807.patch
 
libapache2-mod-auth-mellon-0.12.0/debian/patches/02_session_transfer_vulnerability_CVE-2017-6807.patch
--- 
libapache2-mod-auth-mellon-0.12.0/debian/patches/02_session_transfer_vulnerability_CVE-2017-6807.patch
  1970-01-01 00:00:00.0 +
+++ 
libapache2-mod-auth-mellon-0.12.0/debian/patches/02_session_transfer_vulnerability_CVE-2017-6807.patch
  2017-03-13 13:06:19.0 +
@@ -0,0 +1,218 @@
+From 7af21c53da7bb1de024274ee6da30bc22316a079 Mon Sep 17 00:00:00 2001
+From: Olav Morken <olav.mor...@uninett.no>
+Date: Mon, 13 Mar 2017 09:55:48 +0100
+Subject: [PATCH] Fix Cross-Site Session Transfer vulnerability
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+mod_auth_mellon did not verify that the site the session was created
+for was the same site as the site the user accessed. This allows an
+attacker with access to one web site on a server to use the same
+session to get access to a different site running on the same server.
+
+This patch fixes this vulnerability by storing the cookie parameters
+used when creating the session in the session, and verifying those
+parameters when the session is loaded.
+
+Thanks to François Kooman for reporting this vulnerability.
+
+This vulnerability has been assigned CVE-2017-6807.
+---
+ NEWS   

Bug#850515: RM: squirrelmail/experimental -- ROM; removed from sid

2017-01-07 Thread Thijs Kinkhorst
Package: ftp.debian.org
Severity: normal

Hi,

Please remove squirrelmail from experimental.

The package has been removed from sid as per #846069.
The version in experimental is nearly 10 years old.


Thanks,
Thijs



Bug#849626: Patch for 5.4.2-1.1 NMU

2017-01-04 Thread Thijs Kinkhorst
Hi,

I've taken the liberty to fix this security issue in an NMU to sid.
Attached is the debdiff.


Cheers,
Thijs
diff -Nru libphp-swiftmailer-5.4.2/debian/changelog libphp-swiftmailer-5.4.2/debian/changelog
--- libphp-swiftmailer-5.4.2/debian/changelog	2016-06-10 14:26:56.0 +
+++ libphp-swiftmailer-5.4.2/debian/changelog	2017-01-04 16:31:03.0 +
@@ -1,3 +1,11 @@
+libphp-swiftmailer (5.4.2-1.1) unstable; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * Fix CVE-2016-10074: Remote Code Execution by applying patch
+e6ccf40d from upstream (Closes: #849626).
+
+ -- Thijs Kinkhorst <th...@debian.org>  Wed, 04 Jan 2017 16:31:03 +
+
 libphp-swiftmailer (5.4.2-1) unstable; urgency=medium
 
   * Imported Upstream version 5.4.2
diff -Nru libphp-swiftmailer-5.4.2/debian/patches/0001-fix-CVE-2016-10074.patch libphp-swiftmailer-5.4.2/debian/patches/0001-fix-CVE-2016-10074.patch
--- libphp-swiftmailer-5.4.2/debian/patches/0001-fix-CVE-2016-10074.patch	1970-01-01 00:00:00.0 +
+++ libphp-swiftmailer-5.4.2/debian/patches/0001-fix-CVE-2016-10074.patch	2017-01-04 16:31:03.0 +
@@ -0,0 +1,53 @@
+diff -Nur libphp-swiftmailer-5.4.2.orig/lib/classes/Swift/Transport/MailTransport.php libphp-swiftmailer-5.4.2/lib/classes/Swift/Transport/MailTransport.php
+--- libphp-swiftmailer-5.4.2.orig/lib/classes/Swift/Transport/MailTransport.php	2016-05-01 08:45:47.0 +
 libphp-swiftmailer-5.4.2/lib/classes/Swift/Transport/MailTransport.php	2017-01-04 15:53:43.400445794 +
+@@ -237,6 +237,36 @@
+ }
+ 
+ /**
++ * Fix CVE-2016-10074 by disallowing potentially unsafe shell characters.
++ *
++ * Note that escapeshellarg and escapeshellcmd are inadequate for our purposes, especially on Windows.
++ *
++ * @param string $string The string to be validated
++ *
++ * @return bool
++ */
++private function _isShellSafe($string)
++{
++// Future-proof
++if (escapeshellcmd($string) !== $string || !in_array(escapeshellarg($string), array("'$string'", "\"$string\""))) {
++return false;
++}
++
++$length = strlen($string);
++for ($i = 0; $i < $length; ++$i) {
++$c = $string[$i];
++// All other characters have a special meaning in at least one common shell, including = and +.
++// Full stop (.) has a special meaning in cmd.exe, but its impact should be negligible here.
++// Note that this does permit non-Latin alphanumeric characters based on the current locale.
++if (!ctype_alnum($c) && strpos('@_-.', $c) === false) {
++return false;
++}
++}
++
++return true;
++}
++
++/**
+  * Return php mail extra params to use for invoker->mail.
+  *
+  * @param $extraParams
+@@ -247,7 +277,11 @@
+ private function _formatExtraParams($extraParams, $reversePath)
+ {
+ if (false !== strpos($extraParams, '-f%s')) {
+-$extraParams = empty($reversePath) ? str_replace('-f%s', '', $extraParams) : sprintf($extraParams, escapeshellarg($reversePath));
++if (empty($reversePath) || false === $this->_isShellSafe($reversePath)) {
++$extraParams = str_replace('-f%s', '', $extraParams);
++} else {
++$extraParams = sprintf($extraParams, $reversePath);
++}
+ }
+ 
+ return !empty($extraParams) ? $extraParams : null;
diff -Nru libphp-swiftmailer-5.4.2/debian/patches/series libphp-swiftmailer-5.4.2/debian/patches/series
--- libphp-swiftmailer-5.4.2/debian/patches/series	1970-01-01 00:00:00.0 +
+++ libphp-swiftmailer-5.4.2/debian/patches/series	2017-01-04 16:31:03.0 +
@@ -0,0 +1 @@
+0001-fix-CVE-2016-10074.patch


signature.asc
Description: OpenPGP digital signature


Bug#849365: Additional NMU for phpmailer 5.2.14+dfsg-2.2

2017-01-02 Thread Thijs Kinkhorst
Hi,

In one of my environment a regression surfaced. If using specifically
the isSendmail() method and the default php.ini sendmail settings, you
would get an error.

This was fixed upstream but the backport lacked that specific commit.
I've made another NMU to rectify that.


Cheers,
Thijs
diff -Nru libphp-phpmailer-5.2.14+dfsg/debian/changelog libphp-phpmailer-5.2.14+dfsg/debian/changelog
--- libphp-phpmailer-5.2.14+dfsg/debian/changelog	2016-12-30 12:22:28.0 +0100
+++ libphp-phpmailer-5.2.14+dfsg/debian/changelog	2017-01-02 15:21:27.0 +0100
@@ -1,3 +1,11 @@
+libphp-phpmailer (5.2.14+dfsg-2.2) unstable; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * Fix regression in previous update: remove check for
+Sendmail binary, upstream commit ed4e7ce8.
+
+ -- Thijs Kinkhorst <th...@debian.org>  Mon, 02 Jan 2017 14:21:27 +
+
 libphp-phpmailer (5.2.14+dfsg-2.1) unstable; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru libphp-phpmailer-5.2.14+dfsg/debian/patches/0002-Fix-CVE-2016-10033-CVE-2016-10045.patch libphp-phpmailer-5.2.14+dfsg/debian/patches/0002-Fix-CVE-2016-10033-CVE-2016-10045.patch
--- libphp-phpmailer-5.2.14+dfsg/debian/patches/0002-Fix-CVE-2016-10033-CVE-2016-10045.patch	2016-12-30 12:22:28.0 +0100
+++ libphp-phpmailer-5.2.14+dfsg/debian/patches/0002-Fix-CVE-2016-10033-CVE-2016-10045.patch	2017-01-02 15:21:25.0 +0100
@@ -1,22 +1,11 @@
 diff -Nur libphp-phpmailer-5.2.14+dfsg.orig/class.phpmailer.php libphp-phpmailer-5.2.14+dfsg.new/class.phpmailer.php
 --- libphp-phpmailer-5.2.14+dfsg.orig/class.phpmailer.php	2015-11-01 10:15:28.0 +
-+++ libphp-phpmailer-5.2.14+dfsg.new/class.phpmailer.php	2016-12-30 11:20:08.368756474 +
-@@ -164,6 +164,7 @@
- 
- /**
-  * The path to the sendmail program.
-+ * Must contain only a path to an executable, with no parameters or switches
-  * @var string
-  */
- public $Sendmail = '/usr/sbin/sendmail';
-@@ -1329,19 +1330,27 @@
 libphp-phpmailer-5.2.14+dfsg.new/class.phpmailer.php	2017-01-02 14:20:47.484824213 +
+@@ -1329,19 +1329,24 @@
   */
  protected function sendmailSend($header, $body)
  {
 -if ($this->Sender != '') {
-+if (!(is_file($this->Sendmail) and is_executable($this->Sendmail))) {
-+throw new phpmailerException($this->lang('execute') . $this->Sendmail, self::STOP_CRITICAL);
-+}
 +// CVE-2016-10033, CVE-2016-10045: Don't pass -f if characters will be escaped.
 +if (!empty($this->Sender) and self::isShellSafe($this->Sender)) {
  if ($this->Mailer == 'qmail') {
@@ -42,7 +31,7 @@
  if ($this->SingleTo) {
  foreach ($this->SingleToArray as $toAddr) {
  if (!@$mail = popen($sendmail, 'w')) {
-@@ -1388,6 +1397,38 @@
+@@ -1388,6 +1393,38 @@
  }
  
  /**
@@ -81,7 +70,7 @@
   * Send mail using the PHP mail() function.
   * @param string $header The message headers
   * @param string $body The message body
-@@ -1404,12 +1445,14 @@
+@@ -1404,12 +1441,14 @@
  }
  $to = implode(', ', $toArr);
  
@@ -101,7 +90,7 @@
  $old_from = ini_get('sendmail_from');
  ini_set('sendmail_from', $this->Sender);
  }
-@@ -1463,10 +1506,10 @@
+@@ -1463,10 +1502,10 @@
  if (!$this->smtpConnect($this->SMTPOptions)) {
  throw new phpmailerException($this->lang('smtp_connect_failed'), self::STOP_CRITICAL);
  }


signature.asc
Description: OpenPGP digital signature


Bug#849365: Patch for NMU 5.2.14+dfsg-2.1

2016-12-30 Thread Thijs Kinkhorst
Hi,

On behalf of the Security Team I've taken the liberty to upload to
unstable a fix for CVE-2016-10033. The debdiff is attached.


Cheers,
Thijs
diff -Nru libphp-phpmailer-5.2.14+dfsg/debian/changelog libphp-phpmailer-5.2.14+dfsg/debian/changelog
--- libphp-phpmailer-5.2.14+dfsg/debian/changelog	2016-03-05 15:06:02.0 +
+++ libphp-phpmailer-5.2.14+dfsg/debian/changelog	2016-12-30 11:22:28.0 +
@@ -1,3 +1,11 @@
+libphp-phpmailer (5.2.14+dfsg-2.1) unstable; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * Fix CVE-2016-10033 (and CVE-2016-10045): apply commits
+4835657c 9743ff5c 833c35fe from upstream. Closes: #849365.
+
+ -- Thijs Kinkhorst <th...@debian.org>  Fri, 30 Dec 2016 11:22:28 +
+
 libphp-phpmailer (5.2.14+dfsg-2) unstable; urgency=medium
 
   * Team upload
diff -Nru libphp-phpmailer-5.2.14+dfsg/debian/patches/0002-Fix-CVE-2016-10033-CVE-2016-10045.patch libphp-phpmailer-5.2.14+dfsg/debian/patches/0002-Fix-CVE-2016-10033-CVE-2016-10045.patch
--- libphp-phpmailer-5.2.14+dfsg/debian/patches/0002-Fix-CVE-2016-10033-CVE-2016-10045.patch	1970-01-01 00:00:00.0 +
+++ libphp-phpmailer-5.2.14+dfsg/debian/patches/0002-Fix-CVE-2016-10033-CVE-2016-10045.patch	2016-12-30 11:22:28.0 +
@@ -0,0 +1,117 @@
+diff -Nur libphp-phpmailer-5.2.14+dfsg.orig/class.phpmailer.php libphp-phpmailer-5.2.14+dfsg.new/class.phpmailer.php
+--- libphp-phpmailer-5.2.14+dfsg.orig/class.phpmailer.php	2015-11-01 10:15:28.0 +
 libphp-phpmailer-5.2.14+dfsg.new/class.phpmailer.php	2016-12-30 11:20:08.368756474 +
+@@ -164,6 +164,7 @@
+ 
+ /**
+  * The path to the sendmail program.
++ * Must contain only a path to an executable, with no parameters or switches
+  * @var string
+  */
+ public $Sendmail = '/usr/sbin/sendmail';
+@@ -1329,19 +1330,27 @@
+  */
+ protected function sendmailSend($header, $body)
+ {
+-if ($this->Sender != '') {
++if (!(is_file($this->Sendmail) and is_executable($this->Sendmail))) {
++throw new phpmailerException($this->lang('execute') . $this->Sendmail, self::STOP_CRITICAL);
++}
++// CVE-2016-10033, CVE-2016-10045: Don't pass -f if characters will be escaped.
++if (!empty($this->Sender) and self::isShellSafe($this->Sender)) {
+ if ($this->Mailer == 'qmail') {
+-$sendmail = sprintf('%s -f%s', escapeshellcmd($this->Sendmail), escapeshellarg($this->Sender));
++$sendmailFmt = '%s -f%s';
+ } else {
+-$sendmail = sprintf('%s -oi -f%s -t', escapeshellcmd($this->Sendmail), escapeshellarg($this->Sender));
++$sendmailFmt = '%s -oi -f%s -t';
+ }
+ } else {
+ if ($this->Mailer == 'qmail') {
+-$sendmail = sprintf('%s', escapeshellcmd($this->Sendmail));
++$sendmailFmt = '%s';
+ } else {
+-$sendmail = sprintf('%s -oi -t', escapeshellcmd($this->Sendmail));
++$sendmailFmt = '%s -oi -t';
+ }
+ }
++
++// TODO: If possible, this should be changed to escapeshellarg.  Needs thorough testing.
++$sendmail = sprintf($sendmailFmt, escapeshellcmd($this->Sendmail), $this->Sender);
++
+ if ($this->SingleTo) {
+ foreach ($this->SingleToArray as $toAddr) {
+ if (!@$mail = popen($sendmail, 'w')) {
+@@ -1388,6 +1397,38 @@
+ }
+ 
+ /**
++ * Fix CVE-2016-10033 and CVE-2016-10045 by disallowing potentially unsafe shell characters.
++ *
++ * Note that escapeshellarg and escapeshellcmd are inadequate for our purposes, especially on Windows.
++ * @param string $string The string to be validated
++ * @see https://github.com/PHPMailer/PHPMailer/issues/924 CVE-2016-10045 bug report
++ * @access protected
++ * @return boolean
++ */
++protected static function isShellSafe($string)
++{
++// Future-proof
++if (escapeshellcmd($string) !== $string or !in_array(escapeshellarg($string), array("'$string'", "\"$string\""))) {
++return false;
++}
++
++$length = strlen($string);
++
++for ($i = 0; $i < $length; $i++) {
++$c = $string[$i];
++
++// All other characters have a special meaning in at least one common shell, including = and +.
++// Full stop (.) has a special meaning in cmd.exe, but its impact should be negligible here.
++// Note that this does permit non-Latin alphanumeric characters based on the current locale.
++if (!ctype_alnum($c) && strpos('@_-.', $c) === false) {
++return false;
++}
++}
++
++return true;
++}
++
++/**
+  * Send mail using the PHP mail() function.
+  * @para

Bug#846069: RM: squirrelmail -- RoQA; RC-buggy; little upstream activity

2016-11-30 Thread Thijs Kinkhorst
On Mon, November 28, 2016 15:19, Scott Kitterman wrote:
> On Monday, November 28, 2016 02:45:29 PM Ondřej Surý wrote:
>> according to the upstream, the SVN snapshot is supposed to support PHP
>> 7.0, but it seems to be untested even by upstream (well, that's what I
>> am reading on the mailing list). One way or another, I agree with Thijs
>> that random SVN snapshot isn't really suited to be supported for next
>> stable cycle.
>>
>> Also I would like you to know that I am trying to properly investigate
>> all the options before filling RM bugs. So far the most common case is:
>> "last release in ~2011-2014 - added support for PHP 5.4/5.5" :(.
>
> Certainly.  I'm not at all meaning to call in to question your efforts.
> In this particular case it was pointed out to me that the maintainer had
> recently expressed a preference for keeping squirrelmail in unstable.
> While I don't think that's very sustainable, I'd prefer to get agreement
> where a php5 rdepend maintainer has expressed a preference.

As the maintainer you have my OK to remove squirrelmail from unstable.


Cheers,
Thijs



Bug#844240: Intent to not ship squirrelmail with stretch

2016-11-30 Thread Thijs Kinkhorst
On Mon, November 28, 2016 13:56, Scott Kitterman wrote:
> On Sun, 13 Nov 2016 18:31:48 +0100 Thijs Kinkhorst <th...@debian.org>
> wrote:
>> Package: squirrelmail
>> Severity: serious
>>
>> SquirrelMail has been missing from Stretch for a while now and I intend
>> to leave it that way. This bug is to document this explicit choice (and
>> room for any concerns).
>>
>> Upstream (of which I'm, at least on paper) part, has not made any new
>> release of SquirrelMail since 2011. There is some activity in commits
>> being done, but these do not result in releases.
>>
>> I've tried to work around this temporarily by packaging a snapshot of
>> upstream svn, but I'm not happy with that since this is an arbitrary
>> point in development and not a clear and tested release which we should
>> ship and support for years. Popcon for squirrelmail is significant but
>> shows a steady decline since 2010.
>>
>> Alternatives are availbale. There's the competing product roundcube
>> which is actively maintained in Debian and shows a steady popcon
>> increase. Another alternative is to install SquirrelMail from source
>> which is very easy and makes it easier to e.g. keep up with commits or
>> newer snapshots. The added value of a Debian package for squirrelmail is
>> hence not immense in my opinion.
>>
>> Of course this is not to pass any judgement value or to try to
>> discourage others from working on this package. I welcome any thoughts
>> in this bug report, or interest in putting the work into a sustainable
>> Debian package of squirrelmail.
>
> Squirrelmail is one of the blockers to php5 removal (See #846069).  Please
> comment on that bug about how we can keep squirrelmail, but still get rid
> of php5 (personally, I don't see how).

If PHP 5 is gone I see no reason to keep squirrelmail in unstable in its
current form. So we should remove it (as per #846069).


Cheers,
Thijs



Bug#845456: Please add a udeb to ca-certificates

2016-11-23 Thread Thijs Kinkhorst
Hi Philipp,

On Wed, November 23, 2016 17:17, Philipp Kern wrote:
> Source: ca-certificates
> Tags: patch,d-i
> X-Debbugs-Cc: ma...@debian.org, debian-b...@lists.debian.org
>
> In an effort to make HTTPS usable in the installer (e.g. to fetch
> preseed, authorized_keys files, or packages) ca-certificates needs to
> add a udeb with the certificates. The result has to be usable by
> openssl, which requires that c_rehash has been run on the directory.
> Unfortunately c_rehash is a Perl script that requires the openssl binary
> to run, so it's not suitable to run in the installer environment.
>
> Please find attached a patch that a) adds a ca-certificates-udeb
> package, b) installs all off Mozilla's certificates into /etc/ssl/certs
> and c) runs c_rehash on the resulting directory during build. I needed
> to rename dirs, postinst and postrm. Hence there are two patch files for
> clarity: one in unified format and one in git diff format.
>
> I'd be nice to have this in Stretch. Not having the certificates
> available blocked inclusion of a HTTPS-capable wget altogether.

Thanks for the patch. This seems useful & fine to me. I'd leave it to
Michael as the primary maintainer to judge on its stretchworthiness
however.


Cheers,
Thijs



Bug#844826: libapache2-mod-auth-mellon: FTBFS: build-dependency not installable: liblasso3-dev (>= 2.1.0)

2016-11-19 Thread Thijs Kinkhorst
On Sat, November 19, 2016 07:25, Lucas Nussbaum wrote:
>> The following packages have unmet dependencies:
>>  sbuild-build-depends-libapache2-mod-auth-mellon-dummy : Depends:
>> liblasso3-dev (>= 2.1.0) but it is not going to be installed
>> E: Unable to correct problems, you have held broken packages.
>> apt-get failed.

Thanks. This is due to the OpenSSL transition. Since discussion is ongoing
on whether or not this transition will proceed or be rolled back, I'm
holding off on any action for now.


Cheers,
Thijs



Bug#844799: [Pkg-cas-maintainers] Bug#844799: libapache2-mod-auth-cas: FTBFS: build-dependency not installable: libssl-dev

2016-11-19 Thread Thijs Kinkhorst
On Sat, November 19, 2016 07:24, Lucas Nussbaum wrote:
>> The following packages have unmet dependencies:
>>  sbuild-build-depends-libapache2-mod-auth-cas-dummy : Depends:
>> libssl-dev but it is not going to be installed
>> E: Unable to correct problems, you have held broken packages.
>> apt-get failed.

Thanks. This is due to the OpenSSL transition. Since discussion is ongoing
on whether or not this transition will proceed or be rolled back, I'm
holding off on any action for now.


Cheers,
Thijs



Bug#844240: Intent to not ship squirrelmail with stretch

2016-11-13 Thread Thijs Kinkhorst
Package: squirrelmail
Severity: serious

SquirrelMail has been missing from Stretch for a while now and I intend
to leave it that way. This bug is to document this explicit choice (and
room for any concerns).

Upstream (of which I'm, at least on paper) part, has not made any new
release of SquirrelMail since 2011. There is some activity in commits
being done, but these do not result in releases.

I've tried to work around this temporarily by packaging a snapshot of
upstream svn, but I'm not happy with that since this is an arbitrary
point in development and not a clear and tested release which we should
ship and support for years. Popcon for squirrelmail is significant but
shows a steady decline since 2010.

Alternatives are availbale. There's the competing product roundcube
which is actively maintained in Debian and shows a steady popcon
increase. Another alternative is to install SquirrelMail from source
which is very easy and makes it easier to e.g. keep up with commits or
newer snapshots. The added value of a Debian package for squirrelmail is
hence not immense in my opinion.

Of course this is not to pass any judgement value or to try to
discourage others from working on this package. I welcome any thoughts
in this bug report, or interest in putting the work into a sustainable
Debian package of squirrelmail.


Cheers,
Thijs



Bug#796285: apache2-module-depends-on-real-apache2-package contradicts dh_apache2

2016-11-13 Thread Thijs Kinkhorst
Hi Jakub,

On Wed, March 9, 2016 11:50, Jakub Wilk wrote:
> * Arno Töll , 2015-08-21, 11:13:
>>The fix would be, to raise this Lintian error only if a package depends
>>on apache2-bin but not on apache2-api-MMNN.
>
> There's already separate tag for missing apache2-api-* dep:
> apache2-module-does-not-depend-on-apache2-api
>
> Should we should drop apache2-module-depends-on-real-apache2-package
> completely?

Yes. Some of my packages have been triggering this Lintian error for a
long long time now, while all they do is depend on dh-apache2 and let that
sort out the correct misc:depends.

Please remove the test.


Cheers,
Thijs



Bug#733475: [Pkg-mailman-hackers] Bug#733475: mailmanctl dies silently, messages delayed until intervention

2016-10-30 Thread Thijs Kinkhorst
On Wed, October 12, 2016 17:37, Jan Niehusmann wrote:
> On Wed, Oct 12, 2016 at 03:21:13PM +0200, Jan Niehusmann wrote:
>> May it be that either needrestart or systemd calls the stop and start
>> rules directly, instead of using the restart rule?
>
> It looks like the way systemd calls the init script may be the issue,
> here:
>
> Systemd generates a unit file which contains:
>
> ExecStart=/etc/init.d/mailman start
> ExecStop=/etc/init.d/mailman stop
>
> (See /var/run/systemd/generator.late/mailman.service)
>
> There is no such thing like ExecRestart, so all systemd can do is first
> calling ExecStop and then calling ExecStart, if a restart is requested.
>
> Additionally, the documentation for ExecStop says:
>
> "Note that it is usually not sufficient to specify a command for this
> setting that only asks the service to terminate (for example, by queuing
> some form of termination signal for it), but does not wait for it to do
> so."
>
> https://www.freedesktop.org/software/systemd/man/systemd.service.html
>
> (It continues saying "Since the remaining processes of the services are
> killed using SIGKILL immediately after the command exited, this would
> not result in a clean stop.", which is not the issue we are having, but
> still, the command given in ExecStop should wait for the service to
> exit, to fulfil the expectations of systemd)
>
> Would it hurt to add the 'wait for termination' code found in the
> restart part of /etc/init.d/mailman to the stop part, as well? Like the
> following?
>
>   stop)
> log_daemon_msg "Stopping Mailman master qrunner" "mailmanctl"
> PID=`cat $PIDFILE 2>/dev/null` || true
> $DAEMON -q stop
> if test -n "$PID" && kill -0 $PID 2>/dev/null ; then
> log_action_begin_msg "Waiting"
> for cnt in `seq 1 5`; do
> sleep 1
> kill -0 $PID 2>/dev/null || break
> done;
> if kill -0 $PID 2>/dev/null ; then
> log_end_msg 1
> else
> rm -f $PIDFILE
> log_end_msg 0
> fi
> else
> log_end_msg 0
> fi
> ;;
>
> Note that this is not really tested. Just copied from the restart
> section.

Thanks for the analysis.

I was wondering if we might not take a wholly different route, and that is
to replace the arguably complex init script with a systemd unit.

The most complex part is the checking for the site list. I believe we may
solve that at a different point, e.g. just create it upon first install
for example.


Cheers,
Thijs



Bug#821367: [Pkg-mailman-hackers] Bug#821367: mailman: New upstream 2.1.22 available

2016-04-25 Thread Thijs Kinkhorst
On Mon, April 18, 2016 08:16, Bernhard Schmidt wrote:
> Package: mailman
> Version: 1:2.1.20-1
> Severity: wishlist
>
> Hi,
>
> Mailman 2.1.21 and 2.1.22 have been released. They contain some DMARC
> fixes
> and the translations, especially the German translation, have been
> improved
> a lot.
>
> I can try to whip up a patch for it if you currently don't have enough
> spare time.

Thanks for the offer. I've uploaded 2.1.22 now.


Cheers,
Thijs



Bug#811542: [Pkg-mailman-hackers] Bug#811542: mailman: Update configuration for Apache 2.4

2016-04-25 Thread Thijs Kinkhorst
Version: 1:2.1.20-1

On Tue, January 19, 2016 18:37, David Magda wrote:
> Package: mailman
> Version: 1:2.1.18-2
> Severity: important
>
> The current copy of /etc/mailman/apache.conf in the mailmain package
> has configuration items that are for Apache 2.2. For example:

Thanks. This has been fixed already in 1:2.1.20-1.


Cheers,
Thijs



Bug#783732: [Pkg-mailman-hackers] Bug#783732: status

2016-04-25 Thread Thijs Kinkhorst
On Thu, March 17, 2016 16:08, martin f krafft wrote:
> What's the status of mailman3 for Debian? Has there been any work
> done, and if so, where?

I believe that's tracked in the WNPP bug #799292 (although it doesn't have
very recent updates at the time of writing).


Cheers,
Thijs



Bug#820336: composer: remove mercurial from Recommends

2016-04-07 Thread Thijs Kinkhorst
Package: composer
Version: 1.0.0-1
Severity: wishlist

Hi,

Installing composer by default also pulls in mercurial because it's in
Recommends. I personally doubt that the amount of mercurial use justifies
pulling it in by default (and e.g. not svn). I'd say it could be better
moved to Suggests.


Cheers,
Thijs

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

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

Versions of packages composer depends on:
ii  ca-certificates 20160104
ii  jsonlint1.4.0-2
ii  php-cli-prompt  1.0.1+dfsg-2
ii  php-common  1:35
ii  php-composer-semver 1.4.0-1
ii  php-composer-spdx-licenses  1.1.3-1
ii  php-json-schema 1.6.1-2
ii  php-symfony-console 2.8.4+dfsg-1
ii  php-symfony-filesystem  2.8.4+dfsg-1
ii  php-symfony-finder  2.8.4+dfsg-1
ii  php-symfony-process 2.8.4+dfsg-1
ii  php7.0-cli [php-cli]7.0.5-2

Versions of packages composer recommends:
ii  git1:2.8.0~rc3-1
pn  mercurial  

Versions of packages composer suggests:
pn  php-zip  

-- no debconf information



Bug#811340: php5-lasso: fails to install: php5-lasso.postinst: php5enmod: not found

2016-03-10 Thread Thijs Kinkhorst
Hi Frederic,

> Severity: serious

>  Setting up php5-lasso (2.5.0-3) ...
>  /var/lib/dpkg/info/php5-lasso.postinst: 4: /var/lib/dpkg/info/php5-
> lasso.postinst: php5enmod: not found
>  dpkg: error processing package php5-lasso (--configure):
>   subprocess installed post-installation script returned error exit
> status 127

Have you been able to look at this yet? It's keeping lasso and by
extension libapache2-mod-auth-mellon out of testing currently.

Not sure if upstream is already working on a PHP 7 compatible module.

Cheers,
Thijs



signature.asc
Description: OpenPGP digital signature


Bug#796285: apache2-module-depends-on-real-apache2-package contradicts dh_apache2

2016-03-09 Thread Thijs Kinkhorst
Hi,

On Fri, 21 Aug 2015 10:19:06 -0700, Russ Allbery wrote:
> > we agreed that we should change Lintian to accommodate these
> > changes. The fix would be, to raise this Lintian error only if a package
> > depends on apache2-bin but not on apache2-api-MMNN.
>
> Ah, yes, that would work.

So, any update on this issue? The test is still triggered on my package as
at level error with "Severity: serious, Certainty: certain".


Cheers,
Thijs



Bug#796208: ca-certificates: removal of SPI CA

2016-01-18 Thread Thijs Kinkhorst
On Sat, January 16, 2016 22:15, Robert Edmonds wrote:
> Axel Beckert wrote:
>> So why was the CA then removed already if debconf.org still uses this
>> CA? https://www.debconf.org/ is now reported as broken.
>
> Hi,
>
> If you examine the certificate served by www.debconf.org:443, it has a
> common name of wiki.debconf.org, with SANs for wiki.debconf.org and
> www.wiki.debconf.org.  It will report as broken regardless of which CAs
> are in the ca-certificates package, because the server does not appear
> to be configured to correctly serve its www.debconf.org virtual host via
> HTTPS.
>
> Also note that the certificate is issued by "Gandi Standard SSL CA 2",
> not SPI, Inc.
>
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number:
> 71:12:ca:53:8d:33:d4:41:c7:c6:63:f5:04:ed:22:84
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: C=FR, ST=Paris, L=Paris, O=Gandi, CN=Gandi Standard SSL CA
> 2
> Validity
> Not Before: Jan  1 00:00:00 2016 GMT
> Not After : Jan  1 23:59:59 2017 GMT
> Subject: OU=Domain Control Validated, OU=Gandi Standard SSL,
> CN=wiki.debconf.org
> Subject Public Key Info:
> Public Key Algorithm: rsaEncryption
> Public-Key: (4096 bit)
> Modulus:
> 00:c0:84:16:fc:c8:8b:78:aa:b9:ac:db:b4:23:fc:
> 2a:db:d9:6b:76:1d:de:92:8c:4c:d7:86:5f:15:d4:
> 15:90:64:7d:a9:05:cd:4c:49:63:63:00:e3:a6:63:
> bb:04:29:fb:67:ee:d7:25:17:4f:e1:87:23:fa:a1:
> ea:38:aa:9d:dc:d6:a0:f7:ab:5f:44:43:1f:03:80:
> d9:d3:39:e0:42:5a:48:91:b3:da:b3:b1:1e:fa:86:
> 0b:5d:b7:34:fe:f1:22:e7:96:58:2e:c3:86:09:e1:
> 5b:82:54:a0:e7:db:ba:fa:0c:6c:f6:42:4d:54:54:
> 2a:4a:48:87:35:f9:71:e8:67:a9:8e:ba:23:74:32:
> 12:dc:ff:15:9b:c3:98:bd:d1:0c:ba:3f:2d:de:50:
> 71:27:ef:a1:88:96:f2:d5:15:d8:ff:14:c2:c4:b8:
> 83:32:81:a8:91:67:97:19:c1:c2:c1:e2:0c:1b:4b:
> 4f:f2:19:fb:19:4a:07:ee:29:36:13:dd:0c:a2:76:
> 48:79:d7:a0:03:51:d4:7f:31:a5:5d:00:dc:4f:cc:
> 3b:f9:00:84:d6:2b:63:d7:86:e7:e3:aa:7a:f9:6f:
> 75:2b:87:0d:c9:82:3e:85:03:d6:a0:7a:2e:cf:b2:
> 85:9a:72:38:51:92:f6:a7:d9:d1:19:97:e3:3e:99:
> c5:b6:ae:c9:55:77:34:34:ae:a5:66:3a:5d:13:57:
> 25:da:44:29:43:dd:33:ca:05:53:c0:3f:84:e3:64:
> 12:d2:b0:68:d9:05:55:8e:14:e6:99:6d:bd:73:e4:
> e9:f9:3c:26:5b:f1:1c:fa:a2:28:dc:ea:24:af:71:
> 33:66:10:14:a9:3a:c1:a1:ca:66:f2:bd:31:08:60:
> 2c:b4:f9:d6:a9:6c:3b:7c:c4:bd:99:42:b4:7f:f5:
> 0e:14:ea:13:80:c2:bd:ea:4f:c2:ff:ff:ae:67:2c:
> 8e:5a:40:87:85:97:b8:c1:25:f5:5d:e2:1f:cf:bb:
> f1:18:89:0a:08:2c:da:b1:d8:1d:4d:c2:7b:4b:67:
> eb:af:e8:38:7c:74:41:8b:7f:08:cb:1a:24:d1:0e:
> c4:2f:5c:cd:ff:6a:96:c3:34:b2:f8:bb:4e:50:66:
> 82:84:02:4b:b9:81:4b:a8:1c:d6:90:35:56:26:a1:
> 8f:b9:8b:68:a0:78:f5:f7:75:e9:cb:de:8a:b1:1d:
> c6:e3:df:7b:08:bc:39:76:cf:ed:6b:29:9b:2c:f5:
> 06:3f:d5:9d:32:c6:cd:9a:42:1f:66:ee:3c:4e:21:
> b3:30:7c:74:d0:ed:80:6c:d2:a9:01:1c:91:b1:b0:
> ac:4d:99:09:4c:ac:dd:7b:d6:21:95:37:d5:6e:4a:
> ef:0b:6f
> Exponent: 65537 (0x10001)
> X509v3 extensions:
> X509v3 Authority Key Identifier:
> 
> keyid:B3:90:A7:D8:C9:AF:4E:CD:61:3C:9F:7C:AD:5D:7F:41:FD:69:30:EA
>
> X509v3 Subject Key Identifier:
> 92:53:21:4C:FE:33:67:8A:BB:CA:17:19:49:EF:30:FD:15:F9:EE:56
> X509v3 Key Usage: critical
> Digital Signature, Key Encipherment
> X509v3 Basic Constraints: critical
> CA:FALSE
> X509v3 Extended Key Usage:
> TLS Web Server Authentication, TLS Web Client
> Authentication
> X509v3 Certificate Policies:
> Policy: 1.3.6.1.4.1.6449.1.2.2.26
>   CPS: https://cps.usertrust.com
> Policy: 2.23.140.1.2.1
>
> X509v3 CRL Distribution Points:
>
> Full Name:
>   URI:http://crl.usertrust.com/GandiStandardSSLCA2.crl
>
> Authority Information Access:
> CA Issuers -
> URI:http://crt.usertrust.com/GandiStandardSSLCA2.crt
> OCSP - URI:http://ocsp.usertrust.com
>
> X509v3 Subject Alternative Name:
> DNS:wiki.debconf.org, DNS:www.wiki.debconf.org
> Signature Algorithm: sha256WithRSAEncryption
>  

Bug#810984: openssh-client: CVE-2016-0777

2016-01-14 Thread Thijs Kinkhorst
On Thu, January 14, 2016 15:49, Christoph Anton Mitterer wrote:
> You probably know about this already, but just in case not:
> https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-January/034679.html

Thanks for reporting.
The security team is indeed aware and a DSA is in preparation.

Cheers,
Thijs



Bug#810084: RM: websvn (RoQA; unmaintained, rc-buggy, inactive upstream, alternatives exist)

2016-01-06 Thread Thijs Kinkhorst
Package: websvn
Severity: serious

I propose to remove websvn from Debian.

The package is unmaintained with last maintainer upload in 2011. There was also
no response to a security issues which I fixed in an NMU one year ago. I then
noticed and reported several packaging issues which have gone unaddressed.

A bug was upgraded to RC over 200 days ago with no response to date.

Last upstream release was in 2011. There are several alternatives to this
package.

I will reassign this bug to ftp-master when no objections arrive 'soon'.

Cheers,
Thijs



Bug#808568: ca-certificates: show certificates subjects

2015-12-21 Thread Thijs Kinkhorst
On Tue, December 22, 2015 01:15, Christoph Anton Mitterer wrote:
> Control: tags -1 + wontfix
>
> On Mon, 2015-12-21 at 10:23 +0100, Thijs Kinkhorst wrote:
>> Such polarizing comments are not welcome and do not serve to improve
>> Debian. I'm closing the bug now.
> I'm afraid when factual issues are considered polarising.
> Well serving examples for such CA's should include e.g. CNNIC or
> TURKTRUST (yeah, of course, it was an "accident" that they created
> forged google.com certs and placed them in the wild o.O)

Your statement was:
"Given that Mozilla includes for money basically any
CA nowadays, even such which are inherently untrustworthy"

As you've clarified, apparently your opinion is that audits alone are not
reliable to determine worthiness of inclusion and you wish to see full
certificate subjects to better make your own choice of which CA's to
trust. I personally doubt whether the C= field is a reliable indicator of
that, but that is up to you.

By not formulating it this way, but instead choosing to use the statement
above 'will do (basically) anything for money', you choose to put focus
explicitly on the fact that it costs money and highly suggest a moral
judgment of their operation. It is really not a matter of language
difference that you choose to play the money card. It doesn't help to add
the claim that some CA's are 'inherently' untrustworthy in the same
sentence, which further reinforces the connection between accepting money
and doing something morally rejectable.

It's clear to me that you're strongly opinionated about the workings of
the CA system; your concerns also surface again in your followup. However,
I believe the BTS is not the right platform for that.

As for your request, I will reopen it and we can consider the
possibilities of it. I do hope that in the future you can show some
restraint in your approach.


Cheers,
Thijs



Bug#808600: Remove "UTN - DATACorp SGC" root certificate

2015-12-21 Thread Thijs Kinkhorst
fixed 808600 20151214
tags 808600 wheezy jessie
thanks

Hi Rob,

On Mon, December 21, 2015 12:57, Rob Stradling wrote:
> Package: ca-certificates
> Version: 20150426
>
> Please sync the latest additions/removals from Mozilla's NSS
> certdata.txt file.
>
> Comodo have recently removed our "UTN - DATACorp SGC" root from NSS, and
> we would like this removal to be propagated as widely as possible.  We
> no longer consider "UTN - DATACorp SGC" to be in-scope for the CAB
> Forum's Baseline Requirements, although it does remain in-scope for our
> "WebTrust for Certification Authorities" audit.

This has been removed from our unstable distribution already and will
propagate soon to our testing distribution. The stable and oldstable
distributions will be fixed when we get the ACKs from their release
managers.


Cheers,
Thijs



Bug#808600: Remove "UTN - DATACorp SGC" root certificate

2015-12-21 Thread Thijs Kinkhorst
On Mon, December 21, 2015 13:14, Rob Stradling wrote:
> I just noticed that ca-certificates/20151214 addresses this request, so
> I guess you can close this bug as a duplicate.
>
> ca-certificates/20151214 doesn't currently show up when I search for
> "ca-certificates" on packages.debian.org.  That's why I didn't see it
> before I opened this bug.

The bug is marked as affecting the correct versions, so there's no further
action required.

The packages.debian.org website has a tendency to lag behind updates
indeed. This will catch up automatically.


Cheers,
Thijs



Bug#775667: lintian: Create a command line to suppress excess tags

2015-08-31 Thread Thijs Kinkhorst
On Mon, August 31, 2015 07:46, Niels Thykier wrote:
> On 2015-08-30 20:28, Axel Beckert wrote:
>> Hi,
>>
>> Niels Thykier wrote:
 Moreover minified js is a security risk so removing tag is not really
 an option
>>>
>>> The bug is not about removing the tag, it is about the amount of times
>>> it is emitted makes it difficult to spot other issues.
>>
>> Yep, wanted to argue, too. But Niels was quicker
>>
>>> This is not the only tag with this issue (improper stripping of static
>>> libraries also do this), and I think we need to look into a solution
>>> for
>>> this at a general level.
>>
>> What about a command-line and/or configuration file option which
>> restricts the amount of tags of the same type to be printed at all?
>>
>> Example option: --max-output-same-tag=10
>>
>>  Regards, Axel
>>
>
> Yes.  Though I would prefer lintian did something like this by default
> when stdout is a tty.  Also, 10 instances of a single tag is quite a
> lot, I think 1-3 and a "+X more instances of this tag"-remark would be
> sufficient for most users.

That would be a nice feature and I think it makes sense as the default.

Nonetheless, the original issue could also be addressed by modifying the
test not to issue a tag on each of the potentially over 100 files it
encounters, but rather do something like:

if (any of the tinymce files found) {
  issue tag ("tinymce found")
}


Cheers,
Thijs



Bug#794762: Incomplete link in candidate assignment mail

2015-08-06 Thread Thijs Kinkhorst
Package: nm.debian.org
Severity: minor
Tags: patch

Attached patch fixes the missing url part of this email text:

 The mailbox with everything so far can be downloaded at:
 /am/mail-archive/username
From dd0b9ed3df0cb4b124f4ee59af344e291f55bbc6 Mon Sep 17 00:00:00 2001
From: Thijs Kinkhorst th...@kinkhorst.com
Date: Thu, 6 Aug 2015 12:12:25 +
Subject: [PATCH] Mailbox download link missed protocol and hostname

---
 templates/notification_mails/am_assigned_to_applicant.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/templates/notification_mails/am_assigned_to_applicant.txt b/templates/notification_mails/am_assigned_to_applicant.txt
index 9bae593..955b6d0 100644
--- a/templates/notification_mails/am_assigned_to_applicant.txt
+++ b/templates/notification_mails/am_assigned_to_applicant.txt
@@ -9,7 +9,7 @@ Hello,
 I have just assigned you a new NM applicant: {{process.person.fullname|safe}}, who is
 {{process.person.status|desc_status|safe}} and is applying to be {{process.applying_for|desc_status|safe}}.
 {% if process.mailbox_file %}The mailbox with everything so far can be downloaded at:
-{% url 'download_mail_archive' key=process.lookup_key %}
+https://nm.debian.org{% url 'download_mail_archive' key=process.lookup_key %}
 {% endif %}
 Note that you have not acknowledged the assignment yet, and could still refuse
 it, for example if you do not have time at the moment.
-- 
2.5.0



Bug#794029: [php-maint] Bug#794029: php5-cli doesn't satisfy php dependency for php5 metapackage

2015-07-30 Thread Thijs Kinkhorst
On Thu, July 30, 2015 01:01, Nick Adams wrote:
 The metapackage `php5` has a number of options to supply php but
 php5-cli is not one of those. On a host that doesn't require a web
 server, this metapackage seems to require that one be installed.

 Adding php5-cli to the php5 package dependency options would fix this.

What is the use case of this? The packages currently depending on the php5
meta package do so because they are applications that need to be run in a
webserver context. Otherwise they'd depend on php5-cli directly.


Cheers,
Thijs


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



Bug#788780: apt-file: diffindex-rred passes arguments to the shell

2015-06-21 Thread Thijs Kinkhorst
On Sun, June 14, 2015 23:57, brian m. carlson wrote:
 I'm marking this bug as security in case the Security Team wants to
 issue an advisory, although I suspect they will not (or I would have
 notified them directly).

Agreed that although good to fix, this is not something for an advisory.


Cheers,
Thijs


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



Bug#785642: [Pkg-mailman-hackers] Bug#785642: Bug#785642: Bug#785642: queue runner dies with uncaught UnicodeDecodeError

2015-06-09 Thread Thijs Kinkhorst
On Mon, June 8, 2015 09:34, Wouter Verhelst wrote:
 On Mon, Jun 08, 2015 at 09:16:44AM +0200, Thorsten Glaser wrote:
 On Sun, 7 Jun 2015, Wouter Verhelst wrote:

   Actually, the traceback says what's happening is CookHeaders is
 trying
   to create the List-Id: header to be added to the message.
  
   It tries to create a header of the form:
  
   List-Id: list description list.example.com
  
   And the exception occurs when trying to rfc 2047 encode the list's
   description in the charset of the list's preferred language. This
   exception should be occurring on every list post. Is that the case?
 
  Yes.

 Wouter, I think you hit the second paragraph of this:

 mailman (1:2.1.16-1exp1) experimental; urgency=low

   This version has changed the encoding of most strings, templates
   and pages to UTF-8 to meet the Debian release goal of full UTF-8
   support in all packages. It also no longer automatically converts
   mails to ISO-8859-1.

   If you have been using any nōn-ASCII strings in places such as
   the mailing list description, these were be stored wrongly in the
   list configuration file (config.pck), so you will need to change
   those (e.g. via the webinterface) again in order to have them be
   displayed correctly.

  -- Thorsten Glaser t...@mirbsd.de  Sun, 29 Dec 2013 14:35:50 +

 (from NEWS.Debian, which you “probably should” have followed ;)

 So, in short, load the list config via the webinterface,
 then retype the description and save the entry. Or just
 use config_list and put it in as Unicode/UTF-8.

 That seems likely, yes. I guess I didn't realize I had a non-ASCII
 character in there. There's really only a handful of lists here, and
 that one was the only one with non-ASCII.

Thanks. A solution for this situation was committed in upstream 2.1 stable
branch so it at least does not crash the qrunner.


Cheers,
Thijs


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



Bug#785642: [Pkg-mailman-hackers] Bug#785642: Bug#785642: queue runner dies with uncaught UnicodeDecodeError

2015-06-07 Thread Thijs Kinkhorst
Hoi Wouter,

I got some questions back from upstream, can you help?


Actually, the traceback says what's happening is CookHeaders is trying
to create the List-Id: header to be added to the message.

It tries to create a header of the form:

List-Id: list description list.example.com

And the exception occurs when trying to rfc 2047 encode the list's
description in the charset of the list's preferred language. This
exception should be occurring on every list post. Is that the case?

Also, what is the list's preferred_language and what is the raw value of
the list's description attribute. Obtain this info with something like:

$ bin/withlist list1
Loading list list1 (unlocked)
The variable `m' is the list1 MailList instance
 m.preferred_language
'en'
 m.description
'My List one'


(of course the list name and responses will be different in your case.)


Cheers,
Thijs


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



Bug#785642: [Pkg-mailman-hackers] Bug#785642: queue runner dies with uncaught UnicodeDecodeError

2015-06-07 Thread Thijs Kinkhorst
severity 785642 important
thanks

On Mon, May 18, 2015 19:18, Wouter Verhelst wrote:
 I received a message from one of my list admins that he couldn't send a
 mail to his list. Investigating turned up the following in
 /var/log/mailman/error:

 May 17 15:32:20 2015 (981) Uncaught runner exception: 'utf8' codec can't
 decode byte 0xe9 in position 18: invalid continuation byte
 May 17 15:32:20 2015 (981) Traceback (most recent call last):
   File /var/lib/mailman/Mailman/Queue/Runner.py, line 119, in _oneloop
 self._onefile(msg, msgdata)
   File /var/lib/mailman/Mailman/Queue/Runner.py, line 190, in _onefile
 keepqueued = self._dispose(mlist, msg, msgdata)
   File /var/lib/mailman/Mailman/Queue/IncomingRunner.py, line 130, in
 _dispose
 more = self._dopipeline(mlist, msg, msgdata, pipeline)
   File /var/lib/mailman/Mailman/Queue/IncomingRunner.py, line 153, in
 _dopipeline
 sys.modules[modname].process(mlist, msg, msgdata)
   File /var/lib/mailman/Mailman/Handlers/CookHeaders.py, line 239, in
 process
 i18ndesc = uheader(mlist, mlist.description, 'List-Id',
 maxlinelen=998)
   File /var/lib/mailman/Mailman/Handlers/CookHeaders.py, line 65, in
 uheader
 return Header(s, charset, maxlinelen, header_name, continuation_ws)
   File /usr/lib/python2.7/email/header.py, line 183, in __init__
 self.append(s, charset, errors)
   File /usr/lib/python2.7/email/header.py, line 267, in append
 ustr = unicode(s, incodec, errors)
 UnicodeDecodeError: 'utf8' codec can't decode byte 0xe9 in position 18:
 invalid continuation byte

 May 17 15:32:20 2015 (981) SHUNTING:
 1431869540.389822+156779307d54473d0eb732994bb67eee95733285

This seems to be a bug in python-email rather than Mailman. I think it
doesn't make sense to set errors to strict rather than something like
replace when the intention is to parse stuff so free-formed, under-specd
and user-controlled as email.

Nonetheless, Mailman could override this upstream choice and contruct the
Header class with replace. I will file a request upstream.


Cheers,
Thijs


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



Bug#786442: some lines don't appear in some messages

2015-06-07 Thread Thijs Kinkhorst
On Thu, May 21, 2015 20:20, Carlos Carvalho wrote:
 Package: squirrelmail
 Version: 2:1.4.23~svn20120406-2
 Severity: grave

 Below is a message that doesn't display in squirrelmail; Its single line
 doesn't appear. When clicking reply it appears quoted, as it should.

Thanks. I've committed a fix upstream and will upload this to Debian if it
does not give any problems.


Cheers,
Thijs


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



Bug#785642: [Pkg-mailman-hackers] Bug#785642: queue runner dies with uncaught UnicodeDecodeError

2015-05-26 Thread Thijs Kinkhorst
On Mon, May 18, 2015 19:18, Wouter Verhelst wrote:
 Package: mailman
 Version: 1:2.1.18-2
 Severity: grave
 Justification: causes data loss

 Hi,

 I received a message from one of my list admins that he couldn't send a
 mail to his list. Investigating turned up the following in
 /var/log/mailman/error:

 May 17 15:32:20 2015 (981) Uncaught runner exception: 'utf8' codec can't
 decode byte 0xe9 in position 18: invalid continuation byte
 May 17 15:32:20 2015 (981) Traceback (most recent call last):
   File /var/lib/mailman/Mailman/Queue/Runner.py, line 119, in _oneloop
 self._onefile(msg, msgdata)
   File /var/lib/mailman/Mailman/Queue/Runner.py, line 190, in _onefile
 keepqueued = self._dispose(mlist, msg, msgdata)
   File /var/lib/mailman/Mailman/Queue/IncomingRunner.py, line 130, in
 _dispose
 more = self._dopipeline(mlist, msg, msgdata, pipeline)
   File /var/lib/mailman/Mailman/Queue/IncomingRunner.py, line 153, in
 _dopipeline
 sys.modules[modname].process(mlist, msg, msgdata)
   File /var/lib/mailman/Mailman/Handlers/CookHeaders.py, line 239, in
 process
 i18ndesc = uheader(mlist, mlist.description, 'List-Id',
 maxlinelen=998)
   File /var/lib/mailman/Mailman/Handlers/CookHeaders.py, line 65, in
 uheader
 return Header(s, charset, maxlinelen, header_name, continuation_ws)
   File /usr/lib/python2.7/email/header.py, line 183, in __init__
 self.append(s, charset, errors)
   File /usr/lib/python2.7/email/header.py, line 267, in append
 ustr = unicode(s, incodec, errors)
 UnicodeDecodeError: 'utf8' codec can't decode byte 0xe9 in position 18:
 invalid continuation byte

 May 17 15:32:20 2015 (981) SHUNTING:
 1431869540.389822+156779307d54473d0eb732994bb67eee95733285

 I'm not sure why mailman needs to decode the data in the mail as part of

I agree that this may be too strict. Can you provide the mail that caused
this?

 running the queue, but at any rate that shouldn't case the mail to get
 lost...

It's not lost, it's shunted, so I'm inclined to downgrade the bug as there
is no dataloss I think.

Cheers,
Thijs


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



Bug#783732: [Pkg-mailman-hackers] Bug#783732: mailman: please package mailman 3 released today

2015-05-11 Thread Thijs Kinkhorst
On Wed, April 29, 2015 17:29, shirish wrote:
 Package: mailman
 Version: 1:2.1.18-2
 Severity: wishlist

 Dear Maintainer,
 Please package mailman 3 which was released today. From the announce mail

The current Debian Mailman team has very limited resources. I heartily
invite anyone interested in packaging Mailman 3 to join the team and start
working on it.

I'd advise to use mailman3 as a package name because the differences are
so big.


Cheers,
Thijs


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



Bug#784670: jessie-pu: package pound/2.6-6+deb8u1

2015-05-07 Thread Thijs Kinkhorst
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Hi,

I'd like to update pound in jessie to fix the ability to disable ssl client
renegotiation (#765649). The same patch has been uploaded to sid a few days ago.
Wheezy and earlier are not affected by this specific issue.

After this patch is applied I can get an A score at SSLlabs with pound.


Cheers,
Thijs

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
diff -Nru pound-2.6/debian/changelog pound-2.6/debian/changelog
--- pound-2.6/debian/changelog	2014-10-19 23:49:01.0 +
+++ pound-2.6/debian/changelog	2015-05-07 16:30:55.0 +
@@ -1,3 +1,11 @@
+pound (2.6-6+deb8u1) jessie; urgency=medium
+
+  * Non-maintainer upload by the security team with maintainer approval.
+  * Add missing part of anti_beast patch to fix disabling of client
+renegotiation. (Closes: #765649)
+
+ -- Thijs Kinkhorst th...@debian.org  Tue, 05 May 2015 13:27:06 +
+
 pound (2.6-6) unstable; urgency=low
 
   * Add options to disable SSLv2 and SSLv3.
diff -Nru pound-2.6/debian/patches/0008-disable_client_initiated_renegotiation.patch pound-2.6/debian/patches/0008-disable_client_initiated_renegotiation.patch
--- pound-2.6/debian/patches/0008-disable_client_initiated_renegotiation.patch	1970-01-01 00:00:00.0 +
+++ pound-2.6/debian/patches/0008-disable_client_initiated_renegotiation.patch	2015-05-07 16:30:22.0 +
@@ -0,0 +1,120 @@
+Added the missing parts that makes the option SSLAllowClientRenegotiation
+work as advertised, allowing client initiated renegotiation to be turned off.
+This patch is a compliment to the changes introduced in the 0001-anti_beast.patch, 
+which was missing the changes to http.c as seen in the original patch from 
+Joe Gooch mrwiz...@k12system.com at:
+http://goochfriend.org/pound_2.6f_ssl_renegotiation_and_ciphers.patch
+
+--- a/http.c
 b/http.c
+@@ -273,6 +273,11 @@
+ 
+ static int  err_to = -1;
+ 
++typedef struct {
++int timeout;
++RENEG_STATE *reneg_state;
++} BIO_ARG;
++
+ /*
+  * Time-out for client read/gets
+  * the SSL manual says not to do it, but it works well enough anyway...
+@@ -280,6 +285,7 @@
+ static long
+ bio_callback(BIO *const bio, const int cmd, const char *argp, int argi, long argl, long ret)
+ {
++BIO_ARG *bio_arg;
+ struct pollfd   p;
+ int to, p_res, p_err;
+ 
+@@ -287,11 +293,22 @@
+ return ret;
+ 
+ /* a time-out already occured */
+-if((to = *((int *)BIO_get_callback_arg(bio)) * 1000)  0) {
++if((bio_arg = (BIO_ARG*)BIO_get_callback_arg(bio))==NULL) return ret;
++if((to = bio_arg-timeout * 1000)  0) {
+ errno = ETIMEDOUT;
+ return -1;
+ }
+ 
++/* Renegotiations */
++if (bio_arg-reneg_state != NULL  *bio_arg-reneg_state == RENEG_ABORT) {
++logmsg(LOG_NOTICE, REJECTING renegotiated session);
++errno = ECONNABORTED;
++return -1;
++}
++
++//logmsg(LOG_NOTICE, TO %d, to);
++if (to == 0) return ret;
++
+ for(;;) {
+ memset(p, 0, sizeof(p));
+ BIO_get_fd(bio, p.fd);
+@@ -326,7 +343,7 @@
+ return -1;
+ case 0:
+ /* timeout - mark the BIO as unusable for the future */
+-BIO_set_callback_arg(bio, (char *)err_to);
++bio_arg-timeout = err_to;
+ #ifdef  EBUG
+ logmsg(LOG_WARNING, (%lx) CALLBACK timeout poll after %d secs: %s,
+ pthread_self(), to / 1000, strerror(p_err));
+@@ -531,6 +548,15 @@
+ struct linger   l;
+ double  start_req, end_req;
+ 
++RENEG_STATE reneg_state;
++BIO_ARG ba1, ba2;
++
++reneg_state = RENEG_INIT;
++ba1.reneg_state =  reneg_state;
++ba2.reneg_state = reneg_state;
++ba1.timeout = 0;
++ba2.timeout = 0;
++
+ from_host = ((thr_arg *)arg)-from_host;
+ memcpy(from_host_addr, from_host.ai_addr, from_host.ai_addrlen);
+ from_host.ai_addr = (struct sockaddr *)from_host_addr;
+@@ -539,6 +565,8 @@
+ free(((thr_arg *)arg)-from_host.ai_addr);
+ free(arg);
+ 
++if(lstn-allow_client_reneg) reneg_state = RENEG_ALLOW;
++
+ n = 1;
+ setsockopt(sock, SOL_SOCKET, SO_KEEPALIVE, (void *)n, sizeof(n));
+ l.l_onoff = 1;
+@@ -562,10 +590,10 @@
+ close(sock);
+ return;
+ }
+-if(lstn-to  0) {
+-BIO_set_callback_arg(cl, (char *)lstn-to);
+-BIO_set_callback(cl, bio_callback);
+-}
++
++ba1.timeout = lstn-to;
++BIO_set_callback_arg(cl, (char *)ba1);
++BIO_set_callback(cl, bio_callback);
+ 
+ if(lstn-ctx != NULL) {
+ if((ssl = SSL_new(lstn-ctx-ctx)) == NULL) {
+@@ -574,6 +602,7

Bug#784237: Emails about needing to restart apt-get

2015-05-04 Thread Thijs Kinkhorst
Package: needrestart
Version: 2.0-2
Severity: normal

Hi,

Running needrestart after an upgrade which included a new apt version triggers
an email with the following content:

  Your session on host tetraquark.soleus.nu (/dev/pts/0) is running 
  obsolete binaries or libraries as listed below.
  
  Please consider to relogin or restart the affected processes!
  
  apt-get[4699,31634]

Probably the current package manager should be excluded from the checks.



Cheers,
Thijs

-- Package-specific info:
needrestart output:
Your outdated processes:
bash[2394], irssi[2397]



-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (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
Init: sysvinit (via /sbin/init)

Versions of packages needrestart depends on:
ii  dpkg   1.17.25
ii  libmodule-find-perl0.12-1
ii  libmodule-scandeps-perl1.16-1
ii  libproc-processtable-perl  0.51-1
ii  libsort-naturally-perl 1.03-1
ii  libterm-readkey-perl   2.32-1+b1
ii  perl   5.20.2-4

needrestart recommends no packages.

Versions of packages needrestart suggests:
pn  libnotify-bin  none

-- 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#783340: Trying to load modules that doesn't exist

2015-04-28 Thread Thijs Kinkhorst
Hi,

 /etc/modules contain:

 # Required for cinder hotplug
 acpiphp
 pci_hotplug

 Those modules don't exist in Jessie. This makes systemd display a
 failed unit.

We are seeing the same on our OpenStack platform when using the official
Jessie image.

It was also reported in Ubuntu at
https://bugs.launchpad.net/debian/+source/openstack-debian-images/+bug/1430323

Could this be fixed in Jessie r1?


Thanks,
Thijs



signature.asc
Description: OpenPGP digital signature


Bug#782565: unblock: commons-httpclient/3.1-11

2015-04-14 Thread Thijs Kinkhorst
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package commons-httpclient.

It fixes security issue CVE-2014-3577.

unblock commons-httpclient/3.1-11


Cheers,
Thijs
diff -Nru commons-httpclient-3.1/debian/ant.properties commons-httpclient-3.1/debian/ant.properties
--- commons-httpclient-3.1/debian/ant.properties	2011-08-30 09:42:03.0 +
+++ commons-httpclient-3.1/debian/ant.properties	2015-04-13 16:15:49.0 +
@@ -1,5 +1,5 @@
 # JSSE stub classes required for build
 lib.dir=/usr/share/java
 #jsse.jar=/usr/share/java/jsse.jar
-ant.build.javac.source=1.4
-ant.build.javac.target=1.4
+ant.build.javac.source=1.5
+ant.build.javac.target=1.5
diff -Nru commons-httpclient-3.1/debian/changelog commons-httpclient-3.1/debian/changelog
--- commons-httpclient-3.1/debian/changelog	2012-12-06 13:41:48.0 +
+++ commons-httpclient-3.1/debian/changelog	2015-04-13 16:15:49.0 +
@@ -1,3 +1,20 @@
+commons-httpclient (3.1-11) unstable; urgency=high
+
+  * Team upload.
+  * Add CVE-2014-3577.patch. (Closes: #758086)
+It was found that the fix for CVE-2012-6153 was incomplete: the code added
+to check that the server hostname matches the domain name in a subject's
+Common Name (CN) field in X.509 certificates was flawed. A
+man-in-the-middle attacker could use this flaw to spoof an SSL server using
+a specially crafted X.509 certificate. The fix for CVE-2012-6153 was
+intended to address the incomplete patch for CVE-2012-5783. The issue is
+now completely resolved by applying this patch and the
+06_fix_CVE-2012-5783.patch.
+  * Change java.source and java.target ant properties to 1.5, otherwise
+commons-httpclient will not compile with this patch.
+
+ -- Markus Koschany a...@gambaru.de  Mon, 23 Mar 2015 22:57:54 +0100
+
 commons-httpclient (3.1-10.2) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru commons-httpclient-3.1/debian/patches/CVE-2014-3577.patch commons-httpclient-3.1/debian/patches/CVE-2014-3577.patch
--- commons-httpclient-3.1/debian/patches/CVE-2014-3577.patch	1970-01-01 00:00:00.0 +
+++ commons-httpclient-3.1/debian/patches/CVE-2014-3577.patch	2015-04-13 16:15:49.0 +
@@ -0,0 +1,110 @@
+From: Markus Koschany a...@gambaru.de
+Date: Mon, 23 Mar 2015 22:45:14 +0100
+Subject: CVE-2014-3577
+
+It was found that the fix for CVE-2012-6153 was incomplete: the code added to
+check that the server hostname matches the domain name in a subject's Common
+Name (CN) field in X.509 certificates was flawed. A man-in-the-middle attacker
+could use this flaw to spoof an SSL server using a specially crafted X.509
+certificate.
+The fix for CVE-2012-6153 was intended to address the incomplete patch for
+CVE-2012-5783. This means the issue is now completely resolved by applying
+this patch and the 06_fix_CVE-2012-5783.patch.
+
+References:
+
+upstream announcement:
+https://mail-archives.apache.org/mod_mbox/www-announce/201408.mbox/CVE-2014-3577
+
+Fedora-Fix:
+http://pkgs.fedoraproject.org/cgit/jakarta-commons-httpclient.git/tree/jakarta-commons-httpclient-CVE-2014-3577.patch
+
+CentOS-Fix:
+https://git.centos.org/blob/rpms!jakarta-commons-httpclient/SOURCES!jakarta-commons-httpclient-CVE-2014-3577.patch
+
+Debian-Bug: https://bugs.debian.org/758086
+Forwarded: not-needed, already fixed
+---
+ .../protocol/SSLProtocolSocketFactory.java | 57 ++
+ 1 file changed, 37 insertions(+), 20 deletions(-)
+
+diff --git a/src/java/org/apache/commons/httpclient/protocol/SSLProtocolSocketFactory.java b/src/java/org/apache/commons/httpclient/protocol/SSLProtocolSocketFactory.java
+index fa0acc7..e6ce513 100644
+--- a/src/java/org/apache/commons/httpclient/protocol/SSLProtocolSocketFactory.java
 b/src/java/org/apache/commons/httpclient/protocol/SSLProtocolSocketFactory.java
+@@ -44,9 +44,15 @@ import java.util.Iterator;
+ import java.util.LinkedList;
+ import java.util.List;
+ import java.util.Locale;
+-import java.util.StringTokenizer;
++import java.util.NoSuchElementException;
+ import java.util.regex.Pattern;
+ 
++import javax.naming.InvalidNameException;
++import javax.naming.NamingException;
++import javax.naming.directory.Attribute;
++import javax.naming.directory.Attributes;
++import javax.naming.ldap.LdapName;
++import javax.naming.ldap.Rdn;
+ import javax.net.ssl.SSLException;
+ import javax.net.ssl.SSLSession;
+ import javax.net.ssl.SSLSocket;
+@@ -424,28 +430,39 @@ public class SSLProtocolSocketFactory implements SecureProtocolSocketFactory {
+ 		return dots;
+ 	}
+ 
+-	private static String getCN(X509Certificate cert) {
+-// Note:  toString() seems to do a better job than getName()
+-//
+-// For example, getName() gives me this:
+-// 1.2.840.113549.1.9.1=#16166a756c6975736461766965734063756362632e636f6d
+-//
+-// whereas toString() gives me this:
+-// 

Bug#758086: CVE-2014-3577 Apache HttpComponents hostname verification bypass

2015-04-13 Thread Thijs Kinkhorst
Hi,

Since the last maintainer upload was well over three years ago and there have 
been several unacknowledged NMU's since then, I've taken the liberty to upload 
Markus' good work as-is to unstable to fix this security issue for jessie.


Cheers,
Thijs


signature.asc
Description: This is a digitally signed message part.


Bug#781063: commons-httpclient: should be removed from Debian during the Stretch release cycle

2015-04-13 Thread Thijs Kinkhorst
Hi Emmanuel,

On 24.03.2015 12:30, Emmanuel Bourg wrote:
 I don't think this is a good idea. commons-httpclient is a very popular
 library, even in its older incarnation. Removing it could make it harder
 to bring new libraries or applications to Debian.

This could be the case, however, the package has not seen maintainer uploads 
in a very long time and has a number of issues. Security issues went 
unaddressed for months. If it's important to keep it, it should be well-
maintained.


Cheers,
Thijs


signature.asc
Description: This is a digitally signed message part.


Bug#782147: unblock: mediawiki/1:1.19.20+dfsg-2.3

2015-04-08 Thread Thijs Kinkhorst
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package mediawiki.

The only change is an addition of an upstream patch for this release branch
which fixes a number of security issues.

unblock mediawiki/1:1.19.20+dfsg-2.3

Thanks,
Thijs
diff -Nru mediawiki-1.19.20+dfsg/debian/changelog mediawiki-1.19.20+dfsg/debian/changelog
--- mediawiki-1.19.20+dfsg/debian/changelog	2014-12-21 12:11:10.0 +
+++ mediawiki-1.19.20+dfsg/debian/changelog	2015-04-06 16:55:57.0 +
@@ -1,3 +1,21 @@
+mediawiki (1:1.19.20+dfsg-2.3) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Add patch fixing several security issues:
+- (bug T85848, bug T71210) SECURITY: Don't parse XMP blocks that
+   contain XML entities, to prevent various DoS attacks.
+- (bug T88310) SECURITY: Always expand xml entities when checking
+  SVG's.
+- (bug T73394) SECURITY: Escape  in Html::expandAttributes to
+  prevent XSS.
+- (bug T85855) SECURITY: Don't execute another user's CSS or JS
+  on preview.
+- (bug T85349, bug T85850, bug T86711) SECURITY: Multiple issues
+  fixed in SVG filtering to prevent XSS and protect viewer's
+  privacy.
+
+ -- Thijs Kinkhorst th...@debian.org  Mon, 06 Apr 2015 16:53:54 +
+
 mediawiki (1:1.19.20+dfsg-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru mediawiki-1.19.20+dfsg/debian/patches/security_1.19.24.patch mediawiki-1.19.20+dfsg/debian/patches/security_1.19.24.patch
--- mediawiki-1.19.20+dfsg/debian/patches/security_1.19.24.patch	1970-01-01 00:00:00.0 +
+++ mediawiki-1.19.20+dfsg/debian/patches/security_1.19.24.patch	2015-04-06 17:03:41.0 +
@@ -0,0 +1,636 @@
+From: Mediawiki
+Subject: Fix security issues as fixed in upstream security fix release 1.19.24:
+(bug T85848, bug T71210) SECURITY: Don't parse XMP blocks that contain XML entities, to prevent various DoS attacks.
+(bug T88310) SECURITY: Always expand xml entities when checking SVG's.
+(bug T73394) SECURITY: Escape  in Html::expandAttributes to prevent XSS.
+(bug T85855) SECURITY: Don't execute another user's CSS or JS on preview.
+(bug T85349, bug T85850, bug T86711) SECURITY: Multiple issues fixed in SVG filtering to prevent XSS and protect viewer's privacy.
+Origin: upstream, https://lists.wikimedia.org/pipermail/mediawiki-announce/2015-March/000175.html
+
+diff -Nruw -x '*~' -x '.js*' -x '.git*' -x '*.xcf' -x '#*#' -x '.#*' -x '.rubocop*' -x .travis.yml -x package.json -x messages -x Gemfile -x '*.png' -x '*.jpg' -x '*.xcf' -x '*.gif' -x '*.svg' -x '*.tiff' -x '*.zip' -x '*.xmp' mediawiki-1.19.23/includes/EditPage.php mediawiki-1.19.24/includes/EditPage.php
+--- mediawiki-1.19.23/includes/EditPage.php	2015-03-31 13:24:03.0 +
 mediawiki-1.19.24/includes/EditPage.php	2015-03-31 13:23:38.0 +
+@@ -1988,14 +1988,19 @@
+ if ( $this-isWrongCaseCssJsPage ) {
+ 	$wgOut-wrapWikiMsg( div class='error' id='mw-userinvalidcssjstitle'\n$1\n/div, array( 'userinvalidcssjstitle', $this-mTitle-getSkinFromCssJsSubpage() ) );
+ }
++if ( $this-getTitle()-isSubpageOf( $wgUser-getUserPage() ) ) {
+ if ( $this-formtype !== 'preview' ) {
+-	if ( $this-isCssSubpage )
++		if ( $this-isCssSubpage ) {
+ 		$wgOut-wrapWikiMsg( div id='mw-usercssyoucanpreview'\n$1\n/div, array( 'usercssyoucanpreview' ) );
+-	if ( $this-isJsSubpage )
++		}
++
++		if ( $this-isJsSubpage ) {
+ 		$wgOut-wrapWikiMsg( div id='mw-userjsyoucanpreview'\n$1\n/div, array( 'userjsyoucanpreview' ) );
+ }
+ 			}
+ 		}
++			}
++		}
+ 
+ 		if ( $this-mTitle-getNamespace() != NS_MEDIAWIKI  $this-mTitle-isProtected( 'edit' ) ) {
+ 			# Is the title semi-protected?
+diff -Nruw -x '*~' -x '.js*' -x '.git*' -x '*.xcf' -x '#*#' -x '.#*' -x '.rubocop*' -x .travis.yml -x package.json -x messages -x Gemfile -x '*.png' -x '*.jpg' -x '*.xcf' -x '*.gif' -x '*.svg' -x '*.tiff' -x '*.zip' -x '*.xmp' mediawiki-1.19.23/includes/Html.php mediawiki-1.19.24/includes/Html.php
+--- mediawiki-1.19.23/includes/Html.php	2015-03-31 13:24:03.0 +
 mediawiki-1.19.24/includes/Html.php	2015-03-31 13:23:38.0 +
+@@ -525,17 +525,20 @@
+ 			} else {
+ # Apparently we need to entity-encode \n, \r, \t, although the
+ # spec doesn't mention that.  Since we're doing strtr() anyway,
+-# and we don't need  escaped here, we may as well not call
+-# htmlspecialchars().
++# we may as well not call htmlspecialchars().
+ # @todo FIXME: Verify that we actually need to
+ # escape \n\r\t here, and explain why, exactly.
+ #
+ # We could call Sanitizer::encodeAttribute() for this, but we
+ # don't because we're stubborn and like our marginal savings on
+ # byte size from not having to encode unnecessary quotes.
++# The only difference between this transform and the one by
++# Sanitizer::encodeAttribute() is '' is only

Bug#782146: unblock: mailman/1:2.1.18-2

2015-04-08 Thread Thijs Kinkhorst
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package mailman.

The diff is a security fix for CVE-2015-2775.

unblock mailman/1:2.1.18-2


Thanks,
Thijs
diff -Nru mailman-2.1.18/debian/changelog mailman-2.1.18/debian/changelog
--- mailman-2.1.18/debian/changelog	2014-07-10 18:01:59.0 +
+++ mailman-2.1.18/debian/changelog	2015-04-06 15:37:32.0 +
@@ -1,3 +1,13 @@
+mailman (1:2.1.18-2) unstable; urgency=high
+
+  * Fix security issue: path traversal through local_part.
+Affects installations which use an Exim or Postfix transport
+instead of fixed aliases; attacker needs to be able to place
+files on the local filesystem.
+(CVE-2015-2775, Closes: 781626)
+
+ -- Thijs Kinkhorst th...@debian.org  Mon, 06 Apr 2015 15:36:15 +
+
 mailman (1:2.1.18-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru mailman-2.1.18/debian/config mailman-2.1.18/debian/config
--- mailman-2.1.18/debian/config	2012-06-16 09:50:23.0 +
+++ mailman-2.1.18/debian/config	2015-04-06 15:30:32.0 +
@@ -1,5 +1,5 @@
 #! /bin/sh -e
-# $URL: svn+ssh://svn.debian.org/svn/svn/pkg-mailman/trunk/debian/config $
+# $URL: svn+ssh://svn.debian.org/svn/pkg-mailman/trunk/debian/config $
 # $Id: config 693 2011-10-08 15:30:38Z thijs $
 
 . /usr/share/debconf/confmodule
diff -Nru mailman-2.1.18/debian/control mailman-2.1.18/debian/control
--- mailman-2.1.18/debian/control	2014-07-10 18:19:25.0 +
+++ mailman-2.1.18/debian/control	2015-04-06 15:30:32.0 +
@@ -4,7 +4,6 @@
 Maintainer: Mailman for Debian pkg-mailman-hack...@lists.alioth.debian.org
 Uploaders: Lionel Elie Mamane lmam...@debian.org,
  Thijs Kinkhorst th...@debian.org,
- Thorsten Glaser t...@mirbsd.de,
  Hector Garcia hec...@debian.org
 Build-Depends: debhelper (= 7), autoconf, python-dev (= 2.6.6-3~), gettext, python-dnspython
 Standards-Version: 3.9.5
diff -Nru mailman-2.1.18/debian/patches/92_CVE-2015-2775.patch mailman-2.1.18/debian/patches/92_CVE-2015-2775.patch
--- mailman-2.1.18/debian/patches/92_CVE-2015-2775.patch	1970-01-01 00:00:00.0 +
+++ mailman-2.1.18/debian/patches/92_CVE-2015-2775.patch	2015-04-06 15:44:18.0 +
@@ -0,0 +1,34 @@
+From: Mark Sapiro m...@msapiro.net
+Subject: Fix path traversal through local_part (CVE-2015-2775)
+Origin: upstream, https://launchpadlibrarian.net/201407944/p
+Bug: https://bugs.launchpad.net/mailman/+bug/1437145
+Bug-Debian: http://bugs.debian.org/781626
+
+diff -ur mailman-2.1.18.orig/Mailman/Defaults.py.in mailman-2.1.18/Mailman/Defaults.py.in
+--- mailman-2.1.18.orig/Mailman/Defaults.py.in	2014-05-03 17:37:22.0 +
 mailman-2.1.18/Mailman/Defaults.py.in	2015-04-06 15:43:20.0 +
+@@ -138,7 +138,7 @@
+ 
+ # A Python regular expression character class which defines the characters
+ # allowed in list names.  Lists cannot be created with names containing any
+-# character that doesn't match this class.
++# character that doesn't match this class.  Do not include '/' in this list.
+ ACCEPTABLE_LISTNAME_CHARACTERS = '[-+_.=a-z0-9]'
+ 
+ 
+diff -ur mailman-2.1.18.orig/Mailman/Utils.py mailman-2.1.18/Mailman/Utils.py
+--- mailman-2.1.18.orig/Mailman/Utils.py	2014-05-03 17:37:22.0 +
 mailman-2.1.18/Mailman/Utils.py	2015-04-06 15:43:20.0 +
+@@ -99,6 +99,12 @@
+ #
+ # The former two are for 2.1alpha3 and beyond, while the latter two are
+ # for all earlier versions.
++#
++# But first ensure the list name doesn't contain a path traversal
++# attack.
++if len(re.sub(mm_cfg.ACCEPTABLE_LISTNAME_CHARACTERS, '', listname))  0:
++syslog('mischief', 'Hostile listname: %s', listname)
++return False
+ basepath = Site.get_listpath(listname)
+ for ext in ('.pck', '.pck.last', '.db', '.db.last'):
+ dbfile = os.path.join(basepath, 'config' + ext)
diff -Nru mailman-2.1.18/debian/patches/series mailman-2.1.18/debian/patches/series
--- mailman-2.1.18/debian/patches/series	2014-07-10 17:59:41.0 +
+++ mailman-2.1.18/debian/patches/series	2015-04-06 15:36:11.0 +
@@ -10,3 +10,4 @@
 79_archiver_slash.patch
 90_gettext_errors.patch
 91_utf8.patch
+92_CVE-2015-2775.patch
diff -Nru mailman-2.1.18/debian/postinst mailman-2.1.18/debian/postinst
--- mailman-2.1.18/debian/postinst	2012-06-16 09:50:23.0 +
+++ mailman-2.1.18/debian/postinst	2015-04-06 15:30:32.0 +
@@ -7,7 +7,7 @@
 # Other modifications 2004-2007 by other maintainers of the Debian package:
 #  Lionel Elie Mamane, Thijs Kinkhorst, Riccardo Setti, Matej Vela, Hector Garcia, László Böszörményi, Bernd S. Brentrup, ...
 #
-# $URL: svn+ssh://svn.debian.org/svn/svn/pkg-mailman/trunk/debian/postinst $
+# $URL: svn+ssh://svn.debian.org/svn/pkg-mailman/trunk/debian/postinst $
 # $Id: postinst 693 2011-10-08 15:30:38Z thijs $
 #
 . /usr/share/debconf/confmodule
diff -Nru

Bug#781467: Here's the patch

2015-03-29 Thread Thijs Kinkhorst
Index: en/whats-new.dbk
===
--- en/whats-new.dbk	(revision 10679)
+++ en/whats-new.dbk	(working copy)
@@ -480,6 +480,15 @@
   systemitem role=packagehardening-wrapper/systemitem can
   provide a systemitemgcc/systemitem with these flags enabled.
   /para
+
+  paraNew in this release is the 
+  systemitem role=packageneedrestartsystemitem package. When installed,
+  it will check after each APT upgrade session for any services running on
+  the system that require a restart to take advantage of the changes in the
+  upgraded packages and offers to perform that restart. It's recommended to
+  install systemitem role=packageneedrestartsystemitem to ensure that
+  security updates in libraries are propagated to running services.
+  /para
 /section
 section id=mariadb
   titleMariaDB next to MySQL/title

Bug#781467: Mention needrestart in Security section

2015-03-29 Thread Thijs Kinkhorst
Package: release-notes
Severity: wishlist
Tags: patch

Hi,

Please see attached patch to mention the needrestart package in the Security
section.


Cheers,
Thijs


needrestart.patch
Description: inode/empty


  1   2   3   4   5   6   7   8   9   10   >