Bug#1000068: libapache2-mod-auth-cas: depends on obsolete pcre3 library
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
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
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
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
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
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
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
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)?
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/
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/
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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))
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
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
>> 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?
On Fri, January 12, 2018 10:24, Raphael Hertzog wrote: > Hi, > > On Tue, 09 Jan 2018, Brian May wrote: >> Raphael Hertzogwrites: >> >> > 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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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.
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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