Bug#840800: New upstream version 2.10.1

[Anders Kaseorg]

Package: git
Version: 1:2.9.3-1
Severity: wishlist
Tags: patch

I prepared packages for git 2.10.0 and 2.10.1, but the other maintainers 
have not responded with any feedback.  However, at least two other DDs 
indicated willingness to sponsor an upload for me, so I will take them up 
on that, with the suggestion of using DELAYED/7 to make sure there is a 
final opportunity for feedback.

git://andersk.mit.edu/git.git debian-sid

http://web.mit.edu/andersk/Public/debian/git_2.10.1-1.dsc
http://web.mit.edu/andersk/Public/debian/git_2.10.1.orig.tar.xz
http://web.mit.edu/andersk/Public/debian/git_2.10.1-1.debian.tar.xz

git (1:2.10.1-1) unstable; urgency=medium

  * New upstream release (see RelNotes/2.10.0.txt, RelNotes/2.10.1.txt).
  * debian/rules: Fix clean target to remove GIT-VERSION-FILE and
contrib/subtree build products.  (Closes: #834870)
  * Fix a missing reference in /usr/share/doc-base/everyday-git.
(Closes: #836516)
  * Migrate patches to 3.0 (quilt) format.  (Closes: #834566)
  * Migrate packaging to Debhelper.  (Closes: #834886)
  * Replace perl-modules dependency with perl.

 -- Anders Kaseorg   Mon, 03 Oct 2016 23:31:28 -0400

Bug#791944: My workaround

[Theppitak Karoonboonyanan]

Control: reassign -1 udev 231-9
Control: tag -1 + patch

On Mon, Oct 10, 2016 at 10:03 AM, Theppitak Karoonboonyanan
 wrote:

> With this patch to /etc/init.d/udev, my machine (using sysvinit)
> shuts down successfully again.
>
> Is the fix reasonable for udev?

Reassigning the bug to udev to hear its maintainer's opinion.

Regards,
-- 
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/

Bug#840791: ITP: ros-robot-state-publisher -- publish the state of a robot to tf

[Johannes Schauer]

Package: wnpp
Severity: wishlist
Owner: Johannes Schauer 

We (Robotics section of Debian Science team) are packaging ROS (Robot OS:
http://www.ros.org/) for Debian. ROS uses   many packages already in Debian,
but also has a set of   core/toolchain/build-system packages which are not yet
uploaded. This package is part of that ROS system.

Most of the packaging work is already done, and available at
http://anonscm.debian.org/cgit/debian-science/packages/ros/

* Package name: ros-robot-state-publisher
  Version : 1.13.2
* URL : http://www.ros.org/wiki/robot_state_publisher
* License : BSD-3-clause
  Programming Lang: C++
  Description : publish the state of a robot to tf

This package is part of Robot OS (ROS). This package allows you to publish the
state of a robot to tf. Once the state gets published, it is available to all
components in the system that also use tf. The package takes the joint angles
of the robot as input and publishes the 3D poses of the robot links, using a
kinematic tree model of the robot. The package can both be used as a library
and as a ROS node.

This package is required to run the Google Cartographer ROS nodes:

https://google-cartographer-ros.readthedocs.io/en/latest/

Bug#840382: [Pkg-samba-maint] Bug#840382: samba (2:4.4.6+dfsg-2) still crashes with libtevent0-0.31

[J Mo]

Confirmed fixed as of 2:4.4.6+dfsg-2. If there is any release after 
which, I have not teted.




On 10/14/2016 12:08 PM, Mathieu Parent wrote:

To the recipients:

Do you still have the problem when using latest packages from sid?

I cant' reproduce the problem anymore.

Thanks

Mathieu Parent

Bug#690695: no debian version in maven-repo

[Thorsten Glaser]

On Sat, 15 Oct 2016, Emmanuel Bourg wrote:

> Hum old bug, it should have been closed since we use the 0.x version for
> this library now.

Well closure-compiler doesn’t, it depends on the debian version,
and so do all things that depend on it.

> Le 15/10/2016 à 00:29, Thorsten Glaser a écrit :
> 
> > Shouldn’t *every* artefact have a debian version, anyway?
> 
> Every artifact (except the Maven plugins) should have a generic version
> that doesn't change with every update. The recommended version is
> 'debian' because it's the default and doesn't require any extra

OK.

> substitution rule, but sometimes we use a '.x' version when two
> incompatible versions share the same groupId/artifactId (junit 3 and 4
> is a good example).

AFAICT, this doesn’t apply to jsr305?

> > Anyway, patch attached. I applied to join pkg-java on Alioth; if
> > that’s granted I’ll commit and team-upload it, otherwise I might
> > consider an NMU unless you prefer to handle this.
> 
> I added you to the group, welcome :) The patch isn't strictly

OK, thanks.

> necessary, you could add a substitution rule in the minify-maven-plugin
> package (in debian/maven.rules) such as:

No, because it chokes before mh_make is even finished, and I
cannot change debian/maven.rules and restart mh_make because
it starts from the beginning.

> A 'debian' version wouldn't hurt though, I added a --relocate option to
> maven-repo-helper recently to ease the migration from '.x' to
> 'debian' version or other groupId/artifactId changes.

OK, nice.

Merci,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#839701: #839701: native GTK3 print dialog crashes

[Rene Engelhard]

On Fri, Oct 14, 2016 at 10:36:28AM +0800, Drew Parsons wrote:
> Should be fixed in 5.2.4.

Yeah, thanks. bts-link already told me yesterday :) and it's tagged pending
already (for 5.3.0 alpha1 and 5.2.4 rc1).

Regards,

Rene

Bug#840714: bind9 FTCBFS: python3 dependency, missing --host flags, bad configure checks, etc

[Helmut Grohne]

Source: bind9
Version: 1:9.10.3.dfsg.P4-10.1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

bind9 fails to cross build from source for lots of different reasons. It
starts out with trying to execute the host architecture python3 (which
is not installable as its postinst fails for too foreign architectures).
Then there are lots of fiddly things that go wrong in ./configure and
finally gost wasn't busted consistently leading to conflicting
declarations. Please consider applying the attached patch or taking
parts of it and requesting more information on why the rest is
necessary. You can test cross compiling bind9 in unstable with the
following sbuild invocation:

export ac_cv_file__dev_random=yes
sbuild -d sid --host=$DEB_HOST_ARCH --add-depends="libc-dev, libstdc++-dev" 
something.dsc

The environment variable is needed (with the patch) for linux, kfreebsd
and hurd and needs to be allowed in sbuild's environment_filter. It
should transition to whatever replaces dpkg-cross. The --add-depends is
necessary to work around #815172.

Helmut
diff --minimal -Nru bind9-9.10.3.dfsg.P4/debian/changelog 
bind9-9.10.3.dfsg.P4/debian/changelog
--- bind9-9.10.3.dfsg.P4/debian/changelog   2016-07-02 14:34:12.0 
+0200
+++ bind9-9.10.3.dfsg.P4/debian/changelog   2016-10-14 06:59:35.0 
+0200
@@ -1,3 +1,16 @@
+bind9 (1:9.10.3.dfsg.P4-10.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Annotate python3 dependency with :any
++ Let dh_auto_configure pass cross flags such as --host
++ 80_cross.diff: Enable cross compiling without --random-dev
++ Tell ./configure about openssl's features
++ export BUILD_CC
++ Consistently bust gost
+
+ -- Helmut Grohne   Fri, 14 Oct 2016 06:59:28 +0200
+
 bind9 (1:9.10.3.dfsg.P4-10.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru bind9-9.10.3.dfsg.P4/debian/control 
bind9-9.10.3.dfsg.P4/debian/control
--- bind9-9.10.3.dfsg.P4/debian/control 2016-05-04 01:40:36.0 +0200
+++ bind9-9.10.3.dfsg.P4/debian/control 2016-10-14 06:59:26.0 +0200
@@ -14,7 +14,7 @@
   libcap2-dev [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386],
   libgeoip-dev (>= 1.4.6.dfsg-5),
   dpkg-dev (>= 1.16.1~),
-  python3,
+  python3:any,
   dh-systemd,
   autotools-dev,
   dh-autoreconf
diff --minimal -Nru bind9-9.10.3.dfsg.P4/debian/patches/80_cross.diff 
bind9-9.10.3.dfsg.P4/debian/patches/80_cross.diff
--- bind9-9.10.3.dfsg.P4/debian/patches/80_cross.diff   1970-01-01 
01:00:00.0 +0100
+++ bind9-9.10.3.dfsg.P4/debian/patches/80_cross.diff   2016-10-14 
07:20:49.0 +0200
@@ -0,0 +1,24 @@
+From: Helmut Grohne 
+Subject: improve configure's cross build support
+
+configure explicitly fails cross compilation when not passing --with-randomdev
+even though it could just continue. In the non-cross case, it uses
+AC_CHECK_FILE, which can be preseeded with a config cache. There is no reason
+to fail here.
+
+Index: bind9-9.10.3.dfsg.P4/configure.in
+===
+--- bind9-9.10.3.dfsg.P4.orig/configure.in
 bind9-9.10.3.dfsg.P4/configure.in
+@@ -1009,11 +1009,6 @@
+ 
+ case "$use_randomdev" in
+   unspec)
+-  case "$cross_compiling" in
+-  yes)
+-  AC_MSG_RESULT(unspecified)
+-  AC_MSG_ERROR([ need --with-randomdev=PATH or 
--with-randomdev=no])
+-  esac
+   case "$host" in
+   *-openbsd*)
+   devrandom=/dev/arandom
diff --minimal -Nru bind9-9.10.3.dfsg.P4/debian/patches/series 
bind9-9.10.3.dfsg.P4/debian/patches/series
--- bind9-9.10.3.dfsg.P4/debian/patches/series  2016-05-04 01:40:36.0 
+0200
+++ bind9-9.10.3.dfsg.P4/debian/patches/series  2016-10-14 07:16:46.0 
+0200
@@ -10,3 +10,4 @@
 34_prepare_native_pkcs11.diff
 70_precise_time.diff
 75_ctxstart_no_sighandling.diff
+80_cross.diff
diff --minimal -Nru bind9-9.10.3.dfsg.P4/debian/rules 
bind9-9.10.3.dfsg.P4/debian/rules
--- bind9-9.10.3.dfsg.P4/debian/rules   2016-05-04 01:40:36.0 +0200
+++ bind9-9.10.3.dfsg.P4/debian/rules   2016-10-14 07:49:37.0 +0200
@@ -27,6 +27,10 @@
 ifeq ($(DEB_HOST_ARCH_OS),kfreebsd)
 EXTRA_FEATURES=--disable-linux-caps --disable-threads
 endif
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+EXTRA_FEATURES += --with-ecdsa=yes --with-gost=yes
+export BUILD_CC ?= cc
+endif
 
 stamps/prepare:
dh_testdir
@@ -40,7 +44,7 @@
cp -r lib/dns lib/dns-pkcs11
patch -p1 < debian/patches/extra-add_native_pkcs11.diff
# disable GOST, can't use openssl with native pkcs11 anyway
-   sed -i 's/HAVE_OPENSSL_GOST/GOSTBUSTERS/' lib/dns-pkcs11/*.[ch]
+   sed -i 's/HAVE_OPENSSL_GOST/GOSTBUSTERS/' lib/dns-pkcs11/*.[ch] 
lib/dns/dst_gost.h
dh_autotools-dev_updateconfig
dh_autoreconf
@mkdir -p stamps
@@ 

Bug#840715: ispell FTCBFS: build system overrides maintainer supplied CC

[Helmut Grohne]

Source: ispell
Version: 3.4.00-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

ispell fails to cross build from source, because the build system
overrides the maintainer supplied cross compiler with the build
architecture compiler. Please consider applying the attached patch.

Helmut
diff --minimal -Nru ispell-3.4.00/debian/changelog 
ispell-3.4.00/debian/changelog
--- ispell-3.4.00/debian/changelog  2016-03-04 08:34:39.0 +0100
+++ ispell-3.4.00/debian/changelog  2016-10-14 08:11:38.0 +0200
@@ -1,3 +1,10 @@
+ispell (3.4.00-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: 0037-CC-from-environment.patch (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 14 Oct 2016 08:08:00 +0200
+
 ispell (3.4.00-5) unstable; urgency=medium
 
   * Add 0035-Force-text-grep-in-munchlist.patch to pass the `-a' flag to grep
diff --minimal -Nru ispell-3.4.00/debian/patches/0037-CC-from-environment.patch 
ispell-3.4.00/debian/patches/0037-CC-from-environment.patch
--- ispell-3.4.00/debian/patches/0037-CC-from-environment.patch 1970-01-01 
01:00:00.0 +0100
+++ ispell-3.4.00/debian/patches/0037-CC-from-environment.patch 2016-10-14 
08:11:24.0 +0200
@@ -0,0 +1,24 @@
+From: Helmut Grohne 
+Subject: Use CC from environment
+
+Index: ispell-3.4.00/Makefile
+===
+--- ispell-3.4.00.orig/Makefile
 ispell-3.4.00/Makefile
+@@ -536,7 +536,7 @@
+ 
+ config.sh:  config.X defhash.h local.h Makefile
+   set $(SHELLDEBUG); \
+-  for var in BAKEXT BINDIR CC COUNTSUFFIX DEFDICT DEFHASH \
++  for var in BAKEXT BINDIR COUNTSUFFIX DEFDICT DEFHASH \
+ DEFLANG EXEEXT HASHSUFFIX INSTALL \
+ LANGUAGES LIBDIR LIBES LINK LINT LINTFLAGS LOOK_XREF \
+ MAKE_SORTTMP MAN1DIR MAN1EXT MAN45DIR MAN45EXT MAN45SECT MASTERHASH \
+@@ -548,6 +548,7 @@
+ | sed -e 's/"[^"]*$$/'"'/" -e "s/=/='/" -e 's/\\"/"/g' \
+ | sed -n -e '$$p'; \
+ done > config.sh; \
++  echo "CC='$(CC)'" >> config.sh; \
+   echo "CFLAGS='$(CFLAGS)'" >> config.sh; \
+   echo 'case "$$MAKE_SORTTMP" in "") \
+ SORTTMP="-e /!!SORTTMP!!/s/=.*$$/=/";; *) SORTTMP=;; esac' \
diff --minimal -Nru ispell-3.4.00/debian/patches/series 
ispell-3.4.00/debian/patches/series
--- ispell-3.4.00/debian/patches/series 2016-03-04 08:34:39.0 +0100
+++ ispell-3.4.00/debian/patches/series 2016-10-14 08:10:19.0 +0200
@@ -25,3 +25,4 @@
 0034-Fix-munchlist-failure.patch
 0035-Force-text-grep-in-munchlist.patch
 0036-Reproducible-hashes.patch
+0037-CC-from-environment.patch

Bug#840717: make libquvi-scripts-0.9.pc discoverable during cross building

[Helmut Grohne]

Package: libquvi-scripts-0.9
Version: 0.9.20131130-1.1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:libquvi

libquvi fails to cross build from source, because it cannot find
libquvi-scripts-0.9.pc. During cross compilation, pkg-config does not
consider /usr/lib/pkgconfig. So move the .pc file to
/usr/share/pkgconfig as it really is architecture independent. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru libquvi-scripts-0.9.20131130/debian/changelog 
libquvi-scripts-0.9.20131130/debian/changelog
--- libquvi-scripts-0.9.20131130/debian/changelog   2016-02-18 
16:56:33.0 +0100
+++ libquvi-scripts-0.9.20131130/debian/changelog   2016-10-14 
08:19:20.0 +0200
@@ -1,3 +1,10 @@
+libquvi-scripts (0.9.20131130-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Make pkg-config file discoverable to cross compilation (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 14 Oct 2016 08:18:50 +0200
+
 libquvi-scripts (0.9.20131130-1.1) unstable; urgency=medium
 
   * Non-maintainer upload with maintainer permission.
diff --minimal -Nru libquvi-scripts-0.9.20131130/debian/patches/pkgconfig.diff 
libquvi-scripts-0.9.20131130/debian/patches/pkgconfig.diff
--- libquvi-scripts-0.9.20131130/debian/patches/pkgconfig.diff  1970-01-01 
01:00:00.0 +0100
+++ libquvi-scripts-0.9.20131130/debian/patches/pkgconfig.diff  2016-10-14 
08:21:03.0 +0200
@@ -0,0 +1,17 @@
+From: Helmut Grohne 
+Subject: move pkg-config file to /usr/share/pkgconfig
+
+During cross compilation /usr/lib/pkgconfig is not considered.
+Index: libquvi-scripts-0.9.20131130/Makefile.am
+===
+--- libquvi-scripts-0.9.20131130.orig/Makefile.am
 libquvi-scripts-0.9.20131130/Makefile.am
+@@ -6,7 +6,7 @@
+ SUBDIRS+= doc
+ endif
+ 
+-pkgconfigdir= $(libdir)/pkgconfig
++pkgconfigdir= $(datadir)/pkgconfig
+ pkgconfig_DATA=   libquvi-scripts-0.9.pc
+ 
+ .PHONY: doc test stamp_scripts ChangeLog VERSION
diff --minimal -Nru libquvi-scripts-0.9.20131130/debian/patches/series 
libquvi-scripts-0.9.20131130/debian/patches/series
--- libquvi-scripts-0.9.20131130/debian/patches/series  1970-01-01 
01:00:00.0 +0100
+++ libquvi-scripts-0.9.20131130/debian/patches/series  2016-10-14 
08:17:38.0 +0200
@@ -0,0 +1 @@
+pkgconfig.diff

Bug#840716: RFS: dh-sysuser/0.2

[Dmitry Bogatov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "dh-sysuser"

* Package name: dh-sysuser
  Version : 0.2
  Upstream Author : Dmitry Bogatov 
* Url : 
https://anonscm.debian.org/cgit/users/kaction-guest/dh-sysuser.git
* Licenses: GPL-3+
  Section : admin

It builds those binary packages:

  * dh-sysuser

To access futher information about this package, visit the following URL:

http://mentors.debian.net/package/dh-sysuser

Alternatively, one can download the package with dget using this command:
dget -x 
http://mentors.debian.net/debian/pool/main/d/dh-sysuser/dh-sysuser_0.2.dsc

Alternatively, you can access package debian/ directory via git from URL:
https://anonscm.debian.org/cgit/users/kaction-guest/dh-sysuser.git

More information about dh-sysuser can be obtained from
https://anonscm.debian.org/cgit/users/kaction-guest/dh-sysuser.git

Changes since last upload:

  * Remove empty 'debian/docs' file
  * Fix typo in 'debian/copyright'
  * Add dependency on perl, which is required for
`deluser --remove-home' (Closes: #840469)
  * Delete user with --force flag, allowing removing users,
which have running processed.

Regards,
  Dmitry Bogatov

Bug#840097: sysprof ppc binaries removed

[Andreas Henriksson]

Control: severity -1 important

Hello!

The old powerpc binaries has now been removed from unstable.
Porter assistance with identifying if this is a real issue or
a testcase problem would be welcome.

Regards,
Andreas Henriksson

Bug#840669: [pkg-gnupg-maint] Bug#840669: Need way to avoid agent, or reliable way to kill agent

[Daniel Kahn Gillmor]

Hi Ian--

Thanks for this note, there's a lot in here.

On Thu 2016-10-13 12:47:14 -0400, Ian Jackson wrote:

> The dgit test suite involves setting up a dummy home directory with
> some dummy keys and making and verifying some dummy signatures.  There
> is one of these per test.
>
> When the test suite is run under adt-run --- adt-virt-schroot, the
> agents are automatically started but nothing kills them.
>
> This results in problems: schroot cannot unmount the chroot and cannot
> clean up properly.
>
> I haven't checked but I am pretty sure that if I run the test suite
> natively with gnupg2, it will leak enormous numbers of gpg agent
> processes.

Right, i can see why this might be a problem :)

Does your test suite delete its test homedirs after it is finished?  If
not, would you be willing to include removal of the test homedirs as
part of the tests, or as a final post-test cleanup phase?

I ask because upstream intends for gpg-agent and dirmngr to
auto-terminate when their sockets are removed, and those patches have
been backported into 2.1.15-4 (see
debian/patches/0015-agent-Terminate-on-deletion-of-the-socket-file-Linux.patch
and
debian/patches/0016-dirmngr-Terminate-on-deletion-of-the-socket-file-Lin.patch
).

However, hmm, this doesn't seem to work properly; i just tested with:

export GNUPGHOME=$(mktemp -d)
gpg-connect-agent 'getinfo pid' /bye
rm -rf "$GNUPGHOME"
sleep 1
pidof gpg-agent

I've just reported this problem upstream:

https://bugs.gnupg.org/gnupg/issue2756

One thing worth observing is that if the agent's socket is deleted, it
will eventually terminate itself after a minute or two anyway.  This
will happen even without inotify (but obviously the inotify trigger
should really work to automate cleanup on platforms that support inotify)

> IMO: there should be a way to get gnupg2 to do everything synchronously;
> that is, if it needs an agent, to spawn one which does not listen on a
> socket, but rather just has an existing connection to its parent and
> which will die when the parent does.

This could potentially complicate the agent -- at the moment, i think
the agent expects to be the only process dealing with
$GNUPGHOME/private-keys-v1.d/, and that means that two gpg processes
using this approach could potentially trample on each other.

> Also gpg agent processes should automatically exit if their HOME
> ceases to exist (or if they cease to be the process listening on their
> socket for some other reason)

yes, this is upstream's intended behavior, and it happens (after some
delay), but it's not instantaneous.  Getting the inotify stuff fixed
will make it much closer to instantaneous.

> This problem, and how to deal with it, should be better documented.
> (I looked in gpg-agent(1).  I searched for "agent" and didn't find
> any information that looked helpful; I did find information that
> suggests that `drmngr' may be troublesome too.)  NB gpg-agent(1)
> refers to gpg2(1) and gpgsm(1) which do not exist.

The reference to gpg2(1) is an error, and i've sent a patch upstream to
gnupg-devel.  gpgsm(1) is correct, but you probably don't have the gpgsm
package installed.

> In particular, `gpgconf --kill gpg-agent' should be documented.

Where would you like it documented?  it's in gpgconf(1):

   --kill [component]
  Kill the given component.  Components which support killing  are
  gpg-agent  and scdaemon.  Components which don't support reload‐
  ing are ignored.  Note that as of now reload and kill  have  the
  same effect for scdaemon.

If you can suggest what the text should say and where a reasonable
person might look for it, i'll happily write a patch and encourage its
adoption by upstream.

> NB that I don't think that expecting the dgit test suite to run
> `gpgconf --kill-agent' after every test is reasonable.  Currently
> there is _no_ code for running a specific positive command after
> running a test.  Given the nature of test suites and indeed the nature
> of error handling on posix systems, it's not clear that such a thing
> would be sensible.

If you're not willing to do *anything* (including deletion of the
temporary $GNUPGHOME or some sort of session termination event) upon
completing the test suite, but before tearing down your builder
instance, then i don't know if there's a solution.  But at the moment i
suspect getting the inotify stuff fixed is the sanest and simplest
approach on the platform you and i probably care most about :)

 --dkg


signature.asc
Description: PGP signature

Bug#840718: ITP: node-test -- (Un)CommonJS test runner

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-test
  Version : 0.6.0
  Upstream Author : Irakli Gozalishvili 
(http://jeditoolkit.com)
* URL : https://github.com/Gozala/test-commonjs/
* License : Expat
  Programming Lang: JavaScript
  Description : (Un)CommonJS test runner

Bug#839542: typo: Send/Que command to all matching filters

[Mathieu Malaterre]

On Thu, Oct 13, 2016 at 11:29 PM, Andreas Cadhalpun
 wrote:
> Control: forwarded -1 
> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201062.html
>
> Hi Mathieu,
>
> On 01.10.2016 21:14, Mathieu Malaterre wrote:
>> I do not believe this is proper english. Patch attached.
>
> Thanks for reporting this. I've forwarded the fix upstream together
> with a couple of other spelling fixes. I hope you don't mind that.

This is the only way to have it fixed in the long term, so definitely:
thanks for doing it ! :)

Bug#840575: [buildd-tools-devel] Bug#840575: sbuild bpo: uses non-available option gnupg --pinentry-mode

[Daniel Kahn Gillmor]

On Fri 2016-10-14 01:36:56 -0400, Johannes Schauer wrote:
>  - it is a feature of sbuild since version 0.67.0 (I corrected the wiki page
>accordingly) to *not* require signing of the internal dummy repository (and
>thus you don't need to run sbuild-update --keygen anymore) and that

awesome, thanks for this improvement (and thanks for all your work on
sbuild)!

Regards,

--dkg

Bug#840719: apt command should have clean parameter shortcut to run apt-get clean

[NetVicious]

Package: apt
Version: 1.0.9.8.3
Severity: wishlist

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate
***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (/etc/apt/sources.list present, but not submitted) --


-- 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=es_ES@euro, LC_CTYPE=es_ES@euro (charmap=ISO-8859-15)
(ignored: LC_ALL set to es_ES@euro)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages apt depends on:
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.18-7+deb8u3
ii  libapt-pkg4.12  1.0.9.8.3
ii  libc6   2.19-18+deb8u6
ii  libgcc1 1:4.9.2-10
ii  libstdc++6  4.9.2-10

apt recommends no packages.

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.6.11-1+b1
ii  dpkg-dev1.17.27
ii  python-apt  0.9.3.12

-- no debconf information

-- 
.. //\/ e t . \/ i c i o u s ..

Bug#840720: installation-report: stretch/testing setup inside qemu/kvm with virt-manager

[Andreas Glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: installation-reports
Version: 2.62
Severity: wishlist

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


- -- Package-specific info:

Boot method: iso-img
Image version:
http://gensho.acc.umu.se/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
Date: 2016-10-13

Machine: kvm vm, see attachment
Partitions:
Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs500520   0500520   0% /dev
tmpfs  tmpfs   1020283420 98608   4% /run
/dev/vda1  xfs   11523072 3138444   8384628  28% /
tmpfs  tmpfs   510132  68510064   1% /dev/shm
tmpfs  tmpfs 5120   4  5116   1% /run/lock
tmpfs  tmpfs   510132   0510132   0% /sys/fs/cgroup
tmpfs  tmpfs   102024  12102012   1% /run/user/1000
tmpfs  tmpfs   102024   4102020   1% /run/user/109



Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [o]
Detect network card:[o]
Configure network:  [o]
Detect CD:  [o]
Load installer modules: [o]
Clock/timezone setup:   [o]
User/password setup:[o]
Detect hard drives: [o]
Partition hard drives:  [o]
Install base system:[o]
Install tasks:  [o]
Install boot loader:[o]
Overall install:[o]

Comments/Problems:

This is actually not an installer-problem, but one with libvirt or virt-manager
respectively, there is fix necessary in order to be able to start up existing 
virtual
machines:
This is the problem:
> Error starting domain: Requested operation is not valid: network 'default' is 
> not active
> 
> Traceback (most recent call last):
>   File "/usr/share/virt-manager/virtManager/asyncjob.py", line 91, in 
> cb_wrapper
> callback(asyncjob, *args, **kwargs)
>   File "/usr/share/virt-manager/virtManager/asyncjob.py", line 127, in tmpcb
> callback(*args, **kwargs)
>   File "/usr/share/virt-manager/virtManager/domain.py", line 1355, in startup
> self._backend.create()
>   File "/usr/lib/python2.7/dist-packages/libvirt.py", line 999, in create
> if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
> libvirtError: Requested operation is not valid: network 'default' is not 
> active

This is the fix:

> root@dop58:/home/remosrv# cd /etc/libvirt/qemu/networks/autostart
> root@dop58:/etc/libvirt/qemu/networks/autostart# ln -s ../default.xml 
> default.xml
> root@dop58:/etc/libvirt/qemu/networks/autostart# ls -la
> total 4
> drwxr-xr-x 1 root root 22 Oct 10 13:48 .
> drwxr-xr-x 1 root root 40 Oct 10 13:45 ..
> lrwxrwxrwx 1 root root 14 Oct 10 13:48 default.xml -> ../default.xml
> root@dop58:/etc/libvirt/qemu/networks/autostart# cat default.xml 
> 
>   default
>   
>   
>   
> 
>   
> 
>   
> 
> 
> root@dop58:/etc/libvirt/qemu/networks/autostart# service libvirtd restart

I also disabled the bridge-netfilter, now I am able to log in to the host with 
SSH,
see: 

> $$ man sysctl.d

VM-configuration attached, also kernel-bootup messages [dmesg-output]

There is a message at bootup. saying that hardware-support for kvm is missing 
inside the
guest, so this would most probably require nested virtualisation, the other 
issue is,
that there is a 90 seconds grace-period at startup while systemd waits for
Network-Manager, which ist not really required inside a VM.

- -- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20161003-00:06"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux stretchtst 4.7.0-1-amd64 #1 SMP Debian 4.7.5-1 (2016-09-26) 
x86_64
GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 440FX - 
82441FX PMC
[Natoma] [8086:1237] (rev 02) lspci -knn:   Subsystem: Red Hat, Inc Device
[1af4:1100] lspci -knn: 00:01.0 ISA bridge [0601]: Intel Corporation 82371SB 
PIIX3 ISA
[Natoma/Triton II] [8086:7000] lspci -knn:  Subsystem: Red Hat, Inc Device
[1af4:1100] lspci -knn: 00:01.1 IDE interface [0101]: Intel Corporation 82371SB 
PIIX3 IDE
[Natoma/Triton 

Bug#840727: cmark: please provide libcmark0 and libcmark-dev packages

[Peter Eisentraut]

On 10/14/16 4:33 AM, Andrew Shadura wrote:
> Please provide libcmark-* packages, so that packages using
> CommonMark library can link against and depend on these
> packages.

Do you have an actual package in mind that needs this?

I have some doubts that upstream is following "proper" shared library
compatibility practices.  So I don't want to put out a shared library
package on a hunch.  A static library might be possible.

Bug#833741: Workaround

[Paul van der Vlis]

Hello,

There is no big problem for existing installations, but if you make a
new installation then flash does not work. This is what I do as root as
a workaround:

apt-get install pepperflashplugin-nonfree
cd /usr/lib/
mv pepperflashplugin-nonfree pepperflashplugin-nonfree-backup
mkdir pepperflashplugin-nonfree
cd pepperflashplugin-nonfree
wget -r -nd --no-parent
https://vandervlis.nl/files/pepperflashplugin-nonfree/
rm index.html*

After this flash will work, maybe you have to restart the browser.

Of cause you can also use your /usr/lib/pepperflashplugin-nonfree from
an older installation. That's what I did.

With regards,
Paul van der Vlis.

-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Bug#840672: RFS: libcork/0.15.0+ds-7~exp1 -- simple, easily embeddable, cross-platform C library

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo


>I am looking for a sponsor for my package "libcork".

>This is the first time I'm trying to raise a library transition.
>So if there's anything wrong, just let me know. Thank you!


bumping soname with the same upstream tarball and no changes

makes no real sense.
If you want to bump soname you need to have API/ABI changes in the packaging,
and then the need to do a transition.

G.

Bug#840669: [pkg-gnupg-maint] Bug#840669: Need way to avoid agent, or reliable way to kill agent

[Ian Jackson]

Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#840669: Need way to 
avoid agent, or reliable way to kill agent"):
> On Fri 2016-10-14 07:10:29 -0400, Ian Jackson wrote:
> > When run under adt-run with a filesystem snapshotting virt server,
> > there is to need (of course) to delete the temporary area, since it's
> > in a filesystem a snapshot which is going to be deleted.
> 
> i think you mean "no need" here, not "to need", right?

Yes.

> There are multiple ways that processes from a given test run could
> potentially linger with files open in that snapshotted filesystem.

Those leftover processes would be bugs.  They aren't always detected,
it's true, particularly in the less-formal ways of running the test
suite.

> gpg-agent happens to be one of them.  what do you propose to do about
> the others?

There are no others.

If others should start to occur then I would want the tests to fail so
that I could arrange for my code not to leak wreckage in the process
table.

So I actively _want_ to detect these leaks and fail on them.

> If dgit is willing to do this work, it should also be willing to just
> invoke "gpgconf --kill gpg-agent" when it's ready to terminate the
> agent, right?  Why craft all this new mechanism and guidance?

That might be possible, but:

1. dgit ought not to start an agent if there's one already running.
So dgit would have to grow code to do that.

2. The agent started by dgit should not be used willy-nilly by other
processes.  The user who types their passphrase to authorise a dgit
push ought not to find that the passphrase has been reused for a
different operation.  (And vice versa.)

3. dgit does in fact not currently have any gnupg2 knowledge at all.
It just runs `gpg' with some very simple command line arguments.
(Consider also `debsign' which could usefully use this feature and is
otherwise a very small program.)

4.  Applications (and users) which are naive (like dgit right now,
before I add any hypothetical key-lifetime-control code) should expect
that the lifetime of authorisation granted to a particular program (by
typing a passphrase at something like pinentry) is limited to that
program.

> >  * The result is that the scope of an auto-spawned agent is a single
> >GNUPG_AGENT_LIFETIME_FD (normally, a single gnupg2 gpg program).
> >Other concurrent calls to gpg will block.
> 
> yuck.  I really don't like the idea that all concurrent calls to gpg
> should block.

I think this is an inevitable consequence of the following facts:

 1. An agent process is the repository of authorisation granted via
pinentry.  (gnupg2 design decision; changed from gnupg1)

 2. In the absence of some kind of ambient desktoppish global pinentry
setup, authorisation granted via pinentry should be limited to the
particular command that the user ran or the particular gpg
invocation.

 2a. If you disagree about that as the default, at the very least,
such an restricted lifetime model should be available as a
configuration or runtime option.  (security property)

 3. Concurrent access to the private key database by different
agents is not safe.  (gnupg2 design decison; I think gnupg1 uses
locks)

If you want to support *concurrent* use of multiple different
authorisation contexts, with different lifetimes, then you need to
either make a single agent somehow able to keep the different security
contexts separate, or allow there to be multiple concurrent agents.

In the absence of those changes, which would be a major architectural
overhaul, blocking one gnupg because another one is blocked in
pinentry is fairly reasonable.  This would only happen in interactive
situations.

> This proposal represents a major change in how gpg-agent works right
> now.

My proposal represents the re-establishment of the semantics of
gnupg1.

And I think you overestimate the amount of code change involved.

> > This doesn't solve the problem when the test scripts are run ad-hoc.
> > It won't solve the problem for other programs which set HOME (or
> > GNUPGHOME) as part of test suites or whatever.
> 
> right, i agree that there is a general problem here, which is how to
> deal with test suites that involve manipulation of gpg secret key
> material.  It would be great for upstream to produce a clear set of
> instructions that say "if you're dealing with gpg secret key material in
> a test suite, here's what we recommend you do".

I don't think that is a reasonable approach, partly because gnupg may
be called by other programs, and partly because gnupg2 is not entitled
to decree particular misbehaviours (which I'm afraid I think the
current behaviour is) "as designed".

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#840669: Beware of leftover gpg-agent processes (was: Re: Changes for GnuPG in debian)

[Ian Jackson]

Ian Jackson writes ("Beware of leftover gpg-agent processes (was: Re: Changes 
for GnuPG in debian)"):
> Johannes Schauer writes ("Beware of leftover gpg-agent processes (was: Re: 
> Changes for GnuPG in debian)"):
> 
> > Quoting Daniel Kahn Gillmor (2016-08-04 18:29:03)
> > > One of the main differences is that all access to your secret key
> > > will be handled through gpg-agent, which should be automatically
> > > launched as needed.
> > 
> > it might be important to note that gpg launching this gpg-agent
> > process is not optional and that it will automatically be launched
> > and continue running in the background for many gpg operations.
> 
> This is rather alarming.  As a longtime gpg1 user I hadn't appreciated
> this.
> 
> Could we not have gpg2 not only automatically launch the agent, but
> also automatically terminate it.  This would provide the same UI and
> same persistence properties as gpg1.
> 
> I don't think a general change to a timeout-based persistence model is
> a good idea in itself; and of course there are the practical problems
> Johannes mentions.

This (and the change to gnupg2) has now broken dgit's DEP-8 test
suite, when run under schroot.  I'm discussing this in #840669 (CC'd).

I am trying to persaude Daniel that we should provide (at least
optionally) a mode where an autostarted agent (and the corresponding
authorisations, if the user types in a passphrase) have a lifetime
limited by that of the gpg process which started the agent.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#840777: ITP: hotdoc -- documentation tool using CommonMark

[Andrew Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrew Shadura 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: hotdoc
  Version : 0.8
  Upstream Author : Mathieu Duponchelle 
* URL : https://github.com/MathieuDuponchelle/hotdoc
* License : LGPL-2.1+
  Programming Lang: Python 2
  Description : documentation tool using CommonMark

HotDoc aims at being a highly modular API documentation tool / library
for C and C++ libraries (initially).
.
It is based on clang for the source code parsing, and CommonMark for
the formatting.
.
It was previously based on pandoc, and a pandoc backend will be
available again soon, but the dependency tree with a hard pandoc
dependency was just too deep.
.
It features:
.
 * An incremental build system, that only rebuilds the output depending
   on the changed resources.
 * A pretty comprehensive extension system, handmade and bound to be
   subjected to API breakage until the 1.0 version of hotdoc is
   released.
 * A built-in gobject-introspection extension, which will expose
   gobject-specific concepts (properties, signals, annotations ...).
 * Themeability (see this example Persisting of the documentation
   through sqlalchemy, with an API to access it. An example project
   that uses this API is the hotdoc server, which will soon be made
   public.
 Many more things!

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJYARmHAAoJEJ1bI/kYT6UUehsH/3F9cNso7lFvTkiPEqN/xRQB
dfeCK0GIqKXSw9DmoXF5HY+JIwzYlo4cFkE0WM4yPgU/HwOdsStpYfMhmeVpJmnH
mfr7SlY8CujZAugaYPLV178HP1qSc7Y2CZYypYtErbDgUowIG+utmGsI8ihrGfWs
uCsA3VeLGSODiof96RUjvlMoXc/+LN3bYM0MztLCdOfKejCc99vboWcIamXiW8zK
NVmF5zAAiEUoWjpiqjXftosPydO0CnyMb8/4fAn0mPJUAEQZmmy9a44vjo5zm2eq
2GgoklftHGB4FSNSoSGXN+WklpB1ak9VGYXXoWIgjHMp/6nAlXG+UNx2OZ7PW8s=
=4B5b
-END PGP SIGNATURE-

Bug#840755: libwebkit2gtk-4.0-37: fails to play any youtube videos using flash plugin

[Alberto Garcia]

On Fri, Oct 14, 2016 at 03:56:02PM +0200, Sergio Villar Senin wrote:

>* What led up to the situation?
> 
>Open any youtube.com video in the epiphany browser.
>The player was showing an error, something like: "There was an
>error. Try it later. Play ID: xxx"

But does YouTube even use Flash to play the videos? I'm able to play
YouTube videos with Epiphany and WebKitGTK+ 2.14.1-1 and I don't even
have Flash installed.

Any video in particular that is failing?

Berto

Bug#824741: keysyms associated with F1 and Shift-F8 are ignored in text input fields

[Graham Inggs]

Hi Vincent

On 19 May 2016 at 14:34, Vincent Lefevre  wrote:
> I reassign this bug to libxm4 since the bug probably occurs at the
> Motif level. I notice that libmotif-common provides bindings files
> (/usr/share/X11/bindings directory), where one can see settings for
> F1 and Shift-F8, but also F10 and Shift-F10. However:
>   * I don't have any problem with F10 and Shift-F10.
>   * No such bindings files are read when running xpdf, as shown
> by strace -f.

Did you see bindings/README from the source package [1] ?

These files are not read, but are examples which can be copied to
~/.motifbind and modified by the user.

Regards
Graham


[1] https://sources.debian.net/src/motif/2.3.4-11/bindings/README/

Bug#840087: libreoffice-draw: does not compress PDFs in the latest version

[Andreas Glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 12 Oct 2016 15:53:48 +0200
Rene Engelhard  wrote:

> Hi,
> 
> On Wed, Oct 12, 2016 at 03:10:47PM +0200, Andreas Glaeser wrote:
> > If I am getting things correctly, the backported version is identical with 
> > the one in
> > Stretch/testing, so the same bug would be there, it migrated there in fact 
> > from
> > unstable  
> 
> In this case, yes..
> 
> Other bugs can be only appearing on backports.
> 

This one does not, I have just checked that, in a KVM-VM, see there:

840...@bugs.debian.org

> And no, it is not identical. If it was there was no need for a backport. It's 
> a rebuild
> (with changed dependencies and any adaptions needed) to work in stable.
> (And it's from testing, not unstable.)
> 
> > and if nobody complains or otherwise nobody feels responsible to react to 
> > the report,
> > it will inevitably migrate to stable.  
> 
> Yes, the testing version. Not *-backports. And that only on the next release.
> -backports is not a staging ground for updates in "real" stable. It's 
> separate.
> 

Ah-ha !

> > > > there appeared a new version of the LibreOffice suite from Backports 
> > > > today.
> > > > LibreOffice-Draw fails to compress multipage-PDFs, it just makes a copy 
> > > > of the
> > > > original document, regardless of the quality- and other settings.
> > > > I use this function quite frequently, so I can tell, the problem 
> > > > appeared
> > > > _today_.
> > > 
> > > So between 5.1.5 and 5.2.2. Very helpful. Another reason why bug reporting
> > > should be done on sid, so one knows what happens when, not only when the
> > > thing is (supposedly) stable enough to get into backports.
> > >   
> > Sorry, I am not using unstable, I never have in fact, I think the version 
> > in testing
> > is usually new enough, except, there is currently a freeze-phase on the
> > testing-branch.  
> 
> No, there isn't a freeze yet in testing. That only starts in some time. If 
> there was,
> 5.2.2 would not have migrated there in the first place and thus there 
> wouldn't be a
> backport of 5.2.2 anyways.
> 

Yeah, anyway, the problem exists in Stretch, it has nothing to do with
stable-dependencies vs. testing-dependencies:

> user@stretchtst:~$ aptitude show libreoffice
> Package: libreoffice 
> Version: 1:5.2.2~rc2-2


> > > Anyway: When looking in LOs Bugzilla I see
> > > https://bugs.documentfoundation.org/show_bug.cgi?id=101563
> > > (do you use linked images?)
> > > and
> > > https://bugs.documentfoundation.org/show_bug.cgi?id=99303
> > > (which isn't very useful.)
> > > 
> > > based on theupstream reports I set the version accordingly to a existing
> > > version. (And tag it moreinfo.)
> > >   
> > Was this enough info or not??  
> 
> No, since you didn't answer any question here. E.g. the question in the cited
> part above.
> 

Now this should really satisfy your needs for INFO, I will tag the report 
'UPSTREAM' now.

Greetings

A.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlgBBRsACgkQ5+rBHyUt5wvunwCgoGKudo1ivSmMpmxsQ32ZOioS
VikAn0gWyvUVfWz6SffV9pRj5TMtFMnv
=g6xY
-END PGP SIGNATURE-

Bug#840776: libp4est-dev: No version available for OpenMPI 2

[Andreas Kloeckner]

Package: libp4est-dev
Version: 1.1-2
Severity: normal

Dear Maintainer,

Thank you for your efforts maintaining p4est in Debian. Is there any
chance that a rebuilt package could be created?

Thanks!
Andreas


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#840641: ITP: python-lecm -- letsencrypt certificates manager

[Sebastien Badia]

On Thu, Oct 13, 2016 at 05:11:32PM (+), Mattia Rizzolo wrote:
> On Thu, Oct 13, 2016 at 04:08:59PM +0200, Sebastien Badia wrote:
> > * Package name: python-lecm
> >   Version : 0.0.4
> >   Upstream Author : Yanis Guenane 
> > * URL : https://github.com/Spredzy/lecm
> > * License : Apache-2.0
> >   Programming Lang: Python
> >   Description : letsencrypt certificates manager
> > 
> >  Let's Encrypt Certificates Manager (lecm) is an utility that allows one to
> >  manage (generate and renew) Let's Encrypt SSL certificates.
> > 
> > I planned to maintain lecm in collab-maint.
> 
> you can also maintain the package in the letsencrypt team, which is
> collecting all software related to letsencrypt.
> 
> Within the team, I'm also very available for sponsoring, if you need it.

Hi Mattia!

Sure, good idea, I just requested to join the letsencrypt team on alioth.d.o
Thanks! And thanks for the sponsoring!

Seb


signature.asc
Description: PGP signature

Bug#828244: bacula: FTBFS with openssl 1.1.0

[Kurt Roeckx]

On Fri, Oct 14, 2016 at 10:56:34AM +0200, Carsten Leonhardt wrote:
> Hi Kurt,
> 
> > OpenSSL 1.1.0 is about to released.  During a rebuild of all packages using
> > OpenSSL this package fail to build.  A log of that build can be found at:
> > https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/bacula_7.4.0+dfsg-1_amd64-20160529-1407
> [...]
> > If you have problems making things work, feel free to contact us.
> 
> I've just got feedback from upstream:
> 
> > From what they write, it seems unlikely we will want to support the
> > newer version for some time. This is because of the comment that if
> > you do support the new version, old versions will not compile. This is
> > not an option for us.

The patch should make it support both old and new version of OpenSSL.

> > What distro is currently using OpenSSL 1.1?"
> 
> Is the plan still to have OpenSSL 1.1 in stretch? There were several
> concerns raised in the thread following your announcement in June.

Yes it is. I don't really know of any raised concerns.


Kurt

Bug#840774: Acknowledgement (silversearcher-ag: Man page lack of REGEX flavour description (and even do not say anything related).)

[Oleksandr Gavenko]

I filed upstream:

  https://github.com/ggreer/the_silver_searcher/issues/993

-- 
http://defun.work/

Bug#824741: keysyms associated with F1 and Shift-F8 are ignored in text input fields

[Vincent Lefevre]

Hi,

On 2016-10-14 18:14:55 +0200, Graham Inggs wrote:
> Hi Vincent
> 
> On 19 May 2016 at 14:34, Vincent Lefevre  wrote:
> > I reassign this bug to libxm4 since the bug probably occurs at the
> > Motif level. I notice that libmotif-common provides bindings files
> > (/usr/share/X11/bindings directory), where one can see settings for
> > F1 and Shift-F8, but also F10 and Shift-F10. However:
> >   * I don't have any problem with F10 and Shift-F10.
> >   * No such bindings files are read when running xpdf, as shown
> > by strace -f.
> 
> Did you see bindings/README from the source package [1] ?
> 
> These files are not read, but are examples which can be copied to
> ~/.motifbind and modified by the user.

But pethaps there's something similar in the default bindings.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#824741: keysyms associated with F1 and Shift-F8 are ignored in text input fields

[Graham Inggs]

On 14 October 2016 at 18:22, Vincent Lefevre  wrote:
> But pethaps there's something similar in the default bindings.

If there are, what do you want to happen here?

Are you able to unbind the keys you want with a custom ~/.motifbind file?

Bug#840268: apt-get update combined with dns problem is destroying filesystem.

[David Kalnischkies]

Control: tags -1 moreinfo unreproducible

Hi,

On Mon, Oct 10, 2016 at 08:12:09AM +0200, Sylvain Labbe wrote:
> When using apt-get update while there is a temporary or permanent dns
> resolution problem due to an invalid configuration into /etc/resolv.conf

Please provide the EXACT command you are running and the configuration
you are using. "reportbug" would have collected this sort of information
automatically (with your input of course). You can use this tool also to
reply to bugreports.

Otherwise, run:
apt-config dump
cat /etc/apt/sources.list /etc/apt/sources.list.d/*
cat /etc/apt/preferences /etc/apt/preferences.d/*

Also look out for any other tools/scripts hooking incorrectly into apt
– I have a feeling one of them might run "amok" – or some other very
non-standard configuration.


> it will result in a corrupted filsystem (read only) or destroyed system at
> reboot.

I don't know what 'reboot' means here. It sounds like the system is in
perfectly fine order until you reboot… but apt isn't really involved in
a reboot, so… and running apt on a read-only filesystem seems also
strange given that apt is supposed to do things… are you perhaps in some
sort of rescue mode or how did you ended up with a read-only filesystem?


> occured on debian 7 and debian 8.

I have relatively frequent DNS issues myself and various reports about
the "wicked" messages apt shows in these cases indicate that others see
them too without their systems being destroyed. We even have testcases
playing with this sort of failure modes which are run on a few setups
and no broken system reported in that context either. So we will need
a hell of a lot more details… hence tagging as such.


> Now a little not about your reporting webpage which is *strongly*
> recommanding :
> 
> # apt-get install reportbug
> 
> in this case it will ask for an apt-update which will destroy the system,
> without a chance to report anything.

Well, if the bug would have involved your webbrowser instead, how would
you have visited the webpage? If a bug effects central parts of the
infrastructure its always more problematic than a bug in leaf package…
the hope is that such bugs are unlikely enough that we don't have to
base our bugreporting system on handwritten notes and carrier pigeons.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#840669: [pkg-gnupg-maint] Bug#840669: Need way to avoid agent, or reliable way to kill agent

[Daniel Kahn Gillmor]

Hi Ian--

On Fri 2016-10-14 07:10:29 -0400, Ian Jackson wrote:
> Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#840669: Need way to 
> avoid agent,   or reliable way to kill agent"):
>> Does your test suite delete its test homedirs after it is finished?  If
>> not, would you be willing to include removal of the test homedirs as
>> part of the tests, or as a final post-test cleanup phase?
>
> No.  It does not do anything after it is finished.
>
> Each script mentioned in debian/tests/control simply exits zero and
> then (according to DEP-8) it's the responsibility of the test runner
> to delete the tree if it cares.
>
> When run under adt-run with a filesystem snapshotting virt server,
> there is to need (of course) to delete the temporary area, since it's
> in a filesystem a snapshot which is going to be deleted.

i think you mean "no need" here, not "to need", right?

I'm sympathentic with your use case, but am ambivalent about whether
major re-architecting of gpg-agent is way to solve it.

There are multiple ways that processes from a given test run could
potentially linger with files open in that snapshotted filesystem.
gpg-agent happens to be one of them.  what do you propose to do about
the others?

If you want a truly bounded/scoped test run setup, you probably want
something like cgroups and a supervised way of terminating all spawned
processes before unmounting the filesystem.  Asking gpg-agent for
a significantly-modified behavior isn't going to solve the general
problem that your use case implies.


>> One thing worth observing is that if the agent's socket is deleted, it
>> will eventually terminate itself after a minute or two anyway.  This
>> will happen even without inotify (but obviously the inotify trigger
>> should really work to automate cleanup on platforms that support inotify)
>
> That's not really fast enough.

agreed, that's why i'm encouraging upstream to fix their inotify
detection:

   https://bugs.gnupg.org/gnupg/issue2756

> Then perhaps it should take a lock.  I assume there must be some kind
> of locking anyway, or concurrent startups would occasionally fail.

I'll let Werner (who i hope is reading this) answer whether locking is
actually happening and what these tradeoffs might be.  I'd be pretty
unhappy if complicating this ends up with an increased possibility of
gpg deadlock, though. :/

> I propose a design something like this:
>
>  * When GNUPG_AGENT_LIFETIME_FD is set:
> - gpg-agent does not create a rendezvous socket.  Instead,
>   it selects/polls this fd for reading.
> - When the fd is readable, gpg-agent expect to receive one end
>   of an AF_UNIX socketpair over it by fd passing.  That
>   received fd is treated the same way the answer from accept()
>   would be.
> - If the master fd signals EOF, gpg-agent exits.
> - gpg-agent should nevertheless take out a lock on a common
>   name in $GNUPGHOME.
>
>  * When gpg needs an agent but none is running discoverable in the
>current global way [1]:
>If GNUPG_AGENT_LIFETIME_FD is not already set,
> - gpg creates an AF_UNIX anonymous socketpair.  One end will
>   become the "agent" fd and is set ~CLOEXEC.  The other end
>   becomes gpg's and is set CLOEXEC.
> - gpg sets GNUPG_AGENT_LIFETIME_FD to the "agent" end of
>   the socketpair
> - gpg spawns the agent
> - Now GNUPG_AGENT_LIFETIME_FD is set.
>When gpg wants to connect to the agent, it creates a new
>socketpair and uses sendmsg to pass one end to the agent;
>it then closes that end and uses the other end as if it had just
>been connect()ed.
>
>  * Creating a socketpair and setting GNUPG_AGENT_LIFETIME_FD should be
>documented as a way to get a privately-scoped gnupg.  For example,
>dgit might like to do this so that it can make its three signatures
>with one user authorisation and then terminate the authorisation
>when it is done.  The document should say that:
>  - Programs must not set GNUPG_AGENT_LIFETIME_FD if it is already
>set, so they must check it first.  (Otherwise deadlock will
>occur.)
>  - Programs need not check for the existence of an `ambient' gnupg
>agent in the user's account/session/environment; if there is
>one, the GNUPG_AGENT_LIFETIME_FD setting will be ignored.

If dgit is willing to do this work, it should also be willing to just
invoke "gpgconf --kill gpg-agent" when it's ready to terminate the
agent, right?  Why craft all this new mechanism and guidance?

>  * The result is that the scope of an auto-spawned agent is a single
>GNUPG_AGENT_LIFETIME_FD (normally, a single gnupg2 gpg program).
>Other concurrent calls to gpg will block.

yuck.  I really don't like the idea that all concurrent calls to gpg
should block.

>  * [1] If you don't think this behaviour is good by default, it could
>be a config option.  But I would argue that it ought to be the
>default is the 

Bug#840269: RM: nodejs [powerpc] -- ROM; nodejs no longer supported on powerpc

[Sebastiaan Couwenberg]

Hi Scott,

Thanks for processing the RM bugs blocking nodejs testing migration.

On Fri, 14 Oct 2016 09:33:24 -0400 Scott Kitterman wrote:
> On Mon, 10 Oct 2016 08:51:04 +0200 Bas Couwenberg  wrote:
> > Please remove nodejs from powerpc, the architecture is no longer
> > supported (#836415).
> 
> Even after processing the related pending removal bugs, there is a large list 
> of others that need to be dealt with.  If any of these are arch all, please 
> note that in the bug, but the others need rm on powerpc (which needs an rm 
> bug 
> for each).  Please remove the moreinfo tag once this is all done.

All arch:any rdeps are processed via the other RM bugs.

All packages reported by dak are arch:all or otherwise unaffected.

Only these sources are not entirely composed of arch:all packages:

   source|  version   | architecture
-++--
 geographiclib   | 1.46-2 | any all
 node-contextify | 0.1.6-1| any
 node-expat  | 2.3.12-1   | any
 node-expat  | 2.3.15-1   | any
 node-groove | 2.5.0-1| any
 node-iconv  | 2.1.11-1   | any
 node-iconv  | 2.2.1-1| any
 nodejs  | 4.4.7~dfsg-2   | any all
 nodejs  | 4.6.0~dfsg-2   | any all
 node-leveldown  | 1.4.1+dfsg-1   | any
 node-postgres   | 0.13.3-1   | any
 node-stringprep | 0.6.2-1| any
 node-stringprep | 0.8.0-1| any
 node-websocket  | 1.0.22-2   | any all
 node-ws | 1.0.0+ds1.e6ddaae4-1   | any
 node-ws | 1.1.0+ds1.e6ddaae4-1   | any
 node-xmlhttprequest | 1.6.0-1| any
 node-zlib   | 1.0.5-1| any
 node-zmq| 2.15.1+dfsg-2  | any
 rustc   | 1.11.0+dfsg1-3 | any all
 rustc   | 1.12.0+dfsg1-1 | any all
 statsmodels | 0.6.1-8| any all
 statsmodels | 0.8.0~rc1+git43-g1ac3f11-1 | any all
(23 rows)

I've trimmed down your dak lists to only the above sources and annotated
them in brackets.

 # Broken Depends:
 geographiclib: node-geographiclib [node-geographiclib is arch:all]
 nodejs: nodejs-legacy [RM bug: #840269]

 # Broken Build-Depends:
 node-contextify: nodejs-dev [FTBFS, no binaries on powerpc]
 node-expat: nodejs  [RM bug: #840273]
 nodejs-dev
 node-groove: nodejs [RM bug: #840274]
 node-iconv: nodejs-dev  [RM bug: #840275]
 node-leveldown: nodejs  [RM bug: #840276]
 node-postgres: nodejs-dev   [FTBFS, no binaries on powerpc]
 node-stringprep: nodejs-dev [RM bug: #840280]
 node-websocket: nodejs-dev  [RM bug: #840282]
 node-ws: nodejs (>= 4.0)[RM bug: #840283]
 node-xmlhttprequest: nodejs [RM bug: #840284]
 node-zlib: nodejs-dev   [FTBFS, no binaries on powerpc]
 node-zmq: nodejs[RM bug: #840285]
   nodejs-dev (>= 4.1.2~)
 rustc: nodejs   [BD-Uninstallable, no binaries on powerpc]
 statsmodels: nodejs [BD-Uninstallable, no binaries on powerpc]

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


nodejs-rdeps.sql
Description: application/sql

Bug#840669: [pkg-gnupg-maint] Bug#840669: Need way to avoid agent, or reliable way to kill agent

[Ian Jackson]

Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#840669: Need way to 
avoid agent, or reliable way to kill agent"):
> Does your test suite delete its test homedirs after it is finished?  If
> not, would you be willing to include removal of the test homedirs as
> part of the tests, or as a final post-test cleanup phase?

No.  It does not do anything after it is finished.

Each script mentioned in debian/tests/control simply exits zero and
then (according to DEP-8) it's the responsibility of the test runner
to delete the tree if it cares.

When run under adt-run with a filesystem snapshotting virt server,
there is to need (of course) to delete the temporary area, since it's
in a filesystem a snapshot which is going to be deleted.

> One thing worth observing is that if the agent's socket is deleted, it
> will eventually terminate itself after a minute or two anyway.  This
> will happen even without inotify (but obviously the inotify trigger
> should really work to automate cleanup on platforms that support inotify)

That's not really fast enough.

> > IMO: there should be a way to get gnupg2 to do everything synchronously;
> > that is, if it needs an agent, to spawn one which does not listen on a
> > socket, but rather just has an existing connection to its parent and
> > which will die when the parent does.
> 
> This could potentially complicate the agent -- at the moment, i think
> the agent expects to be the only process dealing with
> $GNUPGHOME/private-keys-v1.d/, and that means that two gpg processes
> using this approach could potentially trample on each other.

Then perhaps it should take a lock.  I assume there must be some kind
of locking anyway, or concurrent startups would occasionally fail.

I propose a design something like this:

 * When GNUPG_AGENT_LIFETIME_FD is set:
- gpg-agent does not create a rendezvous socket.  Instead,
  it selects/polls this fd for reading.
- When the fd is readable, gpg-agent expect to receive one end
  of an AF_UNIX socketpair over it by fd passing.  That
  received fd is treated the same way the answer from accept()
  would be.
- If the master fd signals EOF, gpg-agent exits.
- gpg-agent should nevertheless take out a lock on a common
  name in $GNUPGHOME.

 * When gpg needs an agent but none is running discoverable in the
   current global way [1]:
   If GNUPG_AGENT_LIFETIME_FD is not already set,
- gpg creates an AF_UNIX anonymous socketpair.  One end will
  become the "agent" fd and is set ~CLOEXEC.  The other end
  becomes gpg's and is set CLOEXEC.
- gpg sets GNUPG_AGENT_LIFETIME_FD to the "agent" end of
  the socketpair
- gpg spawns the agent
- Now GNUPG_AGENT_LIFETIME_FD is set.
   When gpg wants to connect to the agent, it creates a new
   socketpair and uses sendmsg to pass one end to the agent;
   it then closes that end and uses the other end as if it had just
   been connect()ed.

 * Creating a socketpair and setting GNUPG_AGENT_LIFETIME_FD should be
   documented as a way to get a privately-scoped gnupg.  For example,
   dgit might like to do this so that it can make its three signatures
   with one user authorisation and then terminate the authorisation
   when it is done.  The document should say that:
 - Programs must not set GNUPG_AGENT_LIFETIME_FD if it is already
   set, so they must check it first.  (Otherwise deadlock will
   occur.)
 - Programs need not check for the existence of an `ambient' gnupg
   agent in the user's account/session/environment; if there is
   one, the GNUPG_AGENT_LIFETIME_FD setting will be ignored.

 * The result is that the scope of an auto-spawned agent is a single
   GNUPG_AGENT_LIFETIME_FD (normally, a single gnupg2 gpg program).
   Other concurrent calls to gpg will block.

 * [1] If you don't think this behaviour is good by default, it could
   be a config option.  But I would argue that it ought to be the
   default is the environment has not provided an agent, because it
   provides the same authorisation lifetime as was implemented in
   gnupg1.

> > In particular, `gpgconf --kill gpg-agent' should be documented.
> 
> Where would you like it documented?  it's in gpgconf(1):

In gpg-agent(1) !

> If you're not willing to do *anything* (including deletion of the
> temporary $GNUPGHOME or some sort of session termination event) upon
> completing the test suite, but before tearing down your builder
> instance, then i don't know if there's a solution.  But at the moment i
> suspect getting the inotify stuff fixed is the sanest and simplest
> approach on the platform you and i probably care most about :)

For now I have bodged this with a new schroot script
/etc/schroot/setup.d/71killagent.  Attached.

This doesn't solve the problem when the test scripts are run ad-hoc.
It won't solve the problem for other programs which set HOME (or
GNUPGHOME) as part of test suites or whatever.

Thanks for your attention.

Ian.

-- 
Ian 

Bug#840344: cinnamon: Cinnamon almost fully freezes after changing workspace.

[John Kirk]

Package: cinnamon
Version: 3.0.7-1
Followup-For: Bug #840344

Dear Maintainer,

Additional info:

The running window of a virtual machine should be maximized (not fullscreen,
not the virt-manager window).

There is also another way to reproduce it:

1) Open terminal
2) gpg -c somefile.txt
3) When you will see the window for a password try to open an application
through cinnamon menu,
change workspace through the applet or the right button menu on the desktop.

Best wishes,
John




-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cinnamon depends on:
ii  adwaita-icon-theme [gnome-icon-theme-symbolic]  3.22.0-1
ii  caribou 0.4.21-1
ii  cinnamon-common 3.0.7-1
ii  cinnamon-control-center 3.0.1-1
ii  cinnamon-desktop-data   3.0.2-2
ii  cinnamon-screensaver3.0.1-1
ii  cinnamon-session3.0.1-1
ii  cinnamon-settings-daemon3.0.1-2
ii  cjs 3.0.1-3+b1
ii  cups-pk-helper  0.2.6-1
ii  dconf-gsettings-backend [gsettings-backend] 0.26.0-2
ii  gir1.2-accountsservice-1.0  0.6.40-3
ii  gir1.2-caribou-1.0  0.4.21-1
ii  gir1.2-clutter-1.0  1.26.0-2
ii  gir1.2-cmenu-3.03.0.2-1
ii  gir1.2-cogl-1.0 1.22.2-2
ii  gir1.2-gconf-2.03.2.6-3
ii  gir1.2-gdkpixbuf-2.02.36.0-1
ii  gir1.2-gkbd-3.0 3.22.0.1-1
ii  gir1.2-glib-2.0 1.50.0-1
ii  gir1.2-gnomedesktop-3.0 3.22.0-1
ii  gir1.2-gtk-3.0  3.22.1-1
ii  gir1.2-gtkclutter-1.0   1.8.2-1
ii  gir1.2-javascriptcoregtk-3.02.4.11-3
ii  gir1.2-keybinder-3.00.3.1-1
ii  gir1.2-meta-muffin-0.0  3.0.5-1
ii  gir1.2-networkmanager-1.0   1.4.2-1+b1
ii  gir1.2-notify-0.7   0.7.6-2
ii  gir1.2-pango-1.01.40.3-2
ii  gir1.2-polkit-1.0   0.105-16
ii  gir1.2-soup-2.4 2.56.0-1
ii  gir1.2-upowerglib-1.0   0.99.4-4
ii  gir1.2-webkit-3.0   2.4.11-3
ii  gkbd-capplet3.22.0.1-1
ii  gnome-backgrounds   3.22.1-1
ii  gnome-icon-theme-symbolic   3.12.0-2
ii  gnome-themes-standard   3.20.2-3
ii  gsettings-desktop-schemas   3.22.0-1
ii  libatk-bridge2.0-0  2.22.0-1
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-3
ii  libcairo2   1.14.6-1+b1
ii  libcinnamon-menu-3-03.0.2-1
ii  libcjs0 3.0.1-3+b1
ii  libclutter-1.0-01.26.0-2
ii  libcogl-pango20 1.22.2-2
ii  libcogl-path20  1.22.2-2
ii  libcogl20   1.22.2-2
ii  libcroco3   0.6.11-2
ii  libgdk-pixbuf2.0-0  2.36.0-1
ii  libgirepository-1.0-1   1.50.0-1
ii  libgl1-mesa-glx [libgl1]12.0.3-1
ii  libglib2.0-02.50.0-2
ii  libglib2.0-bin  2.50.0-2
ii  libgstreamer1.0-0   1.8.3-1
ii  libgtk-3-0  3.22.1-1
ii  libjs-jquery1.12.4-1
ii  libmozjs-24-0   24.2.0-3.1
ii  libmuffin0  3.0.5-1
ii  libpango-1.0-0  1.40.3-2
ii  libpangocairo-1.0-0 1.40.3-2
ii  libstartup-notification00.12-4
ii  libx11-62:1.6.3-1
ii  libxfixes3  1:5.0.2-1
ii  libxml2 2.9.4+dfsg1-2
ii  mesa-utils  8.3.0-2+b1
ii  nemo3.0.6-3
ii  policykit-1-gnome   

Bug#768073: [pkg-go] Bug#768073: LXC team take over ITP?

[Clément Hermann]

Le 14/10/2016 à 12:34, Jonathan Dowland a écrit :
> On Thu, Oct 13, 2016 at 02:11:13PM +0200, Martín Ferrari wrote:
>> A few of these dependencies are already in the archive, not all have the
>> standard naming yet, but I think about half of those are already packaged.
> 
> Thanks! I've just gone through to re-check them, renamed a few to the 
> canonical
> names for the relevant dev packages, leaving just three missing:
> 
>  lxd-build-deps : Depends: golang-gopkg-flosch-pongo2.v3-dev but it is not 
> installable
>   Depends: golang-gopkg-inconshreveable-log15.v2-dev but it 
> is not installable

From what I looked, this is a fork of
golang-github-tendermint-log15-dev, which is the archive. There seem to
be very few changes, so it might just work:
https://github.com/inconshreveable/log15/compare/master...tendermint:master

Not sure what the pkg-go team policy is on this kind of very similar
packages, but I'm sure people actually in the team can answer. :)

Cheers and thanks for working on this !

-- 
nodens



signature.asc
Description: OpenPGP digital signature

Bug#840743: mdadm: grow fails when no backup file is specified

[Jens Sauer]

Package: mdadm
Version: 3.3.2-5+deb8u1
Severity: important

Dear Maintainer,

I was playing around with mdadm in a KVM machine. 
When the number of active raid devices are changed using the 'grow' feature 
without
specifying a backup file the reshape fails and the array can not be recovered.

First I created an array:
mdadm -C /dev/md0 -n4 -l6 /dev/vd[bcde]1

Add a spare device:
mdadm --add /dev/md0 /dev/vdf

Grow with a backup-file:
mdadm -G /dev/md0 -n5 --backup-file=/root/grow_md0.bak

Reshape is triggered and was successful.

Add another spare device:
mdadm --add /dev/md0 /dev/vdg1

Grow without backup-file:
mdadm -G /dev/md0 -n6

Syslog shows the following:

md0: detected capacity change from 2142240768 to 3213361152
RAID conf printout:
 --- level:6 rd:5 wd:5
  disk 0, o:1, dev:vdb1
  disk 1, o:1, dev:vdc1
  disk 2, o:1, dev:vdd1
  disk 3, o:1, dev:vde1
  disk 4, o:1, dev:vdf1
RAID conf printout:
 --- level:6 rd:6 wd:6
  disk 0, o:1, dev:vdb1
  disk 1, o:1, dev:vdc1
  disk 2, o:1, dev:vdd1
  disk 3, o:1, dev:vde1
  disk 4, o:1, dev:vdf1
  disk 5, o:1, dev:vdg1
md: reshape of RAID array md0
md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
md: using maximum available idle IO bandwidth (but not more than 20 KB/se
md: using 128k window, over a total of 1046016k.
systemd[1]: Starting Manage MD Reshape on /dev/md0...
systemd[1]: Started Manage MD Reshape on /dev/md0.
systemd[1]: mdadm-grow-continue@md0.service: main process exited, code=exited, 
status
systemd[1]: Unit mdadm-grow-continue@md0.service entered failed state.

The reshape stucks at 0%, there was no error or warning displayed from mdadm.
I tried to stop and reassemble the array using the --invalid-backup flag but I 
can't
get it back working.


-- Package-specific info:
--- mdadm.conf
CREATE owner=root group=disk mode=0660 auto=yes
HOMEHOST 
MAILADDR root

--- /etc/default/mdadm
INITRDSTART='none'
AUTOCHECK=true
START_DAEMON=true
DAEMON_OPTIONS="--syslog"
VERBOSE=false

--- /proc/mdstat:
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid6 vdg1[5] vdf1[4] vde1[3] vdd1[2] vdc1[1] vdb1[0]
  3138048 blocks super 1.2 level 6, 512k chunk, algorithm 2 [6/6] [UU]
  [>]  reshape =  0.0% (0/1046016) finish=25.9min 
speed=650K/sec
  
unused devices: 

--- /proc/partitions:
major minor  #blocks  name

 2540   20971520 vda
 2541   20067328 vda1
 2542  1 vda2
 2545 901120 vda5
 254   161048576 vdb
 254   171047535 vdb1
 254   321048576 vdc
 254   331047535 vdc1
  1101048575 sr0
 254   481048576 vdd
 254   491047535 vdd1
 254   641048576 vde
 254   651047535 vde1
 254   801048576 vdf
 254   811047535 vdf1
 254   961048576 vdg
 254   971047535 vdg1
 254  1121048576 vdh
 254  1131047535 vdh1
   903138048 md0

--- LVM physical volumes:
LVM does not seem to be used.
--- mount output
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=255145,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,relatime,size=411692k,mode=755)
/dev/vda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs 
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup 
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/devices type cgroup 
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup 
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup 
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/blkio type cgroup 
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup 
(rw,nosuid,nodev,noexec,relatime,perf_event)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
(rw,relatime,fd=23,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime)

--- initrd.img-3.16.0-4-amd64:
93022 blocks
793809de2771258a23ce068eb898f78c  

Bug#836601: (no subject)

[Mauro Sacchetto]

same bug today on Testing

Bug#840734: systemd-sleep: Regularly unable to resume from hibernate

[Felipe Sateler]

On 14 October 2016 at 10:02, Michael Biebl  wrote:
> Am 14.10.2016 um 14:47 schrieb Felipe Sateler:
>
>> (We should add dracut and initramfs-tools install state to the
>> reportbug template...)
>
> Sounds like a reasonable idea.
> Do we want the state of dracut and initramfs-tools or
> dracut-core and initramfs-tools-core. I assume the former?

I think it is most interesting to see the default hookued up initramfs
tool. Let's hope that people that are trying a manually generated
initrd will tell us when they report a bug happening only under that
initrfamfs tool...

-- 

Saludos,
Felipe Sateler

Bug#840685: tomcat8: DSA-3670 incomplete

[paul . szabo]

Dear Markus,

> First of all you can only gain write permissions as the tomcat8 user if
> you exploit an yet unknown security vulnerability in a web application
> or Tomcat itself. Debian's tomcat8 user has no shell access by default.

Yes, this is a privilege escalation issue: exactly as in DSA-3670.

> So the server must be running ...

No, you are wrong. Once I managed run-any-code-as-tomcat8 from the
running server, I set up something to run in the background, to keep
running after the server exited.

> ... and somehow you managed to remove /tmp/tomcat8-tomcat8-tmp and
> replaced the directory with a symlink to an arbitrary file.

No I do not remove anything. You do the remove, I create the symlink
after you removed (and before you attempt the mkdir).

> Your attack vector requires that the server must be restarted. ...

Yes, exactly as in DSA-3670.

> ... But there is another rm -rf "$JVM_TMP" command in the stop target
> that would remove your symlink again.

No, not another rm. I create the symlink after your rm.

> Ok, let's imagine that you could find a way around the rm -rf commands.
> Let's remove those rm -rf "$JVM_TMP" calls in /etc/init.d/tomcat8. Then
> run systemctl daemon-reload. Log in as tomcat8 user and create your
> symlink for /tmp/tomcat8-tomcat8-tmp. If I run systemctl restart tomcat8
> now, I get this:
> 
> Job for tomcat8.service failed because the control process exited with
> error code.
> 
> The symlink is still present and nothing has changed regarding the file
> permissions for my arbitrary file.

You created the wrong symlink: not to a random place and not to a file,
but a symlink to /etc (an existing directory). Please try again.

> I agree that we should improve the init script in this regard but I
> actually don't see a major risk like a root escalation for users at the
> moment and I suggest to lower the severity of this bug report to important.

Do the right test, please. You will see /etc owned by tomcat8, that
effectively gives root access.

>> What response time should I have expected of team@security? You had
>> close to a whole day...
> In my opinion it is generally understood that you should give people at
> least enough time to react to an e-mail and to assess the issue.
> Expecting a response time in less than a day is not very reasonable,
> especially when there are things like the time difference between
> Australia and Europe.

You can do better, if you try.

Cheers, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

Bug#840780: mysql-server-5.6: 5.6.30 fails with request-tracker4 rt-setup-fulltext-index script

[James Zuelow]

Package: mysql-server-5.6
Version: 5.6.27-2
Severity: normal

Dear Maintainer,

When attempting to setup fulltext indexes with request-tracker4 4.2.13-2
on Squeeze, the script will fail when it attempts to create a fulltext
index InnoDB table.  Running the script looks like this:

#
root@mis-rt-lnx:/usr/sbin# ./rt-setup-fulltext-index --dba rtuser 
--dba-password secret
MySQL 5.6 and above support native full-text indexing; for compatibility
with earlier versions of RT, the external Sphinx indexer is still
supported.

Which indexing solution would you prefer?
[mysql]: mysql

Enter the name of a new MySQL table that will be used to store the
full-text content and indexes:
[AttachmentsIndex]: AttachmentsIndex

Going to run the following in the DB:

 CREATE TABLE AttachmentsIndex ( id INT UNSIGNED AUTO_INCREMENT NOT
NULL PRIMARY KEY,Content LONGTEXT ) ENGINE=InnoDB CHARACTER SET utf8

Indexing existing data...

Going to run the following in the DB:

 CREATE FULLTEXT INDEX AttachmentsIndex ON AttachmentsIndex(Content)

[58876] [Thu Oct 13 02:23:42 2016] [warning]: DBD::mysql::db do failed:
Lost connection to MySQL server during query at
./rt-setup-fulltext-index line 736,  line 2.
(./rt-setup-fulltext-index:736)
[58876] [Thu Oct 13 02:23:42 2016] [critical]: DBD::mysql::db do failed:
Lost connection to MySQL server during query at
./rt-setup-fulltext-index line 736,  line 2.
(/usr/share/request-tracker4/lib/RT.pm:389)
DBD::mysql::db do failed: Lost connection to MySQL server during query
at ./rt-setup-fulltext-index line 736,  line 2.
##

Discussing the issue on the RT User's mailing list, it appears that this 
problem started to occur with MySQL version 5.6.29 and as I can see still 
occurs with 5.6.30 as shipped by Debian.

Since 5.6.30 was the lastest version available to me, I resolved the issue by 
adding a Debian Snapshots entry to apt's sources config and downgrading to 
5.6.27-2, at which time the script ran perfectly.

I see that the changelog for MySQL 5.6.31 includes a fix for MySQL bug 
#22963169, which I believe is the one responsible for the RT4 setup script 
failing.

I don't see any evidence that MySQL 5.6.31 is in the pipe for a Stretch 
release, especially with a potential freeze next month.  But I believe that 
sticking with 5.6.30 will render parts of the request-tracker4 package unusable.

Thanks!

James

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages mysql-server-5.6 depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.59
ii  init-system-helpers1.45
ii  initscripts2.88dsf-59.8
ii  libaio10.3.110-3
ii  libc6  2.24-3
ii  libdbi-perl1.636-1
ii  libgcc11:6.1.1-11
ii  libstdc++6 6.1.1-11
ii  libwrap0   7.6.q-25
ii  lsb-base   9.20160629
ii  mysql-client-5.6   5.6.30-1
ii  mysql-common   5.8+1.0.0
ii  mysql-server-core-5.6  5.6.27-2
ii  passwd 1:4.2-3.2
ii  perl   5.22.2-5
ii  psmisc 22.21-2.1+b1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages mysql-server-5.6 recommends:
ii  libhtml-template-perl  2.95-2

Versions of packages mysql-server-5.6 suggests:
ii  s-nail [mailx]  14.8.10-1
pn  tinyca  

Versions of Request-Tracker4:
ii  request-tracker44.2.13-2
ii  rt4-apache2 4.2.13-2
ii  rt4-clients 4.2.13-2
ii  rt4-db-mysql4.2.13-2

-- debconf information:
  mysql-server/error_setting_password:
  mysql-server/password_mismatch:
  mysql-server-5.6/nis_warning:
  mysql-server-5.6/start_on_boot: true
  mysql-server-5.6/postrm_remove_databases: false
  mysql-server/no_upgrade_when_using_ndb:
  mysql-server-5.6/really_downgrade: false

Bug#840394: motif: FTBFS: relocation R_X86_64_PC32 against symbol ...

[Joachim Wiedorn]

Hello Graham,

Graham Inggs wrote on 2016-10-14 16:35:
> 
> PIE by default is happening for Stretch.
> Release Team have given the go-ahead, see message #21 of #835148 [1],
> and the changes have already been committed to SVN [2] and should be
> included in the next GCC6 upload.

Thank you for this information. I think, than the time is short for
some other packages which still have a problem with 'pie'. 

---
Have a nice day.

Joachim (Germany)


pgpn4w1p0qTgk.pgp
Description: Digitale Signatur von OpenPGP

Bug#840298: [Pkg-samba-maint] Bug#840382: samba (2:4.4.6+dfsg-2) still crashes with libtevent0-0.31

[Mathieu Parent]

To the recipients:

Do you still have the problem when using latest packages from sid?

I cant' reproduce the problem anymore.

Thanks

Mathieu Parent

Bug#815231: cmake: FTBFS on kfreebsd, hurd: 2 tests fail: BuildDepends, RunCMake.Configure

[Brad King]

On 04/24/2016 11:59 AM, Andreas Beckmann wrote:
> On Thu, 7 Apr 2016 14:54:20 +0100 Steven Chamberlain wrote:
>> If I change all files except CustomCMakeInput.txt to have identical
>> timestamps, then I can reproduce the bug as seen on the buildds:
[snip]
>> And finally, it seems I can avoid that happening by making just the
>> Makefile have a newer timestamp than the others.  The bug is no longer
>> reproducible then:
[snip]
> You may have to consider make's behavior w.r.t. files of the identical
> time stamp:
[snip]
> A target is considered up-to-date if it's timestamp is newer *or same*
> as its prerequisites. Even if a prerequisite was just created.
> (#820658, this is documented make behavior)
> 
> And if I understand this correctly, cmake is doing the opposite:

That is *only* in the if(IS_NEWER_THAN) check which does not come into
play in the RunCMake.Configure test AFAIK.  The way CMake decides whether
it needs to re-configure is the following:

* The "make" tool sees the cmake_check_build_system target in the Makefile
  as always out of date and always runs CMake to do the check.  See
  the `cmake::CheckBuildSystem` method for the implementation.

* CMake reads CMakeFiles/Makefile.cmake and collects the timestamps
  of all the files listed as CMAKE_MAKEFILE_{DEPENDS,OUTPUTS}.

* CMake finds the newest entry in DEPENDS and the oldest entry in OUTPUTS.

* If the newest dependency is newer than (but not equal to) the oldest
  output then it decides to re-run.  This is the same as the "make"
  behavior for identical timestamps.

If you place `VERBOSE=1` in your environment then CMake will print out
what pair of files caused it to decide to re-run.

Steven, in your earlier test that I quoted above, did you ensure that
the timestamps of all files listed as described above (which includes
some under CMakeFiles/) had the same timestamp?  If not then I don't
think the test was set up the way you intended.

-

FWIW I would not consider this test failure to be a blocking issue for
packaging a new CMake on this platform.  The behavior of this logic is
the same as it has been for years in CMake.  It is just that this test
case did not exist before.

-Brad

Bug#840650: Firmware Part 2

[Ritesh Raj Sarraf]

On Fri, 2016-10-14 at 10:15 +0300, George Vasiliou (GMAIL) wrote:
> Booting with the previous linux image 4.7.5.1 and after setting firmware
> swtich fwlps to off , seems that established a rigid connection.
> 
> Maybe the new kernel 4.7.6.1 is more "sensitive" on the FW flags, since i had
> never issues before with fwlps which had been left to it's default value (1)
> for a lot of months.
> 
> Maybe i could try to upgrade again in the new linux-image 4.7.6.1 and see how
> it performs with fwlps off.
> 
> I switched off fwlps by using
> echo "options rtl8723be fwlps=0">/etc/modprobe.d/rtl8723be.conf
> (or could be done by adding above line in the end of the existed
> modsetting.conf file in the same directory).
> PS: All the rest options of rtl8723be are left to default.

I'm glad you figured it out. Yes. This device is screwed up and solely depends
on firmware and operating modes.


-- 
Given the large number of mailing lists I follow, I request you to CC
me in replies for quicker response

signature.asc
Description: This is a digitally signed message part

Bug#840650: RTLWIFI/RTL8723BE stopped working after Debian Sid Update

[Ritesh Raj Sarraf]

On Thu, 2016-10-13 at 17:49 +0300, George Vasiliou (GMAIL) wrote:
> While the wifi network indicator was looking alive, I had no internet access
> and also i had not even lan access. 
> Moreover wifi icon starts showing disconected and reconnected a lot of times.
> 
> Once every 30 minutes i had some limited internet connection and then lost
> again.
> 
> Since Debian keeps the stable linux-image 3.16 , i was capable to boot with
> stable kernel and wifi worked correctly. 
> 
> Using modprobe -r rtl8723be and again modprobe rtl8723be has no improvement.
> 
> The strange thing is that i downgraded linux-image and linux-headers back to
> the old good working version 4.7.0.1 / 4.7.5.1 using the /testing repository,
> but still wifi refuses to work.

That hardware works fine for me. But I'm on Debian Unstable.

But given that you too are on a very recent kernel, it shouldn't matter if you
are on Debian Stable or Unstable.

The hardware is very dependent of the firmware, and the mode of operation in
firmware.

Please try the following:
Load the module with these arguments: fwlps=0 swlps=1

I hope it'll solve your issue.


-- 
Given the large number of mailing lists I follow, I request you to CC
me in replies for quicker response

signature.asc
Description: This is a digitally signed message part

Bug#840778: fprintd: Please announce supported hardware using AppStream

[Petter Reinholdtsen]

Package: fprintd
Version: 0.6.0-2
Severity: wishlist
User: p...@hungry.com
Usertags: appstream-modalias

Hi.

The fprintd package is one of the packages in the Debian archive that
should be proposed for installation when a given hardware dongle is
inserted or available.  Thanks to the appstream system, this can now be
announced in a way other tools can use and act on.  I've written the
isenkram system to ask the current user if hardware specific packages
should be installed when a new dongle is installed or already present on
a machine, and isenkram now uses appstream as one source for hardware to
package mappings.

You can read more about this on my blog, 
http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html
 >.

Instructions on how to create the metadata XML file can be found in
https://wiki.debian.org/AppStream/Guidelines >.

It would be great if you could add an appstream metainfo file to the
fprintd package, with content similar to this:

  
  
   [...]
   
usb:v147Ep2020d*
   
  

If there are other hardware ids or kernel modules also supported by the
package, please add those too. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#766461: gitg: upload 3.22 to unstable

[Jérémy Lal]

Package: gitg
Followup-For: Bug #766461

Hi Dmitry,

just a few words to say that i'm having an incredibly good
user experience with gitg 3.22.
It's fast, it's packed with wonderful features (uncomparably
better than old 0.2.7 version) and upstream seems to be
going in a very pragmatic direction.
If you need any help maintaining libgit2-glib/gitg, please
do not hesitate to ask.

Jérémy



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gitg depends on:
ii  dbus-x11 1.10.12-1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gir1.2-peas-1.0  1.20.0-1
ii  git  1:2.9.3-1
ii  gsettings-desktop-schemas3.22.0-1
ii  libc62.24-3
ii  libcairo21.14.6-1+b1
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libgee-0.8-2 0.18.1-1
ii  libgirepository-1.0-11.50.0-1
ii  libgit2-glib-1.0-0   0.24.4-1
ii  libglib2.0-0 2.50.1-1
ii  libgtk-3-0   3.22.1-1
ii  libgtksourceview-3.0-1   3.22.0-1
ii  libgtkspell3-3-0 3.0.9-1
ii  libpango-1.0-0   1.40.3-2
ii  libpeas-1.0-01.20.0-1
ii  libsecret-1-00.18.5-2
ii  libsoup2.4-1 2.56.0-1
ii  libxml2  2.9.4+dfsg1-2

gitg recommends no packages.

gitg suggests no packages.

-- no debconf information

Bug#840727: cmark: please provide libcmark0 and libcmark-dev packages

[Andrew Shadura]

On 14/10/16 19:37, Peter Eisentraut wrote:
> On 10/14/16 4:33 AM, Andrew Shadura wrote:
>> Please provide libcmark-* packages, so that packages using
>> CommonMark library can link against and depend on these
>> packages.
> 
> Do you have an actual package in mind that needs this?

Yes, hotdoc (see #840777). It however requires some patches not yet in
upstream cmark.

> I have some doubts that upstream is following "proper" shared library
> compatibility practices.  So I don't want to put out a shared library
> package on a hunch.  A static library might be possible.

Well, at least a static library would be better than nothing.

-- 
Cheers,
  Andrew



signature.asc
Description: OpenPGP digital signature

Bug#840546: CVE-2016-7966 kdepimlibs jessie

[Sandro Knauß]

Hey,

I now back ported the second part of the fix of the CVE. I updated the version 
deb8u1 from Scott. Should I create a deb8u2 for the additional patch?

I attached the uptodate debdiff.
 
Regards,

sandro

Am Donnerstag, 13. Oktober 2016, 18:19:35 CEST schrieb Moritz Mühlenhoff:
> On Thu, Oct 13, 2016 at 12:15:01PM +0200, Sandro Knauß wrote:
> > Hey,
> > 
> > The description
> > https://www.kde.org/info/security/advisory-20161006-1.txt do not describe
> > all patches that are needed to fix the CVE (at the moment).
> > 
> > The additional patches are not part of KDE Frameworks 5.27, so they need
> > to be applied for KF 5.27:
> > 5e13d2439dbf540fdc840f0b0ab5b3ebf6642c6a (0004-Display-bad-url.patch)
> > a06cef31cc4c908bc9b76bd9d103fe9c60e0953f (0003-Add-more-autotests.patch)
> > 
> > (the first two will be included in KF 5.27).
> > 
> > The fixed version is 5.26.0-3 (sid only - already uploaded). I'll test if
> > we need these patches also for stable inside kdepimlibs.
> 
> Ok, please let us know once you know more. Scott Kitterman has already sent
> an update for kdepimlibs (attached).
> 
> Cheers,
> Moritz

diff -Nru kdepimlibs-4.14.2/debian/changelog kdepimlibs-4.14.2/debian/changelog
--- kdepimlibs-4.14.2/debian/changelog	2014-11-17 04:38:20.0 +0100
+++ kdepimlibs-4.14.2/debian/changelog	2016-10-14 18:09:02.0 +0200
@@ -1,3 +1,21 @@
+kdepimlibs (4:4.14.2-2+deb8u1) jessie-security; urgency=high
+
+  * Team upload.
+  [ Scott Kitterman ]
+  * CVE-2016-7966 KMail: HTML injection in plain text viewer (Closes: #840546)
+- Avoid transforming as a url in plain text mode when there is a quote
+- Add debian/patches/CVE-2016-7966.diff from upstream
+
+  [ Sandro Knauß ]
+  * Additional patch to complete the fix for CVE-2016-7966
+- Replace all scary charactars (", <, > and &) with safe HTML
+  replacements.
+- Backport commit kcoreaddons 5e13d2439dbf540fdc840f0b0ab5b3ebf6642c6a
+  in debian/patches/CVE-2016-7966_part2.diff
+  * Update symbols files.
+
+ -- Sandro Knauß   Fri, 14 Oct 2016 18:09:02 +0200
+
 kdepimlibs (4:4.14.2-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru kdepimlibs-4.14.2/debian/libkpimutils4.symbols kdepimlibs-4.14.2/debian/libkpimutils4.symbols
--- kdepimlibs-4.14.2/debian/libkpimutils4.symbols	2014-10-20 17:13:26.0 +0200
+++ kdepimlibs-4.14.2/debian/libkpimutils4.symbols	2016-10-14 18:09:02.0 +0200
@@ -7,6 +7,7 @@
  _ZN9KPIMUtils11LinkLocator15getEmailAddressEv@Base 4:4.3.4
  _ZN9KPIMUtils11LinkLocator15highlightedTextEv@Base 4:4.3.4
  _ZN9KPIMUtils11LinkLocator16setMaxAddressLenEi@Base 4:4.3.4
+ _ZN9KPIMUtils11LinkLocator23getUrlAndCheckValidHrefEPb@Base 4:4.14.2-2+deb8u1
  _ZN9KPIMUtils11LinkLocator6getUrlEv@Base 4:4.3.4
  _ZN9KPIMUtils11LinkLocatorC1ERK7QStringi@Base 4:4.3.4
  _ZN9KPIMUtils11LinkLocatorC2ERK7QStringi@Base 4:4.3.4
diff -Nru kdepimlibs-4.14.2/debian/patches/CVE-2016-7966.diff kdepimlibs-4.14.2/debian/patches/CVE-2016-7966.diff
--- kdepimlibs-4.14.2/debian/patches/CVE-2016-7966.diff	1970-01-01 01:00:00.0 +0100
+++ kdepimlibs-4.14.2/debian/patches/CVE-2016-7966.diff	2016-10-14 16:59:11.0 +0200
@@ -0,0 +1,89 @@
+From: Montel Laurent 
+Date: Fri, 30 Sep 2016 13:55:35 +
+Subject: Backport avoid to transform as a url when we have a quote
+X-Git-Url: http://quickgit.kde.org/?p=kdepimlibs.git=commitdiff=176fee25ca79145ab5c8e2275d248f1a46a8d8cf
+---
+Backport avoid to transform as a url when we have a quote
+---
+
+
+--- a/kpimutils/linklocator.cpp
 b/kpimutils/linklocator.cpp
+@@ -94,6 +94,12 @@
+ }
+ 
+ QString LinkLocator::getUrl()
++{
++return getUrlAndCheckValidHref();
++}
++
++
++QString LinkLocator::getUrlAndCheckValidHref(bool *badurl)
+ {
+   QString url;
+   if ( atUrl() ) {
+@@ -129,13 +135,26 @@
+ 
+ url.reserve( maxUrlLen() );  // avoid allocs
+ int start = mPos;
++bool previousCharIsADoubleQuote = false;
+ while ( ( mPos < (int)mText.length() ) &&
+ ( mText[mPos].isPrint() || mText[mPos].isSpace() ) &&
+ ( ( afterUrl.isNull() && !mText[mPos].isSpace() ) ||
+   ( !afterUrl.isNull() && mText[mPos] != afterUrl ) ) ) {
+   if ( !mText[mPos].isSpace() ) {   // skip whitespace
+-url.append( mText[mPos] );
+-if ( url.length() > maxUrlLen() ) {
++  if (mText[mPos] == QLatin1Char('>') && previousCharIsADoubleQuote) {
++  //it's an invalid url
++  if (badurl) {
++  *badurl = true;
++  }
++  return QString();
++  }
++  if (mText[mPos] == QLatin1Char('"')) {
++  previousCharIsADoubleQuote = true;
++  } else {
++  previousCharIsADoubleQuote = false;
++  }
++  url.append( mText[mPos] );
++  if ( url.length() > maxUrlLen() ) {
+   break;
+ }
+   }
+@@ -367,7 +386,12 @@
+ } else {
+   const int start = 

Bug#840669: [pkg-gnupg-maint] Bug#840669: Need way to avoid agent, or reliable way to kill agent

[Simon McVittie]

On Fri, 14 Oct 2016 at 12:58:17 -0400, Daniel Kahn Gillmor wrote:
> Furthermore, it seems likely that this will be complex and difficult for
> most people to use, even moreso than saying "please exec 'gpgconf --kill
> gpg-agent' when you're done".  It's also not a pattern i've seen
> elsewhere, which will likely limit its adoption.

If you like other people's patterns, have you considered borrowing the
"adverb" pattern from dbus-run-session, but with s/dbus-daemon/gpg-agent/
applied? Whether it addresses Ian's desired properties for dgit's
credentials handling or not (probably not), it's certainly a viable
model for running unit tests with a transient GPGHOME. I've found myself
wishing for this facility when dealing with Flatpak and OSTree; both of
those optionally sign the content you publish with them, and hence both
of those need some special gpg-agent handling if you're going to run
their unit tests without leaving stray processes.

dbus-run-session consists of: start a dbus-daemon --session; set the
environment for its other child to point to that dbus-daemon; run its
remaining argv as a child process; when the other child exits, terminate
the dbus-daemon and exit with the other child's exit status.

In particular, I've been encouraging dbus-run-session as a replacement
for unit tests' (ab)uses of dbus-launch, which is a complicated "do what
I mean" dbus-daemon-starter for X11, and as a result doesn't implement
any of its various purposes particularly well.

S

Bug#840687: [pkg-gnupg-maint] Bug#840687: gnupg: Fails to sign git commits

[Daniel Kahn Gillmor]

Control: forwarded 840687 https://bugs.gnupg.org/gnupg/issue2758
Control: retitle 840687 gpg does not cope well with long passphrases

On Fri 2016-10-14 03:29:34 -0400, Josef Vítů wrote:

> thanks for your prompt reply. The test setup worked just fine, but
> after debugging gpg-agent as you suggested (with a higher debug-level,
> though) I know where the problem is. Attaching the log is pointless I
> think, as the critical line is clearly here:
>
> DBG: chan_10 -> SETERROR Passphrase too long (try 2 of 3)
>
> Looks like pinentry cannot handle passwords longer than 255 ASCII
> characters (at least in my case), and there's even an abandoned bug
> report about that, so maybe I should move there?
>
> https://bugs.gnupg.org/gnupg/issue1592

ah yes, sounds like you've found the issue.  I'm retitling this bug
report, because gpg should at least tell you that it doesn't like the
length of your passphrases, rather than leaving it to fail mysteriously.

there's also:

   https://bugs.gnupg.org/gnupg/issue2038

I've also just done some additional experimentation with ultra-long
passphrases and the result is this additional upstream bug report:

   https://bugs.gnupg.org/gnupg/issue2758

fwiw, i don't think you should need more than 128 characters or so for a
really strong passphrase (plain english is about 1 bit of entropy per
character, and passphrases longer than 128 bits of entropy are probably
pointless), and gpg's limits are supposed to be ~256 characters.

But still, gpg should make those limits much more clear to the user.

--dkg


signature.asc
Description: PGP signature

Bug#840779: /usr/sbin/update-pepperflashplugin-nonfree: Fail to update

[Spanky]

Package: pepperflashplugin-nonfree
Version: 1.8.1+deb8u1
Severity: important
File: /usr/sbin/update-pepperflashplugin-nonfree

latest stable version still fails



-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages pepperflashplugin-nonfree depends on:
ii  binutils   2.25-5
ii  ca-certificates20141019+deb8u1
ii  debconf [debconf-2.0]  1.5.56
ii  gnupg  1.4.18-7+deb8u3
ii  libatk1.0-02.14.0-1
ii  libcairo2  1.14.0-2.1+deb8u1
ii  libcurl3-gnutls7.38.0-4+deb8u4
ii  libfontconfig1 2.11.0-6.3+deb8u1
ii  libfreetype6   2.5.2-3+deb8u1
ii  libgcc11:4.9.2-10
ii  libglib2.0-0   2.48.0-1~bpo8+1
ii  libgtk2.0-02.24.25-3+deb8u1
ii  libnspr4   2:4.12-1+debu8u1
ii  libnss32:3.26-1+debu8u1
ii  libpango-1.0-0 1.36.8-3
ii  libpango1.0-0  1.36.8-3
ii  libstdc++6 4.9.2-10
ii  libx11-6   2:1.6.2-3
ii  libxext6   2:1.3.3-1
ii  libxt6 1:1.1.4-1+b1
ii  wget   1.16-1+deb8u1

pepperflashplugin-nonfree recommends no packages.

Versions of packages pepperflashplugin-nonfree suggests:
ii  chromium   53.0.2785.143-1~deb8u1
ii  hal0.5.14-8
ii  ttf-dejavu 2.34-1
ii  ttf-mscorefonts-installer  3.6
pn  ttf-xfree86-nonfree

-- no debconf information

Bug#840781: sddm: Missing option to choose window maker

[Helge Kreutzmann]

Package: sddm
Version: 0.13.0-1
Severity: important

Until the last update sddm (which I assume is the successor to kdm
which I used on stable) was enabling users to choose the window
manager of choice. Unfortunately, this was not automatic.

This is no longer the case, i.e. all users are "stuck" with the window
manager last used before the update.

In my use case my wife uses plasma, while I'm using window maker. Now
we both use window maker.

Or is there another x session manager more suited for multi user (and
multi preference users) systems?

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.5samd.10-grsec (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sddm depends on:
ii  adduser 3.115
ii  debconf [debconf-2.0]   1.5.59
ii  libc6   2.24-3
ii  libgcc1 1:6.1.1-11
ii  libpam0g1.1.8-3.3
ii  libqt5core5a5.6.1+dfsg-3+b1
ii  libqt5dbus5 5.6.1+dfsg-3+b1
ii  libqt5gui5  5.6.1+dfsg-3+b1
ii  libqt5network5  5.6.1+dfsg-3+b1
ii  libqt5qml5  5.6.1-11
ii  libqt5quick55.6.1-11
ii  libstdc++6  6.1.1-11
ii  libsystemd0 231-9
ii  libxcb-xkb1 1.12-1
ii  libxcb1 1.12-1
ii  qml-module-qtquick2 5.6.1-11
ii  sddm-theme-breeze [sddm-theme]  4:5.8.0-1

Versions of packages sddm recommends:
ii  libpam-systemd  231-9

Versions of packages sddm suggests:
ii  libpam-kwallet5  5.8.0-1

-- debconf information:
* shared/default-x-display-manager: sddm
  sddm/daemon_name: /usr/bin/sddm

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#840429: Please explain " Packages should not build-depend on this package. "

[Sven Joachim]

On 2016-10-11 16:34 +0200, Ailin Nemui wrote:

> Package: libtinfo-dev
> Version: 6.0+20160917-1
>
> I need libtinfo.so and stumbled upon this sentence in the description.
> It is bad for 2 reasons - no explanation given - no suggested action.
>
> My guess is to depend on ncurses, but why if I only need tinfo?

Because libtinfo-dev does not contain any header files, so you will need
libncurses5-dev (or libncursesw5-dev, but its header files are in
/usr/include/ncursesw, so you have to take some action to find them).
See the discussion in https://bugs.debian.org/644426 for some
background.

Cheers,
   Sven

Bug#840546: CVE-2016-7966 kdepimlibs jessie

[Moritz Muehlenhoff]

On Fri, Oct 14, 2016 at 08:23:04PM +0200, Sandro Knauß wrote:
> Hey,
> 
> I now back ported the second part of the fix of the CVE. I updated the 
> version 
> deb8u1 from Scott. Should I create a deb8u2 for the additional patch?
> 
> I attached the uptodate debdiff.

Thanks, please upload.

Cheers,
Moritz

Bug#840669: [pkg-gnupg-maint] Bug#840669: Beware of leftover gpg-agent processes (was: Re: Changes for GnuPG in debian)

[Daniel Kahn Gillmor]

On Fri 2016-10-14 13:17:06 -0400, Ian Jackson wrote:
> This (and the change to gnupg2) has now broken dgit's DEP-8 test
> suite, when run under schroot.  I'm discussing this in #840669 (CC'd).

in particular, the lack of a cleanup process breaks the test suite.  If
the test suite had a cleanup process, we know exactly how to "un-break"
things.

> I am trying to persaude Daniel that we should provide (at least
> optionally) a mode where an autostarted agent (and the corresponding
> authorisations, if the user types in a passphrase) have a lifetime
> limited by that of the gpg process which started the agent.

fwiw, i'm not the person who needs persuading.  Ian's proposal is rather
complex, seems likely to introduce new problems, and it isn't a change
i'm up for either writing myself or supporting as a divergence from
GnuPG upstream.

The simple fix (cleaning up the test suite by eithe deleting the
temporary GNUPGHOME directory or by invoking "gpgconf --kill gpg-agent")
is a lot more straightforward.

Alternately, if schroot was to run under a session management supervisor
like systemd, then the session manager could take care of both launching
and terminating the agent as needed.

--dkg


signature.asc
Description: PGP signature

Bug#840669: [pkg-gnupg-maint] Bug#840669: Bug#840669: Need way to avoid agent, or reliable way to kill agent

[Werner Koch]

On Fri, 14 Oct 2016 19:14, ijack...@chiark.greenend.org.uk said:

>  3. Concurrent access to the private key database by different
> agents is not safe.  (gnupg2 design decison; I think gnupg1 uses
> locks)

It is safe.  There are no locks for the private key files, last writer
wins.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpxl0NZdF_KK.pgp
Description: PGP signature

Bug#840669: [pkg-gnupg-maint] Bug#840669: Bug#840669: Need way to avoid agent, or reliable way to kill agent

[Werner Koch]

On Fri, 14 Oct 2016 18:58, d...@fifthhorseman.net said:

> agreed, that's why i'm encouraging upstream to fix their inotify
> detection:
>
>https://bugs.gnupg.org/gnupg/issue2756

I'll look at this next week.  I guess the problem is that we watch the
directory for inotify events of the socket file (because socket files
don't work with inotify) but if the directory is gone we won't receive
the notification.  The fix would be easy but that might reflect on the
Unix ability to keep working with file descriptors of unlinked file.  I
don't think this will be a problem , though.

>> Then perhaps it should take a lock.  I assume there must be some kind
>> of locking anyway, or concurrent startups would occasionally fail.
>
> I'll let Werner (who i hope is reading this) answer whether locking is
> actually happening and what these tradeoffs might be.  I'd be pretty

Yes, there are lock files during the starting of the agent and other
daemons.

> instructions that say "if you're dealing with gpg secret key material in
> a test suite, here's what we recommend you do".

Which could be as simple as: Do what GnuPG does in its test suite.


Salam-Shalom,

   Werner


p.s.
ian: we are still waiting for the torified ADNS.
-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpXp2Qt25On8.pgp
Description: PGP signature

Bug#839941: whishlist ffmpeg

[Andreas Cadhalpun]

Hi Marc,

On 07.10.2016 11:01, Struminski, Marc wrote:
> I compiled ffmpeg with ‹enable-decklink without nonfree.
> All you need are the header files.

>From where did you get these headers?

Best regards,
Andreas

Bug#840669: [pkg-gnupg-maint] Bug#840669: Beware of leftover gpg-agent processes

[Werner Koch]

On Fri, 14 Oct 2016 19:17, ijack...@chiark.greenend.org.uk said:

> authorisations, if the user types in a passphrase) have a lifetime
> limited by that of the gpg process which started the agent.

In a new temp directory do:

 GNUPGHOME=$(pwd) gpg-agent --daemon gpg .

Or whatever you want to run under gpg-agent's control.  This has been
there for ages.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpT9WrAxFnT7.pgp
Description: PGP signature

Bug#840768: [Pkg-opencl-devel] Bug#840768: Bug#840768: beignet-dev: arch-dependent files in "Multi-Arch: same" package

[Rebecca N. Palmer]

Control: tags -1 patch

It's the documentation timestamp added by ikiwiki: while this is
the file timestamp not the build time, some of these files are
modified by debian/patches.

This should fix it, but has not yet been tested:

--- a/debian/rules
+++ b/debian/rules
@@ -27,7 +27,7 @@ override_dh_auto_configure:
 #Include the test suite and the documentation
 override_dh_auto_build:
dh_auto_build
-   ikiwiki --verbose --no-usedirs --underlaydir docs --plugin map 
--rebuild docs docs_build
+   ikiwiki --verbose --no-usedirs --underlaydir docs --plugin map 
--rebuild --timeformat "`dpkg-parsechangelog -SDate`" docs docs_build
rm -rf docs_build/ikiwiki
 
 override_dh_gencontrol:

Bug#840782: gnulib: please demote unnecessary dependencies to recommends

[Helmut Grohne]

Package: gnulib
Version: 20140202+stable-2
Severity: wishlist

gnulib has a long list of dependencies. Most of them look like they are
not actually required for using check-module or gnulib-tool. For
instance, gnulib-tool seems to work just fine without bison or gperf.

Looking at gnulib-tool, it seems like none of the dependencies is
required to run it. Would it be sensible to just move all (or most) of
them from Depends to Recommends?

The actual need behind that suggestion is that gnulib currently cannot
satisfy other packages' cross build dependencies, because it is not
marked Multi-Arch: foreign. As long as it depends on build-essential or
bison[1], it cannot be marked such. After demoting those dependencies to
Recommends, it can be marked.

Helmut

[1] bison is currently wrongly marked Multi-Arch: foreign.

Bug#840762: motif: Please update to newest upstream release 2.3.6

[Joachim Wiedorn]

Hello Graham, 

Graham Inggs wrote on 2016-10-14 17:27:

> Paul and I discussed this recently, and we would prefer to stick with
> 2.3.4 plus patches for Stretch.  We believe 2.3.4-11 includes all of
> the bugfixes from 2.3.5 and 2.3.6 (and more!), but if we missed
> anything please file bug reports.

After I have tested the 'enable-utf8' or better 'disable-utf8' option
I see that utf8 was already enabled in you packages. I misunderstood some
lines in file configure.ac and enabled utf8 again.

> What is the reason for converting INCLUDES to AM_CPPFLAGS?  Have you
> submitted this upstream?

While running autoreconf many Makefile.am files printed following
warnings:

  warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')

So I have changed in all Makefile.am files to this newer name. 

---
Have a nice day.

Joachim (Germany)


pgp33jLsQ6I3l.pgp
Description: Digitale Signatur von OpenPGP

Bug#840669: [pkg-gnupg-maint] Bug#840669: Need way to avoid agent, or reliable way to kill agent

[Daniel Kahn Gillmor]

Hi Simon--

On Fri 2016-10-14 14:38:34 -0400, Simon McVittie wrote:
> If you like other people's patterns, have you considered borrowing the
> "adverb" pattern from dbus-run-session, but with s/dbus-daemon/gpg-agent/
> applied? Whether it addresses Ian's desired properties for dgit's
> credentials handling or not (probably not), it's certainly a viable
> model for running unit tests with a transient GPGHOME. I've found myself
> wishing for this facility when dealing with Flatpak and OSTree; both of
> those optionally sign the content you publish with them, and hence both
> of those need some special gpg-agent handling if you're going to run
> their unit tests without leaving stray processes.
>
> dbus-run-session consists of: start a dbus-daemon --session; set the
> environment for its other child to point to that dbus-daemon; run its
> remaining argv as a child process; when the other child exits, terminate
> the dbus-daemon and exit with the other child's exit status.

gpg-agent used to support this pattern explicitly:

gpg-agent run-my-test-suite

would have worked fine and behaved as you describe.  fwiw, OpenSSH's
ssh-agent can do the same thing.  We used the same pattern for the
monkeysphere validation agent in msva-perl.

However, since gpg-agent's move to the standard socket location, this
pattern isn't working any more.  Any process which shares a GNUPGHOME
with another process will also share an agent with it.

If you see a way to restore that behavior, i'd certainly be interested.
It might help, perhaps, if there were a standard way for gpg to know to
use a different gpg-agent explicitly.

This has also been discussed tangentially in an upstream bug report,
fwiw: https://bugs.gnupg.org/gnupg/issue2749

--dkg


signature.asc
Description: PGP signature

Bug#840140: fastx-toolkit: please make the build reproducible

[Sascha Steinbiss]

Hi Chris,

thanks for the report. I just took a look at the patch and now it seems that 
there are no man pages built for fasta_clipping_histogram.pl and 
fastx_barcode_splitter.pl at all any more, is that intentional?

Cheers
Sascha

On Sat, 08 Oct 2016 20:28:18 +0100 Chris Lamb  wrote:
> Source: fastx-toolkit
> Version: 0.0.14-1
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: buildpath
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Hi,
> 
> Whilst working on the Reproducible Builds effort [0], we noticed
> that fastx-toolkit could not be built reproducibly.
> 
> Patch attached.
> 
> I ended up patching upstream sources instead of fixing/extending the
> regexes in debian/rules; the result is subjectively far cleaner and
> objectively less brittle.
> 
> 
>  [0] https://reproducible-builds.org/
> 
> 
> Regards,
> 
> -- 
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

Bug#840669: [pkg-gnupg-maint] Bug#840669: Bug#840669: Need way to avoid agent, or reliable way to kill agent

[Daniel Kahn Gillmor]

On Fri 2016-10-14 15:11:39 -0400, Werner Koch wrote:
> On Fri, 14 Oct 2016 18:58, d...@fifthhorseman.net said:
>> instructions that say "if you're dealing with gpg secret key material in
>> a test suite, here's what we recommend you do".
>
> Which could be as simple as: Do what GnuPG does in its test suite.

I don't think it's fair for us to expect people writing projects which
rely on GnuPG (possibly with languages and entirely different
toolchains) to read the full GnuPG test suite and understand its
architectural details and design.  The GnuPG test suite is also
*building* gpg-agent and gpg (likely on systems that already have gpg
and gpg-agent installed), so it's not obvious that the testing behavior
would be the same.

A one- or two-paragraph document that explains the recommendation for
external projects, in English, coming from the official GnuPG project
would be much more helpful in setting reasonable expectations.

--dkg


signature.asc
Description: PGP signature

Bug#840685: TOCTOU race condition in initscript on chown'ing JVM_TMP temporary directory (was: Re: Bug#840685: tomcat8: DSA-3670 incomplete)

[Salvatore Bonaccorso]

Hi Paul,

Markus followed already up, I just want to give some additional
comments on the below:

On Fri, Oct 14, 2016 at 07:07:52PM +1100, paul.sz...@sydney.edu.au wrote:
> Dear Salvatore,
> 
> > ... if the attacher created a symlink between the rm and the mkdir
> > then mkdir will still fail with -p on a symlink.  (Or do I miss
> > something?). ...
> 
> Yes, you missed a simple test:
> 
> $ mkdir mydir
> $ ln -s mydir mylink
> $ ls -ld my*
> drwx-- 2 psz amstaff 4096 Oct 14 18:46 mydir
> lrwxrwxrwx 1 psz amstaff5 Oct 14 18:46 mylink -> mydir
> $ mkdir -p mylink || echo failed
> $ mkdir -p mylink; echo $?
> 0
> $ mkdir mylink || echo failed
> mkdir: cannot create directory `mylink': File exists
> failed
> $ mkdir mylink; echo $?
> mkdir: cannot create directory `mylink': File exists
> 1
> $ ls -ld my*
> drwx-- 2 psz amstaff 4096 Oct 14 18:46 mydir
> lrwxrwxrwx 1 psz amstaff5 Oct 14 18:46 mylink -> mydir
> $ 
> 
> showing that "mkdir -p" does not fail (but plain mkdir does).

You are doing all the tests with the same user. But yes mkdir -p will
succeed for the root user still in some cases. Let's recapitulate your
described attack. The attacker has shell-access on the tomcat8 running
host or by other mean can run code on the server by an unprivileged
user and used inotify to detect when $JVM_TMP will be removed.

Let's say the tomcat8 service is started.

JVM_TMP=/tmp/tomcat8-tomcat8-tmp

# rm -rf "$JVM_TMP".

With inotify the evil user detects, that /tmp/tomcat8-tomcat8-tmp got
removed and has several options for proceeding. Either create a
directory, or directly a malicious symlink. 

evil@jessie:~$ ln -s /etc/passwd /tmp/tomcat8-tomcat8-tmp
evil@jessie:~$ ls -l /tmp/tomcat8-tomcat8-tmp 
lrwxrwxrwx 1 evil evil 11 Oct 14 20:20 /tmp/tomcat8-tomcat8-tmp -> /etc/passwd
evil@jessie:~$

raced before root will issue the mkdir -p call:

root@jessie# mkdir -p /tmp/tomcat8-tomcat8-tmp 
mkdir: cannot create directory ‘/tmp/tomcat8-tomcat8-tmp’: File exists
root@jessie# echo $?
1
root@jessie#

if the evil user instead created a directory, then yes you are right
for that part:

evil@jessie$ mkdir -p /tmp/tomcat8-tomcat8-tmp
evil@jessie$ ls -ld /tmp/tomcat8-tomcat8-tmp
drwxr-xr-x 2 evil evil 4096 Oct 14 20:25 /tmp/tomcat8-tomcat8-tmp
evil@jessie$

followed by the root user

root@jessie# mkdir -p /tmp/tomcat8-tomcat8-tmp
root@jessie# echo $?
0
root@jessie#

If now the evil user wins again the race, and removes the directory in
time and replaces it with the symlink to a desired file to overwrite,
before the chown call of the root user:

evil@jessie$ rmdir /tmp/tomcat8-tomcat8-tmp
evil@jessie$ ln -s /etc/passwd /tmp/tomcat8-tomcat8-tmp
evil@jessie$ ls -l /tmp/tomcat8-tomcat8-tmp
lrwxrwxrwx 1 evil evil 11 Oct 14 20:28 /tmp/tomcat8-tomcat8-tmp -> /etc/passwd
evil@jessie$

root@jessie# chown tomcat8 /tmp/tomcat8-tomcat8-tmp
chown: cannot dereference ‘/tmp/tomcat8-tomcat8-tmp’: Permission denied
root@jessie# echo $?
1
root@jessie# ls -l /etc/passwd
-rw-r--r-- 1 root root 1631 Oct 14 20:07 /etc/passwd
root@jessie#

The same if the evil user created a symlink to a existing directory:

evil@jessie$ ln -sf /etc /tmp/tomcat8-tomcat8-tmp
evil@jessie$ ls -l /tmp/tomcat8-tomcat8-tmp
lrwxrwxrwx 1 evil evil 4 Oct 14 21:01 /tmp/tomcat8-tomcat8-tmp -> /etc
evil@jessie$

root@jessie# mkdir -p /tmp/tomcat8-tomcat8-tmp
mkdir: cannot create directory ‘/tmp/tomcat8-tomcat8-tmp’: File exists
root@jessie#

root@jessie# chown tomcat8 /tmp/tomcat8-tomcat8-tmp 
chown: cannot dereference ‘/tmp/tomcat8-tomcat8-tmp’: Permission denied
root@jessie#

because of the kernel hardening.

> > On the practicality for Debian systems though this is mitigated by the
> > Kernel hardenings which are enabled by default:
> > 
> > fs.protected_hardlinks=1
> > fs.protected_symlink=1
> > 
> > which will prevent that the target of the symlink in /tmp will be
> > changed on the chown call.
> 
> Another missing test (besides: who is changing anything?):
> 
> # grep . /proc/sys/fs/prot*
> /proc/sys/fs/protected_hardlinks:1
> /proc/sys/fs/protected_symlinks:1
> # cd ~psz
> # ls -ld my*
> drwx-- 2 psz amstaff 4096 Oct 14 18:46 mydir
> lrwxrwxrwx 1 psz amstaff5 Oct 14 18:46 mylink -> mydir
> # chown mike mylink
> # ls -ld my*
> drwx-- 2 mike amstaff 4096 Oct 14 18:46 mydir
> lrwxrwxrwx 1 psz  amstaff5 Oct 14 18:46 mylink -> mydir
> # 

You are operating here outside of /tmp (sticky world-writable
directory) which the above issue for the init scripts relies on,
right?  fs.protected_(hardlinks|symlinks) is exactly a hardening for
those issues:

https://www.kernel.org/doc/Documentation/sysctl/fs.txt
https://sources.debian.net/src/linux/3.16.36-1%2Bdeb8u1/Documentation/sysctl/fs.txt/#L205

In the release notes such issues are not treated as security-issues
anymore since:

https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#security


> > So while I think it should be fixed, this would not warrant a DSA,
> > since