Re: [stable] openssl rfc5746 / renegotiation support
On Fri, 19 Nov 2010, Philipp Kern wrote:
When we throw out tor 0.2.0.x from lenny, are we replacing it with the
version currently in lenny-volatile?
I'd be ok with that.
Ok, I'll upload it later today. I'll include the no-coredump patch too,
unless somebody shouts.
Patches attached.
--
| .''`. ** Debian GNU/Linux **
Peter Palfrader | : :' : The universal
http://www.palfrader.org/ | `. `' Operating System
| `-http://www.debian.org/
From 0856f24277cd984231418420fc7a9dbf7e32bf86 Mon Sep 17 00:00:00 2001
From: Peter Palfrader pe...@palfrader.org
Date: Sat, 20 Nov 2010 11:30:04 +0100
Subject: [PATCH 1/2] Changelog for upload to lenny as 0.2.1.26-1~lenny+1
---
debian/changelog | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 62639b7..047276b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,22 @@
+tor (0.2.1.26-1~lenny+1) stable; urgency=low
+
+ * Upload to stable, since a potential future security upload
+for openssl will break Tor 0.2.0.35, the version currently in
+stable.
+.
+This libssl update will change how openssl does renegotiation,
+and Tor 0.2.0.x relies on the old behaviour but does not yet
+know how to tell openssl to stick to it. The 0.2.1.x tree
+has special support for newer openssls and sets the proper, new
+flags so libssl continues to provide the old renegotiation
+features.
+.
+The old-style renegotiation feature is potentially dangerous
+in some cases, but it is believed that Tor does everything
+correctly and thus can use it safely.
+
+ -- Peter Palfrader wea...@debian.org Sat, 20 Nov 2010 11:24:32 +0100
+
tor (0.2.1.26-1~lennyvolatile1) lenny-volatile; urgency=low
* Upload to lenny-volatile.
--
1.7.1
From 3b9ecd3001478b15a0c418f4e825d4fea98de426 Mon Sep 17 00:00:00 2001
From: Peter Palfrader pe...@palfrader.org
Date: Sat, 20 Nov 2010 11:32:36 +0100
Subject: [PATCH 2/2] disable coredumps by default
Up until now the init script (or actually /etc/default/tor) raised
the ulimit for coredumps to unlimited, so that Tor would produce
coredumps on assert errors or segfaults. Coredumps however can
leak sensitive information, like cryptographic session keys and
clients' data should the core files get into the wrong hands. As
such it seems prudent to only enable coredumps if the user or
operator explicitly asks for them, and knows what to do with them.
Also include a cron.weekly job that removes old coredumps from /var/lib/tor.
This action can be disabled in etc/default/tor.
Cherry-picked from debian-0.2.1. Original commit is
270ed52406acd28eea57114acf04ba7d63cedad5.
Conflicts:
debian/changelog
---
debian/changelog | 10 ++
debian/rules |1 +
debian/tor.cron.weekly | 14 ++
debian/tor.default | 20 ++--
4 files changed, 43 insertions(+), 2 deletions(-)
create mode 100755 debian/tor.cron.weekly
diff --git a/debian/changelog b/debian/changelog
index 047276b..1ce1cd6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -14,6 +14,16 @@ tor (0.2.1.26-1~lenny+1) stable; urgency=low
The old-style renegotiation feature is potentially dangerous
in some cases, but it is believed that Tor does everything
correctly and thus can use it safely.
+ * No longer set ulimit -c to unlimited:
+Up until now the init script (or actually /etc/default/tor) raised
+the ulimit for coredumps to unlimited, so that Tor would produce
+coredumps on assert errors or segfaults. Coredumps however can
+leak sensitive information, like cryptographic session keys and
+clients' data should the core files get into the wrong hands. As
+such it seems prudent to only enable coredumps if the user or
+operator explicitly asks for them, and knows what to do with them.
+ * Also include a cron.weekly job that removes old coredumps from
+/var/lib/tor. This action can be disabled in /etc/default/tor.
-- Peter Palfrader wea...@debian.org Sat, 20 Nov 2010 11:24:32 +0100
diff --git a/debian/rules b/debian/rules
index f5aaa95..5c6a302 100755
--- a/debian/rules
+++ b/debian/rules
@@ -187,6 +187,7 @@ binary-common:
dh_installexamples
dh_installlogrotate
dh_installinit
+ dh_installcron
dh_installman
dh_link
dh_strip --dbg-package=tor-dbg
diff --git a/debian/tor.cron.weekly b/debian/tor.cron.weekly
new file mode 100755
index 000..ae4469d
--- /dev/null
+++ b/debian/tor.cron.weekly
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+set -e
+set -u
+
+DEFAULTSFILE=/etc/default/tor
+
+if [ -f $DEFAULTSFILE ] ; then
+ . $DEFAULTSFILE
+fi
+
+if [ ${CLEANUP_OLD_COREFILES:-} = y ] ; then
+ find /var/lib/tor -mindepth 1 -maxdepth 1 -type f -mtime +21 -user debian-tor -regex '.*/core\(\.[0-9]+\)?' -exec rm '{}' +
+fi
diff --git a/debian/tor.default b/debian/tor.default
index
Re: [stable] openssl rfc5746 / renegotiation support
On Sat, 20 Nov 2010, Peter Palfrader wrote:
When we throw out tor 0.2.0.x from lenny, are we replacing it with the
version currently in lenny-volatile?
I'd be ok with that.
Ok, I'll upload it later today. I'll include the no-coredump patch too,
unless somebody shouts.
Uploaded just the volatile version, with no further changes as per your
request.
interdiff and debdiff attached.
Thanks,
weasel
--
| .''`. ** Debian GNU/Linux **
Peter Palfrader | : :' : The universal
http://www.palfrader.org/ | `. `' Operating System
| `-http://www.debian.org/
diff -u tor-0.2.1.26/debian/changelog tor-0.2.1.26/debian/changelog
--- tor-0.2.1.26/debian/changelog
+++ tor-0.2.1.26/debian/changelog
@@ -1,3 +1,22 @@
+tor (0.2.1.26-1~lenny+1) stable; urgency=low
+
+ * Upload to stable, since a potential future security upload
+for openssl will break Tor 0.2.0.35, the version currently in
+stable.
+.
+This libssl update will change how openssl does renegotiation,
+and Tor 0.2.0.x relies on the old behaviour but does not yet
+know how to tell openssl to stick to it. The 0.2.1.x tree
+has special support for newer openssls and sets the proper, new
+flags so libssl continues to provide the old renegotiation
+features.
+.
+The old-style renegotiation feature is potentially dangerous
+in some cases, but it is believed that Tor does everything
+correctly and thus can use it safely.
+
+ -- Peter Palfrader wea...@debian.org Sat, 20 Nov 2010 11:24:32 +0100
+
tor (0.2.1.26-1~lennyvolatile1) lenny-volatile; urgency=low
* Upload to lenny-volatile.
diff -u tor-0.2.1.26/debian/micro-revision.i
tor-0.2.1.26/debian/micro-revision.i
--- tor-0.2.1.26/debian/micro-revision.i
+++ tor-0.2.1.26/debian/micro-revision.i
@@ -1 +1 @@
-59d3dbb874f0deb3
+0856f24277cd9842
File lists identical (after any substitutions)
Control files of package tor: lines which differ (wdiff format)
---
Version: [-0.2.1.26-1~lennyvolatile1-] {+0.2.1.26-1~lenny+1+}
Control files of package tor-dbg: lines which differ (wdiff format)
---
Depends: tor (= [-0.2.1.26-1~lennyvolatile1)-] {+0.2.1.26-1~lenny+1)+}
Version: [-0.2.1.26-1~lennyvolatile1-] {+0.2.1.26-1~lenny+1+}
Control files of package tor-geoipdb: lines which differ (wdiff format)
---
Depends: tor (= [-0.2.1.26-1~lennyvolatile1)-] {+0.2.1.26-1~lenny+1)+}
Version: [-0.2.1.26-1~lennyvolatile1-] {+0.2.1.26-1~lenny+1+}
Re: [stable] openssl rfc5746 / renegotiation support
Hey release folks, On Tue, 16 Nov 2010, Kurt Roeckx wrote: I would like to add rfc5746 support to openssl in stable, so that CVE-2009-3555 can be fixed. But adding that support means that the old renegotiation doesn't work anymore unless you set an option. There are atleast 2 packages that have an issue with this that I'm currently aware of: - tor: It should always disable the new renegotiation. Running it as a server doesn't work. Newer versions than in stable, like the version in volatile, do work properly with any version of openssl. The maintainer and upstream favour dropping the version currently in stable. What's the verdict here? Are we going to update openssl in stable (either via -security or with the next point release), and if yes, what are we doing with tor? When we throw out tor 0.2.0.x from lenny, are we replacing it with the version currently in lenny-volatile? Cheers, -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101119103548.gs10...@anguilla.noreply.org
Re: [stable] openssl rfc5746 / renegotiation support
On Fri, Nov 19, 2010 at 11:35:48AM +0100, Peter Palfrader wrote: On Tue, 16 Nov 2010, Kurt Roeckx wrote: I would like to add rfc5746 support to openssl in stable, so that CVE-2009-3555 can be fixed. But adding that support means that the old renegotiation doesn't work anymore unless you set an option. There are atleast 2 packages that have an issue with this that I'm currently aware of: - tor: It should always disable the new renegotiation. Running it as a server doesn't work. Newer versions than in stable, like the version in volatile, do work properly with any version of openssl. The maintainer and upstream favour dropping the version currently in stable. What's the verdict here? Are we going to update openssl in stable (either via -security or with the next point release), and if yes, what are we doing with tor? That's up to security. When we throw out tor 0.2.0.x from lenny, are we replacing it with the version currently in lenny-volatile? I'd be ok with that. Kind regards Philipp kern signature.asc Description: Digital signature
Re: [stable] openssl rfc5746 / renegotiation support
On Fri, 19 Nov 2010 11:35:48 +0100, Peter Palfrader wrote: What's the verdict here? Are we going to update openssl in stable (either via -security or with the next point release), and if yes, what are we doing with tor? The decision was made a while back to fix this in an SPU. Kurt put out packages a few weeks ago and called for testing, but I've only seen one response so far. So I think that what needs to happen is a little more testing? Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101119102808.9a4b8a48.michael.s.gilb...@gmail.com
Re: [stable] openssl rfc5746 / renegotiation support
On Fri, Nov 19, 2010 at 10:28:08AM -0500, Michael Gilbert wrote: On Fri, 19 Nov 2010 11:35:48 +0100, Peter Palfrader wrote: What's the verdict here? Are we going to update openssl in stable (either via -security or with the next point release), and if yes, what are we doing with tor? The decision was made a while back to fix this in an SPU. Kurt put out packages a few weeks ago and called for testing, but I've only seen one response so far. So I think that what needs to happen is a little more testing? You might want to point us to that decision. We'd prefer to have this handled by security. Thanks Philipp Kern signature.asc Description: Digital signature
openssl rfc5746 / renegotiation support
Hi, I would like to add rfc5746 support to openssl in stable, so that CVE-2009-3555 can be fixed. But adding that support means that the old renegotiation doesn't work anymore unless you set an option. This has the potentional to break both client and server applications making use of openssl. See the SSL_CTX_set_options manpage for the behaviour and the options you can set. There are atleast 2 packages that have an issue with this that I'm currently aware of: - apache2: It would need an option an admin can turn on to allow insecure renegotiation. - tor: It should always disable the new renegotiation. Running it as a server doesn't work. Newer versions than in stable, like the version in volatile, do work properly with any version of openssl. The maintainer and upstream favour dropping the version currently in stable. Other packages still need to be checked. I think at this point we're not going to be able to check the various packages that might be affected by this before the next point release. So I wonder when the next point release is going to happen, or that we should try and update this via the security archive. Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101116204806.ga14...@roeckx.be
