Debian binary debdiff for tor

Version in base suite: 0.4.7.16-1

Base version: tor_0.4.7.16-1

Target version: tor_0.4.9.6-0+deb12u1

Base files: tor-dbgsym_0.4.7.16-1_i386.deb tor_0.4.7.16-1_i386.deb

Target files: tor-dbgsym_0.4.9.6-0+deb12u1_i386.deb tor_0.4.9.6-0+deb12u1_i386.deb

Postinst files of package tor: lines which differ

Postinst files of package tor: lines which differ

which

command -v restorecon >/dev/null 2>&1 && restorecon /var/lib/tor

which

command -v restorecon >/dev/null 2>&1 && restorecon /var/log/tor

move_away_keys=0

[--]

if [ "$1" = "configure" ] &&

[ -e /var/lib/tor/keys ] &&

[ ! -z "$2" ]; then

if dpkg --compare-versions "$2" lt 0.1.2.19-2; then

move_away_keys=1

elif dpkg --compare-versions "$2" gt 0.2.0 &&

dpkg --compare-versions "$2" lt 0.2.0.26-rc; then

move_away_keys=1

if [ "$move_away_keys" = "1" ]; then

echo "Retiring possibly compromised keys. See /usr/share/doc/tor/NEWS.Debian.gz"

echo "and /var/lib/tor/keys/moved-away-by-tor-package/README.REALLY for"

echo "further information."

if ! [ -d /var/lib/tor/keys/moved-away-by-tor-package ]; then

mkdir /var/lib/tor/keys/moved-away-by-tor-package

cat > /var/lib/tor/keys/moved-away-by-tor-package/README.REALLY << EOF

It has been discovered that the random number generator in Debian's

openssl package is predictable. This is caused by an incorrect

Debian-specific change to the openssl package (CVE-2008-0166). As a

result, cryptographic key material may be guessable.

[--]

See Debian Security Advisory number 1571 (DSA-1571) for more information:

http://lists.debian.org/debian-security-announce/2008/msg00152.html

[--]

The Debian package for Tor has moved away the onion keys upon package

upgrade, and it will have moved away your identity key if it was created

in the affected timeframe. There is no sure way to automatically tell

if your key was created with an affected openssl library, so this move

is done unconditionally.

[--]

If you have restarted Tor since this change (and the package probably

did that for you already unless you configured your system differently)

then the Tor daemon already created new keys for itself and in all

likelyhood is already working just fine with new keys.

[--]

If you are absolutely certain that your identity key was created with

a non-affected version of openssl and for some reason you have to retain

the old identity, then you can move back the copy of secret_id_key to

/var/lib/tor/keys. Do not move back the onion keys, they were created

only recently since they are temporary keys with a lifetime of only a few

days anyway.

[--]

Sincerely,

Peter Palfrader, Tue, 13 May 2008 13:32:23 +0200

EOF

for f in secret_onion_key secret_onion_key.old; do

if [ -e /var/lib/tor/keys/"$f" ]; then

mv -v /var/lib/tor/keys/"$f" /var/lib/tor/keys/moved-away-by-tor-package/"$f"

done

if [ -e /var/lib/tor/keys/secret_id_key ]; then

id_mtime=`stat -c %Y /var/lib/tor/keys/secret_id_key`

sept=`date -d '2006-09-10' +%s`

if [ "$id_mtime" -gt "$sept" ] ; then

mv -v /var/lib/tor/keys/secret_id_key /var/lib/tor/keys/moved-away-by-tor-package/secret_id_key

[--]

# clean out apparmor policy files that we shipped with

# Tor 0.2.3.16-alpha-1 in experimental and

# Tor 0.2.3.17-beta-1 in unstable.

if [ "$1" = "configure" ] &&

[ -e /etc/apparmor.d/usr.sbin.tor ] &&

[ ! -z "$2" ] &&

dpkg --compare-versions "$2" le 0.2.3.17-beta-1; then

checksum="`md5sum /etc/apparmor.d/usr.sbin.tor | awk '{print $1}'`"

pkg_md5="`dpkg-query -W -f='${Conffiles}' tor | awk '$1=="/etc/apparmor.d/usr.sbin.tor" {print $2}'`"

if [ "$checksum" = "$pkg_md5" ]; then

if command -v apparmor_parser > /dev/null 2>&1 ; then

apparmor_parser --remove -T -W /etc/apparmor.d/usr.sbin.tor || true

[--]

rm -f "/etc/apparmor.d/usr.sbin.tor"

rm -f "/etc/apparmor.d/disable/usr.sbin.tor" || true

rm -f "/etc/apparmor.d/force-complain/usr.sbin.tor" || true

rm -f "/etc/apparmor.d/local/usr.sbin.tor" || true

rmdir /etc/apparmor.d/local 2>/dev/null || true

rmdir /etc/apparmor.d 2>/dev/null || true