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 0000000..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 48127cc..1cc0601 100644 --- a/debian/tor.default +++ b/debian/tor.default @@ -34,9 +34,25 @@ RUN_DAEMON="yes" # ARGS="" # -# Comment this out if you do not want to get coredumps +# Uncomment the ulimit call below if you want tor to produce coredumps on +# segfaults and assert errors. # -ulimit -c unlimited +# Keeping coredumps around is some sort of security issue since they +# may leak session keys, sensitive client data and more, should such +# files fall into the wrong hands. Therefore coredumps are not enabled +# by default. +# +# ulimit -c unlimited + +# +# Config option for the weekly cron file: Whether or not to remove old +# coredumps in /var/lib/tor. Coredumps can hold sensitive data, as such +# they probably should not be kept lying around if nobody will ever look +# at them. This option makes /etc/cron.weekly/tor clean out files older +# then three weeks. +# +CLEANUP_OLD_COREFILES=y + # Let the vidalia package override some of our settings. # People who have vidalia installed might not want to run Tor as a system -- 1.7.1