Bug#1071571: mdir: wrong byte count reported in summary

[g1]

Package: mtools
Version: 4.0.33-1+really4.0.32-1
Severity: normal
Tags: upstream patch

The overall byte count shown in the summary is truncated (from the left)
to ten effective digits, and is therefore wrong as soon as it reaches
10 GB (10^10 B):

$ mdir f:abc
 Volume in drive F has no label
 Volume Serial Number is 1234-5678
Directory for F:/abc

. 2024-05-21  13:32 
..2024-05-21  13:32 
f1  30 2024-05-21  13:32 
f2  30 2024-05-21  13:32 
f3  30 2024-05-21  13:32 
f4  30 2024-05-21  13:32 
6 files   2 000 000 000 bytes ** should be 12 000 000 000 **
 17 331 192 064 bytes free

I haven't the time to modify dotted_num() to prevent omission of the most
significant digits, but the following patch is a quick fix for sizes up
to 10 TB - 1.

Best regards,
g.b.

--- mdir.c.old  2021-07-15 14:28:53.0 +0200
+++ mdir.c  2024-05-21 13:18:25.079157668 +0200
@@ -229,8 +229,8 @@
putchar(' ');
else
putchar('s');
-   printf("   %s bytes\n",
-  dotted_num(bytes, 13, ));
+   printf("   %s bytes\n",
+  dotted_num(bytes, 17, ));
if(s1)
free(s1);
}

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-21-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash

Versions of packages mtools depends on:
ii  libc6  2.36-9+deb12u7

mtools recommends no packages.

Versions of packages mtools suggests:
pn  floppyd  

-- no debconf information

Bug#1064634: qemu-system-x86: possible race-condition in qemu nat layer or virtio-net

[g1]

Package: qemu-system-x86
Version: 1:7.2+dfsg-7+deb12u5
Severity: normal
X-Debbugs-Cc: g...@libero.it

I believe I spotted a race condition in virtio-net or qemu/kvm (but
only when virtio-net is involved).

To replicate, one needs a virtualization environment similar to

Host:
- debian 12 x86_64
- caching name server listening on 127.0.0.1

Guest:
- linux/musl or linux/glibc or freebsd or openbsd
- kvm acceleration
- virtio netdev, configured in (default) user-mode
- /etc/resolv.conf:
nameserver 10.0.2.2 i.e. the caching dns in the host
nameserver 192.168.1.123non existent

and run the attached program in the guest.

The program opens a UDP socket, sends out a bunch of (dns) requests,
poll()s on the socket, and then receives the responses.

If a delay is inserted between the sendto() calls, the (unique) response
from the host is received correctly:

$ ./a.out 10.0.2.2 >/dev/null # to warm up the host cache
$ ./a.out 10.0.2.2 delay 192.168.1.123
poll: 1 1 1
recvfrom() 45

recvfrom() -1

If the sento()s are performed in short order, the response packet
gets lost:

$ ./a.out 10.0.2.2 192.168.1.123
poll: 0 1 0
recvfrom() -1
recvfrom() -1

A tcpdump capture on the host side shows no difference between the two cases.

Tcpdump on the guest side is another story: in the good case, it looks like
this

7:32:44.332 IP 10.0.2.15.43276 > 10.0.2.2.53: 33452+ A? example.com. (29)
7:32:44.333 IP 10.0.2.2.53 > 10.0.2.15.43276: 33452 1/0/0 A 93.184.216.34 (45)
7:32:44.349 IP 10.0.2.15.43276 > 192.168.1.123.53: 33452+ A? example.com. (29)

while in the bad case it looks like this

7:32:55.358 IP 10.0.2.15.46537 > 10.0.2.2.53: 33452+ A? example.com. (29)
7:32:55.358 IP 10.0.2.15.46537 > 192.168.1.123.53: 33452+ A? example.com. (29)
7:32:55.358 IP *127.0.0.1*.53 > 10.0.2.15.46537: 33452 1/0/0 A 93.184.216.34 
(45)

where the response packet has wrong src ip.

Looks like a failure of the NAT layer, but it does not happen when
the guest uses another emulated network driver: don't know whether it's
because the relevant code is in virtio-net or because other drivers add
overhead that masks the issue.

There's nothing special in port 53: I was just investigating
a weird failure in name resolution in a MUSL based guest
(https://www.openwall.com/lists/musl/2024/02/17/3) and wrote the program
to mimic MUSL resolver's behaviour.

But it succeeds/fails consistently with a different port, and in all
guests I tried (as long as the emulated network device is virtio-net).

To see the issue, it's important that the response to the first request
is so fast that it's simultaneous with the second request.

Best regards,
g.b.


-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu   1.0.0+git-20190125.36a4c85-5.1
ii  libaio1 0.3.113-4
ii  libbpf1 1:1.1.0-1
ii  libc6   2.36-9+deb12u4
ii  libcapstone44.0.2-5
ii  libfdt1 1.6.1-4+b1
ii  libfuse3-3  3.14.0-4
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libgmp102:6.2.1+dfsg1-1.1
ii  libgnutls30 3.7.9-2+deb12u2
ii  libhogweed6 3.8.1-2
ii  libibverbs1 44.0-2
ii  libjpeg62-turbo 1:2.1.5-2
ii  libnettle8  3.8.1-2
ii  libnuma12.0.16-1
ii  libpixman-1-0   0.42.2-1
ii  libpmem11.12.1-2
ii  libpng16-16 1.6.39-2
ii  librdmacm1  44.0-2
ii  libsasl2-2  2.1.28+dfsg-10
ii  libseccomp2 2.5.4-1+b3
ii  libslirp0   4.7.0-1
ii  libudev1252.22-1~deb12u1
ii  liburing2   2.3-3
ii  libvdeplug2 4.0.1-4
ii  libzstd11.5.4+dfsg2-5
ii  qemu-system-common  1:7.2+dfsg-7+deb12u5
ii  qemu-system-data1:7.2+dfsg-7+deb12u5
ii  seabios 1.16.2-1
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages qemu-system-x86 recommends:
ii  ovmf  2022.11-6+deb12u1
pn  qemu-block-extra  
ii  qemu-system-gui   1:7.2+dfsg-7+deb12u5
ii  qemu-utils1:7.2+dfsg-7+deb12u5

Versions of packages qemu-system-x86 suggests:
pn  samba  
pn  vde2   

-- no debconf information
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 

static void dump(const char *s, size_t len) {
while (len--) {
char t = *s++;
if (' ' <= t && t <= '~' && t != '\\')
printf("%c", t);
else
printf("\\%o", t & 0xff);
}
printf("\n");
}

int main(int argc, char *argv[]) {
int sock, rv, n;
const char 

Bug#1040458: bookworm: please document that /etc/init.d/rsyslog is gone

[g1]

Package: release-notes
Severity: wishlist

On servers that run sysvinit instead of systemd, after upgrading from
bullseye to bookworm rsyslogd doesn't start at boot anymore, unless
orphan-sysvinit-packages is installed.

Perhaps it's worth mentioning in the RN, otherwise people might discover
that logging was stopped days or weeks after the upgrade.

Best regards,
g.b.

Bug#1037039: rsyslog - SysV init file missing

[g1]

Package: rsyslog
Version: 8.2302.0-1
Followup-For: Bug #1037039
X-Debbugs-Cc: g...@libero.it

In case someone lands on this bug after discovering that rsyslogd doesn't
start at boot anymore after upgrading to bookworm:

If you don't want to install orphan-sysvinit-scripts, you can use the
following minimal script (man init-d-script for reference):

#!/bin/sh
### BEGIN INIT INFO
# Provides:   rsyslog
# Required-Start: $remote_fs $time
# Required-Stop:  umountnfs $time
# Default-Start:  2 3 4 5
# Default-Stop:   0 1 6
# Description:rsyslog
### END INIT INFO

DAEMON=/usr/sbin/rsyslogd
/lib/init/init-d-script "$0" "$@"



-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-10-cloud-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rsyslog depends on:
ii  libc6 2.36-9
ii  libestr0  0.1.11-1
ii  libfastjson4  1.2304.0-1
ii  liblognorm5   2.0.6-4
ii  libsystemd0   252.6-1
ii  libuuid1  2.38.1-5+b1
ii  libzstd1  1.5.4+dfsg2-5
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages rsyslog recommends:
ii  logrotate  3.21.0-1

Versions of packages rsyslog suggests:
pn  rsyslog-doc   
pn  rsyslog-gssapi
pn  rsyslog-mongodb   
pn  rsyslog-mysql | rsyslog-pgsql 
pn  rsyslog-openssl | rsyslog-gnutls  
pn  rsyslog-relp  

-- no debconf information

Bug#1040453: rsyslog: please, make postrotate action work also under sysvinit

[g1]

Package: rsyslog
Version: 8.2302.0-1
Severity: wishlist
X-Debbugs-Cc: g...@libero.it

Dear Maintainer,

in bookworm, logrotate post-action does not work under sysvinit, because
/usr/lib/rsyslog/rsyslog-rotate invokes systemctl in order to send SIGHUP
to the daemon.

A workaround is to install orphan-sysvinit-scripts, which diverts
/usr/lib/rsyslog/rsyslog-rotate to the old, working version.

A fix would be:

1. drop "-iNONE" from /lib/systemd/system/rsyslog.service, to make rsyslogd
   write its pidfile: not used for supervision, yet harmless;

2. replace the code in /usr/lib/rsyslog/rsyslog-rotate with
pkill -HUP -F /run/rsyslogd.pid rsyslogd

This way, logrotate's post-action works under both systemd and sysvinit.

Best regards
g.b.

-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-10-cloud-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rsyslog depends on:
ii  libc6 2.36-9
ii  libestr0  0.1.11-1
ii  libfastjson4  1.2304.0-1
ii  liblognorm5   2.0.6-4
ii  libsystemd0   252.6-1
ii  libuuid1  2.38.1-5+b1
ii  libzstd1  1.5.4+dfsg2-5
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages rsyslog recommends:
ii  logrotate  3.21.0-1

Versions of packages rsyslog suggests:
pn  rsyslog-doc   
pn  rsyslog-gssapi
pn  rsyslog-mongodb   
pn  rsyslog-mysql | rsyslog-pgsql 
pn  rsyslog-openssl | rsyslog-gnutls  
pn  rsyslog-relp  

-- Configuration Files:
/etc/logrotate.d/rsyslog changed [not included]

-- no debconf information

Bug#1040364: orphan-sysvinit-scripts: add triggers to restart daemons

[g1]

Source: orphan-sysvinit-scripts
Version: 0.14
Severity: wishlist
Tags: patch
X-Debbugs-Cc: g...@libero.it

Dear Maintainer,

please consider adding triggers for restarting daemons when the executables
change (usually at package upgrade).

The following patch just mentions rsyslogd (newly orphaned script in bookworm),
but it should be easy to extend to other daemons handled by o-s-s.

Best regards,
g.b.

-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
diff -NrwbBu 
orphan-sysvinit-scripts-0.14.orig/debian/orphan-sysvinit-scripts.triggers 
orphan-sysvinit-scripts-0.14/debian/orphan-sysvinit-scripts.triggers
--- orphan-sysvinit-scripts-0.14.orig/debian/orphan-sysvinit-scripts.triggers   
2023-02-24 11:01:40.0 +0100
+++ orphan-sysvinit-scripts-0.14/debian/orphan-sysvinit-scripts.triggers
2023-07-04 18:42:08.045446810 +0200
@@ -9,3 +9,4 @@
 interest-noawait /lib/systemd/system/pdns.service
 interest-noawait /lib/systemd/system/rsyslog.service
 interest-noawait /lib/systemd/system/tomcat9.service
+interest-noawait /usr/sbin/rsyslogd
diff -NrwbBu orphan-sysvinit-scripts-0.14.orig/debian/postinst 
orphan-sysvinit-scripts-0.14/debian/postinst
--- orphan-sysvinit-scripts-0.14.orig/debian/postinst   2023-02-24 
11:01:40.0 +0100
+++ orphan-sysvinit-scripts-0.14/debian/postinst2023-07-04 
21:11:55.055908922 +0200
@@ -5,6 +5,7 @@
 case "$1" in
 configure|triggered)
/usr/lib/orphan-sysvinit-scripts/update_init_d.sh
+   /usr/lib/orphan-sysvinit-scripts/invoke_init_d.sh "$@"
 
;;
 esac
diff -NrwbBu orphan-sysvinit-scripts-0.14.orig/lib/invoke_init_d.sh 
orphan-sysvinit-scripts-0.14/lib/invoke_init_d.sh
--- orphan-sysvinit-scripts-0.14.orig/lib/invoke_init_d.sh  1970-01-01 
01:00:00.0 +0100
+++ orphan-sysvinit-scripts-0.14/lib/invoke_init_d.sh   2023-07-04 
18:58:43.344947505 +0200
@@ -0,0 +1,12 @@
+#!/bin/sh
+
+if [ $# -gt 1 ] && [ "$1" = triggered ]; then
+shift
+for t in $*; do
+   case $t in
+   /usr/sbin/rsyslogd) invoke-rc.d rsyslog try-restart ;;
+   esac
+done
+fi
+
+exit 0

Bug#1024416: unbound does not restart reliably under sysvinit with apparmor in enforcing mode

[g1]

Package: unbound
Version: 1.13.1-1
Severity: normal
Tags: patch
X-Debbugs-Cc: g...@libero.it

Hi

With the apparmor profile shipped with unbound, /usr/sbin/unbound is
allowed to truncate and create its own pidfile /run/unbound.pid, but
cannot remove it at exit or rewrite it when it starts again.

As a consequence, "start-stop-daemon --stop" leaves behind an empty pidfile,
and a subsequent "start-stop-daemon --start" spawns a new daemon whose
pid is written nowhere.  The overall result is that N invocations of
"/etc/init.d/unbound restart" end up with N-1 daemons running, with
obvious implications for security.

In #947771 Stephane Lapie and Gedalya suggested a simple patch that
solves the problem.  That bug report was closed as "problem solved",
without actually applying the patch, probably because I failed to clearly
explain how to reproduce the issue.

Please, do not close this report unless, on a system managed by
sysvinit-core with apparmor in enforcing mode, exactly one instance of
unbound is left running after invoking "/etc/init.d/unbound restart"
at least four times in a row.

Since 2020, I've been applying the following patch against the script
shipped by the debian package at each new release, again and again.
Hope it can be included for real in the debian tree.

Best regards,
g.

--- /etc/init.d/unbound.dpkg-dist   2021-02-09 23:53:57.0 +0100
+++ /etc/init.d/unbound 2022-11-19 08:28:58.429007869 +0100
@@ -42,7 +42,7 @@
 
 stop)
 log_daemon_msg "Stopping $DESC" "$NAME"
-if start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE --name 
$NAME --retry 5; then
+if start-stop-daemon --stop --quiet --oknodo --remove-pidfile 
--pidfile $PIDFILE --name $NAME --retry 5; then
 $HELPER resolvconf_stop
 $HELPER chroot_teardown
 log_end_msg 0
@@ -53,7 +53,7 @@
 
 restart|force-reload)
 log_daemon_msg "Restarting $DESC" "$NAME"
-start-stop-daemon --stop --quiet --pidfile $PIDFILE --name $NAME 
--retry 5
+start-stop-daemon --stop --quiet --remove-pidfile --pidfile $PIDFILE 
--name $NAME --retry 5
 $HELPER resolvconf_stop
 if start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE 
--name $NAME --startas $DAEMON -- $DAEMON_OPTS; then
 $HELPER chroot_setup

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-19-amd64 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages unbound depends on:
ii  adduser3.118
ii  dns-root-data  2021011101
ii  libc6  2.31-13+deb11u5
ii  libelogind0 [libsystemd0]  246.9.1-1+debian1
ii  libevent-2.1-7 2.1.12-stable-1
ii  libprotobuf-c1 1.3.3-1+b2
ii  libpython3.9   3.9.2-1
ii  libssl1.1  1.1.1n-0+deb11u3
ii  lsb-base   11.1.0
ii  openssl1.1.1n-0+deb11u3
ii  unbound-anchor 1.13.1-1

unbound recommends no packages.

Versions of packages unbound suggests:
ii  apparmor  2.13.6-10

-- no debconf information

Bug#996361: iitalian: Italian hash file not compatible with current version of ispell

[g1]

Package: iitalian
Version: 1:2.3-3+b1
Severity: grave
Justification: renders package unusable

$ echo albergo ciao | ispell -d american -l
albergo

$ echo albergo ciao | ispell -d italian -l
Illegal format hash table /usr/lib/ispell/italian.hash - expected magic2 
0x9602, got 0x5053

$ file -L /usr/lib/ispell/[ai]*.hash
/usr/lib/ispell/american.hash: little endian ispell 3.1 hash file, 7-bit, 
capitalization, 52 flags and 1024 string characters
/usr/lib/ispell/italian.hash:  little endian ispell 3.1 hash file, 7-bit, 
capitalization, 52 flags and 512 string characters

$ ls -lL /usr/lib/ispell/[ai]*.hash
-rw-r--r-- 1 root root 1693656 Oct 13 11:19 /usr/lib/ispell/american.hash
-rw-r--r-- 1 root root 1548432 Jul 29  2019 /usr/lib/ispell/italian.hash

Most likely this package was not rebuilt after the last backward-incompatible
change to on-disk format in ispell.  Perhaps a rebuild would solve the problem.

Best regards
g.

-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages iitalian depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  dictionaries-common1.28.4
ii  ispell 3.4.02-2

iitalian recommends no packages.

Versions of packages iitalian suggests:
ii  witalian  1.10

-- debconf information:
  iitalian/languages: italiano (Italian)
  shared/packages-ispell:

Bug#992618: hdparm: /lib/udev/hdparm does not set APM options anymore when resuming from suspend

[g1]

Package: hdparm
Version: 9.60+ds-1

/lib/udev/rules.d/85-hdparm.rules invokes /lib/udev/hdparm when
block devices matching /dev/sdX or /dev/hdX are added.

/lib/udev/hdparm is supposed to extract options relevant to
$DEVNAME and battery-vs-ac status from /etc/hdparm.conf and apply
them using /sbin/hdparm.  According to the changelog, since version
9.58+ds-2 the script singles out APM options and delegates them to
/usr/lib/pm-utils/sleep.d/95hdparm-apm.

However, /usr/lib/pm-utils/sleep.d/95hdparm-apm includes the following fragment:

# Do nothing when called via /etc/init.d/acpi-support; udev rules take care
# of setting the initial hdparm policy for us.
if ([ "$previous" ] && [ "$runlevel" ]) || [ "$runlevel" = S ]; then
exit 0
fi

When the condition is met (e.g. acpid handling resume-from-suspend),
APM options are not restored according to /etc/hdparm.conf.  Since udev
rules rely on /lib/udev/hdparm, the comment doesn't apply.

Please revert /lib/udev/hdparm to the previous version, so that it again
does just one thing: apply to device X all options configured for X
in /etc/hdparm.conf.

By the way, every now and then the hdparm package changes in surprising
ways: perhaps including a NEWS.Debian.gz could help.

Best regards,
g.



-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages hdparm depends on:
ii  libc6 2.31-13
ii  lsb-base  11.1.0

Versions of packages hdparm recommends:
pn  powermgmt-base  

hdparm suggests no packages.

-- Configuration Files:
/etc/hdparm.conf changed:
quiet
/dev/sda {
apm = 254
apm_battery = 254
spindown_time = 250
write_cache = off
}


-- no debconf information

Bug#983606: base-files: umask is not set for superuser

[g1]

Package: base-files
Version: 10.3+deb10u8
Severity: normal

In /usr/share/base-files/dot.bashrc (which is copied to /root/.bashrc
at package installation) the umask command is commented out, with this
explanation:

# Note: PS1 and umask are already set in /etc/profile. You should not
# need this unless you want different defaults for root.

That's not true anymore: umask is not set in /usr/share/base-files/profile
(copied to /etc/profile) or in /usr/share/base-files/dot.profile (copied
to /root/.profile).

As a result, umask for the superuser is never set explicitly, just
inherited, perhaps from an unprivileged shell.  Which can have unpleasant
effects:

$ id -u
1000
$ umask
0027
$ su -
Password:

# id -u
0
# umask
0027
# dpkg-reconfigure pkg-that-updates-some-index-supposed-world-readable

It's a corner case, limited to users that change their umask from the
default value, but you know, "the road to hell is paved with default
values".

Best regards,
g.b.


-- System Information:
Debian Release: 10.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-14-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages base-files depends on:
ii  gawk [awk]  1:4.2.1+dfsg-1
ii  mawk [awk]  1.3.3-17+b3
ii  original-awk [awk]  2012-12-20-6

base-files recommends no packages.

base-files suggests no packages.

-- no debconf information

Bug#950714: unbound: cache confusion results in NXDOMAIN for existing names

[g1]

Package: unbound
Version: 1.9.0-2+deb10u1
Severity: important

Sometimes unbound replies to a query for a forward-zone using a spurious
cache entry, resulting in bogus NXDOMAIN responses that persist for
cache-max-negative-ttl seconds (1 hour, by default), effectively
disrupting name resolution for the zone.

Given this piece of configuration on 10.0.2.15:

server:
do-ip6: no
interface: 127.0.0.1
   #log-local-actions: yes
log-queries: yes
log-replies: yes
log-servfail: yes
log-tag-queryreply: yes
   #log-time-ascii: yes
statistics-cumulative: yes
statistics-interval: 3607
val-log-level: 2
verbosity: 4
logfile: /var/log/unbound.log

domain-insecure: test.local

remote-control:
control-enable: yes
control-interface: /run/unbound.ctl

forward-zone:
name: test.local
forward-addr: 10.0.2.2

and the zone test.local defined on 10.0.2.2 like this: 

$TTL 3600; 1 hour
@SOA x.test.local. root.test.local. (
 1  ; serial
 900; refresh (15 +minutes)
 600; retry (10 minutes)
 86400  ; expire (1 day)
 3600   ; minimum / negative ttl (1 hour)
 )
 NS  x.test.local.
xA   10.0.2.2
yA   10.0.2.10

responses from a freshly started instance of unbound on 10.0.2.15 depend on
query ordering:

successful sequence:
# service unbound restart
# dig @127.0.0.1 A y.test.local.  => 10.0.2.10 (correct)
# dig @127.0.0.1 A nonexistent.local. => nxdomain  (correct)
# dig @127.0.0.1 A y.test.local.  => 10.0.2.10 (correct)

failing sequence:
# service unbound restart
# dig @127.0.0.1 A nonexistent.local. => nxdomain  (correct)
# dig @127.0.0.1 A y.test.local.  => nxdomain  (WRONG)

At verbosity 4, the logfile contains this excerpt:

[1580891316] unbound[1842:0] info: msg from cache lookup
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 0
;; flags: qr ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 0 
;; QUESTION SECTION:
y.test.local.   IN  A

;; ANSWER SECTION:

;; AUTHORITY SECTION:
loans.  86394   IN  NSEClocker. NS DS RRSIG NSEC
loans.  86394   IN  RRSIG   NSEC 8 1 86400 2020021717 [...]
.   86394   IN  NSECaaa. NS SOA RRSIG NSEC DNSKEY
.   86394   IN  RRSIG   NSEC 8 0 86400 2020021717 [...]
.   3594IN  SOA a.root-servers.net. nstld.verisign-grs.com.
2020020401 1800 900 604800 86400
.   86394   IN  RRSIG   SOA 8 0 86400 2020021717 [...]

;; ADDITIONAL SECTION:
;; MSG SIZE  rcvd: 1022

That entry looks like a response packet with rcode NXDOMAIN and Question
"y.test.local. IN A".

The network capture, however, shows that no such reply was ever received by
unbound.  In fact unbound sent no query for "y.test.local." or "test.local."
to 10.0.2.2 or root nameservers.

The closest match is the packet received from a root server with rcode
NXDOMAIN and Question "local. IN A".  Looks like the above "msg from
cache" is spurious.

Best regards,
g.b.

-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-6-686 (SMP w/1 CPU core)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages unbound depends on:
ii  adduser 3.118
ii  dns-root-data   2019031302
ii  libc6   2.28-10
ii  libevent-2.1-6  2.1.8-stable-4
ii  libfstrm0   0.4.0-1
ii  libprotobuf-c1  1.3.1-1+b1
ii  libpython3.73.7.3-2
ii  libssl1.1   1.1.1d-0+deb10u2
ii  libsystemd0 241-7~deb10u2
ii  lsb-base10.2019051400
ii  openssl 1.1.1d-0+deb10u2
ii  unbound-anchor  1.9.0-2+deb10u1

unbound recommends no packages.

Versions of packages unbound suggests:
pn  apparmor  

-- no debconf information

Bug#947771: unbound: cannot restart daemon under sysvinit-core when apparmor is enforced

[g1]

Package: unbound
Version: 1.9.0-2+deb10u1
Severity: normal
Tags: patch

At startup the daemon creates its pidfile (/run/unbound.pid) while running
as root, chown()s it to unbound:unbound, then drops privileges and runs
as user unbound.  At shutdown, the pidfile is successfully truncated,
but the following unlink() call fails because /run is owned by root.

In a subsequent start the daemon is prevented by the apparmor profile
from updating the pidfile (AFAICT, because it runs as root, but the
file exists and is owned by unbound), and as a result the pidfile is
left empty, and the daemon cannot be managed anymore.  Of course, under
systemd-sysv the problem does not exist.

I'm not proficient in apparmor enough to amend the profile, and I guess
the proper solution should mimic the one for bind9 (i.e. a directory
/run/named owned by root:bind), but in the meantime the following patch
solved the problem for me and might be useful to other users.

Best regards,
g.b.

= patch begin
--- /etc/init.d/unbound.orig2019-10-13 02:40:17.0 +0200
+++ /etc/init.d/unbound 2019-12-30 14:31:48.463876228 +0100
@@ -44,6 +44,7 @@
 log_daemon_msg "Stopping $DESC" "$NAME"
 if start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE --name 
$NAME --retry 5; then
 $HELPER resolvconf_stop
+rm -f $PIDFILE
 log_end_msg 0
 else
 log_end_msg 1
@@ -51,16 +52,8 @@
 ;;
 
 restart|force-reload)
-log_daemon_msg "Restarting $DESC" "$NAME"
-start-stop-daemon --stop --quiet --pidfile $PIDFILE --name $NAME 
--retry 5
-$HELPER resolvconf_stop
-if start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE 
--name $NAME --startas $DAEMON -- $DAEMON_OPTS; then
-$HELPER chroot_setup
-$HELPER resolvconf_start
-log_end_msg 0
-else
-log_end_msg 1
-fi
+$0 stop
+$0 start
 ;;
 
 reload)
= patch end

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-6-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages unbound depends on:
ii  adduser 3.118
ii  dns-root-data   2019031302
ii  libc6   2.28-10
ii  libevent-2.1-6  2.1.8-stable-4
ii  libfstrm0   0.4.0-1
ii  libprotobuf-c1  1.3.1-1+b1
ii  libpython3.73.7.3-2
ii  libssl1.1   1.1.1d-0+deb10u2
ii  libsystemd0 241-7~deb10u2
ii  lsb-base10.2019051400
ii  openssl 1.1.1d-0+deb10u2
ii  unbound-anchor  1.9.0-2+deb10u1

unbound recommends no packages.

Versions of packages unbound suggests:
ii  apparmor  2.13.2-10

-- Configuration Files:
/etc/init.d/unbound changed [not included]

-- no debconf information

Bug#930247: grep: inconsistent behaviour with anchored regex containing back-references

[g1]

Package: grep
Version: 2.27-2
Severity: normal

There seems to be a problem with beginning/end-of-line anchors in regex
containing back-references:

$ cat words
ana
deed
ill
stats

Using -x to match whole line works:

$ egrep -x '(.?)(.?).?\2\1' words
ana
deed
stats

Using explicit anchors emits false positives:

$ egrep   '^(.?)(.?).?\2\1$' words
ana
deed
ill <<<
stats

On the other hand, colouring the output shows that grep somewhat knows its
mistake:

$ egrep --color '^(.?)(.?).?\2\1$' words
ana (coloured)
deed(coloured)
ill
stats   (coloured)

-- System Information:
Debian Release: 9.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages grep depends on:
ii  dpkg  1.18.25
ii  install-info  6.3.0.dfsg.1-1+b2
ii  libc6 2.24-11+deb9u4
ii  libpcre3  2:8.39-3

grep recommends no packages.

Versions of packages grep suggests:
ii  libpcre3  2:8.39-3

-- no debconf information

Bug#930245: libstdc++-6-dev: namespace pollution with low-level macros

[g1]

Package: libstdc++-6-dev
Version: 6.3.0-18+deb9u1
Severity: normal

$ cat s.cc
#include 
int major(int x) { return x & ~0x; }

$ g++ -E -dD -ansi  s.cc | grep -w major
int major(int x) { return x & ~0x; }

$ g++ -E -dDs.cc | grep -w major
#define major(dev) gnu_dev_major (dev)

Without the -ansi option, iostream pulls sys/sysmacros.h, where 
major() and minor() are defined as macros taking one argument, aliases of
gnu_dev_major/minor.

Likely to cause interesting bugs if one mixes source files with and
without  includes, or gets library/object order wrong at link time.

Goes undetected until code changes to something like
int major(std::pair x) { return x.first; }
at which point g++ emits a revealing
error: macro "major" passed 2 arguments, but takes just 1

Not sure if the problem belongs to libstdc++-6-dev, gcc or libc6-dev.

Best regards,
g

-- System Information:
Debian Release: 9.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libstdc++-6-dev depends on:
ii  gcc-6-base6.3.0-18+deb9u1
ii  libc6-dev 2.24-11+deb9u4
ii  libgcc-6-dev  6.3.0-18+deb9u1
ii  libstdc++66.3.0-18+deb9u1

libstdc++-6-dev recommends no packages.

Versions of packages libstdc++-6-dev suggests:
pn  libstdc++-6-doc  

-- no debconf information

Bug#928449: firefox-esr: Add-ons fail to install probably due to upstream certificate issue

[g1]

Package: firefox-esr
Version: 60.6.1esr-1~deb9u1
Followup-For: Bug #928449

The problem is caused by an expired intermediate certificate in the builtin
chain of trust that the browser applies to verify signatures on addons.

More details are available at
https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/
https://bugzilla.mozilla.org/show_bug.cgi?id=1548973
https://bugzilla.mozilla.org/show_bug.cgi?id=1549078

Unfortunately, the solution devised by Firefox devs is based on Studies
(as far as I know, a way to push high-level code to installed browsers).

I believe studies are disabled in the firefox-esr package in Debian, and
I could not enable them.  I worked around the issue by downloading the
XPI file that the studies would have pushed, extracting the certificate,
and importing it in firefox (Preferences -> Privacy and Security ->
View Certificates -> Import).

I presume I'll have to manually delete that certificate from FF when upstream
makes a new fixed ESR version of FF, or a new version of firefox-esr appears
in Debian with an updated cert, but in the meantime it works for me.

If you want to try this out AND you trust both me and bugs.debian.org,
you can find the certificate in the attached file moz-add-int.pem,
ready to import.

Otherwise, here is the procedure I applied:

- navigate to https://normandy.cdn.mozilla.net/api/v1/recipe/signed/
- locate the recipe with name
"Hotfix: Update XPI signing intermediate [Bug 1548973]"
  and copy the corresponding addonUrl
- use wget or curl to fetch the xpi file from addonUrl, and rename it to
  something.zip
- unzip it to a temporary directory
- edit experiments/skeleton/api.js, copy the base64-encoded string in
  double quotes from the line "let intermediate = ...", and save it to a
  temporary file, say /tmp/xyz
- convert it to DER form
base64 -d /tmp/moz-add-int.der
- import it in FF
- or inspect and/or convert to PEM format:
openssl x509 -in /tmp/moz-add-int.der -inform DER -text -noout
openssl x509 -in /tmp/moz-add-int.der -inform  DER \
-out /tmp/moz-add-int.pem -outform PEM

By the way, this upstream bug disables many extensions that improve security
or privacy for FF users, including ad-blockers, javascript filters, password
managers: I would have labeled it "important".
-BEGIN CERTIFICATE-
MIIHLTCCBRWgAwIBAgIDEAAIMA0GCSqGSIb3DQEBDAUAMH0xCzAJBgNVBAYTAlVT
MRwwGgYDVQQKExNNb3ppbGxhIENvcnBvcmF0aW9uMS8wLQYDVQQLEyZNb3ppbGxh
IEFNTyBQcm9kdWN0aW9uIFNpZ25pbmcgU2VydmljZTEfMB0GA1UEAxMWcm9vdC1j
YS1wcm9kdWN0aW9uLWFtbzAeFw0xNTA0MDQwMDAwMDBaFw0yNTA0MDQwMDAwMDBa
MIGnMQswCQYDVQQGEwJVUzEcMBoGA1UEChMTTW96aWxsYSBDb3Jwb3JhdGlvbjEv
MC0GA1UECxMmTW96aWxsYSBBTU8gUHJvZHVjdGlvbiBTaWduaW5nIFNlcnZpY2Ux
JjAkBgNVBAMTHXNpZ25pbmdjYTEuYWRkb25zLm1vemlsbGEub3JnMSEwHwYJKoZI
hvcNAQkBFhJmb3hzZWNAbW96aWxsYS5jb20wggIiMA0GCSqGSIb3DQEBAQUAA4IC
DwAwggIKAoICAQC/qluiiI+wO6qGA4vH7cHvWvXpdju9JnvbwnrbYmxhtUpfS68L
bdjGGtv7RP6F1XhHT4MU3v4GuMulH0E4Wfalm8evsb3tBJRMJPICJX5UCLi6VJ6J
2vipXSWBf8xbcOB+PY5Kk6L+EZiWaepiM23CdaZjNOJCAB6wFHlGe+zUk87whpLa
7GrtrHjTb8u9TSS+mwjhvgfP8ILZrWhzb5H/ybgmD7jYaJGIDY/WDmq1gVe03fSh
xD09Ml1P7H38o5kbFLnbbqpqC6n8SfUI31MiJAXAN2e6rAOM8EmocAY0EC5KUooX
KRsYvHzhwwHkwIbbe6QpTUlIqvw1MPlQPs7Zu/MBnVmyGTSqJxtYoklr0MaEXnJN
Y3g3FDf1R0Opp2/BEY9Vh3Fc9Pq6qWIhGoMyWdueoSYa+GURqDbsuYnk7ZkysxK+
yRoFJu4x3TUBmMKM14jQKLgxvuIzWVn6qg6cw7ye/DYNufc+DSPSTSakSsWJ9IPx
iAU7xJ+GCMzaZ10Y3VGOybGLuPxDlSd6KALAoMcl9ghB2mvfB0N3wv6uWnbKuxih
q/qDps+FjliNvr7C66mIVH+9rkyHIy6GgIUlwr7E88Qqw+SQeNeph6NIY85PL4p0
Y8KivKP4J928tpp18wLuHNbIG+YaUk5WUDZ6/2621pi19UZQ8iiHxN/XKQIDAQAB
o4IBiTCCAYUwDAYDVR0TBAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwFgYDVR0lAQH/
BAwwCgYIKwYBBQUHAwMwHQYDVR0OBBYEFBY++xz/DCuT+JsV1y2jwuZ4YdztMIGo
BgNVHSMEgaAwgZ2AFLO86lh0q+FueCqyq5wjHqhjLJe3oYGBpH8wfTELMAkGA1UE
BhMCVVMxHDAaBgNVBAoTE01vemlsbGEgQ29ycG9yYXRpb24xLzAtBgNVBAsTJk1v
emlsbGEgQU1PIFByb2R1Y3Rpb24gU2lnbmluZyBTZXJ2aWNlMR8wHQYDVQQDExZy
b290LWNhLXByb2R1Y3Rpb24tYW1vggEBMDMGCWCGSAGG+EIBBAQmFiRodHRwOi8v
YWRkb25zLm1vemlsbGEub3JnL2NhL2NybC5wZW0wTgYDVR0eBEcwRaFDMCCCHi5j
b250ZW50LXNpZ25hdHVyZS5tb3ppbGxhLm9yZzAfgh1jb250ZW50LXNpZ25hdHVy
ZS5tb3ppbGxhLm9yZzANBgkqhkiG9w0BAQwFAAOCAgEAX1PNli/zErw3tK3S9Bv8
03RV4tHkrMa5xztxzlWja0VAUJKEQx7f1yM8vmcQJ9g5RE8WFc43IePwzbAoum5F
4BTM7tqM//+e476F1YUgB7SnkDTVpBOnV5vRLz1Si4iJ/U0HUvMUvNJEweXvKg/D
NbXuCreSvTEAawmRIxqNYoaigQD8x4hCzGcVtIi5Xk2aMCJW2K/6JqkN50pnLBNk
Px6FeiYMJCP8z0FIz3fv53FHgu3oeDhi2u3VdONjK3aaFWTlKNiGeDU0/lr0suWf
QLsNyphTMbYKyTqQYHxXYJno9PuNi7e1903PvM47fKB5bFmSLyzB1hB1YIVLj0/Y
qD4nz3lADDB91gMBB7vR2h5bRjFqLOxuOutNNcNRnv7UPqtVCtLF2jVb4/AmdJU7
8jpfDs+BgY/t2bnGBVFBuwqS2Kult/2kth4YMrL5DrURIM8oXWVQRBKxzr843yDm
Ho8+2rqxLnZcmWoe8yQ41srZ4IB+V3w2TIAd4gxZAB0Xa6KfnR4D8RgE5sgmgQoK
7Y/hdvd9Ahu0WEZI8Eg+mDeCeojWcyjF+dt6c2oERiTmFTIFUoojEjJwLyIqHKt+
eApEYpF7imaWcumFN1jR+iUjE4ZSUoVxGtZ/Jdnkf8VVQMhiBA+i7r5PsfrHq+lq
TTGOg+GzYx7OmoeJAT0zo4c=
-END CERTIFICATE-

Bug#882586: libc6-dev:amd64: pthread_rwlock_unlock segfaults in statically linked executable

[g1]

Package: libc6-dev
Version: 2.24-11+deb9u1
Severity: important

A minimal program that exercises R/W locks crashes when linked statically:

$ cat test-rwlock.c
#include 
int main() {
pthread_rwlock_t rw;
if (pthread_rwlock_init(, NULL)) return -1;
if (pthread_rwlock_wrlock()) return -2;
if (pthread_rwlock_unlock()) return -3;
if (pthread_rwlock_destroy())return -4;
return 0;
}

$ cc -pthread -O0 -g test-rwlock.c ; ./a.out ; echo $?
0

$ cc -pthread -static -O0 -g test-rwlock.c ; ./a.out ; echo $?
Illegal instruction
132

Most likely, the problem is not in pthread_rwlock_unlock, but in
pthread_rwlock_wrlock: gdb shows that when the latter returns, 
rw.__data.__writer == pid_of_the_process
in the dynamic case, and 
rw.__data.__writer == 0 
in the static case.

Best regards,
g.



-- System Information:
Debian Release: 9.1
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libc6-dev:amd64 depends on:
ii  libc-dev-bin2.24-11+deb9u1
ii  libc6   2.24-11+deb9u1
ii  linux-libc-dev  4.9.51-1

libc6-dev:amd64 recommends no packages.

Versions of packages libc6-dev:amd64 suggests:
ii  glibc-doc 2.24-11+deb9u1
ii  manpages-dev  4.10-2

-- no debconf information

Bug#879058: cpio: crashes when reading ustar archives created by itself

[g1]

Package: cpio
Version: 2.11+dfsg-6
Severity: normal

cpio is unable to read a USTAR archive created by itself:

$ ls -ogl
4 -rw-r--r-- 1 30 Oct 18 21:35 x

$ echo x | cpio -ovH ustar > x.cpio
x
4 blocks

$ cpio -ivtH ustar < x.cpio
*** Error in `cpio': realloc(): invalid pointer: 0x0044cb20 ***
=== Backtrace: =
/lib/i386-linux-gnu/libc.so.6(+0x6737a)[0xb75d637a]
/lib/i386-linux-gnu/libc.so.6(+0x6dfb7)[0xb75dcfb7]
/lib/i386-linux-gnu/libc.so.6(realloc+0x1ee)[0xb75e133e]
/lib/i386-linux-gnu/libc.so.6(realloc+0x24b)[0xb75e139b]
cpio(+0x18e6e)[0x43ce6e]
cpio(process_copy_in+0x52b)[0x4283ab]
cpio(main+0x82)[0x4264e2]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6)[0xb7587276]
cpio(+0x2593)[0x426593]
=== Memory map: 
00424000-0044b000 r-xp  fe:01 98322  /bin/cpio
0044b000-0044c000 r--p 00026000 fe:01 98322  /bin/cpio
0044c000-0044d000 rw-p 00027000 fe:01 98322  /bin/cpio
0044d000-0044e000 rw-p  00:00 0 
00477000-00498000 rw-p  00:00 0  [heap]
b73e2000-b73fe000 r-xp  fe:01 475279 
/lib/i386-linux-gnu/libgcc_s.so.1
b73fe000-b73ff000 r--p 0001b000 fe:01 475279 
/lib/i386-linux-gnu/libgcc_s.so.1
b73ff000-b740 rw-p 0001c000 fe:01 475279 
/lib/i386-linux-gnu/libgcc_s.so.1
b740-b7421000 rw-p  00:00 0 
b7421000-b750 ---p  00:00 0 
b7529000-b7534000 r-xp  fe:01 475380 
/lib/i386-linux-gnu/libnss_files-2.24.so
b7534000-b7535000 r--p a000 fe:01 475380 
/lib/i386-linux-gnu/libnss_files-2.24.so
b7535000-b7536000 rw-p b000 fe:01 475380 
/lib/i386-linux-gnu/libnss_files-2.24.so
b7536000-b753c000 rw-p  00:00 0 
b753c000-b7547000 r-xp  fe:01 475383 
/lib/i386-linux-gnu/libnss_nis-2.24.so
b7547000-b7548000 r--p a000 fe:01 475383 
/lib/i386-linux-gnu/libnss_nis-2.24.so
b7548000-b7549000 rw-p b000 fe:01 475383 
/lib/i386-linux-gnu/libnss_nis-2.24.so
b7549000-b755f000 r-xp  fe:01 475353 
/lib/i386-linux-gnu/libnsl-2.24.so
b755f000-b756 r--p 00016000 fe:01 475353 
/lib/i386-linux-gnu/libnsl-2.24.so
b756-b7561000 rw-p 00017000 fe:01 475353 
/lib/i386-linux-gnu/libnsl-2.24.so
b7561000-b7563000 rw-p  00:00 0 
b7563000-b756b000 r-xp  fe:01 475362 
/lib/i386-linux-gnu/libnss_compat-2.24.so
b756b000-b756c000 r--p 7000 fe:01 475362 
/lib/i386-linux-gnu/libnss_compat-2.24.so
b756c000-b756d000 rw-p 8000 fe:01 475362 
/lib/i386-linux-gnu/libnss_compat-2.24.so
b756d000-b756f000 rw-p  00:00 0 
b756f000-b772 r-xp  fe:01 475294 
/lib/i386-linux-gnu/libc-2.24.so
b772-b7721000 ---p 001b1000 fe:01 475294 
/lib/i386-linux-gnu/libc-2.24.so
b7721000-b7723000 r--p 001b1000 fe:01 475294 
/lib/i386-linux-gnu/libc-2.24.so
b7723000-b7724000 rw-p 001b3000 fe:01 475294 
/lib/i386-linux-gnu/libc-2.24.so
b7724000-b7727000 rw-p  00:00 0 
b773d000-b774 rw-p  00:00 0 
b774-b7742000 r--p  00:00 0  [vvar]
b7742000-b7744000 r-xp  00:00 0  [vdso]
b7744000-b7767000 r-xp  fe:01 475286 /lib/i386-linux-gnu/ld-2.24.so
b7767000-b7768000 r--p 00022000 fe:01 475286 /lib/i386-linux-gnu/ld-2.24.so
b7768000-b7769000 rw-p 00023000 fe:01 475286 /lib/i386-linux-gnu/ld-2.24.so
bfab1000-bfad2000 rw-p  00:00 0  [stack]
Aborted

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-4-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages cpio depends on:
ii  libc6  2.24-11+deb9u1

cpio recommends no packages.

Versions of packages cpio suggests:
pn  libarchive1  

-- no debconf information

Bug#874798: libc6: mktime() does not set errno when it fails

[g1]

Package: libc6
Version: 2.24-11+deb9u1
Severity: normal
Tags: upstream

When mktime() fails to convert a struct tm to a time_t, it returns -1.
It should also set errno to EOVERFLOW in order to distinguish the failure
from the legitimate case of converting "1 second before the epoch".

The following program, when run on a 32-bit system, shows that mktime
does not comply to the standard.  On recent amd64 systems, time_t is 64
bit long, therefore failure doesn't occur for the same broken down times.

Best regards,
g.b.

#define _POSIX_C_SOURCE 200112L

#include 
#include 
#include 
#include 
#include 

int main() {
struct tm tm0;
struct tm *ptm;
time_t t;
int eno;

assert(sizeof t == 4);  /* need 32 bit to trigger failure in 1900 */

/* nail timezone to UTC */
setenv("TZ", "UTC", 1);
tzset();

t = -1; /* 1 sec before epoch */
ptm = gmtime_r(, );
assert(ptm != NULL);
errno = 0;
t = mktime();
eno = errno;
printf("struct TM: %d-%d-%d %02d:%02d:%02d (dst=%d)\n", 1900 + tm0.tm_year,
   1 + tm0.tm_mon, tm0.tm_mday, tm0.tm_hour, tm0.tm_min,
   tm0.tm_sec, tm0.tm_isdst);
printf("mktime(): retval %ld (expected -1), "
   "errno %d (expected 0)\n", (long) t, eno);

tm0.tm_year = 0;/* warp to year 1900 */
/* bad conversion for 32-bit time_t, should return -1 and set errno */
errno = 0;
t = mktime();
eno = errno;
printf("struct TM: %d-%d-%d %02d:%02d:%02d (dst=%d)\n", 1900 + tm0.tm_year,
   1 + tm0.tm_mon, tm0.tm_mday, tm0.tm_hour, tm0.tm_min,
   tm0.tm_sec, tm0.tm_isdst);
printf("mktime(): retval %ld (expected -1), "
   "errno %d (expected EOVERFLOW=%d)\n", (long) t, eno, EOVERFLOW);
return 0;
}


-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-3-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libc6 depends on:
ii  libgcc1  1:6.3.0-18

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.61
pn  glibc-doc  
ii  libc-l10n  2.24-11+deb9u1
ii  locales2.24-11+deb9u1

-- debconf information excluded

Bug#864598: python-reportbug: logic error in send_report()

[g1]

Package: python-reportbug
Version: 6.6.3
Severity: normal

The condition 

elif outfile or not ((mta and os.path.exists(mta)) or smtphost):

in /usr/lib/python2.7/dist-packages/reportbug/submit.py (line 315) is true
also if outfile is None and mta is set to a non-existent path.

The following line 

msgname = os.path.expanduser(outfile) or ('/var/tmp/%s.bug' % package)

triggers an exception when os.path.expanduser is called with outfile=None
as its argument.

e.g., with .reportbugrc containing 

reportbug_version "6.6.3"
mode standard
ui text
realname "john smith"
email "john.sm...@example.com"
mta "~/bin/mta-wrapper"

submitting bug reports fails with

Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2211, in 
main()
  File "/usr/bin/reportbug", line 1081, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 2203, in user_interface
self.options.envelopefrom)
  File "/usr/lib/python2.7/dist-packages/reportbug/submit.py", line 316, in 
send_report
elif outfile or not ((mta and os.path.exists(mta)) or smtphost):
  File "/usr/lib/python2.7/posixpath.py", line 261, in expanduser
if not path.startswith('~'):

because

- mta is true
- os.path.exists(mta) is false (tilde expansion is not performed before testing)
- smtphost is false

so the block is entered with outfile=None

Best regards,
g.

-- System Information:
Debian Release: 8.8
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-586
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages python-reportbug depends on:
ii  apt   1.0.9.8.4
ii  python-debian 0.1.27
ii  python-debianbts  1.12
pn  python:any

python-reportbug recommends no packages.

Versions of packages python-reportbug suggests:
ii  reportbug  6.6.3

-- no debconf information

Bug#864500: cpp-4.9: warnings from assert(strncmp(...) == 0) when using -O

[g1]

Package: cpp-4.9
Version: 4.9.2-10
Severity: minor

The following program, 

#include 
#include 
int main() {
const char *a = "xyz", *b = a;
assert(strncmp(a, b, 3) == 0);
return 0;
}

compiles fine with
"gcc -Wall -ansi -pedantic -Wprogram.c",
but emits a warning when compiled with
"gcc -Wall -ansi -pedantic -W -O program.c",
namely

program.c: In function 'main':
program.c:6:5: warning: string length '2172' is greater than the length '509' 
ISO C90 compilers are required to support [-Woverlength-strings]
 assert(strncmp(a, b, 3) == 0);
 ^

The reason is that the -O option makes cpp expand "strncmp(a, b, 3)" into an
inline monster.

Best regards,
g.

-- System Information:
Debian Release: 8.8
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages cpp-4.9 depends on:
ii  gcc-4.9-base   4.9.2-10
ii  libc6  2.19-18+deb8u9
ii  libcloog-isl4  0.18.2-1+b2
ii  libgmp10   2:6.0.0+dfsg-6
ii  libisl10   0.12.2-2
ii  libmpc31.0.2-1
ii  libmpfr4   3.1.2-2
ii  zlib1g 1:1.2.8.dfsg-2+b1

cpp-4.9 recommends no packages.

Versions of packages cpp-4.9 suggests:
pn  gcc-4.9-locales  

-- no debconf information

Bug#821759: Iceweasel does not warn about website asking to store data for offline use

[g1]

Package: firefox-esr
Version: 45.7.0esr-1~deb8u1
Followup-For: Bug #821759

I believe browser.offline-apps.notify (i.e. ask me for offline
storage) is overridden by the offline-apps.allow_by_default,
which is true by default (no pun intended).

I got FF to ask me for permission after toggling the latter option
in about:config.

Probably an upstream bug.

Best regards,
g.

-- Package-specific info:

-- Extensions information
Name: Default theme
Location: 
/usr/lib/firefox-esr/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox-esr
Status: enabled

Name: Firefox Hello Beta
Location: ${PROFILE_EXTENSIONS}/l...@mozilla.org.xpi
Status: enabled

-- Plugins information

-- Addons package information
ii  firefox-esr45.7.0esr-1~ amd64Mozilla Firefox web browser - Ext

-- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages firefox-esr depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3+deb8u1
ii  libasound21.0.28-1
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-18+deb8u7
ii  libcairo2 1.14.0-2.1+deb8u2
ii  libdbus-1-3   1.8.22-0+deb8u1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.1-2+b2
ii  libfontconfig12.11.0-6.3+deb8u1
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:4.9.2-10
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libglib2.0-0  2.42.1-1+b1
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libhunspell-1.3-0 1.3.3-3
ii  libpango-1.0-01.36.8-3
ii  libsqlite3-0  3.8.7.1-1+deb8u2
ii  libstartup-notification0  0.12-4
ii  libstdc++64.9.2-10
ii  libx11-6  2:1.6.2-3
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  procps2:3.3.9-9
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages firefox-esr recommends:
ii  gstreamer1.0-libav 1.4.4-2
ii  gstreamer1.0-plugins-good  1.4.4-2+deb8u2

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.4-5
ii  fonts-stix [otf-stix]  1.1.1-1
ii  libcanberra0   0.30-2.1
pn  libgnomeui-0   
ii  libgssapi-krb5-2   1.12.1+dfsg-19+deb8u2
pn  mozplugger 

-- no debconf information

Bug#844089: e2fsprogs: e2image unable to restore metadata

[g1]

Package: e2fsprogs
Version: 1.42.12-2
Severity: normal

Apparently, e2image is unable to restore metadata from its own image files:

# mke2fs /tmp/scratch/b.img 
Creating filesystem with 262144 1k blocks and 65536 inodes
Filesystem UUID: f1cd508c-ea95-420f-89c4-61b989a0890e
Superblock backups stored on blocks: 
8193, 24577, 40961, 57345, 73729, 204801, 221185

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done 
# sync
# e2image -r /tmp/scratch/b.img /tmp/scratch/b.e2i 
# file /tmp/scratch/b.e2i
/tmp/scratch/b.e2i: Linux rev 1.0 ext2 filesystem data, 
UUID=f1cd508c-ea95-420f-89c4-61b989a0890e
# e2image -I /tmp/scratch/b.img /tmp/scratch/b.e2i 
e2image: Wrong magic number for Ext2 Image Header while trying to open 
/tmp/scratch/b.e2i

-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages e2fsprogs depends on:
ii  e2fslibs1.42.12-2
ii  libblkid1   2.25.2-6
ii  libc6   2.19-18+deb8u6
ii  libcomerr2  1.42.12-2
ii  libss2  1.42.12-2
ii  libuuid12.25.2-6
ii  util-linux  2.25.2-6

e2fsprogs recommends no packages.

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  gpart  
ii  parted 3.2-7

-- no debconf information

Bug#844050: cryptsetup: /lib/cryptsetup/scripts/decrypt_ssl throws away the key it has just decrypted

[g1]

Package: cryptsetup
Version: 2:1.6.6-5
Severity: normal

In /lib/cryptsetup/scripts/decrypt_ssl the relevant decryption command,
/usr/bin/openssl enc -aes-256-cbc -d -salt -in $1 >/dev/null 2>&1
redirects output from openssl enc -d to /dev/null, rendering the script
useless except for checking the key can actually be decrypted.  I'm not sure
that was the intent.

Best regards,
g.

-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages cryptsetup depends on:
ii  cryptsetup-bin 2:1.6.6-5
ii  debconf [debconf-2.0]  1.5.56
ii  dmsetup2:1.02.90-2.2+deb8u1
ii  libc6  2.19-18+deb8u6

Versions of packages cryptsetup recommends:
pn  busybox | busybox-static
pn  console-setup   
ii  initramfs-tools [linux-initramfs-tool]  0.120+deb8u2
ii  kbd 1.15.5-2

Versions of packages cryptsetup suggests:
ii  dosfstools  3.0.27-1
pn  keyutils
ii  liblocale-gettext-perl  1.05-8+b1

-- debconf information excluded

Bug#838958: linux: mount(2) _silently_ ignores other mountflags when MS_BIND is set

[g1]

Source: linux
Severity: important
Tags: upstream

>From the mount(2) man page:

MS_BIND (Linux 2.4 onward)
Perform a bind mount, making a file or a directory subtree visible at
another point within a filesystem. Bind mounts may cross filesystem
boundaries and span chroot(2) jails. The filesystemtype and data
arguments are ignored. Up until Linux 2.6.26, mountflags was also
ignored (the bind mount has the same mount options as the underlying
mount point).

Apparently, this applies to recent kernels too (at least 3.16).

Silently ignoring user-specified flags can open security holes, e.g. when
a sysadm bind-mounts a filesystem for use by a containter, thinking the mount
will be read-only:

# mount -o bind,ro /usr /containers/X/usr

Despite mount returning successfully, container X has /usr mounted
read/write, and root inside the container can easily corrupt/subvert
the host system.

Please keep in mind that recent versions of mount(1) work around the bug, by
calling mount() twice (once with the "bind" flag, then with the other flags),
but other applications calling mount() directly are usually affected.

Best regards,
giuseppe

-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#838957: lxc: read-only bind mounts are in fact read/write

[g1]

Package: lxc
Version: 1:1.0.6-6+deb8u3
Severity: important

To reproduce:

root@debian-host# lxc-create -n bb -t busybox

root@debian-host# cat /var/lib/lxc/bb/config 
lxc.network.type = empty
lxc.rootfs = /var/lib/lxc/bb/rootfs
lxc.haltsignal = SIGUSR1
lxc.utsname = bb
lxc.tty = 1
lxc.pts = 1
lxc.cap.drop = sys_module mac_admin mac_override sys_time

lxc.mount.entry = /lib lib none ro,bind 0 0
lxc.mount.entry = /usr/lib usr/lib none ro,bind 0 0
lxc.mount.entry = /lib64 lib64 none ro,bind 0 0
lxc.mount.entry = /sys/kernel/security sys/kernel/security none 
ro,bind,optional 0 0
lxc.mount.auto = proc:mixed sys

root@debian-host# lxc-start -n bb -d

root@debian-host# lxc-attach -n bb touch /lib/test-file

root@debian-host# ls -l /lib/test-file && rm -f /lib/test-file
-rw-r--r-- 1 root root 0 Sep 15 16:57 /lib/test-file

I.E., where the lxc config specifies "ro,bind" for the bind mounts,
in fact only the "bind" flag is honoured, and filesystems are mounted
read/write.  That's because of this passage in the mount(2) manpage:

MS_BIND (Linux 2.4 onward)
Perform a bind mount, making a file or a directory subtree visi-
ble at another point within a filesystem.  Bind mounts may cross
filesystem boundaries and span chroot(2) jails.  The filesystem-
type and data arguments are ignored.   Up  until  Linux  2.6.26,
>>>mountflags  was  also ignored<<< (the bind mount has the same
mount options as the underlying mount point).

Apparently, this behaviour (respect MS_BIND, _silently_ ignore other
flags) is still present in recent kernels, and is (IMO) a bug in
itself.

As a result, people are misled into thinking they can use LXC to build
sandboxes, perhaps by dropping the SYS_ADMIN capability in the containers,
yet commands performed by root inside such a container (think dpkg -i/-r,
or rm -rf or ...) may cause considerable damage to the host system, unless
uid/gid remapping is enforced.

The bug in mount(2) can be verified in debian/jessie e.g. by running
# mkdir /tmp/xyz-lib; mount -o ro,bind /lib /tmp/xyz-lib
which leaves /lib mounted r/w as /tmp/xyz-lib.

Recent versions of the mount(1) command work around the bug in mount(2)
by calling it twice, once with the MS_BIND flag, and then with the
other user-specified flags.  It is not an ideal solution (implies a race
condition), yet the end result is correct.

As to LXC, I believe the problem was fixed upstream by this commit:
https://github.com/lxc/lxc/commit/7c5b6e7c3524031c3e9e203a9ab3beea7efa7a41
which implements the double call to mount(2), and AFAICT is included
in lxc-1.0.7.  Therefore, I suggest to rebase the debian/jessie lxc
sources on lxc-1.0.7, instead of lxc-1.0.6.

Best regards,
giuseppe


-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lxc depends on:
ii  init-system-helpers  1.22
ii  libapparmor1 2.9.0-3
ii  libc62.19-18+deb8u6
ii  libcap2  1:2.24-8
ii  libseccomp2  2.1.1-1
ii  libselinux1  2.3-2
ii  multiarch-support2.19-18+deb8u6
ii  python3  3.4.2-2

Versions of packages lxc recommends:
ii  debootstrap  1.0.67
ii  openssl  1.0.1t-1+deb8u5
ii  rsync3.1.1-3

Versions of packages lxc suggests:
pn  lua5.2  

-- no debconf information

Bug#835421: mutt: Bug in POP3 authentication via SASL mechanism DIGEST-MD5

[g1]

Package: mutt
Version: 1.5.23-3
Severity: normal
Tags: patch upstream

According to , the DIGEST-MD5
authentication should proceed along a sequence similar to the following:

1. C: AUTH DIGEST-MD5
2. S: + base64-encoded-server-challenge
3. C: base64-encoded-client-response
4. S: + base64-encoded-server-auth-confirmation
5. C:
6. S: +OK Maildrop locked and ready

In fact, even if the server grants access, mutt detects a spurious error,
sends the server a standalone "*" to request protocol shutdown, and fails.

The problem stems from the fact that the pop_auth_sasl() in
file pop_auth.c incorrectly terminates the SASL protocol at
step 4, then checks that the last message from the server
("+ base64-encoded-server-auth-confirmation") starts with "+OK", and of
course fails.

I believe the attached patch fixes the problem.

Best regards,
g.b.

-- Package-specific info:
Mutt 1.5.23 (2014-03-12)
Copyright (C) 1996-2009 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 3.16.0-4-amd64 (x86_64)
ncurses: ncurses 5.9.20140913 (compiled with 5.9)
libidn: 1.29 (compiled with 1.29)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-4' 
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs 
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.9 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls 
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify 
--enable-plugin --with-system-zlib --disable-browser-plugin 
--enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-4) 

Configure options: '--prefix=/usr' '--sysconfdir=/etc' 
'--mandir=/usr/share/man' '--with-docdir=/usr/share/doc' 
'--with-mailpath=/var/mail' '--disable-dependency-tracking' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' '--with-curses' 
'--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' '--with-sasl' 
'--without-gdbm' '--without-bdb' '--without-qdbm' '--build' 'x86_64-linux-gnu' 
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall' 'LDFLAGS=-Wl,-z,relro' 
'CPPFLAGS=-D_FORTIFY_SOURCE=2 -I/usr/include/qdbm'

Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +COMPRESSED  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET 
 +HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  +HAVE_GETSID  +USE_HCACHE  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"
To contact the developers, please mail to .
To report a bug, please visit http://bugs.mutt.org/.

misc/am-maintainer-mode.patch
features/ifdef.patch
features/xtitles.patch
features/trash-folder.patch
features/purge-message.patch
features/imap_fast_trash.patch
features/sensible_browser_position.patch
features-old/patch-1.5.4.vk.pgp_verbose_mime.patch
features/compressed-folders.patch
features/compressed-folders.debian.patch
debian-specific/Muttrc.patch
debian-specific/Md.etc_mailname_gethostbyname.patch
debian-specific/use_usr_bin_editor.patch
debian-specific/correct_docdir_in_man_page.patch
debian-specific/dont_document_not_present_features.patch

Bug#825416: libssl1.0.0: upstream bug report

[g1]

Package: libssl1.0.0
Followup-For: Bug #825416

https://rt.openssl.org/Ticket/Display.html?id=4546

Bug#825416: libssl1.0.0: EVP_{Encrypt, Decrypt, Cipher}Final() do not clean up cipher context

[g1]

Package: libssl1.0.0
Version: 1.0.1k-3+deb8u5
Severity: important
Tags: upstream

The EVP_EncryptFinal(3ssl) man page reads:

EVP_EncryptFinal(), EVP_DecryptFinal() and EVP_CipherFinal() behave
in a similar way to EVP_EncryptFinal_ex(), EVP_DecryptFinal_ex()
and EVP_CipherFinal_ex() except ctx is automatically cleaned up after
the call.

However, the code in crypto/evp/evp_enc.c has

int EVP_EncryptFinal(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl)
{
int ret;
ret = EVP_EncryptFinal_ex(ctx, out, outl);
return ret;
}

that is, EVP_EncryptFinal() is exactly equivalent to EVP_EncryptFinal_ex().

In addition to causing memory leaks, promptly flagged by valgrind,
this might have security implications, because context cleanup does
not happen, and keys remain in memory, waiting for the next heartbleed.
I'd love to be mistaken.

Best regards,
g.

-- System Information:
Debian Release: 8.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libssl1.0.0 depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  libc6  2.19-18+deb8u4
ii  multiarch-support  2.19-18+deb8u4

libssl1.0.0 recommends no packages.

libssl1.0.0 suggests no packages.

-- debconf information:
  libssl1.0.0/restart-failed:
* libssl1.0.0/restart-services: ssh exim4 bind9 apache2

Bug#823222: gcc-4.9: reordering of signed int operations triggers overflow

[g1]

Package: gcc-4.9
Version: 4.9.2-10
Severity: normal

I compiled the program

#include 
#include 
int main() {
int s = 1 << 30;
s += (s - 1);
printf("%d\n%d\n%d\n", sizeof s, s, INT_MAX);
return 0;
}

with "gcc -W -Wall -ansi -pedantic -O0 -fsanitize=undefined".
The executable emits warnings for undefined behaviour at runtime:

a.c:6:7: runtime error: signed integer overflow: 1073741824 + 1073741824 cannot 
be represented in type 'int'
a.c:6:7: runtime error: signed integer overflow: -2147483648 + -1 cannot be 
represented in type 'int'
4
2147483647
2147483647

As far as I can tell, the program is correct, and does not involve undefined
behaviour because no signed-integer overflow occurs.  It turns out, however,
that gcc transforms 

s += (s - 1);

into 

s += s;
s -= 1;

even at -O0, as is apparent in the generated assembly code (gcc -O0 -S)
...
movl$1073741824, -12(%ebp)
movl-12(%ebp), %eax
addl%eax, %eax
subl$1, %eax
movl%eax, -12(%ebp)
...

Here, it seems that the compiler and libubsan disagree, and I'm not sure which
one is right.

Best regards,
g.

-- System Information:
Debian Release: 8.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gcc-4.9 depends on:
ii  binutils2.25-5
ii  cpp-4.9 4.9.2-10
ii  gcc-4.9-base4.9.2-10
ii  libc6   2.19-18+deb8u4
ii  libcloog-isl4   0.18.2-1+b2
ii  libgcc-4.9-dev  4.9.2-10
ii  libgmp102:6.0.0+dfsg-6
ii  libisl100.12.2-2
ii  libmpc3 1.0.2-1
ii  libmpfr43.1.2-2
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages gcc-4.9 recommends:
ii  libc6-dev  2.19-18+deb8u4

Versions of packages gcc-4.9 suggests:
ii  gcc-4.9-doc   4.9.1-3
pn  gcc-4.9-locales   
pn  gcc-4.9-multilib  
pn  libasan1-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information

Bug#787969: udev integration: overheating disk caused by mistakes in 85-hdparm.rules and hdparm-functions

[g1]

Package: hdparm
Version: 9.43-2
Severity: important

Mistake in /lib/udev/rules.d/85-hdparm.rules:
ACTION==add, SUBSYSTEM==block, KERNEL==[sh]d[a-z]*, 
RUN+=/lib/udev/hdparm
should be 
ACTION==add, SUBSYSTEM==block, KERNEL==[sh]d[a-z], 
RUN+=/lib/udev/hdparm

As it is now, the rule matches when partitions are detected by udev,
typically after the disk device, and /lib/udev/hdparm is invoked with
e.g. DEVNAME=/dev/sda2 after being invoked with DEVNAME=/dev/sda.
I'm quite confident this is not the behaviour most users expect.

Brain damage in /lib/hdparm/hdparm-functions:
hdparm_options() contains 
# set our default global apm policy here.
if hdparm_try_apm $WANTED_DISK; then
if hdparm_is_on_battery; then
hdparm_set_option -B128
...
else
hdparm_set_option -B254
fi
fi
which causes it to emit -B254 or -B128 even if no stanza in
/etc/hdparm.conf matches the device name (and usually hdparm.conf has
no stanza for partitions).  Since the ioctl() on the partition acts in
fact on the disk, the result is that power management is set on the disk
depending only on battery vs AC status, overriding user's preferences
listed in /etc/hdparm.conf for the disk.

As a side note: duplicating (almost) the parsing logic of
/etc/init.d/hdparm in /lib/hdparm/hdparm-functions is an efficient way
to let bugs slip through.

Best regards
g

-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages hdparm depends on:
ii  libc6 2.19-18
ii  lsb-base  4.1+Debian13+nmu1

Versions of packages hdparm recommends:
pn  powermgmt-base  none

Versions of packages hdparm suggests:
pn  apmd  none

-- Configuration Files:
/etc/hdparm.conf changed:
/dev/sda {
apm = 128
apm_battery = 128
quiet
}


-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#785307: xcolorsel: Crash in Grab color

[g1]

Package: xcolorsel
Version: 1.1a-18
Severity: normal
Tags: patch

If I start xcolorsel and click Grab color, the program crashes with a SEGV as
soon as I pick a color and click.

I could not understand why it happens, but apparently the attached patch works
around the problem.

best regards
g1

-- System Information:
Debian Release: 8.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages xcolorsel depends on:
ii  libc6 2.19-18
ii  libice6   2:1.0.9-1+b1
ii  libsm62:1.2.2-1+b1
ii  libx11-6  2:1.6.2-3
ii  libxext6  2:1.3.3-1
ii  libxmu6   2:1.1.2-1
ii  libxpm4   1:3.5.11-1+b1
ii  libxt61:1.1.4-1+b1
ii  xaw3dg1.5+E-18.2

xcolorsel recommends no packages.

xcolorsel suggests no packages.

-- no debconf information
diff -rwub old/RgbText.c new/RgbText.c
--- old/RgbText.c	2015-05-14 16:06:06.375622569 +0200
+++ new/RgbText.c	2015-05-14 16:06:32.239774231 +0200
@@ -1116,6 +1116,7 @@
 	start+=1+myself(w).rgb_text.tile_width;
 	end=(strchr(ptr,'\n')-myself(w).rgb_text.asciirep);
 	/*Display selection:*/
+	XawTextSetSelection(w, 0, end);
 	XawTextSetSelection(w, start, end);
 	XawTextSetInsertionPoint(w, end);
 	/*Set cursor*/

Bug#784143: pgrep: behaviour of '-lf' changed.

[g1]

Package: procps
Version: 2:3.3.9-9
Severity: normal

In procps/wheezy, the combination of the '-l' and '-f' flags had a specific
output, which IIRC was the same across *BSD, Solaris, and many versions of
GNU/Linux:

$ pgrep -lf iceweasel
6543 iceweasel --no-remote

In jessie, the behaviour has changed, and the '-a' flag was added to restore
the previous output format:

$ pgrep -lf iceweasel
6543 iceweasel

Wouldn't it be more convenient to _add_ an option to change the behaviour
according to #526355, instead of changing the result of pre-existing
options?

-- System Information:
Debian Release: 8.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages procps depends on:
ii  initscripts   2.88dsf-59
ii  libc6 2.19-18
ii  libncurses5   5.9+20140913-1+b1
ii  libncursesw5  5.9+20140913-1+b1
ii  libprocps32:3.3.9-9
ii  libtinfo5 5.9+20140913-1+b1
ii  lsb-base  4.1+Debian13+nmu1

Versions of packages procps recommends:
ii  psmisc  22.21-2

procps suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#744942: a2ps: ap2s reads init file from current directory

[g1]

Package: a2ps
Version: 1:4.14-1.1+deb7u1
Severity: normal

a2ps reads and parses ./.a2psrc, without checking ownership of the
file/directory.  This might be used to trick other users (even root) into
executing crafted code, perhaps leading to local compromise.

joe:~$ echo 'Variable: lp.default | /bin/echo whatever...' /tmp/.a2psrc

later...

root:~# cd /tmp
root:/tmp# a2ps -q /etc/group
whatever...

Best regards,
g

-- System Information:
Debian Release: 7.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages a2ps depends on:
ii  dpkg  1.16.12
ii  file  5.11-2+deb7u3
ii  install-info  4.13a.dfsg.1-10
ii  libc6 2.13-38+deb7u1
ii  libpaper1 1.1.24+nmu2
ii  psutils   1.17.dfsg-1

Versions of packages a2ps recommends:
ii  bzip2  1.0.6-4
ii  lpr1:2008.05.17+nmu1
pn  wdiff  none

Versions of packages a2ps suggests:
ii  emacsen-common   2.0.5
ii  ghostscript  9.05~dfsg-6.3+deb7u1
pn  groffnone
ii  gv   1:3.7.3-1
pn  html2ps  none
ii  imagemagick  8:6.7.7.10-5+deb7u3
pn  t1-cyrillic  none
ii  texlive-binaries [texlive-base-bin]  2012.20120628-4

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#743973: duplicity: make imap backend split files in chunks

[g1]

Package: duplicity
Version: 0.6.18-3
Severity: normal
Tags: patch

I implemented a set of changes to the imap backend, to work around
the restrictions on message size that most IMAP providers impose on
customer mailboxes: the code has been slightly simplified, and changed
to transparently store and fetch large files in chunks not larger than
a chosen size (specified via the --imapsize option).

I had no time to run extensive tests, but I was able to backup and restore
a large tree with a signature file in excess of 40 MB (base64-encoded)
to my mailbox.  (with --volsize 60 --imapsize 21)

I experimented with a few mailboxes of mine, and failed with all but
one of them, for a variety of reasons ranging from timeouts during IMAP
STORE to unavailable folders after the upload.  The one that consistently
worked like a charm has a g in the domain part. ;-)

I hope the DD considers the patch for inclusion in the debian package, and
perhaps submit it to upstream as a hint.

Best regards,
g

-- System Information:
Debian Release: 7.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (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 duplicity depends on:
ii  libc6  2.13-38+deb7u1
ii  librsync1  0.9.7-9
ii  python 2.7.3-4+deb7u1
ii  python-gnupginterface  0.3.2-9.1

Versions of packages duplicity recommends:
pn  python-paramiko  none
ii  rsync3.0.9-4

Versions of packages duplicity suggests:
ii  lftp   4.3.6-1+deb7u2
pn  ncftp  none
pn  python-botonone
pn  python-cloudfiles  none
pn  python-gdata   none
pn  python-pexpect none
pn  tahoe-lafs none

-- no debconf information
diff -ru /tmp/d.or/usr/share/pyshared/duplicity/backends/imapbackend.py /usr/share/pyshared/duplicity/backends/imapbackend.py
--- /tmp/d.or/usr/share/pyshared/duplicity/backends/imapbackend.py	2012-02-29 20:24:04.0 +0100
+++ /usr/share/pyshared/duplicity/backends/imapbackend.py	2014-04-08 22:07:17.312737024 +0200
@@ -29,6 +29,8 @@
 import rfc822
 import getpass
 import email
+import email.message
+import base64
 
 import duplicity.backend
 from duplicity import globals
@@ -37,12 +39,15 @@
 
 
 class ImapBackend(duplicity.backend.Backend):
+
 def __init__(self, parsed_url):
 duplicity.backend.Backend.__init__(self, parsed_url)
 
 log.Debug(I'm %s (scheme %s) connecting to %s as %s %
   (self.__class__.__name__, parsed_url.scheme, parsed_url.hostname, parsed_url.username))
 
+self.reKofN = re.compile(^(.*)-([0-9]+)of([0-9]+)$)
+
 #  Store url for reconnection on error
 self._url = parsed_url
 
@@ -99,8 +104,8 @@
 log.Info(IMAP connected)
 
 
-def _prepareBody(self,f,rname):
-mp = email.MIMEMultipart.MIMEMultipart()
+def _prepareBody(self,payload,rname):
+mp = email.message.Message()
 
 # I am going to use the remote_dir as the From address so that
 # multiple archives can be stored in an IMAP account and can be
@@ -108,12 +113,9 @@
 mp[From]=self.remote_dir
 mp[Subject]=rname
 
-a = email.MIMEBase.MIMEBase(application,binary)
-a.set_payload(f.read())
-
-email.Encoders.encode_base64(a)
+a = base64.encodestring(payload)
 
-mp.attach(a)
+mp.set_payload(a)
 
 return mp.as_string()
 
@@ -121,18 +123,27 @@
 if not remote_filename:
 remote_filename = source_path.get_filename()
 f=source_path.open(rb)
+payload=f.read()
+chunks = {}
+nchunks = int((len(payload) + globals.imapsize - 1) / globals.imapsize)
+if nchunks  2:
+chunks[] = payload
+else:
+for i in xrange(nchunks):
+chunks[- + str(i+1) + of + str(nchunks)] = \
+payload[i * globals.imapsize : (i + 1) * globals.imapsize]
 allowedTimeout = globals.timeout
 if (allowedTimeout == 0):
 # Allow a total timeout of 1 day
 allowedTimeout = 2880
 while allowedTimeout  0:
 try:
-self._conn.select(remote_filename)
-body=self._prepareBody(f,remote_filename)
 # If we don't select the IMAP folder before
 # append, the message goes into the INBOX.
 self._conn.select(globals.imap_mailbox)
-self._conn.append(globals.imap_mailbox, None, None, body)
+for csuf in chunks:
+body=self._prepareBody(chunks[csuf],remote_filename + csuf)
+self._conn.append(globals.imap_mailbox, None, None, body)
 break
 except (imaplib.IMAP4.abort, socket.error, socket.sslerror):
 allowedTimeout -= 1
@@ 

Bug#735168: FILESAVE: LibreOffice corrupts XLSX file (upstream bug 49120)

[g1]

Package: libreoffice-calc
Version: 1:3.5.4+dfsg2-0+deb7u2
Followup-For: Bug #735168


This looks like an upstream bug, 
https://bugs.freedesktop.org/show_bug.cgi?id=49120,
which might have been resolved by this patch
http://cgit.freedesktop.org/libreoffice/core/commit/?id=95487b1116471b19447b9720b64a934abd668aff.

Would you please incorporate it in LO/wheezy?

Best regards,
g


-- System Information:
Debian Release: 7.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages libreoffice-calc depends on:
ii  libc6  2.13-38+deb7u1
ii  libgcc11:4.7.2-5
ii  libreoffice-base-core  1:3.5.4+dfsg2-0+deb7u2
ii  libreoffice-core   1:3.5.4+dfsg2-0+deb7u2
ii  libstdc++6 4.7.2-5
ii  lp-solve   5.5.0.13-7
ii  uno-libs3  3.5.4+dfsg2-0+deb7u2
ii  ure3.5.4+dfsg2-0+deb7u2

libreoffice-calc recommends no packages.

libreoffice-calc suggests no packages.

Versions of packages libreoffice-core depends on:
ii  fontconfig   2.9.0-7.1
ii  fonts-opensymbol 2:102.2+LibO3.5.4+dfsg2-0+deb7u2
ii  libc62.13-38+deb7u1
ii  libcairo21.12.2-3
ii  libcmis-0.2-00.1.0-1+b1
ii  libcurl3-gnutls  7.26.0-1+wheezy8
ii  libdb5.1 5.1.29-5
ii  libexpat12.1.0-1+deb7u1
ii  libexttextcat0   3.2.0-2
ii  libfontconfig1   2.9.0-7.1
ii  libfreetype6 2.4.9-1.1
ii  libgcc1  1:4.7.2-5
ii  libglib2.0-0 2.33.12+really2.32.4-5
ii  libgraphite2-2.0.0   1.1.3-1
ii  libgstreamer-plugins-base0.10-0  0.10.36-1.1
ii  libgstreamer0.10-0   0.10.36-1.2
ii  libhunspell-1.3-01.3.2-4
ii  libhyphen0   2.8.3-2
ii  libice6  2:1.0.8-2
ii  libicu48 4.8.1.1-12+deb7u1
ii  libjpeg8 8d-1
ii  libmythes-1.2-0  2:1.2.2-1
ii  libneon27-gnutls 0.29.6-3
ii  libnspr4 2:4.9.2-1+deb7u1
ii  libnss3  2:3.14.5-1
ii  libnss3-1d   2:3.14.5-1
ii  libpng12-0   1.2.49-1
ii  librdf0  1.0.15-1+b1
ii  libreoffice-common   1:3.5.4+dfsg2-0+deb7u2
ii  librsvg2-2   2.36.1-2
ii  libsm6   2:1.2.1-2
ii  libssl1.0.0  1.0.1e-2+deb7u4
ii  libstdc++6   4.7.2-5
ii  libx11-6 2:1.5.0-1+deb7u1
ii  libxext6 2:1.3.1-2+deb7u1
ii  libxinerama1 2:1.1.2-1+deb7u1
ii  libxml2  2.8.0+dfsg1-7+nmu2
ii  libxrandr2   2:1.3.2-2+deb7u1
ii  libxrender1  1:0.9.7-1+deb7u1
ii  libxslt1.1   1.1.26-14.1
ii  uno-libs33.5.4+dfsg2-0+deb7u2
ii  ure  3.5.4+dfsg2-0+deb7u2
ii  zlib1g   1:1.2.7.dfsg-13

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#694351: lsof: Please downgrade the dependency on perl to Recommends

[g1]

Package: lsof
Version: 4.86+dfsg-1
Followup-For: Bug #694351

As far as I can tell, the lsof executable is perfectly usable, and very
useful, without perl installed; and perl is only needed to run example
scripts.

Since 
- this bug has been open since 2012;
- contrary to widespread belief, perl is not universally installed (e.g. name
  servers, ntp servers);
- the dependence on perl bumps the disk requirements from 500 kB to ~27MB,
  which is plain unacceptable on tight systems;
I propose to expedite its closing via a downgrade of the dependency from
Depends: to Recommends:.

Best regards,
g1

-- System Information:
Debian Release: 7.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages lsof depends on:
ii  libc6  2.13-38+deb7u1
ii  perl   5.14.2-21+deb7u1
ii  perl-modules [libperl4-corelibs-perl]  5.14.2-21+deb7u1

lsof recommends no packages.

lsof suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#740221: cvs: configure --disable-rootcommit considered harmful

[g1]

Package: cvs
Version: 2:1.12.13+real-9
Severity: normal

debian/rules configures the package with --disable-rootcommit (which
is also the upstream default), to prevent root from committing to local
repositories.

That makes impossible for root to track his own files in a private local
repository, located under /root, thus forcing sysadms to fall back to RCS,
or switch to heavier and less flexible VC systems.

Now, the obstacle can be circumvented, e.g. by working around getlogin()
and overriding its NULL return value via the environment variable LOGNAME,
effectively impersonating any user:

env LOGNAME=someuser cvs -d :fork:/root/my.repo commit -m blablabla -

As a last resort, a malicious superuser (?!?) can always commit as a
non-privileged user, and then manipulate the text files under CVSROOT.

Summarizing: as a security measure, disabling root commit is next to
irrelevant, but inconvenient for honest sysadms.  Therefore I suggest to
toggle the flag in debian/rules, replacing it with --enable-rootcommit.

A better solution would be to add a flag (perhaps -S) to the commit
subcommand, and refuse to proceed (to remind the superuser that he is
trying to commit with root privileges) unless the flag is specified on
the command line; but I don't expect upstream to easily agree.

Best regards
g

-- System Information:
Debian Release: 7.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (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 cvs depends on:
ii  adduser   3.113+nmu3
ii  dpkg  1.16.12
ii  install-info  4.13a.dfsg.1-10
ii  libbsd0   0.4.2-1
ii  libc6 2.13-38+deb7u1
ii  libgssapi-krb5-2  1.10.1+dfsg-5+deb7u1
ii  libkrb5-3 1.10.1+dfsg-5+deb7u1
ii  zlib1g1:1.2.7.dfsg-13

Versions of packages cvs recommends:
ii  openssh-client  1:6.0p1-4

Versions of packages cvs suggests:
pn  mksh  none
ii  rcs   5.8.1-1

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739853: bash: hash -l output not always reusable for input

[g1]

Package: bash
Version: 4.2+dfsg-0.1
Severity: minor

Output from hash -l is not properly quoted, and might lead to surprises
when a file name contains whitespace characters:

$ add2path=`mktemp -d /tmp/XX`
$ export PATH=$PATH:$add2path
$ cp -p /bin/true $add2path/t rue
$ t rue
$ hash -l | tee $add2path/script
builtin hash -p /tmp/PukY3C/t rue t rue
builtin hash -p /bin/cp cp
$ . $add2path/script
$ hash -l
builtin hash -p /tmp/C3TzlZ/t rue
builtin hash -p /tmp/C3TzlZ/t rue t rue
builtin hash -p /bin/cp cp
builtin hash -p /tmp/C3TzlZ/t t

Best regards,
g

-- System Information:
Debian Release: 7.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (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 bash depends on:
ii  base-files   7.1wheezy4
ii  dash 0.5.7-3
ii  debianutils  4.3.2
ii  libc62.13-38+deb7u1
ii  libtinfo55.9-10

Versions of packages bash recommends:
pn  bash-completion  none

Versions of packages bash suggests:
pn  bash-doc  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#731621: duplicity: verify does not really check file contents. it compares only inode information

[g1]

Package: duplicity
Version: 0.6.18-3
Severity: normal
Tags: upstream

The verify command of duplicity does not check file contents, it only
compares modification time and size of files and directories.

For example, if one issues the following commands, 
mkdir /tmp/src
echo hello  /tmp/src/a
touch -r /tmp/src/a /tmp/refdate
duplicity full   --no-encryption /tmp/src file:///tmp/dst
echo world  /tmp/src/a
touch -r /tmp/refdate /tmp/src/a
duplicity verify --no-encryption file:///tmp/dst /tmp/src
then the last verify does not report any difference, although /tmp/src/a HAS 
changed.

In other words, one cannot rely on duplicity to check that the data on disk
are identical to those backed up.

Best regards,
g



-- System Information:
Debian Release: 7.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (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 duplicity depends on:
ii  libc6  2.13-38
ii  librsync1  0.9.7-9
ii  python 2.7.3-4+deb7u1
ii  python-gnupginterface  0.3.2-9.1

Versions of packages duplicity recommends:
pn  python-paramiko  none
ii  rsync3.0.9-4

Versions of packages duplicity suggests:
ii  lftp   4.3.6-1+deb7u2
pn  ncftp  none
pn  python-botonone
pn  python-cloudfiles  none
pn  python-gdata   none
pn  python-pexpect none
pn  tahoe-lafs none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#731330: libstdc++6: functions labelled FNV-1a in /usr/include/c++/4.7/tr1/functional_hash.h are not FNV-1a

[g1]

Package: libstdc++6
Version: 4.7.2-5
Severity: minor

As far as I know, the FNV and FNV-1a algorithms process octects, i.e. unsigned
chars.  (see e.g. http://tools.ietf.org/html/draft-eastlake-fnv-03#section-2 )

The implementations in /usr/include/c++/4.7/tr1/functional_hash.h work
on chars, instead, and their output is wrong (in architectures where char is
signed) when the input byte sequence includes bytes with the MSB set.

For example
std::tr1::_Fnv_hash_base4::hash(\x80, 1)
returns 83079839, instead of the correct value 2232128415.

The problem resides in the type cast:

template
struct _Fnv_hash_base4
{
  templatetypename _Tp
static size_t
hash(const _Tp* __ptr, size_t __clength)
{
  size_t __result = static_castsize_t(2166136261UL);
   const char* __cptr = reinterpret_castconst char*(__ptr);
  for (; __clength; --__clength)
{
  __result ^= static_castsize_t(*__cptr++);
  __result *= static_castsize_t(16777619UL);
}
  return __result;
}
};

The highlighed line should read:
const unsigned char* __cptr = reinterpret_castconst unsigned char*(__ptr);

Since the FNV primes were carefully chosen in order to minimize
collision rates and maximize dispersion, there might be consequences in
the performance of data structures that build on tr1::hash template,
perhaps tr1::unordered_map and tr1::unordered_set.

Best regards,
g

-- System Information:
Debian Release: 7.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages libstdc++6 depends on:
ii  gcc-4.7-base   4.7.2-5
ii  libc6  2.13-38
ii  libgcc11:4.7.2-5
ii  multiarch-support  2.13-38

libstdc++6 recommends no packages.

libstdc++6 suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#730029: fdm does not match hostname/fqdn against Subject Alternative Name

[g1]

Package: fdm
Version: 1.6+cvs20111013-2
Severity: wishlist
Tags: patch upstream

fdm rejects the SSL certificate for one of the pop3s servers listed in my
configuration, because the hostname does not match the CN in the X509
structure.  

However, the hostname does match one of the DNS names listed in the
X509v3 Subject Alternative Name extension, and should be considered valid.

In fact, other pop3s clients (notably mutt and icedove) do accept the
certificate, while fdm requires a no-verify option to proceed to my inbox.

The attached patch implements the logic to check SANs in case the CN does not
match.

Best regards,
g

-- System Information:
Debian Release: 7.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages fdm depends on:
ii  adduser  3.113+nmu3
ii  libc62.13-38
ii  libpcre3 1:8.30-5
ii  libssl1.0.0  1.0.1e-2
ii  libtdb1  1.2.10-2
ii  zlib1g   1:1.2.7.dfsg-13

fdm recommends no packages.

fdm suggests no packages.

-- no debconf information
--- connect.c.orig	2013-11-20 09:41:34.632235841 +0100
+++ connect.c	2013-11-20 12:13:25.294174792 +0100
@@ -33,6 +33,7 @@
 
 #include openssl/ssl.h
 #include openssl/err.h
+#include openssl/x509v3.h
 
 #include fdm.h
 
@@ -83,6 +84,39 @@
 	return (cause);
 }
 
+static
+char *
+ssl_check_alt_names(char *host, char *fqdn, X509 *x509)
+{
+	int n;
+	const int fn_flags = FNM_NOESCAPE | FNM_CASEFOLD;
+	char *ptr = NULL;
+	const GENERAL_NAMES *ans =
+		X509_get_ext_d2i(x509, NID_subject_alt_name, NULL, NULL);
+
+	if (!ans) 
+		return ptr;
+
+	n = sk_GENERAL_NAME_num(ans);
+
+	while (n--  0  ptr == NULL) {
+		char *buf = NULL;
+		const GENERAL_NAME *p = sk_GENERAL_NAME_value(ans, n);
+		if (!p || p-type != GEN_DNS)
+			continue;
+		ASN1_STRING_to_UTF8((unsigned char **) buf, p-d.dNSName);
+		if (buf == NULL) 
+			continue;
+		if (fnmatch(buf, host, fn_flags) == 0 ||
+(fqdn  fnmatch(buf, fqdn, fn_flags) == 0))
+			ptr = buf;
+		OPENSSL_free(buf);
+	}
+
+	sk_GENERAL_NAME_free(ans);
+	return ptr;
+}
+
 int
 sslverify(struct server *srv, SSL *ssl, char **cause)
 {
@@ -130,6 +164,11 @@
 		if (ptr2 != NULL)
 			*ptr2 = '/';
 	} while ((ptr = strstr(ptr, /CN=)) != NULL);
+
+	/* No valid CN found.  Try alternative names */
+	if (ptr == NULL)
+		ptr = ssl_check_alt_names(srv-host, fqdn, x509);
+
 	if (fqdn != NULL)
 		xfree(fqdn);
 

Bug#725417: mbr: install-mbr wipes the disk-id portion of the MBR, rendering Windows 7 unbootable

[g1]

Package: mbr
Version: 1.1.11-5+b1
Severity: important
Tags: upstream

For years, I have run install-mbr /dev/sda on every hard disk where
I wanted to install Linux to its own partition, in addition to a
pre-existing Windows partition.  Last time I did, it resulted in an
unbootable Windows 7 system.  Here is what I discovered afterwards:

According to http://en.wikipedia.org/wiki/Master_boot_record, bytes
440--443 of the MBR are reserved for the Disk Id.  Windows 7 (and likely
also Vista) stores that Id in its Boot Configuration Data (BCD) file,
and fails to boot unless the Id on disk matches the one in the BCD.

The install-mbr program copies the original MBR from disk into RAM,
overwrites the first 512 - 66 == 446 bytes with internal code, appends
the original partition table at offset 446, then writes the sector back
to disk.  With the default internal code, the Disk Id is changed to
0x, rendering W7 unbootable with overwhelming probability.

I don't know if bytes 440--446 of the internal MBR are useful code
or leftover garbage, therefore I'm not able to suggest a patch.
Please consider adding to the man page (and perhaps the executable itself)
a prominent warning against using install-mbr on a disk containing
Windows Vista or later.

For the record, I was able to restore the disk-id by examining the BCD
via hexdump, guessing the original id, and restoring it on disk via the
expert menu of the fdisk utility.  Needless to say, I promptly purged
the mbr package from my system.

Best regards,
g

-- System Information:
Debian Release: 7.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (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 mbr depends on:
ii  libc6  2.13-38

mbr recommends no packages.

mbr suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718205: e2fsprogs: integer overflow in e2freefrag leads to wrong max extent report

[g1]

Package: e2fsprogs
Version: 1.42.5-1.1
Severity: minor
Tags: patch upstream

e2freefrag report incoherent information on a large filesystem with large
chunks of contiguous free space, due to integer overflow in computing max free
extent.  I did not check if it's really present upstream, but I believe it
likely.

In the following output, max free  1G disagree with 1 extent = 16 GB.  A
minimal --- meaning that no types are changed --- patch is attached.

best regards,
g

:   Device: /dev/sda6
:   Blocksize: 4096 bytes
:   Total blocks: 29302784
:   Free blocks: 11744387 (40.1%)
:
:   Min. free extent: 4 KB 
:   Max. free extent: 653272 KB
:   Avg. free extent: 15828 KB
:   Num. free extent: 3012
:
:   HISTOGRAM OF FREE EXTENT SIZES:
:   Extent Size Range :  Free extents   Free Blocks  Percent
:   4K...8K-  :   333   3330.00%
:   8K...   16K-  :   206   4840.00%
:  16K...   32K-  :   258  13700.01%
:  32K...   64K-  :   292  32830.03%
:  64K...  128K-  :   334  75710.06%
: 128K...  256K-  :   212  96170.08%
: 256K...  512K-  :   214 192760.16%
: 512K... 1024K-  :   323 585330.50%
:   1M...2M-  :   4491687681.44%
:   2M...4M-  :   2872037161.73%
:   4M...8M-  :981178781.00%
:  16M...   32M-  : 1  76780.07%
:  32M...   64M-  : 1 123370.11%
:  64M...  128M-  : 1 186100.16%
:   8G...   16G-  : 2   5884523   50.10%
:  16G...   32G-  : 1   5406198   46.03%

-- System Information:
Debian Release: 7.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (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 e2fsprogs depends on:
ii  e2fslibs1.42.5-1.1
ii  libblkid1   2.20.1-5.3
ii  libc6   2.13-38
ii  libcomerr2  1.42.5-1.1
ii  libss2  1.42.5-1.1
ii  libuuid12.20.1-5.3
ii  util-linux  2.20.1-5.3

e2fsprogs recommends no packages.

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  none
pn  gpart  none
ii  parted 2.3-12

-- no debconf information
--- misc/e2freefrag.c.orig	2013-07-28 20:09:52.0 +0200
+++ misc/e2freefrag.c	2013-07-28 20:10:05.0 +0200
@@ -172,10 +172,16 @@
 
 	/* Display chunk information in KB */
 	if (info-real_free_chunks) {
-		info-min = (info-min * fs-blocksize)  10;
-		info-max = (info-max * fs-blocksize)  10;
+		unsigned long scaled_blocksize = fs-blocksize;
+		int shift = 10;
+		if (fs-blocksize = (1  10)) {
+			shift = 0;
+			scaled_blocksize = fs-blocksize  10;
+		}
+		info-min = (info-min * scaled_blocksize)  shift;
+		info-max = (info-max * scaled_blocksize)  shift;
 		info-avg = (info-avg / info-real_free_chunks *
-			 fs-blocksize)  10;
+			 scaled_blocksize)  shift;
 	} else {
 		info-min = 0;
 	}

Bug#712969: spell does not default to reading from stdin when options are present (generalizes #323011)

[g1]

Package: spell
Version: 1.0-24
Severity: normal
Tags: patch

Dear Maintainer,

consider this script:

for i in spell spell - spell -D italian spell -D italian -  ; do
echo  $i
echo casa house sdfsdfhk | $i
done

and its output:

 spell
casa
sdfsdfhk
 spell -
casa
sdfsdfhk
 spell -D italian
 spell -D italian -
house
sdfsdfhk

The cause is a test for default to stdin that fails when argc  1
(because options where specified in the command line).  The attached
patch fixes that.

Best regards
g

-- System Information:
Debian Release: 7.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (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 spell depends on:
ii  iamerican [ispell-dictionary]  3.3.02-6
ii  iitalian [ispell-dictionary]   1:2.3-3
ii  ispell 3.3.02-6
ii  libc6  2.13-38

spell recommends no packages.

spell suggests no packages.

-- no debconf information
--- spell.c.orig	2013-06-21 11:41:44.0 +0200
+++ spell.c	2013-06-21 11:46:27.0 +0200
@@ -613,7 +613,7 @@
   }
   file = xstrdup (-);
 
-  if (argc == 1)
+  if (argc = optind)
 read_file (the_pipe, stdin, -);
 
   while (arg_index  argc)

Bug#702605: icedove does not start if ~/.icedove is empty.

[g1]

Package: icedove
Version: 3.0.11-1+squeeze15
Severity: important


On my system, the first time icedove is started with an empty or
non-existent $HOME/.icedove directory, it crashes with the message

/usr/lib/icedove/icedove-bin: symbol lookup error: 
/usr/lib/icedove/components/libmailcomps.so: undefined symbol: 
NS_CStringContainerInit2

I guess the problem is caused by the fact that
1. icedove-bin is linked against libxpcom_core.so but not against
   libxpcom.so (as per objdump output)
2. for some reason, the first time icedove is started it dlopen()s
   libmailcomps.so before libxpcom.so.

A quick and dirty workaround consists in setting the environment variable
LD_BIND_NOW=1 before launching the executable (see the following patch).
Of course it would be much better to change the build script in order
to add libxpcom.so to the libraries.

Best regards,
g1

PS: I see that there are several (merged) bug reports that are
variations on this theme, with different undefined symbols.  Maybe the
trick works for them too.

 cut here
--- /usr/bin/icedove.old2013-03-08 22:21:58.0 +0100
+++ /usr/bin/icedove2013-03-08 22:24:23.0 +0100
@@ -109,6 +109,10 @@
 echo *INFO* No $HOME/.$pfname detected. Moving $HOME/.mozilla-thunderbird 
into this place
 mv $HOME/.mozilla-thunderbird $HOME/.$pfname
   fi
+  if [ ! -d $HOME/.$pfname ] || [ ! -f $HOME/.$pfname/profiles.ini ]; then
+LD_BIND_NOW=1
+export LD_BIND_NOW
+  fi
 fi
 
 script_args=
 cut here

-- System Information:
Debian Release: 6.0.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (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 icedove depends on:
ii  debianutils   3.4Miscellaneous utilities specific t
pi  fontconfig2.8.0-2.1  generic font configuration library
pi  libasound21.0.23-2.1 shared library for ALSA applicatio
pi  libatk1.0-0   1.30.0-1   The ATK accessibility toolkit
pi  libc6 2.11.3-4   Embedded GNU C Library: Shared lib
ii  libcairo2 1.8.10-6   The Cairo 2D vector graphics libra
ii  libdbus-1-3   1.2.24-4+squeeze2  simple interprocess messaging syst
pi  libfontconfig12.8.0-2.1  generic font configuration library
pi  libfreetype6  2.4.2-2.1+squeeze4 FreeType 2 font engine, shared lib
pi  libgcc1   1:4.4.5-8  GCC support library
pi  libglib2.0-0  2.24.2-1   The GLib library of C routines
pi  libgtk2.0-0   2.20.1-2   The GTK+ graphical user interface 
pi  libjpeg62 6b1-1  The Independent JPEG Group's JPEG 
ii  libnspr4-0d   4.8.6-1NetScape Portable Runtime Library
ii  libnss3-1d3.12.8-1+squeeze6  Network Security Service libraries
pi  libpango1.0-0 1.28.3-1+squeeze2  Layout and rendering of internatio
pi  libpng12-01.2.44-1+squeeze4  PNG library - runtime
ii  libsqlite3-0  3.7.3-1SQLite 3 shared library
pi  libstartup-notificati 0.10-1 library for program launch feedbac
pi  libstdc++64.4.5-8The GNU Standard C++ Library v3
pi  libx11-6  2:1.3.3-4  X11 client-side library
pi  libxrender1   1:0.9.6-1  X Rendering Extension client libra
pi  libxt61:1.0.7-1  X11 toolkit intrinsics library
pi  psmisc22.11-1utilities that use the proc file s
pi  zlib1g1:1.2.3.4.dfsg-3   compression library - runtime

Versions of packages icedove recommends:
pi  myspell-en-us [myspell-dictio 1:3.2.1-2  English_american dictionary for my

Versions of packages icedove suggests:
ii  libdbus-glib-1-20.88-2.1+squeeze1simple interprocess messaging syst
pi  libgconf2-4 2.28.1-6 GNOME configuration database syste
pn  libgnome2-0 none   (no description available)
pn  libgnomevfs2-0  none   (no description available)
pi  libgssapi-krb5-21.8.3+dfsg-4squeeze6 MIT Kerberos runtime libraries - k
pi  ttf-lyx 1.6.7-1  TrueType versions of some TeX font

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#701083: nvi: 27support_C_locale.dpatch broke command history. please revert

[g1]

Package: nvi
Version: 1.81.6-8.1
Severity: normal


When nvi is built with debian patch 27support_C_locale.dpatch included, the
command history doesn't work: 
:set cedit=^P
:%s/a/a
:^P
shows 
:^@^@^@s^@^@^@e^@^@^@t^@^@^@^@^@^@c^@^@^@e^@^@^@d^@^@^@i^@^@^@t^@^@^@=^@^@^@^P^@^@^@
:^@^@^@%^@^@^@s^@^@^@/^@^@^@a^@^@^@/^@^@^@a^@^@^@

instead of 
:set cedit=^P
:%s/a/a

The patch reads 
## 27support_C_locale.dpatch by  he...@pool.math.tu-berlin.de
##
## DP: Allow users to edit 8-bit files even under LC_CTYPE=C.

Don't know exactly what its purpose was (I believe there are other ways to
edit 8-bit characters in nvi, in the C locale), but it's harmful.  Please
remove it.

-- System Information:
Debian Release: 6.0.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages nvi depends on:
ii  libc6 2.11.3-4   Embedded GNU C Library: Shared lib
ii  libdb4.7  4.7.25-9   Berkeley v4.7 Database Libraries [
ii  libncursesw5  5.7+20100313-5 shared libraries for terminal hand

Versions of packages nvi recommends:
ii  nvi-doc   1.81.6-8.1 4.4BSD re-implementation of vi - d

nvi suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#695143: mercurial removes directory when removing the last contained file.

[g1]

Package: mercurial
Version: 1.6.4-1
Severity: normal


If I hg remove the last file in a directory, mercurial removes
the directory on commit (see below). 

Perhaps it's an upstream bug.

Perhaps it's a feature documented in the Definitive Guide, but I
won't buy the book just to check this, and the online version at
http://hgbook.red-bean.com/read/ is barely usable.

Script started on Tue Dec  4 16:21:35 2012
| $ hg init
| $ mkdir d
| $ echo a  d/a
| $ hg add d/a
| $ hg commit -m file_created 
| $ ls -s d
| total 4
| 4 a
| $ hg manifest -v
| 644   d/a
| $ hg rm d/a
| $ hg commit -m file_removed
| $ ls -s d
| ls: cannot access d: No such file or directory
Script done on Tue Dec  4 16:23:16 2012


-- System Information:
Debian Release: 6.0.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages mercurial depends on:
pi  libc6   2.11.3-4 Embedded GNU C Library: Shared lib
pi  mercurial-common1.6.4-1  scalable distributed version contr
pi  python  2.6.6-3+squeeze7 interactive high-level object-orie
pi  python-support  1.0.10   automated rebuilding support for P
pi  ucf 3.0025+nmu1  Update Configuration File: preserv

mercurial recommends no packages.

Versions of packages mercurial suggests:
pi  emacs23.2+1-7The GNU Emacs editor (metapackage)
pn  kdiff3 | tkd none  (no description available)
pn  qct  none  (no description available)
pi  tk8.5 [wish] 8.5.8-1 Tk toolkit for Tcl and X11, v8.5 -
pi  vim  2:7.2.445+hg~cb94c42c0e1a-1 Vi IMproved - enhanced vi editor

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org