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#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#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#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#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#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#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#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#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#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#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#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#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#828378: closing 828378
close 828378 1.1-2 thanks
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#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#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-rc-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-rc-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-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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#780429: snmp-mibs-downloader: postinst uses /usr/share/doc content (Policy 12.3): /usr/share/doc/mibrfcs/*
Hi, a test with piuparts revealed that your package uses files from /usr/share/doc in its maintainer scripts which is a violation of Policy 12.3: Packages must not require the existence of any files in /usr/share/doc/ in order to function. cp: cannot stat '/usr/share/doc/mibrfcs/*': No such file or directory Downloading the MIBs failed. I've taken a look and this is a rather core piece of functionality for this package. Moving the files around is not impossible, but seems not appropriate in this stage of the release. Therefore, indeed: PS: it's probably OK to tag this bug jessie-ignore I agree. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778747: openssl: RFC 7465 says RC4 is broken, never to be used
On Thu, February 19, 2015 10:38, Florian Schlichting wrote: Newly released RFC 7465 [0] describes RC4 as being on the verge of becoming practically exploitable and consequently mandates that both servers and clients MUST NOT offer or negotiate an RC4 cipher suite, and indeed terminate the TLS handshake if RC4 ciphers are the only ones available. I agree with Kurt that this is a desirable direction to choose, but is not something opportune nor necessary to change so late in the release cycle. This issue must be fixed for stretch. The use of RC4 should indeed be discouraged, but the current platform already provides many knobs and levers to disable the use, as will many of the defaults. RFC 7465 has been adopted for a reason. Let's take that seriously, please? The reason it's adopted is to migrate away from RC4. Debian is already on that path. As with any RFC, it's not intended to be immediately adopted amongst all supported platforms the day it's released. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775842: [moodle-packaging] Bug#775842: 3 left (was: Re: Bug#775842: Bug#775842: moodle: Multiple security issues)
On Fri, February 13, 2015 16:10, Joost van Baal-IliÄ wrote: CVE-2014-4172 php-cas problem, fixed in Debian's php-cas 1.3.3-1 and 1.3.1-4+deb7u1. Moodle ships with unchanged phpCAS 1.3.3, see moodle-2.7.5+dfsg/auth/cas/CAS/moodle_readme.txt Moodle can likely use the Debian-maintained php-cas package. I'll try test that. Probably, yes. It wasn't possible earlier because the versions were different, that has now been solved. CVE-2013-3630 https://tracker.moodle.org/browse/MDL-41449 I'll apply for a Jira account later... :-/ I can read it. The issue is still unfixed and under embargo. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776246: MD4 collision/preimage attacks (CVE-2014-8242)
Hi, See https://github.com/librsync/librsync/issues/5 . librsync uses MD4 as part of syncing; given the low strength and size of MD4, and the relative ease of computing collisions/preimages, that makes librsync unsafe to use on untrusted data, such as when running a duplicity backup. The upstream fix involves changing the signature format to use a strong hash. The new version of librsync supports reading the old signature format, but always writes the new one. So, fixing this has some of the same implications as Berkeley DB upgrades. In particular, any applications using librsync and its data format across multiple systems will require upgrading any readers along with writers. I'd suggest coordinating this with the reverse dependencies of librsync1. Although a genuine issue, the fix is indeed too invasive to deploy in a stable release and requires something of a transition. We should therefore start this in sid for stretch. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775682: diff for websvn nmu
Hi, I've NMU'ed websvn for this security issue with attached debdiff. Cheers, Thijs websvn_nmudiff.debdiff Description: Binary data
Bug#775682: arbitrary file access when downloads enabled for users with commit access
Package: websvn
Severity: serious
Tags: security patch
Hi,
James Clawson reported:
Arbitrary files with a known path can be accessed in websvn by committing a
symlink to a repository and then downloading the file (using the download
link).
An attacker must have write access to the repo, and the download option must
have been enabled in the websvn config file.
Example:
- Create a symlink to /etc/passwd and commit it to the repo.
- Access websvn and download the file.
- The downloaded file will be the web server's /etc/passwd (i.e. the symlink is
resolved on the web server).
This will also work with symlinks to directories, but dlmode=zip must be added
to the download link manually. Zip must be installed manually to be able to
download directories.
I've assigned CVE-2013-6892 to this issue. Please mention it in the changelog
when fixing the issue.
I've created attached patch which solves the bug.
Cheers,
Thijs
diff -ur oud/dl.php nieuw/dl.php
--- oud/dl.php 2015-01-18 16:03:30.688791512 +0100
+++ nieuw/dl.php 2015-01-18 16:27:00.950897749 +0100
@@ -137,6 +137,18 @@
exit(0);
}
+ // For security reasons, disallow direct downloads of filenames that
+ // are a symlink, since they may be a symlink to anywhere (/etc/passwd)
+ // Deciding whether the symlink is relative and legal within the
+ // repository would be nice but seems to error prone at this moment.
+ if ( is_link($tempDir.DIRECTORY_SEPARATOR.$archiveName) ) {
+ header('HTTP/1.x 500 Internal Server Error', true, 500);
+ error_log('to be downloaded file is symlink, aborting: '.$archiveName);
+ print 'Download of symlinks disallowed: '.xml_entities($archiveName).'.';
+ removeDirectory($tempDir);
+ exit(0);
+ }
+
// Set timestamp of exported directory (and subdirectories) to timestamp of
// the revision so every archive of a given revision has the same timestamp.
$revDate = $logEntry-date;
@@ -180,7 +192,7 @@
$downloadMimeType = 'application/x-zip';
$downloadArchive .= '.zip';
// Create zip file
- $cmd = $config-zip.' -r '.quote($downloadArchive).' '.quote($archiveName);
+ $cmd = $config-zip.' --symlinks -r '.quote($downloadArchive).' '.quote($archiveName);
execCommand($cmd, $retcode);
if ($retcode != 0) {
error_log('Unable to call zip command: '.$cmd);
Bug#772639: squirrelmail: Can't login courier imap server
severity 772639 important thanks Hi Tomoo, On Tue, December 9, 2014 14:40, Tomoo Nomura wrote: When login from squirrelmail to imap server, the server rejects the request due to Unknown user or invalid password. The reason is that squirrelmail sents incorrect password to the server. Squirrelmail gets the password through encryption and decryption. In a process of decription, squirrelmail drops some characters of the password. Thanks for your report and the patch. I've been logging in with SquirrelMail to Courier for many years so I'm not sure that this is a generic problem warranting the serious severity, so I'm downgrading it for now. Nonetheless I'll investigate the issue, of course. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661020: acidbase: CVE-2012-1198 security bypass and remote file inclusion
severity 661020 normal thanks Hi, From what I see the remote file inclusion is limited to environments with register_globals being on though. I've investigated this issue. The vast majority of the mentioned 'attacks' evidently only possible through register_globals, and the one about 'create' is very vague and not reproducible for me. register_globals is in 2014 no longer anything that anyone should still be running, and is explicitly marked as unsupported for many releases now. Add to this that these kinds of tools are not normally operated by untrusted users or exposed to the internet. I'm downgrading the bug for now. It would be nice if the maintainer could comment on it. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765722: CVE-2014-3660 libxml2 billion laugh variant
Package: libxml2 Severity: serious Tags: security patch Hi, The Netherlands Cyber Security Center announced an issue in libxml2. https://www.ncsc.nl/actueel/nieuwsberichten/kwetsbaarheid-ontdekt-in-libxml2.html It seems to be a variant of the classic 'billion laughs' vulnerability. Upstream has fixed this in 2.9.2: https://git.gnome.org/browse/libxml2/commit/?id=be2a7edaf289c5da74a4f9ed3a0b6c733e775230 Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765473: dovecot-common: Dovecot (previous to V2.1) doesn't allow to disable SSLv3 which is bad: CVE-2014-3566
On Wed, October 15, 2014 14:07, Henrik Langos wrote: There is a simple one line patch available for dovecot 2.0. Maybe a similar way exists for 1.2. Do you have a pointer to this patch? Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765473: dovecot-common: Dovecot (previous to V2.1) doesn't allow to disable SSLv3 which is bad: CVE-2014-3566
On Wed, October 15, 2014 16:30, Henrik Langos wrote: Hi Thijs, On 10/15/14 14:26, Thijs Kinkhorst wrote: On Wed, October 15, 2014 14:07, Henrik Langos wrote: There is a simple one line patch available for dovecot 2.0. Maybe a similar way exists for 1.2. Do you have a pointer to this patch? Thijs Sure.. Sorry, thought I had put them in the initial report: Here's the patch: http://www.dovecot.org/pipermail/dovecot/2014-October/098244.html There is also a statement that pop/imap might be harder/impossible to exploit but I wouldn't buy that just yet: http://www.dovecot.org/pipermail/dovecot/2014-October/098248.html Thanks. But the patch does not make SSLv3 configurable, it just blocks it in a hardcoded way. This may be acceptable to some, but I'm reluctant to release this patch through the LTS security channel, because there's no way to avoid any breakage by admins except for not installing the update. Especially because, contrary to web browsers, we do not have a clear picture of the state of SSL/TLS version support in mail clients out there, so the impact is hard to measure. Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763780: This is CVE-2014-7206.
This is CVE-2014-7206. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730057: Remove FreeSCI from Debian
I've asked ftp-master to remove this package from sid in #764256. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763134: acpi-support-base: /usr/share/acpi-support/power-funcs broken from line 24 if consolekit installed and no dbus running
On Mon, September 29, 2014 13:33, Michael Meskes wrote: @security: Is this enough of a security problem to warrant a stable upload? The fix seems easy enough, just run pinky if $user is still empty. On its own, I would not consider failure to lock the screen in specific situations a high priority issue because of the other consequences of having physical access to a machine. Normally I would suggest to fix the bug through the regular stable update channel. However, am I correct that this is a regression in the DSA for acpi-support (0.140-5+deb7u3)? If so, we can fix it through stable security since it's a regression introduced in that channel. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726661: Does not permit login as root from version 1:6.2p2-6
All, Thank you Paul, indeed it helped me, as I too ran into this issue in a fresh Jessie install. I didn't have to downgrade OpenSSH, however, just edit PermitRootLogin as you did. So am I right to conclude that this bug actually concerns the change that changes PermitRootLogin to without-password? I think changing this default makes sense from a security perspective as it provides the best compromise between securing a default install versus the desire to log in as root directly. However, I recognise that there are people that are using password-based root login who may be surprised by this change. The proper solution therefore may be to add a NEWS.Debian entry so everyone is informed about this change, and a release notes item at that. If those are added, this bug could be closed. Colin, what do you think? Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Bug#762760: Working on an update
Hi, The security team is working on an update which includes amongst others the patch referenced in this bug. Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759718: php-cas needs to urlencode all tickets (CVE-2014-4172)
Package: php-cas Severity: serious Tags: fixed-upstream Hi Olivier, php-cas 1.3.3 fixes security issue CVE-2014-4172: urlencode all tickets. Can you please upgrade php-cas in Debian to this version? thanks, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753985: [Pkg-gnupg-maint] Bug#753985: gpgv-udeb: fails to validate Release files (missing sha256 support)
Op maandag 7 juli 2014 11:36:49 schreef Didier 'OdyX' Raboud: b) Thankfully we don't need to consider the backup plan mentioned in a) since all we need is enabling sha256 support. Currently, Release files include MD5+SHA1+SHA256. You'll find a tested patch attached. (This means a whole installation using a netboot-gtk image.) I can confirm that Cyril's patch fixes gpgv.exe usage within win32- loader. Merci beaucoup a vous deux pour votre aide excellente dans ce cas! J'ai a l'heure téĺéchargé un nouveau version du gnupg. Cordialement, Thijs signature.asc Description: This is a digitally signed message part.
Bug#745408: [Pkg-gnupg-maint] Bug#745408: [gnupg] Source package contains non-free IETF RFC/I-D
severity 745408 important tags 745408 moreinfo thanks Op maandag 21 april 2014 16:20:45 schreef bastien ROUCARIES: This source package contains the following files from the IETF under non-free license terms: doc/OpenPGP This file only referances an IETF RFC, so I do not believe it is non-free. Can you elaborate on why you think this is the case? Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Bug#749795: apt: no authentication checks for source packages
Hi, apt: no authentication checks for source packages The Debian security team has assigned CVE-2014-0478 to this issue. APT developers: we should fix this in wheezy. Are you able to provide an update for wheezy for this issue? As for squeeze, if it's not too much extra work it would be great if an update for squeeze was also possible. Perhaps it could also even include the fix for https://security-tracker.debian.org/tracker/CVE-2011-3634? Let us know. Thanks, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749795: apt: no authentication checks for source packages
Hi Michael, On Thu, June 12, 2014 13:52, Michael Vogt wrote: On Thu, Jun 12, 2014 at 11:44:20AM +0200, Thijs Kinkhorst wrote: apt: no authentication checks for source packages The Debian security team has assigned CVE-2014-0478 to this issue. APT developers: we should fix this in wheezy. Are you able to provide an update for wheezy for this issue? [..] Attached is the fix for wheezy with a regression test, a additional test run is very welcome (works in my wheezy container both the testcase and a manual test when removing /var/lib/apt/lists/*Release*). Thanks! I've built it and verified that it works for me aswell (and solves the issue). For the changelog: you need to target wheezy-security, and may want to add closes: #749795 and urgency=high. With these changes you can upload to security-master.debian.org. Make sure to build with full source (-sa) as wheezy-security doesn't yet have the orig tarball. The patch seems to apply rather cleanly to squeeze, so an update for that would be nice if possible. Fixing CVE-2011-3634 aswell would be nice if simple to do but not essential. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750682: [php-maint] Bug#750682: [php5] Experimental warning in NEWS.Debian
severity 750682 normal tags 750682 pending thanks On Thu, June 5, 2014 18:36, Filipus Klutiero wrote: Package: php5 Version: 5.6.0~beta3+dfsg-2 Severity: serious NEWS.Debian contains the following entry: php5 (5.6.0~alpha1+dfsg-1) experimental; urgency=medium * THIS IS A DEVELOPMENT PREVIEW - DO NOT USE IT IN PRODUCTION! * PHP 5.6.0alpha1 comes with new features such as (incomplete list) : + constant scalar expressions, + variadic functions, + argument unpacking, + support for large(2GiB) file uploads, + SSL/TLS improvements, + a new command line debugger called phpdbg. -- OndÅej Surý ond...@debian.org Tue, 28 Jan 2014 11:02:20 +0100 I'm not sure from what angle this should be taken. On one hand, although the version which reached testing is no longer alpha, it's still very early. The current release's announcement had a similar disclaimer: http://php.net/archive/2014.php#id2014-05-15-1 On the other hand, we have a history of aggressive PHP packaging. Even the last major version was packaged at RC stage. As far as I know/remember, that went rather well, so we might be as lucky. Alpha versions have been packaged since January. Thanks. This message was already removed in git so it won't display on jessie upgrades after the next upload. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747084: must not be in jessie without proper long term support
Package: moodle Version: 2.6.2-1 Severity: serious At the time of writing this, I am the single active maintainer on the Moodle package in unstable/testing. The time I spend on the package I can spend at work because we're using the package in its current form as it is in unstable. It's however unlikely that I can commit to supporting Moodle in a stable release in worktime. In discussion with the Security Team it was concluded that a large package like Moodle needs some kind of concrete prospect of being maintained in stable if we want to include it in the release. While there are no other maintainers, that is not the case. Therefore, Moodle should not migrate to Jessie until that is solved. This bug can be closed when there's an active maintainer or team who is willing to keep track of the frequent security issues and wants to prepare updates for the Jessie lifetime. Ideally, this would be based on the upstream 2.7 release which I understand is planned as an LTS. Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746594: [moodle-packaging] Bug#746594: Bug#746594: Embedded OLE is not DFSG-compliant (PHP-2.02)
Hi Dan, On Fri, May 2, 2014 04:02, Dan Poltawski wrote: On 2 May 2014 02:46, David Prévot taf...@debian.org wrote: The embedded PHPExcel copy (#718585) embeds OLE (#487558) which is not DFSG compliant (PHP-2.02)[1,2]. We have removed this library in upstream in version 2.6: https://tracker.moodle.org/browse/MDL-42381 http://git.moodle.org/gw?p=moodle.git;a=commit;h=383d414478f1f3129f243e4d047d4fa06b9a3b8f It wasn't used and can be safely deleted. Is there another instance of this library or is it a packaging problem? It's indeeed a second copy, it's under lib/phpexcel/PHPExcel/Shared/ Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744018: Wordpress 3.8.2 fixes two vulnerabilities [CVE-2014-0165 CVE-2014-0166]
Package: wordpress Severity: serious Tags: security fixed-upstream patch Hi, Wordpress 3.8.2 was released which fixes two security issues and several more bugs. http://wordpress.org/news/2014/04/wordpress-3-8-2/ CVE-2014-0165 Wordpress privilege escalation: prevent contributors from publishing posts CVE-2014-0166 Wordpress potential authentication cookie forgery Can you see to it that this is fixed in unstable? I'm not sure if these vulnerabilities warrant an update to stable on their own, can you advise? Thanks, Thijs signature.asc Description: This is a digitally signed message part.
Bug#742522: liblasso-perl: Not a CODE reference when using perl binding for Lasso
Hi Frederic, So indeed, it was just a compilation option bug... Do you think you can include this patch in next 2.4.0 ? Sure, I'll have it in the next upload and I'll see to get it included upstream. Can you please upload it over the coming days? I got an email that my package libapache2-mod-auth-mellon was scheduled for removal from jessie because of this RC bug. I can alternatively also make an NMU if desired. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743889: libssl1.0.0: libssl update does not cause applications that use it to restart
severity 743889 normal thanks Hi, We have code that checks some of the applications that need to be restarted, but it has a static list of packages to check and it's outdated. We're working on improving that list and providing an other update that will restart those services. I do not believe this is a grave bug in openssl. Debian has never claimed that 100% automatic upgrades are fully supported. Tools like checkrestart and needrestart exist for this reason; and the advisories from both Debian and CERT-CC explicitly mention the need to restart services. That some packages have lists of services to restart is an extra bonus, but since not all libraries have such functionality and there may be first or third party applications on the system, such a service is never a guarantee and the list can never be complete. Therefore, manual action and/or use of tools like checkrestart is always necessary. I'm leaving it at normal, not wishlist, because indeed if the package the package contains such functonality, it should aim to indeed have at least the most important ones in there. In the long term however, I have more faith in a solution where a high level package manager would check such things by default, instead of each individual package. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743842: [php-maint] Bug#743842: php5: uninstallable due to dependency loops
On Mon, April 7, 2014 11:49, Thorsten Glaser wrote: Please remove the Depends: php5-json from php itself. PHP should not depend on any of its extensions; people can rather do that themselves. (Actually, this is an issue in every version that had this Depends.) The dependency exists for transitional reasons: the functionality in the extension used to be in core, so the dependency guarantees that upgrades will not regress in functionality and applications will suddenly break. It can be weakened after one release cycle. Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743175: zendframework: two security issues
Hi, CVE names have been assigned for these issues. The assignment is rather complicated. If you fix both issues in one upload it's ok to just mention that it addresses the 5 CVE's named below. http://framework.zend.com/security/advisory/ZF2014-01 CVE-2014-2681 - This CVE is for the lack of protection against XML External Entity injection attacks in some functions, because of the incomplete fix in CVE-2012-5657. It appears that this only affects Zend Framework 1.x, although that isn't critical to determining the number of CVE IDs. CVE-2014-2682 - This CVE is for the failure to consider that the libxml_disable_entity_loader setting is shared among threads in the PHP-FPM case. Again, the existence of this CVE means that the CVE-2012-5657 fix was incomplete. It appears that this affects more than just Zend Framework 1.x, although that isn't critical to determining the number of CVE IDs. CVE-2014-2683 - This CVE is for the lack of protection against XML Entity Expansion attacks in some functions, because of the incomplete fix in CVE-2012-6532. It appears that this also affects more than just Zend Framework 1.x, although that isn't critical to determining the number of CVE IDs. http://framework.zend.com/security/advisory/ZF2014-02 CVE-2014-2684 - This CVE is for the error in the consumer's verify method that leads to acceptance of wrongly sourced tokens. The same CVE is used for Zend Framework 1.x and ZendOpenId 2.x, even though the code is not identical. CVE-2014-2685 - This CVE is for the specification violation in which signing of a single parameter is incorrectly considered sufficient. Again, this CVE is for both Zend Framework 1.x and ZendOpenId 2.x. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743158: systemd: sends private information without confirmation
Hi Norbert, On Mon, March 31, 2014 03:33, Norbert Preining wrote: Sending /etc/fstab without asking the user is not acceptable, as there might be passwords saved in there. It would help the security team and anyone else not intimately involved with this package if you could indicate more precisely to which functionality you refer here. Thanks, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743175: zendframework: two security issues
Package: zendframework Severity: serious Tags: security fixed-upstream patch Hi, Two new security advisories were published for the Zend Framework. * ZF2014-01: Potential XXE/XEE attacks using PHP functions: simplexml_load_*, DOMDocument::loadXML, and xml_parse http://framework.zend.com/security/advisory/ZF2014-01 * ZF2014-02: Potential security issue in login mechanism of ZendOpenId and Zend_OpenId consumer http://framework.zend.com/security/advisory/ZF2014-02 Can you please see to it that these are addressed in Debian? Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743158: [Pkg-systemd-maintainers] Bug#743158: systemd: sends private information without confirmation
On Mon, March 31, 2014 15:29, Norbert Preining wrote: Hi Michael, On Mon, 31 Mar 2014, Michael Biebl wrote: can you try the attached bug script, you need to copy it to it works for me. I chose to use Y as default, since /etc/fstab should not usually contain password information. I think this is fine. Yes, fine. Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735363: [Pkg-gnupg-maint] Bug#735363: [PATCH] init trustdb before trying to clear it
Op dinsdag 18 februari 2014 20:30:28 schreef Werner Koch: On Tue, 18 Feb 2014 09:47, th...@debian.org said: I do not object against this upload but would like to know if Werner would approve of the patch. Werner? The patch is quite obvious. IIRC, it has also been posted to the BTS or the ML. Yes, indeed. Just checking to be sure, as I'd rather only carry patches in Debian's GnuPG that will at some point be applied upstream. Thanks, Thijs signature.asc Description: This is a digitally signed message part.
Bug#735363: [Pkg-gnupg-maint] Bug#735363: [PATCH] init trustdb before trying to clear it
On Mon, February 17, 2014 19:43, Daniel Kahn Gillmor wrote: On 02/15/2014 01:07 PM, Dominic Hargreaves wrote: Control: severity -1 critical Justification: makes unrelated software on the system break [...] On reflection, I'm upgrading the severity of this bug, since it's blocking RC (FTBFS) bugs on multiple other packages. I think this is the right thing to do for #735363. thanks for doing it, Dominic. Could someone familiar with gnupg's internals check Daniel's patch, please (or Daniel do you feel confident to upload this without further review?) I've been running with this patch since January 20th, and it works fine for me. I'm attaching the debdiff here. I'm uploading it to DELAYED/2 now, in case the package maintainers want to try to resolve this some other way. I do not object against this upload but would like to know if Werner would approve of the patch. Werner? Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735312: moodle: deletes files from packages libjs-yui-*
On Tue, January 14, 2014 16:40, Robert Bihlmeyer wrote: Package: moodle Version: 2.5.3-3 Severity: serious Having libjs-yui-common and libjs-yui-common installed, an upgrade of moodle from 2.5.3-2 to -3 results in loss of a large number of files from these two packages. What I think happens here is that dpkg first sets the symlink of /usr/share/moodle/lib/yuilib/3.9.1/build to /usr/share/javascript/yui3, and then goes on to remove all the files from /u/s/m/lib/yuilib/3.9.1/build/ that are no longer contained in the new version of moodle. It *will* follow the symlink and this results in removal of these files from /usr/share/javascript/yui3 instead. This is perfectly reproducable for me: install -2, then upgrade to -3. dpkg -L libjs-yui3-common | while read f; do [ -e $f ] || echo $f; done will list a lot of missing files afterwards. Apart from being a policy violation this bug also cripples the functionality of moodle itself. My suggestion would be: 1. elide the dir removal from preinst 2. don't include the symlink in the package contents 3. remove the dir and create the symlink in the postinst When transplanting the dir removal code, remember that [ -d ... ] will return true for a symlink to a directory. Thanks. I'll investigate early next week. Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734045: closed by Thijs Kinkhorst th...@debian.org (Re: [Pkg-ia32-libs-maintainers] Bug#734045: ia32-libs-gtk: not installable, missing dependencies)
On Fri, January 3, 2014 12:41, Leonardo Boselli wrote: Can you reopen it changing to minor and suggesting to change the error message ? No, because it's an error message from apt, not from this package. It is documented in the release notes on two different places, and in the package description. Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733963: Bug#730104: fixed in moodle 2.5.3-3
Hoi Ivo, On Fri, January 3, 2014 13:48, Ivo De Decker wrote: control: reopen 730104 control: close 733963 2.5.3-3 Hi Thijs, On Fri, Jan 03, 2014 at 12:19:41PM +, Thijs Kinkhorst wrote: Changes: moodle (2.5.3-3) unstable; urgency=medium . * Drop unused libjs-yui dependency (closes: #730104). * Replace bundled yui3 with dependency on packaged libjs-yui3-min. Looks like you closedd the bug in yui, not the one in moodle. Fixing. Sorry and thanks. Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713237: fixed in cpqarrayd 2.3-2
Version: 2.3-2 Hi, This has been fixed in cpqarrayd 2.3-2 but I neglected to mention that in the changelog. Thijs signature.asc Description: This is a digitally signed message part.
Bug#730178: Updates prepared in Git repository
On Fri, November 29, 2013 10:01, Raphael Hertzog wrote: Dear security team, please find attached the diff compared to the respective versions in stable(-security). Is it OK to upload them ? Yes, this is OK (ruby1.8 needs to be built with -sa, ruby1.9.1 without). Thank you for your work on this. PS: I didn't took care of oldstable. Someone should handle that. Obviously we prefer to release updates for all suites at the same time. Are the versions in squeeze so much different that it would be a lot of work to also apply the patches there? Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730544: static IV used in Percona XtraBackup
Package: percona-xtrabackup Severity: serious Tags: security fixed-upstream Hi, Upstream discovered and fixed use of a static IV in encrypting backups: A fixed initialization vector (constant string) was used while encrypting the data. This opened the encrypted stream/data to plaintext attacks among others. Bug fixed #1185343. http://www.percona.com/doc/percona-xtrabackup/2.1/release-notes/2.1/2.1.6.html https://bugs.launchpad.net/percona-xtrabackup/+bug/1185343 Fixed in upstream 2.1.6. Can you please ensure that this gets into Debian? Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728199: fails to upgrade: ln: failed to create symbolic link '/etc/apache2/conf-available/dokuwiki.conf': File exists
Package: dokuwiki Version: 0.0.20130510a-2 Severity: serious Hi, dokuwiki fails to upgrade, and exits the upgrade with an error. Turning set -x on in postinst, this is what happens: + [ -e /etc/apache2/conf.d/dokuwiki.conf ] + [ -d /etc/apache2/conf-available -a ! -e /etc/apache2/conf-available/dokuwiki.conf ] + ln -s /etc/dokuwiki/apache.conf /etc/apache2/conf-available/dokuwiki.conf ln: failed to create symbolic link '/etc/apache2/conf-available/dokuwiki.conf': File exists dpkg: error processing dokuwiki (--configure): subprocess installed post-installation script returned error exit status 1 The code fails because /etc/apache2/conf.d/dokuwiki.conf, the link target, does not exist (it is removed in the same script) and therefore the -e on the link itself fails. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.11-1-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages dokuwiki depends on: ii debconf [debconf-2.0] 1.5.51 ii javascript-common 11 ii libjs-jquery 1.7.2+dfsg-3 ii libjs-jquery-cookie8-2 ii libjs-jquery-ui1.10.1+dfsg-1 ii libphp-simplepie 1.2.1-3 ii php-geshi 1.0.8.11-2 ii php5 5.5.5+dfsg-1 ii ucf3.0027+nmu1 Versions of packages dokuwiki recommends: ii php5-cli5.5.5+dfsg-1 ii php5-gd 5.5.5+dfsg-1 ii php5-ldap 5.5.5+dfsg-1 ii php5-mysql 5.5.5+dfsg-1 Versions of packages dokuwiki suggests: pn libapache2-mod-xsendfile none -- Configuration Files: /etc/dokuwiki/dokuwiki.php changed [not included] -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725889: [Pkg-gnupg-maint] Bug#725889: popularity-contest: cron task gpg: fatal: can't open /tmp/.../trustdb.gpg: No such file or directoryo
Hi Bill, On Wed, October 16, 2013 11:19, Bill Allombert wrote: severity 725889 grave severity 726479 important found 725889 1.4.15-1 quit On Wed, Oct 09, 2013 at 09:09:02PM +0200, Bill Allombert wrote: /usr/bin/gpg --batch --no-options --no-default-keyring --trust-model=always --homedir /tmp/tmp.HC3e3knvrs --keyring /usr/share/popularity-contest/debian-popcon.gpg --quiet --armor -o /var/log/popularity-contest.gpg -r 6672B9765BDF38A3 --encrypt /var/log/popularity-contest gpg: fatal: can't open `/tmp/tmp.HC3e3knvrs/trustdb.gpg': No such file or directory Dear Debian GnuPG maintainers, Please fix this bug soon, since it will affect more and more popcon subscribers as the time pass. Please do a urgency high upload so that testing is fixed too. There are potentially 12000 systems affected. Now has I see it, you have two way to fix the problem: Either apply the patch Werner send (GIT 2528178e7e2fac6454dd988121167305db7c71d9), or revert the previous patch (GIT a1a59e6a539e597996976d0afb6aa3062e954188). The later seems less intrusive. I won't be able to address this until next week, but I welcome an NMU that uses either of those approaches. Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725889: popularity-contest: cron task gpg: fatal: can't open /tmp/.../trustdb.gpg: No such file or directoryo
On Wed, October 16, 2013 15:56, Bill Allombert wrote: On Wed, Oct 16, 2013 at 12:09:42PM +0200, Thijs Kinkhorst wrote: Hi Bill, There are potentially 12000 systems affected. Now has I see it, you have two way to fix the problem: Either apply the patch Werner send (GIT 2528178e7e2fac6454dd988121167305db7c71d9), or revert the previous patch (GIT a1a59e6a539e597996976d0afb6aa3062e954188). The later seems less intrusive. I won't be able to address this until next week, but I welcome an NMU that uses either of those approaches. I have prepared an NMU at http://people.debian.org/~ballombe/pnmu/gnupg/ that revert a1a59e6a539e597996976d0afb6aa3062e954188. The diff is attached. If nobody has concern, I will upload it tomorrow. Looks good, please go ahead. Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704645: [Pkg-gnupg-maint] Bug#704645: Processed: Re: Bug#704613: cdebootstrap: signature verification bypass with manipulated InRelease file
On Sat, April 6, 2013 12:45, Thijs Kinkhorst wrote: I'm seeking input from GnuPG upstream for their view on this case. I have forwarded the issue. Upstream acknowledges the issue but does not seem prepared to change the behaviour of the --verify command. As described in #705536, I do not think that changing the behaviour in Debian specifically will advance the situation (rather deteriorate it). Therefore, the option left is to clearly document the risk of the command. Upstream has put this text in the man page section describing the command. Note: When verifying a cleartext signature, `gpg' verifies only what makes up the cleartext signed data and not any extra data outside of the cleartext signature or header lines following directly the dash marker line. The option `--output' may be used to write out the actual signed data; but there are other pitfalls with this format as well. It is suggested to avoid cleartext signatures in favor of detached signatures. I think this is what from a Debian standpoint completes what we can do for this issue. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718682: CVE name assigned
Hi, This is CVE-2013-4276. Please mention it in your changelog when fixing the issue. Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717928: Remove lcms for jessie
Hi Oleksandr, Upstream has stopped supporting lcms-1 in 2009. Can you please start the process to transition packages to lcms-2? See Moritz' mail above for details. thanks, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717992: moodle,moodle-book: error when trying to install together
reassign 717992 moodle-book thanks On Sat, July 27, 2013 19:08, Andreas Beckmann wrote: /var/cache/apt/archives/moodle-book_1.6.3-2_all.deb (--unpack): trying to overwrite '/usr/share/moodle/mod/book/show.php', which is also in package moodle 2.5.1-1 The module has been integrated into Moodle proper since version 2.3. I'm reassigning the bug to moodle-book and will request removal. Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717992: moodle,moodle-book: error when trying to install together
On Sun, July 28, 2013 11:33, Andreas Beckmann wrote: On 2013-07-28 09:46, Thijs Kinkhorst wrote: The module has been integrated into Moodle proper since version 2.3. I'm reassigning the bug to moodle-book and will request removal. Removal will be one thing, but moodle needs to add Breaks+Replaces or Conflicts+Replaces to get rid of it as well and avoid overwrites on partial upgrades or depending on the upgrade order. I'll add those for completeness in unstable; it won't affect other distributions anyway since Moodle was not in wheezy nor will moodle-book ever be in jessie. Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714362: diff for 1.2.5-2.4 NMU
Hi Roberto,
Here's the diff I used in the 1.2.5-2.4 NMU.
Cheers,
Thijsdiff -u php-radius-1.2.5/radius-1.2.5/radius.c php-radius-1.2.5/radius-1.2.5/radius.c
--- php-radius-1.2.5/radius-1.2.5/radius.c
+++ php-radius-1.2.5/radius-1.2.5/radius.c
@@ -541,23 +541,24 @@
/* {{{ proto string radius_get_vendor_attr(data) */
PHP_FUNCTION(radius_get_vendor_attr)
{
- int res, vendor;
- const void *data;
+ int vendor;
+ const void *data, *raw;
size_t len;
+ unsigned char type;
+ size_t data_len;
- if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, s, data, len) == FAILURE) {
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, s, raw, len) == FAILURE) {
return;
}
- res = rad_get_vendor_attr(vendor, data, len);
- if (res == -1) {
+ if (rad_get_vendor_attr(vendor, type, data, data_len, raw, len) == -1) {
RETURN_FALSE;
} else {
array_init(return_value);
- add_assoc_long(return_value, attr, res);
+ add_assoc_long(return_value, attr, type);
add_assoc_long(return_value, vendor, vendor);
- add_assoc_stringl(return_value, data, (char *) data, len, 1);
+ add_assoc_stringl(return_value, data, (char *) data, data_len, 1);
return;
}
}
diff -u php-radius-1.2.5/debian/changelog php-radius-1.2.5/debian/changelog
--- php-radius-1.2.5/debian/changelog
+++ php-radius-1.2.5/debian/changelog
@@ -1,3 +1,11 @@
+php-radius (1.2.5-2.4) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * Fix security issue in radius_get_vendor_attr()
+(CVE-2013-2220, closes: #714362)
+
+ -- Thijs Kinkhorst th...@debian.org Thu, 25 Jul 2013 14:28:53 +0200
+
php-radius (1.2.5-2.3) unstable; urgency=high
* Non-maintainer upload.
only in patch2:
unchanged:
--- php-radius-1.2.5.orig/radius-1.2.5/radlib.c
+++ php-radius-1.2.5/radius-1.2.5/radlib.c
@@ -898,15 +898,24 @@
}
int
-rad_get_vendor_attr(u_int32_t *vendor, const void **data, size_t *len)
+rad_get_vendor_attr(u_int32_t *vendor, unsigned char *type, const void **data, size_t *len, const void *raw, size_t raw_len)
{
struct vendor_attribute *attr;
- attr = (struct vendor_attribute *)*data;
+ if (raw_len sizeof(struct vendor_attribute)) {
+ return -1;
+ }
+
+ attr = (struct vendor_attribute *) raw;
*vendor = ntohl(attr-vendor_value);
+ *type = attr-attrib_type;
*data = attr-attrib_data;
*len = attr-attrib_len - 2;
+ if ((attr-attrib_len + 4) raw_len) {
+ return -1;
+ }
+
return (attr-attrib_type);
}
only in patch2:
unchanged:
--- php-radius-1.2.5.orig/radius-1.2.5/radlib_vs.h
+++ php-radius-1.2.5/radius-1.2.5/radlib_vs.h
@@ -74,7 +74,7 @@
struct rad_handle;
-int rad_get_vendor_attr(u_int32_t *, const void **, size_t *);
+int rad_get_vendor_attr(u_int32_t *, unsigned char *, const void **, size_t *, const void *, size_t);
int rad_put_vendor_addr(struct rad_handle *, int, int, struct in_addr);
int rad_put_vendor_attr(struct rad_handle *, int, int, const void *,
size_t);
Bug#717476: phpmyadmin: breaks apache starting with invalid config file
On Sun, July 21, 2013 10:46, Norbert Preining wrote: Package: phpmyadmin Version: 4:4.0.4.1-1 Severity: critical Justification: breaks unrelated software Hi, recently I realized that apache does not start anymore, doing the suggested configtest I get: $ env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin /usr/sbin/apache2ctl configtest AH00526: Syntax error on line 3 of /etc/apache2/conf-enabled/phpmyadmin.conf: Invalid command 'Alias', perhaps misspelled or defined by a module not included in the server configuration Action 'configtest' failed. The Apache error log may have more information. Apparently your installation does not have mod_alias enabled. Using mod_alias to configure web applications is the Debian webapps policy compliant way to do it. The Debian Apache maintainers describe that web applications can rely unconditionally on the presence of mod_alias: http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/PACKAGING;hb=master#l194 Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714362: security issue in radius_get_vendor_attr()
Package: php-radius Severity: serious Tags: security patch Hi, A new upstream release of php-radius is available which fixes a security issue. http://pecl.php.net/package-info.php?package=radiusversion=1.2.7 The relevant patch is https://github.com/LawnGnome/php-radius/commit/13c149b051f82b709e8d7cc32111e84b49d57234 A CVE id has been requested and will follow. Can you please fix this issue for unstable, and see if you can prepare updates for (old)stable? thanks, Thijs -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712744: gnupg-agent: Doesn't call prctl(PR_SET_DUMPABLE, 0, 0, 0, 0)
severity 712744 normal tags 712744 -security +moreinfo thanks Hi Samuel, gpg-agent could do prctl(PR_SET_DUMPABLE, 0, 0, 0, 0) to protect user secrets from appearing in coredumps or being stolen using ptrace(), like ssh-agent does. Unfortunately it doesn't yet do this. gpg-agent uses setrlimit to prevent core dumps. Is there any indication that this is not sufficient? Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Bug#710651: [Pkg-gnupg-maint] Bug#710651: Bug#710651: gnupg: FTBFS: ../../util/regcomp.c:528:20: error: unknown type name 'preg'
Op maandag 3 juni 2013 00:53:16 schreef Stephen Kitt: Rest assured, it still supports KR function definitions. This is a combination of failures... On Windows, errcode is typedef'ed as int; mingw-w64 added this recently. This combined with the KR-style function declaration means gcc can't compile regcomp.c! The attached quilt patch fixes this. Thanks for the patch! However, I'm having trouble to reproduce the issue in up to date sid, although gcc-mingw-w64-i686 doesn't seem to have been changed recently. gnupg just builds fine in cowbuilder for me. Is there anything special I need to do to reproduce it? Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Bug#713973: phpmyadmin: Fatal error Call to a member function getPresence() on a non-object on login
severity 713973 important thanks On Mon, June 24, 2013 14:45, Dmitriy wrote: Package: phpmyadmin Version: 4:4.0.3-1 Severity: grave Tags: upstream Justification: renders package unusable Dear Maintainer, When trying to submit the log in form using Iceweasel or Chromium I get fatal error: Fatal error: Call to a member function getPresence() on a non-object in /usr/share/phpmyadmin/libraries/navigation/NavigationTree.class.php on line 1047 Thanks for the report. I cannot reproduce the issue instantly here. Do you have any more information about the specifics of your list of databases and which setting you're using that affect this list? Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708245: backuppc: Upgrade from squeeze : backup fails with Failed to create directory
severity 708245 important tags 708245 moreinfo thanks The bug filer hasn't provided the requested info in over two weeks. If TopDir wasn't defined, how would that happen? Failure to update the config from an a version created by an even older release? User error? Something else? My backuppc upgrade from squeeze to wheezy did not have this problem, that I can recall. If the issue does not affect all users, shouldn't this be downgraded from grave to important? As it stands, backuppc is on the Candidates for removal from testing (2013-06-04) due to this bug's severity (see 51add842.9090...@thykier.net). Agreed; I'm downgrading the bug on these grounds. I'll monitor our upcoming upgrade of BackupPC to Wheezy and report back then. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711352: ships default config which enables automatic survey participation
Package: drbd8-utils Version: 8.3.13-2 Severity: serious Hi, drdb has a usage survey in which the software connects to a remote server. Participation in this survey is controlled via the 'usage-count' option: # Participate in DRBD's online usage counter at http://usage.drbd.org # possilbe options: ask, yes, no. Default is ask. In case you do not # know, set it to ask, and follow the on screen instructions later. The default 'ask' seems to be a good compromise between user privacy and the gathering of statistics. However, the Debian package ships with a default config file which contains: usage-count yes; which means that information about the installed system is already sent (leaked if you wish) before the user even got to choose whether they want this. This really should not be set to yes by default in Debian; 'ask', the default, seems most appropriate. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585448: NMUdiff for 0.3.6+nmu2
Hi, Please find attached the diff for the NMU to oldstable-proposed-updates. Cheers, Thijs dpkg-ruby_585448.debdiff Description: Binary data
Bug#710651: [Pkg-gnupg-maint] Bug#710651: gnupg: FTBFS: ../../util/regcomp.c:528:20: error: unknown type name 'preg'
On Sat, June 1, 2013 18:38, Andrey Rahmatullin wrote:
On Fri, May 31, 2013 at 08:37:24PM +0200, David Suárez wrote:
i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../../util -I.. -I..
-I../../include -I../../intl-g -Os -fno-omit-frame-pointer -Wall
-Wno-pointer-sign -MT regex.o -MD -MP -MF .deps/regex.Tpo -c -o
regex.o ../../util/regex.c
In file included from ../../util/regex.c:50:0:
../../util/regcomp.c:528:20: error: unknown type name 'preg'
../../util/regcomp.c:528:26: error: unknown type name 'errbuf'
../../util/regcomp.c:528:34: error: unknown type name 'errbuf_size'
../../util/regcomp.c:533:1: error: expected identifier or '(' before
'{' token
The code:
size_t
regerror (errcode, preg, errbuf, errbuf_size)
int errcode;
const regex_t *preg;
char *errbuf;
size_t errbuf_size;
{
So it looks like the i686-w64-mingw32-gcc used doesn't support KR
function
definitions?
I'm adding Didier to Cc.
Thijs
Didier Raboud o...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679686: missing symvers/libvers (or soversion) for new librbd1
Hi Laszlo, What is the status of the ceph packages and this bug? It seems there are problems building the release currently in unstable, but do you think that a new version can be uploaded to address this? Would be great to see ceph back in jessie. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585448: Fix libdpkg-ruby1 in squeeze?
Hi Ryan, I think an upload to the next squeeze point update with this patch is in order to prevent this upgrading problem. Are you willing/have time to create such an upload? I can make an NMU if you prefer that. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692613: [php-maint] Bug#692613: php5: non-free files in upstream tarball (The Software shall be used for Good, not Evil)
On Mon, May 13, 2013 13:01, Ondrej Sury wrote: OK, it's very much annoying (since the tarball is huge and the updated module won't hit PHP 5.5), but I will comply. This seems like a paper exercise which I doubt is worth our efforts. I seems extremely unlikely that the author of the software could have a legally valid case where a judge would positively decide that a use case is objectively Evil and in violation of this license. I don't see a practical risk to anyones freedom being in jeopardy here. Surely it's an annoying license, so when removing it is opportune we should do it, but in this case the potential gains (if any?) do not seem to outweigh the cost. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692613: [php-maint] Bug#692613: php5: non-free files in upstream tarball (The Software shall be used for Good, not Evil)
On Mon, May 13, 2013 15:31, Walter Landry wrote: Thijs Kinkhorst th...@debian.org wrote: On Mon, May 13, 2013 13:01, Ondrej Sury wrote: OK, it's very much annoying (since the tarball is huge and the updated module won't hit PHP 5.5), but I will comply. This seems like a paper exercise which I doubt is worth our efforts. I seems extremely unlikely that the author of the software could have a legally valid case where a judge would positively decide that a use case is objectively Evil and in violation of this license. I don't see a practical risk to anyones freedom being in jeopardy here. Surely it's an annoying license, so when removing it is opportune we should do it, but in this case the potential gains (if any?) do not seem to outweigh the cost. The problem is not whether Debian can distribute the software. The problem is that the tarball that Debian distributes to users must not contain non-free bits. This is hardly the first time that this has come up [1]. Yes, it is annoying for the packager. But it is useful for the user to know that, whatever is in the tarball, they will not have to do any forensic analysis before using the tarball. My argument is not about this general idea but against this specific case for this license. Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708164: nginx proxy_pass buffer overflow (CVE-2013-2070)
Package: nginx Version: 1.2.1-2.2 Severity: serious Tags: security patch Hi, A buffer overflow in the proxy_pass module has been reported by Nginx upstream, and a patch made available. Please see: http://www.openwall.com/lists/oss-security/2013/05/13/3 The issue is already fixed in the version in sid, and as far as I can see the code is not present in squeeze. Can you ensure that (a) the RC bug against nginx in sid is dealt with so the fixed package can migrate to jessie, and (b) prepare an update to wheezy? Thanks, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706188: github-cli: missing dependency on git
fwiw, at a five day delay plus two days in unstable, the upload would theoretically be eligible to migrate the night before the release. The chances of that upload getting unblocked are practically nil unless the release is delayed for some reason. Given that the maintainer is on LowThresholdNMU the triviality of the change, I've rescheduled it to 0-day. Please unblock. Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704645: [Pkg-gnupg-maint] Processed: Re: Bug#704613: cdebootstrap: signature verification bypass with manipulated InRelease file
retitle 704645 gpg --verify suggests entire file was verified, even if file contains auxiliary data thanks Hi, After some discussion I've come to the following description of this request (submitters, please correct or augment where necessary): gpg --verify filename returns a binary answer: has a valid signature, doesn't have a valid signature. This is described in the man page as Assume that the first argument is a signed file or a detached signature and verify it without generating any output. This works well for detached signatures or for files that contain only a clearsigned message and nothing else. The problem comes in when somewhere in a file a valid block of clearsigned text is present, but this block is preceded or followed by auxiliary data. Running gpg --verify on that file results in an assertion that the file has a valid signature while in fact only a part of the file was verified with no way of knowing which. As it turned out, implementors have been assuming that running gpg --verify on a file yields enough information to further process that file as if all data in it were correctly signed. It has been argued that running gpg --verify in its current form on a clearsigned file is useless as it only tells you that that something somewhere in that file has a valid signature. (There is currently a working way to verify and extract only the signed data, which is by using --status-fd and parsing its output.) I'm seeking input from GnuPG upstream for their view on this case. Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Bug#659390: bug#670232
Hi, I looked into it and after populating the database by hand and also fixing manually the initial issue [1]. It doesn't work anyway, the following errors appear: [Mon Apr 01 02:15:47 2013] [error] [client x.x.x.x] PHP Warning: include(bookmarks.tpl.php): failed to open stream: No such file or directory in /usr/share/php/SemanticScuttle/Model/Template.php on line 89 [Mon Apr 01 02:15:47 2013] [error] [client x.x.x.x] PHP Warning: include(): Failed opening 'bookmarks.tpl.php' for inclusion (include_path='/etc/semanticscuttle/templates/default:/etc/semanticscuttle/templates/default:.:/usr/share/php:/usr/share/pear:/usr/share/php/SemanticScuttle/../') in /usr/share/php/SemanticScuttle/Model/Template.php on line 89 I wonder if this package have ever worked (looking at popcorn doesn't look like). At this stage, I prefer looking for a nicer replacement of scuttle/semanticscuttle. I doubt a NMU would have small changes, I would go with removing semanticscuttle from Wheezy. I got it to work (that is, not throw obvious immediate errors) from a clean install by fixing three separate problems: 1) Initial issue reported in bug: No default configuration file config.default.php found. This is really, really strange. Fixed by creating a symlink from /usr/share/semanticscuttle/data/config.default.php to /usr/share/php/data/SemanticScuttle/ 2) Database not populated. This is because the dbconfig-common file is named /usr/share/dbconfig-common/data/semanticscuttle/install/tables.sql, while it should be named /usr/share/dbconfig-common/data/semanticscuttle/install/mysql. 3) Spews strict standards errors to the browser. Fixed by setting $debugMode to false in /etc/semanticscuttle/config.php. After fixing these three errors I didn't see any immediate (!) errors anymore. So while I think each one of those could be fixed by a one or few lines change in the packaging, it's more that the package was apparently in wheezy for over a year in this state, with these three rather orthogonal but immediately obvious errors. This, combined with the fact that semanticscuttle was never in a stable release and the maintainer has agreed already with removal from wheezy as an option, leads me to the conclusion that removal from wheezy is the best option at this point. Hence, I'm filing a removal request with the release team. Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Bug#704300: doesn't work with PHP version in wheezy
severity 704300 important thanks Hi, Scuttle doesn't work in Wheezy, all you get are some lovely PHP messages: Strict Standards: Non-static method ServiceFactory::getServiceInstance() should not be called statically in /usr/share/scuttle/www/index.php on line 23 On a production system, strict standards messages (which have log priority notice) should not be displayed but just logged. Debian's shipped php.ini is configured this way. And if you wish to override that, it's still possible to change the setting just for scuttle if you wish. So yes, this is a problem as it logs a lot of stuff, but not a release critical issue for wheezy, I'd say. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704300: doesn't work with PHP version in wheezy
tags 704300 patch pending thanks On Mon, April 1, 2013 10:12, Ana Guerrero wrote: On Mon, Apr 01, 2013 at 10:06:48AM +0200, Thijs Kinkhorst wrote: On Mon, April 1, 2013 09:59, Thijs Kinkhorst wrote: On Mon, April 1, 2013 09:55, Ana Guerrero wrote: On Mon, Apr 01, 2013 at 09:41:54AM +0200, Thijs Kinkhorst wrote: Yes, but I'm making the point that strict standards messages would normally and by default be logged, not output to the browser... Cool, then the problem has an easy fix as hinted by Jan? :) (I can't test that right now). In the current state, the application is not usable, that's a RC bug... I'm saying it can be fixed by changing the value of error_reporting in /etc/php5/*/php.ini back to something that doesn't include E_STRICT. Which is the default in the php.ini Debian ships and which is the recommended production value. So it's not only fixed easily, it should not occur in the default and recommended PHP configuration. Yes, not ideal indeed, but that's why it's still an important bug. Sorry, I have to retract all this. What I said about PHP was correct, but it seems that scuttle overrides these settings in its own code :/ Therefore the default PHP settings are not relevant. So this is indeed RC. Yes, the change proposed by Jan might fix it but I can't test right now. I've made attached fix which fixes it (imo) correctly: follow the local admin's wishes with respect to error_reporting. This ensures that scuttle works in default configurations and generally does whatever the admin configures in php.ini. I have confirmed that the problem goes away on a default wheezy system. Marcelo, given the point in the freeze timeframe, I've uploaded this to DELAYED/5. Let me know if you want me to delay/cancel it or if you want me to reduce the delay and upload immediately. Cheers, Thijs scuttle.debdiff Description: Binary data
Bug#699888: new nss packages fixing cve-2013-1620
On Sat, March 16, 2013 22:35, Mike Hommey wrote: On Sat, Mar 16, 2013 at 04:53:00PM -0400, Michael Gilbert wrote: We can consider to put it into a DSA in which the text details how to disable the options if they cause trouble. An alternative is to put it into spu instead, where it may be slightly (probably just slightly) more acceptable to change behaviour than in a DSA. But it will also mean having to wait a few months at least. Do you know if RHEL is pushing it through the security channels or the stable updates channels? For what its worth, ubuntu pushed 3.14 to all of its releases through their security update channel: http://www.ubuntu.com/usn/usn-1763-1 It also looks like bumping nspr was also required: http://www.ubuntu.com/usn/usn-1763-2 IIRC, it's not required, but one of the releases between 4.9.2 and 4.9.5 fixed some issue that might be worth fixing at this point. Do you want me to look at preparing those updates for squeeze? I'd rather know what we do wrt md5, ssl2 and beast. In the meantime, this should really be fixed in unstable. Mike, do you want to do a maintainer upload, or is ok if I go ahead with the nmu? Likewise, I'd rather know what we do wrt md5, and while at it, cacert (the cert of which uses a md5 signature at the moment, so it effectively doesn't work ; see bug 682470) before uploading, so as to avoid doing two uploads. What information is still lacking to make a decision on that? Thijs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703128: davical: errors when accessing some php files as non-admin user
severity 703128 important thanks Op zaterdag 16 maart 2013 00:45:18 schreef Christoph Anton Mitterer: Marking this as important and security, as such ungracefull errors tend to be prone to attacks. Rightly so. These issues indeed should be fixed to prevent any security issues proactively, and it would be great even, if possible, to fix them in wheezy. However, there are no concrete security holes known so this is a matter of hardening rather than a real vulnerability. 2) setup.php - user get's the whole setup page... including the ability to see the whole phpinfo() output... which contains all kind of private environment information that might be used by an attacker. Therefore the severity: grave. I disagree about the severity of this. Yes, phpinfo() shouldn't be shown. However, nearly all of the 'private environment information' is fully predictable on a Debian system (paths, php versions, library versions, you name it, it's all trivially known already). Add to that that it's not available to the world but only to authorised users. This shouldn't happen, but does not justify 'grave'. Nonetheless, I urge the maintainer to take this up with upstream and if a straightforward patch is available, apply it and request unblock. Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Bug#699888: new nss packages fixing cve-2013-1620
Op zaterdag 16 maart 2013 09:37:25 schreef Yves-Alexis Perez: On sam., 2013-03-16 at 08:34 +0100, Mike Hommey wrote: So, here are a few more info: - 3.13 disabled SSL 2.0 by default - 3.13 added a defense against the Rizzo and Duong attack, which is known to break applications. It can be disabled easily. - 3.14 removed support for md5 signature of certificates. These are the main compatibility issues we'd have with bumping NSS to 3.14 in stable (where it's 3.12) and testing (where it's 3.13). All of them can be fixed by turning some constants to PR_FALSE. That would leave us with the possibility of pure bugs emerging. I think we should take that risk, especially considering the fixes we can't backport. That would also fix bug 697865 (that one is backportable, but that's painful and risky). FWIW, AFAIK, RedHat is pushing 3.14 to all its long term support releases. I know it's invasive but I'm not sure we won't have to do anyway during Wheezy support life. I mean, nobody should do SSL 2.0 at all anyway (OpenSSL already disable SSLv2 in 1.0.1, even though it doesn't matter for browsers), and md5 for certificates is known broken too. Well, wheezy already has 3.13 so SSLv2 and Rizzo (BEAST) are already gone in wheezy, right? I'm all for adding the md5 part aswell to wheezy. Indeed, we need to be proactive with this before it becomes a stable release. So let's go with 3.14 for wheezy. I'ts definitely late for such surprise for users, but will it be better if it's done during the life of a stable release? I think the main question is if we can push this out to users of squeeze. I'm not against that per se. If disabling SSLv2 hurts someone seriously, it's about time because they'd have a big problem otherwise. This is also the case for BEAST, but perhaps the risk of it breaking something legitimate is higher. We can consider to put it into a DSA in which the text details how to disable the options if they cause trouble. An alternative is to put it into spu instead, where it may be slightly (probably just slightly) more acceptable to change behaviour than in a DSA. But it will also mean having to wait a few months at least. Do you know if RHEL is pushing it through the security channels or the stable updates channels? Cheers, Thijs signature.asc Description: This is a digitally signed message part.
Bug#702524: gawk: Depends should really be Pre-Depends
Hi,
| -Change Pre-Depends to Depends (OK now that base-files Pre-Depends: awk)
This is not correct and needs to be reverted, since it means that gawk
might be unpacked before its dependencies during upgrades. If the awk
alternative is set to gawk, other packages which are unpacked in the
same run and use awk in their pre{inst,rm} scripts which fail. This is
not unlikely to happen in squeeze - wheezy upgrades, since gawk in
wheezy gained a new dependency on libsigsegv2.
As Jeroen's sponsor I discussied this issue with him when that upload was
prepared. The conclusion back then was as follows:
Op maandag 21 mei 2012 11:11:40 schreef Jeroen Schot:
- Alle awk's (mawk, original-awk, gawk) gebruiken pre-depends.
- 'awk' bevindt zich in de Essential closure (base-files pre-depends: awk).
Na wat research geloof ik toch dat de pre-depends weg kan.
Oorspronkelijke reden is te vinden in deze mail [1] in debian-policy
1998: base-files had toen een depends: awk. Dit was eigenlijk subtiel
fout en werd gecorrigeerd in 2008 [2]. Sindsdien is de pre-depends
niet meer nodig.
[1]: http://lists.debian.org/debian-policy/1998/02/msg00195.html
[2]: http://lists.debian.org/debian-devel/2008/07/msg01028.html
So this is how we arrived at the conclusion that it would be possible to drop
it.
I've pinged Jeroen oob about this bug but didn't receive a response yet. Given
the point in the release cycle, I think the safe approach for now is to revert
the change and re-add the Pre-depends. We can always reopen the issue post-
release if further discussion on the necessity of the pre-depends is desired.
I'll upload a package with the change soon.
Cheers,
Thijs
signature.asc
Description: This is a digitally signed message part.
Bug#702524: gawk: Depends should really be Pre-Depends
Hi,
Here's the diff for the gawk I'm going to upload.
Cheers,
Thijs
diff -Nru gawk-4.0.1+dfsg/debian/changelog gawk-4.0.1+dfsg/debian/changelog
--- gawk-4.0.1+dfsg/debian/changelog 2012-05-21 10:36:06.0 +0200
+++ gawk-4.0.1+dfsg/debian/changelog 2013-03-16 12:43:50.0 +0100
@@ -1,3 +1,10 @@
+gawk (1:4.0.1+dfsg-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Change Depends back to Pre-Depends (closes: #702524).
+
+ -- Thijs Kinkhorst th...@debian.org Sat, 16 Mar 2013 12:31:51 +0100
+
gawk (1:4.0.1+dfsg-2) unstable; urgency=low
* debian/control:
diff -Nru gawk-4.0.1+dfsg/debian/control gawk-4.0.1+dfsg/debian/control
--- gawk-4.0.1+dfsg/debian/control 2012-05-21 10:29:16.0 +0200
+++ gawk-4.0.1+dfsg/debian/control 2013-03-16 12:33:24.0 +0100
@@ -16,7 +16,8 @@
Architecture: any
Multi-Arch: foreign
Provides: awk
-Depends: ${misc:Depends}, ${shlibs:Depends}
+Pre-Depends: ${shlibs:Depends}
+Depends: ${misc:Depends}
Suggests: gawk-doc
Description: GNU awk, a pattern scanning and processing language
`awk', a program that you can use to select particular records in a
signature.asc
Description: This is a digitally signed message part.
Bug#702872: Segfaults immediately on attempting a radius connection
Verified that squeeze is not affected. Although it contains the same php5-radius code, the version of PHP itself in squeeze does not trigger the segfault. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
