Bug#924623: golang: Both golang and dep are very out of date

[Nye Liu]

Package: golang
Version: 2:1.11~1
Severity: important

Golang and dep are both very out of date. This causes quite a bit of problems
with dep in particular.

If you share repos between debian and non-debian systems (e.g. macos), the
Gopkg.lock file format switches back and forth between trailing commas in the
last item of an array to no trailing commas.

This makes diff/merge thrashing a huge pain.

Please keep both golang and dep at least more or less up to date in a
timely fashion.

The only real workaround is `go get github.com/golang/dep`,
`go install ./cmd/dep`

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.16-x86_64-linode118 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages golang depends on:
ii  golang-1.11  1.11.5-1
ii  golang-doc   2:1.11~1
ii  golang-go2:1.11~1
ii  golang-src   2:1.11~1

golang recommends no packages.

golang suggests no packages.

-- no debconf information

Bug#922938: RFS: python-css-parser/1.0.4-1~bpo9+1

[Nicholas D Steeves]

On Thu, Mar 14, 2019 at 10:14:26PM -0400, Chris Lamb wrote:
> Hi Nicholas,
> 
> > Done.  Updated backport available here:
> 
> Thanks:
> 
> $ dput python-css-parser_1.0.4-1\~bpo9+1_amd64.changes
> Uploading python-css-parser using scp to ssh-upload (host: 
> ssh.upload.debian.org; directory: /srv/upload.debian.org/UploadQueue/)
> running allowed-distribution: check whether a local profile permits 
> uploads to the target distribution
> running protected-distribution: warn before uploading to distributions 
> where a special policy applies
> running checksum: verify checksums before uploading
> running suite-mismatch: check the target distribution for common errors
> running gpg: check GnuPG signatures before the upload
> SCP is deprecated. Please consider upgrading to SFTP.
> Uploading python-css-parser_1.0.4-1~bpo9+1.dsc
> Uploading python-css-parser_1.0.4-1~bpo9+1.debian.tar.xz
> Uploading python-css-parser_1.0.4-1~bpo9+1_all.deb
> Uploading python-css-parser_1.0.4-1~bpo9+1_amd64.buildinfo
> Uploading python3-css-parser_1.0.4-1~bpo9+1_all.deb
> Uploading python-css-parser_1.0.4-1~bpo9+1_amd64.changes
> 

Thank you Chris!  'wish it would have been possible to have it ready
for Boxing Day ;-)

Sincerely,
Nicholas


signature.asc
Description: PGP signature

Bug#924606: skimage: autopkgtest needs update for new version of python-scipy: ValueError: No warning raised matching: matrix subclass

[Drew Parsons]

Source: skimage
Followup-For: Bug #924606

The skimage tests are doing something passing strange, if they're
giving an error when a Warning is no longer emitted.

Anyway, thanks for uploading the patch that sorts it out, Ole.

Drew

Bug#924614: CVE-2018-20536 CVE-2018-20537 CVE-2018-20539

[Sebastiaan Couwenberg]

With libLAS being deprecated and in maintenance mode upstream, it will
take some time to get fixes from upstream unless someone contributes them.

Once the fixes are available they'll be added to the Debian package.

During the bullseye development cycle liblas is likely to be removed
from Debian, once grass & pktools stop using it.

Kind Regards,

Bas

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

Bug#924398: corekeeper can be confused with whitespace in executable names

[Paul Wise]

On Wed, 13 Mar 2019 16:41:02 +0100 Jakub Wilk wrote:

> We could append or prepend a character to %d to make sure the argument 
> won't disappear after %-expansion, for example:

I decided to just check if the arguments are integers, attached the patch.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

From 2d32c124ec8687e353fc32950d2d719fac0f671d Mon Sep 17 00:00:00 2001
From: Paul Wise 
Date: Wed, 13 Mar 2019 14:15:00 +0800
Subject: [PATCH 02/11] Handle older versions of the Linux kernel in a safer
 way

The Linux kernel does argument splitting after parameter expansion,
leading to an attacker on old kernels being able control the owner
variable, leading to the creation of bogus root-owned directories.

Fixes: https://bugs.debian.org/924398
---
 debian/changelog |  2 ++
 debian/dump  | 17 ++---
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 8916e17..c86672b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,8 @@ corekeeper (1.7) UNRELEASED; urgency=medium
 
   * Do not use a world-writable /var/crash with the dumper script
 (Closes: #924397)
+  * Handle older versions of the Linux kernel in a safer way
+(Closes: #924398)
 
  -- Paul Wise   Wed, 13 Mar 2019 14:09:50 +0800
 
diff --git a/debian/dump b/debian/dump
index e8fc3fd..a0230e6 100644
--- a/debian/dump
+++ b/debian/dump
@@ -28,15 +28,26 @@ if [ "$(id -u)" != "0" ]; then
 	exit 1
 fi
 
-# Check how many arguments the kernel sent us.
-if [ $# -eq 2 ] ; then
+# Check if the first two arguments are numeric
+case "$1" in
+	(*[!0-9]*|'') num_1=1;;
+	(*)   num_1=0;;
+esac
+
+case "$2" in
+	(*[!0-9]*|'') num_2=1;;
+	(*)   num_2=0;;
+esac
+
+# Check how many numeric arguments the kernel sent us.
+if [ "$num_1" -eq 1 ] && [ "$num_2" -eq 0 ] ; then
 	# Awww, old kernel that does not support %d
 	# Cannot set the core file owner safely, use root
 	# See v3.6-6800-g12a2b4b in linux.git for more info
 	uid="$1"
 	core="$2"
 	owner="0"
-elif [ $# -eq 3 ] ; then
+elif [ "$num_1" -eq 1 ] && [ "$num_2" -eq 1 ] ; then
 	# Yay! A kernel that does support %d
 	uid="$2"
 	core="$3"
-- 
2.20.1



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

Bug#924622: Can the disabling of AppArmor upon removal of its userland tools be made simpler and more complete?

[Nathan Howard]

Package: apparmor
Severity: wishlist

Removal of AppArmor from the userland leaves a moreso unexpected kernel
side completely enabled and functioning.  So, upon AppArmor's package
removal is it possible to either:

(1) Automate some of the following from
https://wiki.debian.org/AppArmor/HowToUse#Disable_AppArmor

  $ sudo mkdir -p /etc/default/grub.d
  $ echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT
apparmor=0"' | sudo tee /etc/default/grub.d/apparmor.cfg
  $ sudo update-grub
  $ sudo reboot (Perhaps a splash screen displayed (similar to that done
upon selinux's installation)--reminding the user that a system reboot is
required?)

(2) Simply display a splash screen with the remaining steps needed should
the user want to complete the removal themselves.

A related discussion is in bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702030.

Bug#914515: dpkg: please provide an interface to bootstrap dpkg from zero

[Guillem Jover]

Hi!

On Sat, 2018-11-24 at 10:24:09 +0100, Johannes 'josch' Schauer wrote:
> Package: dpkg
> Version: 1.19.2
> Severity: wishlist

> lintian recently tagged mmdebstrap with uses-dpkg-database-directly
> because mmdebstrap contains the string "/var/lib/dpkg" in several
> places. Instead of overwriting the lintian tag in mmdebstrap, dpkg could
> also gain an interface which avoids mmdebstrap having to do anything
> with /var/lib/dpkg inside the chroot. Specifically, what mmdebstrap does
> is the following:
> 
>  - create /var/lib/dpkg, /var/lib/dpkg/triggers, /var/lib/dpkg/info,
>/var/lib/dpkg/alternatives and /var/lib/dpkg/updates because dpkg
>throws an error if these directories are not present

Right, will handle those.

>  - an empty /var/lib/dpkg/status because dpkg refuses to work without
>the file being present

I've fixed this one now in a local next/bootstrap branch which I'll
push out tomorrow-

>  - adds architectures to /var/lib/dpkg/arch because $(dpkg
>--add-architecture) doesn't work without any packages inside the
>chroot

This sould already work when passing --root= or --admindir=, it should
even work w/o being root. :)

>  - cleans up leftover /var/lib/dpkg/lock-frontend and /var/lib/dpkg/lock

As mentioned on IRC, this should not be necessary, these are
range-locks, and they work not based on their presence, but whether
they process has acquired locks within them.

Thanks,
Guillem

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Guillem Jover]

Hi!

On Fri, 2019-03-15 at 00:37:33 +0100, Santiago Vila wrote:
> Maybe, but this is neither a new miscellaneous file nor a new
> bootstrapping action. This is yet another bootstrapping tool
> forgetting the lessons learned from the other bootstrapping tools.

My impression though is that the general consensus is that the
lessons learned from the traditional bootstrapping tools, is that
they are doing it wrong. :)

> Helmut Grohne wrote:
> > How is a bootstrap tool supposed to know
> > that it must configure base-passwd before base-files?
> 
> In a theoretical level, because it's their job to know such things.

As it's been mentioned elsewhere, this is not a property that is
necessary. In the same way that bootstrapping an architecture should
not require manually tracking the order of the build-dependencies
and cycle breakings (which was the case before), etc, even if that
might still be partially the case now, while we have not fully added
build profiles and cross-building support everywhere necessary.

> In a practical level, because you already see what happens when
> you configure any package which uses users defined in /etc/passwd
> without a minimal /etc/passwd in place. Again in a practical level,
> once we know it, we can't pretend that we don't know it.

That's what the traditional bootstrapping tools have been doing, and
it's all kinds of wrong. For example whether a system even uses an
/etc/passwd is an implementation detail of that system. Some don't
even have one. If we added support for such a port, then in addition
to patching the relevant code that directly deals with this, we'd
need to also adapt all the bootstrappers to cope with this. Instead
of them just automatically just working out of the box, w/o needing
to hardcode package names, internal implementation details, etc.

> You want to create a common framework to reuse such knowledge and
> share it between different bootstrapping tools? Fine, maybe then new
> bootstrapping tools finally realize that there must be a valid
> /etc/passwd before configuring anything else.

That knowledge is already in each relevant package, the passwd stuff
in the base-passwd package (in Debian) or possibly elsewhere in other
systems.

> But lack of such a common framework is not an excuse to ditch the
> definition of essential and start doing things "just in case"
> some new bootstrapping tool forgets again that there must
> be a valid /etc/passwd before configuring anything else.

You seem to keep using the definition of essential to justify this,
but as I've mentioned elsehwere, the definition of essential does not
cover what happends before the system has been bootstrapped. If we'd
consider that policy already covers it, that would mean most essential
packages are RC buggy.

(And as I've mention on another reply, dpkg f.ex. is already falling
back to numeric UIDs "just in case". :)

> Please reassign to whatever bootstrapping tool is not doing its job
> properly. Sorry, but this is starting to annoy me.

I'm sorry to hear, but TBH, I'm a bit puzzled about your replies. That
might be due to the apparent conflation of trying to look for a better
solution to the problem presented, and how to incrementally transition
to such a bettter place smoothly already right now?

It's not clear to me whether you oppose the discussion about such
proposals because you consider the current bootstrapping method the
ideal solution, or whether you oppose any progressive move towards
those, as in an all or nothing scenario?

Thanks,
Guillem

Bug#924116: lintian: false positive of package-uses-dh-runit-...

[Chris Lamb]

Dmitry Bogatov wrote:

> > Can you be more specific? That would appear to catch runit itself, at
> > the very least. How about if a package ships a file matching the
> > following scheme?
> >
> >/etc/sv/foo/run
> 
> Well, package can ship /etc/sv/foo/run without dh_runit.

Of course, but those won't --with runit or have a manual call to
dh_runit, right?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#883746: chromium: secretly stores referer and url for downloaded files

[Ken Yap]

I've been asked where wget stores the URL. Same place as Chromium, in the 
extended attributes. Here is my blog entry recounting my small investigation:

https://green-possum-today.blogspot.com/2018/09/chromechromium-is-storing-url-and.html

Bug#924621: openssl 1.1.1b-1 make fetchmail unusable

[Atsuhito Kohda]

Package: openssl
Version: 1.1.1b-1
Severity: important

Dear Maintainer,

I updated openssl 1.1.1a-1 to 1.1.1b-1 then fetchmail failed
to get new email.
So I downgraded openssl to 1.1.1a-1 then fetchmail worked
fine again.
I believe there is a bug in openssl 1.1.1b-1 .
I heard that new Debian will be released soon so please
fix the problem before the new release.

A bit precise info:
I upgraded openssl on both server and local macheines.
Then the problem happened so, first, I downgraded openssl
on local machine but the problem remained. So I downgraded
openssl on server machine then fetchmail worked fine.

Thanks for your maintenance.
Best regards,   2019-3-15(Fri)

Atsuhito Kohda

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), 
LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openssl depends on:
ii  libc6  2.28-8
hi  libssl1.1  1.1.1a-1

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20190110

-- no debconf information

Bug#924611: vtk7: please add support for riscv64

[Paul Wise]

On Fri, Mar 15, 2019 at 5:39 AM Aurelien Jarno wrote:

> The attached patch is a backport from the upstream changes. It would be
> nice if you can include it in the next upload.
> ++#elif defined(__riscv) || defined(__riscv__)
> ++# define KWIML_ABI_ENDIAN_ID KWIML_ABI_ENDIAN_ID_LITTLE

Hmm, shouldn't vtk be using the predefined macros for this?

https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#922938: RFS: python-css-parser/1.0.4-1~bpo9+1

[Chris Lamb]

Hi Nicholas,

> Done.  Updated backport available here:

Thanks:

$ dput python-css-parser_1.0.4-1\~bpo9+1_amd64.changes
Uploading python-css-parser using scp to ssh-upload (host: 
ssh.upload.debian.org; directory: /srv/upload.debian.org/UploadQueue/)
running allowed-distribution: check whether a local profile permits uploads 
to the target distribution
running protected-distribution: warn before uploading to distributions 
where a special policy applies
running checksum: verify checksums before uploading
running suite-mismatch: check the target distribution for common errors
running gpg: check GnuPG signatures before the upload
SCP is deprecated. Please consider upgrading to SFTP.
Uploading python-css-parser_1.0.4-1~bpo9+1.dsc
Uploading python-css-parser_1.0.4-1~bpo9+1.debian.tar.xz
Uploading python-css-parser_1.0.4-1~bpo9+1_all.deb
Uploading python-css-parser_1.0.4-1~bpo9+1_amd64.buildinfo
Uploading python3-css-parser_1.0.4-1~bpo9+1_all.deb
Uploading python-css-parser_1.0.4-1~bpo9+1_amd64.changes

 
Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#432088: pbuilder: please use APTCACHE on --create

[Hideki Yamane]

Hi,

 As Mattia pointed out, 
https://salsa.debian.org/pbuilder-team/pbuilder/merge_requests/6
 is the patch for it. Please review, test and merge it :)

-- 
Hideki Yamane 

Bug#924452: lam4-dev: mpi alternative incompatible with current openmpi, mpich

[Andreas Beckmann]

Followup-For: Bug #924452
Control: tag -1 patch

Hi,

attached is my attempt to modernize the alternatives (and clean up some
more bits). I've quickly tested upgrading in a chroot and it didn't
explode immediately.


Andreas
diff -Nru lam-7.1.4/debian/changelog lam-7.1.4/debian/changelog
--- lam-7.1.4/debian/changelog  2014-03-15 03:47:33.0 +0100
+++ lam-7.1.4/debian/changelog  2019-03-13 08:58:21.0 +0100
@@ -1,3 +1,17 @@
+lam (7.1.4-3.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Conflicts/Replaces against packages predating oldoldstable.
+  * Remove maintainer script code for upgrades from ancient versions.
+  * Convert to Multi-Arch.
+  * Add Breaks against openmpi/mpich using old-style mpi alternatives.
+  * Align mpi alternatives with openmpi/mpich.  (Closes: #924452, #922633)
+  * Support parallel build, thanks to Aron Xu.  (Closes: #721437)
+  * Switch to Priority: optional.
+  * Whitespace cleanup.
+
+ -- Andreas Beckmann   Wed, 13 Mar 2019 08:58:21 +0100
+
 lam (7.1.4-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
@@ -23,8 +37,8 @@
 
   * New upstream release
   * Bug fix: "typo in /etc/lam/lam-helpfile (hreq:timeout should be
-rhreq:timeout)", thanks to Sergio Gelato (Closes: #495182).  
-Applied hreq->rhreq in lam-helpfile 
+rhreq:timeout)", thanks to Sergio Gelato (Closes: #495182).
+Applied hreq->rhreq in lam-helpfile
   * Bug fix: "Suggest a specific ssh-client and ssh-server in Depends",
 thanks to Adam C Powell IV (Closes: #574002).  Dependencies modified
 to suggest openssh client/server.
@@ -100,7 +114,7 @@
 lam (7.1.2-1) unstable; urgency=low
 
   * New upstream release, Closes: #362168
-  * Accept NMU, Closes: #359118. Closes: #355245. 
+  * Accept NMU, Closes: #359118. Closes: #355245.
 Closes: #335721. Closes: #337843. Closes: #331881.
   * Update README.Debian, Closes: #360226
   * Add mpiexec to alternatives, Closes: #384065.
@@ -160,11 +174,11 @@
 
   * Non-maintainer upload.
   * share/boot/asc_run.c: Re-enable stdin for rank 0, accidently disabled in
-7.1.1.  Pulled from upstream revision 9923 of branch-7-1 
+7.1.1.  Pulled from upstream revision 9923 of branch-7-1
 (closes: #308554).
 
  -- Torsten Landschoff   Fri, 24 Jun 2005 22:16:52 +0200
-
+
 lam (7.1.1-3) unstable; urgency=high
 
   * Bug fix: "lam4-dev: /usr/include/lam/mpi++.h is a dangling symlink",
@@ -595,24 +609,24 @@
 
   * Updated upstream-shipped config.guess and config.sub to latest from
   automake (closing #55908)
-  * Included 6.3.1 changes to configure.in to make sure correct compile 
-  flags are used on all systems.  (Previously released binaries were 
+  * Included 6.3.1 changes to configure.in to make sure correct compile
+  flags are used on all systems.  (Previously released binaries were
   correctly compiled anyway.)
 
  -- Camm Maguire   Mon, 24 Jan 2000 14:31:25 -0500
 
 lam (6.3-6) unstable; urgency=low
 
-  * Moved sweep and manpage to lamsweep to avoid name conflict with 
+  * Moved sweep and manpage to lamsweep to avoid name conflict with
   geomview (closes #54699)
-  * Added upstream suggested #if !HAVE_IEEE_FP/#endif around all of 
+  * Added upstream suggested #if !HAVE_IEEE_FP/#endif around all of
   ieee.c to allow compilation on Debian sparc (closes #51871)
 
  -- Camm Maguire   Wed, 12 Jan 2000 16:47:00 -0500
 
 lam (6.3-5) unstable; urgency=low
 
-  * Moved priority to extra, in keeping with policy descriptions, and 
+  * Moved priority to extra, in keeping with policy descriptions, and
   to make dependency on rsh work
 
  -- Camm Maguire   Wed,  8 Dec 1999 15:58:37 -0500
@@ -630,8 +644,8 @@
 hcc,hcp,hf77,balky
   * Separated alternatives into devel set governed by mpi ->
 /usr/include/lam, and runtime set governed by mpirun ->
-/usr/bin/mpirun_lam 
-  * Removed libmpi.so.2 and libmpi++.so.2 from alternatives, 
+/usr/bin/mpirun_lam
+  * Removed libmpi.so.2 and libmpi++.so.2 from alternatives,
 as not used by system anyway
 
  -- Camm Maguire   Tue, 30 Nov 1999 13:59:51 -0500
@@ -838,10 +852,6 @@
   * debian/rules sets config link back to sparc on clean
   * debian/rules sets config link to linux on build
   * Lam home set to /usr/lib/lam
-  * 
-  * 
   * Initial Release.
 
  -- Camm Maguire   Tue, 15 Dec 1998 17:48:49 -0500
-
-
diff -Nru lam-7.1.4/debian/control lam-7.1.4/debian/control
--- lam-7.1.4/debian/control2014-03-15 03:45:39.0 +0100
+++ lam-7.1.4/debian/control2019-03-13 08:58:21.0 +0100
@@ -1,30 +1,38 @@
 Source: lam
 Section: devel
-Priority: extra
+Priority: optional
 Maintainer: Camm Maguire 
-Build-Depends: debhelper (>= 
4.1.16),gfortran,texinfo,autotools-dev,help2man,libltdl-dev
+Build-Depends:
+ debhelper (>= 5),
+ gfortran,
+ texinfo,
+ autotools-dev,
+ help2man,
+ libltdl-dev,
 Standards-Version: 3.9.3
 
 Package: lam-mpidoc
 Section: doc
 Architecture: all
-Conflicts: mpi-doc
-Replaces: mpi-doc
 Depends: ${misc:Depends}
 

Bug#924397: corekeeper: insecure use of world-writable /var/crash

[Paul Wise]

On Thu, 2019-03-14 at 12:12 +0100, Jakub Wilk wrote:

> As a data point, apport creates /var/crash as world-writable in postinst:

Does apport use a core dump handler? If so it shouldn't need a world
writable directory since the core dump handler runs as root.

corekeeper and apport conflict so probably I can ignore this but I
guess you'll investigate and file a bug if needed?

> So I imagine there's software out there that assumes this directory has safe 
> permissions.

That is annoying, but for corekeeper the default is most of the time
(after I fix the bug) going to be safe permissions.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#924620: misbehaving guest can corrupt firmware image

[dann frazier]

Package: qemu-efi-aarch64
Version: 0~20181115.85588389-2
Severity: important

Buggy EFI apps[1] can corrupt the firmware flash volume by dereferencing
NULL pointers because we map the NOR flash at 0x0. Upstream has merged
patches to make these inadvertent accesses fault instead.

[1] For examples, see:
  https://bugs.launchpad.net/bugs/1811722
  https://bugs.launchpad.net/bugs/1811901
[2] 51bb05c795 ArmVirtPkg/QemuVirtMemInfoLib: trim the MMIO region mapping
5e27deed43 ArmVirtPkg/NorFlashQemuLib: disregard our primary FV
aa1097921d ArmPkg/ArmMmuLib ARM: handle unmapped sections when updating 
permissions
36a87fec68 ArmPkg/ArmMmuLib ARM: handle unmapped section in 
GetMemoryRegion()

Ubuntu version of this bug: https://bugs.launchpad.net/bugs/1812093

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-- no debconf information

Bug#924619: shim-signed,shim-helpers-amd64-signed: both ship /usr/lib/shim/fbx64.efi.signed

[Andreas Beckmann]

Package: shim-signed,shim-helpers-amd64-signed
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: found -1 1.28+nmu3+0.9+1474479173.6c180c6-1
Control: found -1 1+15+1533136590.3beb971+5

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package shim-unsigned.
  Preparing to unpack .../shim-unsigned_15+1533136590.3beb971-5_amd64.deb ...
  Unpacking shim-unsigned (15+1533136590.3beb971-5) ...
  Selecting previously unselected package shim-helpers-amd64-signed.
  Preparing to unpack 
.../shim-helpers-amd64-signed_1+15+1533136590.3beb971+5_amd64.deb ...
  Unpacking shim-helpers-amd64-signed (1+15+1533136590.3beb971+5) ...
  dpkg: error processing archive 
/var/cache/apt/archives/shim-helpers-amd64-signed_1+15+1533136590.3beb971+5_amd64.deb
 (--unpack):
   trying to overwrite '/usr/lib/shim/fbx64.efi.signed', which is also in 
package shim-signed 1.28+nmu3+0.9+1474479173.6c180c6-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   
/var/cache/apt/archives/shim-helpers-amd64-signed_1+15+1533136590.3beb971+5_amd64.deb


shim-helpers--signed for other architectures probably have the same 
problem.


cheers,

Andreas


shim-signed=1.28+nmu3+0.9+1474479173.6c180c6-1_shim-helpers-amd64-signed=1+15+1533136590.3beb971+5.log.gz
Description: application/gzip

Bug#924552: jquery-caret.js: Please provide node-jquery.caret and install package.json

[Ben Finney]

Control: retitle -1 jquery-caret.js: Please provide node-jquery.caret and 
install package.json

On 14-Mar-2019, Pirate Praveen wrote:
> I'd be happy to help implement this if you like.

Sure, I'd love for you to fork the repository
https://salsa.debian.org/debian/pkg-jquery-caret.js>
and propose a merge request that I can review.

Alternatively, I'd be happy with files attached to this bug report.

-- 
 \  “You say “Carmina”, and I say “Burana”, You say “Fortuna”, and |
  `\I say “cantata”, Carmina, Burana, Fortuna, cantata, Let's Carl |
_o__)the whole thing Orff.” —anonymous |
Ben Finney 


signature.asc
Description: PGP signature

Bug#924618: RFS: golang-github-kevinburke-ssh-config/0.5-1

[Dawid Dziurla]

Dear Go team,

I am looking for a sponsor for the package 
"golang-github-kevinburke-ssh-config".
This package is a prerequisite for upcoming package "lazygit" (#908894).

I pushed to our team's Salsa:

  https://salsa.debian.org/go-team/packages/golang-github-kevinburke-ssh-config

Could you please reviewing/sponsoring this?
Any kind of reviews and suggestions are appreciated.

Bug#912549: icedtea-web FTBFS with OpenJDK 11

[Matthias Klose]

On 14.03.19 23:03, Emmanuel Bourg wrote:
> 
> 
> On 13/03/2019 17:47, Matthias Klose wrote:
> 
>> please look at the new upstream 1.7.2 and 1.8 releases.
> 
> I got a quick look at these new versions released this week, IcedTea Web
> 1.7.2 is rather close to the version in unstable since October and has a
> few extra Java 9+ fixes, it's probably worth considering for Buster.

see https://launchpad.net/ubuntu/+source/icedtea-web/1.7.2-0ubuntu1
for a packaging proposal.

Bug#684134: Prezado usuário do Zimbra, Atualização do tamanho da caixa de correio.

[Atendimento IEL]

Prezado usuário do Zimbra,

Sua Caixa de Correio excedeu seu limite de armazenamento.Clique AQUI PARA 
DESBLOQUEAR,
Preencha e clique em ENVIAR para mais espaço ou você não poderá enviar e-mails.

De:
Equipe de helpdesk
Copyright © 2019 Inc

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

On Thu, Mar 14, 2019 at 10:37:46AM +, Simon McVittie wrote:
> On Thu, 14 Mar 2019 at 10:21:30 +0100, Santiago Vila wrote:
> > The reason I'm often asked to add hacks to base-files.postinst is only
> > that base-files is usually configured in the second place
> 
> I think it's also fair to say that base-files is exactly a collection of
> the miscellaneous files and bootstrapping actions that no other package
> seems particularly responsible for, so if a new miscellaneous file or a
> new bootstrapping action appears, base-files seems a reasonably natural
> home for it (or at least, more natural than a package that contains
> non-bootstrapping code, for example bash or debianutils).

Maybe, but this is neither a new miscellaneous file nor a new
bootstrapping action. This is yet another bootstrapping tool
forgetting the lessons learned from the other bootstrapping tools.

Helmut Grohne wrote:
> If we agree that this would be the best fix for buster, I volunteer to
> write a patch for base-files to implement that.

No, I do not agree, so please don't.

> How is a bootstrap tool supposed to know
> that it must configure base-passwd before base-files?

In a theoretical level, because it's their job to know such things.

In a practical level, because you already see what happens when
you configure any package which uses users defined in /etc/passwd
without a minimal /etc/passwd in place. Again in a practical level,
once we know it, we can't pretend that we don't know it.

You want to create a common framework to reuse such knowledge and
share it between different bootstrapping tools? Fine, maybe then new
bootstrapping tools finally realize that there must be a valid
/etc/passwd before configuring anything else.
 
But lack of such a common framework is not an excuse to ditch the
definition of essential and start doing things "just in case"
some new bootstrapping tool forgets again that there must
be a valid /etc/passwd before configuring anything else.

Please reassign to whatever bootstrapping tool is not doing its job
properly. Sorry, but this is starting to annoy me.

Thanks.

Bug#924618: ITP: golang-github-kevinburke-ssh-config -- Go parser for ssh_config files

[Dawid Dziurla]

Package: wnpp
Severity: wishlist
Owner: Dawid Dziurla 

* Package name: golang-github-kevinburke-ssh-config
  Version : 0.5-1
  Upstream Author : Kevin Burke
* URL : https://github.com/kevinburke/ssh_config
* License : Expat
  Programming Lang: Go
  Description : Go parser for ssh_config files

 ssh_config This is a Go parser for ssh_config files. Importantly,
 this parser attempts to preserve comments in a given file, so you can
 manipulate a ssh_config file from a program, if your heart desires.
 .
 It's designed to be used with the excellent x/crypto/ssh
 (https://golang.org/x/crypto/ssh) package, which handles SSH negotiation
 but isn't very easy to configure.

This package is in the dependency tree of Lazygit (#908894)

Bug#923891: Workaround Instructions

[Soren Stoutner]

As a temporary and messy workaround, you can download the upstream 
4.0.1-1 release from 
http://www.redmine.org/releases/redmine-4.0.1.tar.gz. Then replace the 
contents of the following two directories with those from the tarball.


/usr/share/redmine/app
/usr/share/redmine/public

I am all in favor of replacing the source-less, embedded (and outdated) 
jQuery files with links to system libraries.  But I also need Redmine to 
work in the meantime.  ;)


--
Soren Stoutner
Small Business Tech Solutions
623-262-6169
so...@smallbusinesstech.net

Bug#924617: update to new upstream (0.74)

[Gianluigi Tiesi]

Source: poppler
Severity: normal

I'm using calibre and I get a lot of problems when converting pdf files,
or files that use pdf as intermediate format.

the problem is fixed in this commit:


commit 903983bbd921a5139e3cd6de227b571870c764d8
Author: Greg Knight 
Date:   Sun Nov 25 15:47:18 2018 -0500

gooString::fromInt: Repair the return value.
formatInt renders from "right to left" and returns the position of
the most significant digit in 'p' - which is not generally equal to
'buf' in the case of GooString::fromInt (unless you're rendering a
24-digit number.)

This repairs several issues in pdftohtml


to fix my problem this commit is enough but I believe there are other
fixes too

Regards



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

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

Bug#917228: autofs: Orphaning package?

[Mike Gabriel]

Control: close -1

Hi,

On Mon, 24 Dec 2018 14:22:52 +0100 =?utf-8?Q?Manu_Al=C3=A9n?= 
 wrote:

> Source: autofs
> Hi,
>
> I have worked with autofs and although I’m going to take care of some 
packages more, I think that I could have a bit time to support it.

>
> Please do not hesitate to give me advices or extra information to 
take care of autofs package if it is still available

>
> Thanks in advance
> Best Regards
> Manu
>
> On Fri, 23 Dec 2016 10:39:41 +1100 Dmitry Smirnov 
 wrote:

> > Source: autofs
> > Severity: important
> > X-Debbugs-CC: 
wdau...@gmail.com,he...@pool.math.tu-berlin.de,m...@tls.msk.ru

> >
> > Dear co-maintainers,
> >
> > I have no capacity to look after "autofs" package. It seems like 
none of us
> > did any meaningful work on this package lately so I suggest either 
to orphan

> > it or start caring about it...
> >
> > Thanks.
> >
> > --
> > Best wishes,
> > Dmitry Smirnov
> > GPG key : 4096R/52B6BBD953968D1B
> >
> > ---
> >
> > Freedom is the freedom to say that two plus two make four. If that is
> > granted, all else follows.
> > -- George Orwell
> Sent from Mail for Windows 10
>

I have just become the new maintainer of the autofs package.

Thus, closing this bug.

Mike

Bug#912947: autofs: new upstream version (5.1.5) available

[Mike Gabriel]

Control: close -1
Control: fixed -1 5.1.5-1

Hi Salvatore,

On Mon, 05 Nov 2018 09:25:22 +0100 Salvatore Bonaccorso 
 wrote:

> Source: autofs
> Severity: wishlist
>
> Hi
>
> There was a new autofs version released (5.1.5) upstream, could it be
> packaged for Debian?
>
> Regards,
> Salvatore
>
>

I just uploaded autofs 5.1.5-1 to Debian experimental.

Thus, closing this bug.

Mike

Bug#908779: bro: CVE-2018-17019: Fix IRC names command parsing

[Moritz Mühlenhoff]

On Tue, Jan 29, 2019 at 02:19:20AM +0100, Hilko Bengen wrote:
> * Moritz Mühlenhoff:
> 
> >> CVE-2018-17019[0]:
> >> | In Bro through 2.5.5, there is a DoS in IRC protocol names command
> >> | parsing in analyzer/protocol/irc/IRC.cc.
> >
> > ping, can we get this one (and CVE-2018-16807) uploaded still in time
> > for buster?
> 
> Working on 2.6.1, but I need to get broker (and a new upstream versio
> nof actor-framework) into unstable first. Working on that, too.

With buster being in full freeze, can you backport CVE-2018-17019 and
CVE-2018-16807 to 2.5.5, please?

Cheers,
Moritz

Bug#924616: CVE-2018-15587

[Moritz Muehlenhoff]

Source: evolution
Severity: grave
Tags: security

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15587:

https://bugzilla.gnome.org/show_bug.cgi?id=796424
https://gitlab.gnome.org/GNOME/evolution/commit/9c55a311325f5905d8b8403b96607e46cf343f21
https://gitlab.gnome.org/GNOME/evolution/commit/f66cd3e1db301d264563b4222a3574e2e58e2b85

Cheers,
Moritz
   

Bug#915801: cairo: CVE-2018-19876

[Moritz Mühlenhoff]

On Thu, Dec 06, 2018 at 09:59:39PM +0100, Salvatore Bonaccorso wrote:
> Source: cairo
> Version: 1.16.0-1
> Severity: important
> Tags: security upstream
> Forwarded: https://gitlab.freedesktop.org/cairo/cairo/merge_requests/5
> 
> Hi,
> 
> The following vulnerability was published for cairo.
> 
> CVE-2018-19876[0]:
> | cairo 1.16.0, in cairo_ft_apply_variations() in cairo-ft-font.c, would
> | free memory using a free function incompatible with WebKit's
> | fastMalloc, leading to an application crash with a "free(): invalid
> | pointer" error.

Fixed in 
https://gitlab.freedesktop.org/cairo/cairo/commit/90e85c2493fdfa3551f202ff10282463f1e36645

Cheers,
Moritz

Bug#924502: systemd: system.conf is ignore multiplicative suffixes K, M, G, T, P, E.

[Michael Biebl]

Control: tags -1 + moreinfo

Am 13.03.19 um 18:14 schrieb Igor Ohrimenko:
> Package: systemd
> Version: 232-25+deb9u9
> Severity: important
> 
> Dear Maintainer, I read man system.conf and found multiplicative suffixes. I 
> tried to use it, like 1G, but DefaultLimit does not change. I have to use the 
> long, ugly number 1048576.

which DefaultLimit?

#DefaultLimitCPU=
#DefaultLimitFSIZE=
#DefaultLimitDATA=
#DefaultLimitSTACK=
#DefaultLimitCORE=
#DefaultLimitRSS=
#DefaultLimitNOFILE=
#DefaultLimitAS=
#DefaultLimitNPROC=
#DefaultLimitMEMLOCK=
#DefaultLimitLOCKS=
#DefaultLimitSIGPENDING=
#DefaultLimitMSGQUEUE=
#DefaultLimitNICE=
#DefaultLimitRTPRIO=
#DefaultLimitRTTIME=

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#924615: CVE-2018-12178 CVE-2018-12180 CVE-2018-12181

[Moritz Muehlenhoff]

Source: edk2
Severity: grave
Tags: security

Please see
https://security-tracker.debian.org/tracker/CVE-2018-12178
https://security-tracker.debian.org/tracker/CVE-2018-12180
https://security-tracker.debian.org/tracker/CVE-2018-12181

Cheers,
Moritz

Bug#328303: iconv breaks on piped input, because it tries to read whole input into a buffer / iconv: Feature request: add stream capabilities

[treaki]

Subject: /usr/bin/iconv: Feature request: add stream capabilities
Package: libc-bin
Version: 2.28-2
Severity: normal
File: /usr/bin/iconv

hi,

i also planned to add this as a feature request, please add some 
parameter to the iconv command, like with script -f or grep 
--line-buffered, to stream the output as fast as possible through iconv 
no matter if EOF is reached or not. So iconv would be much more usable 
in situations where the output input isnt completely generated yet.
Please add this if you are a programmer, understand the code of the 
iconv command and have some time, it would make the iconv command a lot 
more powerful.


Right now i have to start another iconv for every line in my stream 
using xargs and some bash code to work around this which is a lot more 
system load i guess do to repeated initialization and de-initialization 
of the iconv application, of cause a lot more work to do when piping 
stuff through iconv, and so on...


thanks a lot in advance!

treaki

On Wed, 14 Sep 2005 18:54:36 +0100 Chris Lightfoot  
wrote:

> Package: libc6
> Version: 2.3.2.ds1-22
>
> iconv(1) tries to read in its whole input before doing
> conversion. This is no good if you want to use it in a
> pipe.
>
> Example:
>
> yes | iconv -f utf-8 -t iso-8859-1
>
> expected result: ten lines of `y'
> actual result: iconv runs out of memory
>
> As a more serious example, consider
>
> zcat dump-of-wikipedia.xml.gz | iconv -f utf-8 -t $charset | ...
>
> --
> ``The Strategic Railway Authority is not in the business of railway 
lines.''

> (Cambridgeshire County Councillor Shona Johnstone)
>
>

--
|_|0|_|
|_|_|0|
|0|0|0|

http://treaki.tk/

Bug#807666: reopen 807666, it should be fixed properly

[Ana Guerrero Lopez]

unarchive 807666
reopen 807666
notfixed 807666 mpich/3.2-1~exp1
found 807666 3.3-2
forwarded 807666 
https://lists.mpich.org/pipermail/discuss/2019-March/011160.html
kthxbye

Hi,

This bug wasn't closed properly. While a rebuild of the package with
the new upload fixed the problem temporarily, this is a problem
that must be solved in mpich as Matthias and Emilio pointed out.

I have sent a patch to upstream that should fix the issue:
https://lists.mpich.org/pipermail/discuss/2019-March/011160.html

Cheers,
Ana

Bug#912549: icedtea-web FTBFS with OpenJDK 11

[Emmanuel Bourg]

On 13/03/2019 17:47, Matthias Klose wrote:

> please look at the new upstream 1.7.2 and 1.8 releases.

I got a quick look at these new versions released this week, IcedTea Web
1.7.2 is rather close to the version in unstable since October and has a
few extra Java 9+ fixes, it's probably worth considering for Buster. The
version 1.8 doesn't seem to improve the Java 9+ compatibility and the
new Rust based launcher looks like a big change I'd rather see in
Bullseye. The upcoming version 1.9 looks interesting since it removes
the applet code that is causing the FTBFS with Java 11 we are discussing
here, but that will be too late for Buster.

Emmanuel Bourg

Bug#924541: Can't complete journalctl > file

[Michael Biebl]

Am 14.03.19 um 09:13 schrieb 積丹尼 Dan Jacobson:
> Package: systemd
> Version: 241-1
> Severity: minor
> File: /usr/share/bash-completion/completions/journalctl
> 
> It's not happy about me wanting to do
> # journalctl > file

Please file this issuee directly upstream at
https://github.com/systemd/systemd/issues new and report back with the
issue number.

Thanks.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#920899: /usr/lib/pypy/ns/ vs. /usr/share/pypy/ns/

[Piotr Ożarowski]

> > It's using /usr/lib/pypy/ns/ the same way as we do in Python 2.
> 
> It's in /usr/lib/ not /usr/share/
> 
> I couldn't reasonably make pypy use /usr/ as it's prefix, without it
> finding cPython libraries. So the whole of pypy is in /usr/lib/pypy/.

pypy can be in /usr/lib/ and ns files in /usr/share/.
Why do you want them both in /usr/lib? I'm sorry I didn't double check
where /usr/bin/pypycompile searches for these files and assumed it's in
/usr/share, but could you follow other interpreters and read it from
/usr/share? This seems a better choice (FHS wise).
Note that there's already /usr/share/pypy/dist/ dir with pydist files…

patch attached :)
diff --git a/debian/changelog b/debian/changelog
index 6bade0b3..69248c65 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,7 +1,12 @@
 pypy (7.0.0+dfsg-3) UNRELEASED; urgency=medium
 
+  [ Stefano Rivera ]
   * Update watch file regex, upstream calls it pypy2.7 now.
 
+  [ Piotr Ożarowski ]
+  * pypycompile and pypyclean now read namespaces from /usr/share/pypy/ns
+(to follow dh_pypy's suggested location)
+
  -- Stefano Rivera   Tue, 26 Feb 2019 16:38:55 -0800
 
 pypy (7.0.0+dfsg-2) unstable; urgency=medium
diff --git a/debian/scripts/pypyclean b/debian/scripts/pypyclean
index eaba24bd..83c89070 100755
--- a/debian/scripts/pypyclean
+++ b/debian/scripts/pypyclean
@@ -31,7 +31,7 @@ def package_modules(package):
 
 def installed_namespaces():
 '''Return a dictionary of package: frozenset(namespaces)'''
-ns_dir = '/usr/lib/pypy/ns'
+ns_dir = '/usr/share/pypy/ns'
 ns_by_pkg = {}
 for pkg in os.listdir(ns_dir):
 ns_file = os.path.join(ns_dir, pkg)
diff --git a/debian/scripts/pypycompile b/debian/scripts/pypycompile
index 42af3264..31abe2df 100755
--- a/debian/scripts/pypycompile
+++ b/debian/scripts/pypycompile
@@ -45,7 +45,7 @@ def generate_namespace_init(package, verbose):
 '''Iterate through a package's ns file.
 Create all necessary__init__.pys, and yield them.
 '''
-ns_file = os.path.join('/usr/lib/pypy/ns', package)
+ns_file = os.path.join('/usr/share/pypy/ns', package)
 if not os.path.exists(ns_file):
 return
 with open(ns_file) as f:

Bug#924602: systemd - regression: syslog msg from units not routed according to StandardOutput=

[Michael Biebl]

Control: tags -1 + moreinfo

Am 14.03.19 um 21:59 schrieb Bastian Blank:
> Package: systemd
> Version: 241-1
> Severity: normal
> 
> syslog messages from units are not longer routed according to
> the StandardOutput setting, but I don't see a new setting to change it.

StandardOutput= is only supposed to apply to messages received via
stdout (at least that's how it's documented). So what you see is
expected behaviour, I'd say.
I quickly tested a stretch VM and the message sent via syslog (logger)
does not show up on the console, so I don't quite understand the "not
longer" comment.

Regards,
Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#855811: release.debian.org: release.d.o WWW should explicitly recommend against uploading to sid during the freeze

[Sean Whitton]

Hello,

On Thu 14 Mar 2019 at 07:48PM +01, Paul Gevers wrote:

> I the attached patch what you are looking for?

Yes, thank you, although I would wordsmith it as follows (take it or
leave it as you like):

... it is recommended that, during the freeze, you do not upload to
unstable any changes for which you do not intend to request an
unblock.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#924614: CVE-2018-20536 CVE-2018-20537 CVE-2018-20539

[Moritz Muehlenhoff]

Source: liblas
Severity: important
Tags: security

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20539
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20537
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20536

Cheers,
Moritz

Bug#924613: CVE-2009-5155

[Moritz Muehlenhoff]

Source: gnulib
Severity: grave
Tags: security

Please see https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-5155

Patch:
http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=5513b40999149090987a0341c018d05d3eea1272

Cheers,
Moritz

Bug#924602: Acknowledgement (systemd - regression: syslog msg from units not routed according to StandardOutput=)

[Bastian Blank]

complete journal entries of a different try:

__CURSOR=s=8545edb250274321b56a06f3763e1935;i=2cb;b=72db9eebfc5d4d599d064d1dec0942a2;m=84edb947;t=58414a225dfde;x=358be
__REALTIME_TIMESTAMP=1552599038156766
__MONOTONIC_TIMESTAMP=2230171975
_BOOT_ID=72db9eebfc5d4d599d064d1dec0942a2
PRIORITY=6
_MACHINE_ID=b90bd60286744a36ac3dbf43a788906f
_HOSTNAME=debian-9
SYSLOG_FACILITY=3
_UID=0
_GID=0
_TRANSPORT=stdout
_SYSTEMD_UNIT=test.service
SYSLOG_IDENTIFIER=service-test
MESSAGE=message stdout
_STREAM_ID=3bec5a8b057b403195b6955a10cfe37d
_PID=1899

__CURSOR=s=8545edb250274321b56a06f3763e1935;i=2cc;b=72db9eebfc5d4d599d064d1dec0942a2;m=84edb947;t=58414a225dfde;x=7add3
__REALTIME_TIMESTAMP=1552599038156766
__MONOTONIC_TIMESTAMP=2230171975
_BOOT_ID=72db9eebfc5d4d599d064d1dec0942a2
PRIORITY=6
_MACHINE_ID=b90bd60286744a36ac3dbf43a788906f
_HOSTNAME=debian-9
SYSLOG_FACILITY=3
_UID=0
_GID=0
_TRANSPORT=stdout
_SYSTEMD_UNIT=test.service
SYSLOG_IDENTIFIER=service-test
MESSAGE=message stderr
_STREAM_ID=3bec5a8b057b403195b6955a10cfe37d
_PID=1899

__CURSOR=s=8545edb250274321b56a06f3763e1935;i=2ca;b=72db9eebfc5d4d599d064d1dec0942a2;m=84edb133;t=58414a225d7ca;x=dcf31
__REALTIME_TIMESTAMP=1552599038154698
__MONOTONIC_TIMESTAMP=2230169907
_BOOT_ID=72db9eebfc5d4d599d064d1dec0942a2
_MACHINE_ID=b90bd60286744a36ac3dbf43a788906f
_HOSTNAME=debian-9
PRIORITY=5
_UID=0
_GID=0
_CAP_EFFECTIVE=3f
_SYSTEMD_SLICE=system.slice
_TRANSPORT=syslog
SYSLOG_IDENTIFIER=root
MESSAGE=message syslog
_COMM=logger
_EXE=/usr/bin/logger
_SYSTEMD_CGROUP=/system.slice/test.service
_SYSTEMD_UNIT=test.service
SYSLOG_FACILITY=1
SYSLOG_TIMESTAMP=Mar 14 21:30:38 
_PID=1900
_CMDLINE=logger message syslog
_SYSTEMD_INVOCATION_ID=757ed0b113704703964fc50ed273e831
_SOURCE_REALTIME_TIMESTAMP=1552599038154693

-- 
Mind your own business, Spock.  I'm sick of your halfbreed interference.

Bug#924612: CVE-2019-9169

[Moritz Muehlenhoff]

Source: glibc
Severity: important
Tags: security

Please see
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34140
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34142
https://sourceware.org/bugzilla/show_bug.cgi?id=24114
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commit;h=583dd860d5b833037175247230a328f0050dbfe9

Cheers,
Moritz

Bug#924611: vtk7: please add support for riscv64

[Aurelien Jarno]

Package: src:vtk7
Version: 7.1.1+dfsg1-12
Severity: normal
Tags: upstream patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hi,

vtk7 currently fails to build on the riscv64 architecture as it can be
seen on the following build log excerpt:

| In file included from /<>/Utilities/KWIML/vtkkwiml/abi.h:2,
|  from 
/<>/debian/build/Utilities/KWIML/vtk_kwiml.h:19,
|  from /<>/Common/Core/vtkType.h:19,
|  from /<>/Wrapping/Tools/vtkParse.tab.c:180:
| /<>/Utilities/KWIML/vtkkwiml/include/kwiml/abi.h:472:3: error: 
#error "Byte order of target CPU unknown."
|  # error "Byte order of target CPU unknown."
|^
| [  0%] Linking C executable ../../bin/vtkWrapTclInit-7.1

The full build log is available there:
https://buildd.debian.org/status/fetch.php?pkg=vtk7=riscv64=7.1.1%2Bdfsg1-12=1552472983=0

vtk7 has a list of define per architecture to define the endianness and
riscv64 is missing. This has already been fixed upstream:
https://gitlab.kitware.com/vtk/vtk/blob/master/Utilities/KWIML/vtkkwiml/include/kwiml/abi.h

The attached patch is a backport from the upstream changes. It would be
nice if you can include it in the next upload.

Thanks,
Aurelien
diff -Nru vtk7-7.1.1+dfsg1/debian/patches/112_riscv_support.patch 
vtk7-7.1.1+dfsg1/debian/patches/112_riscv_support.patch
--- vtk7-7.1.1+dfsg1/debian/patches/112_riscv_support.patch 1970-01-01 
00:00:00.0 +
+++ vtk7-7.1.1+dfsg1/debian/patches/112_riscv_support.patch 2019-03-13 
21:37:13.0 +
@@ -0,0 +1,15 @@
+Changes taken from 
https://gitlab.kitware.com/vtk/vtk/blob/master/Utilities/KWIML/vtkkwiml/include/kwiml/abi.h
+
+--- vtk7-7.1.1+dfsg1.orig/Utilities/KWIML/vtkkwiml/include/kwiml/abi.h
 vtk7-7.1.1+dfsg1/Utilities/KWIML/vtkkwiml/include/kwiml/abi.h
+@@ -467,6 +467,10 @@ suppression macro KWIML_ABI_NO_VERIFY wa
+ #elif defined(__XTENSA_EL__)
+ # define KWIML_ABI_ENDIAN_ID KWIML_ABI_ENDIAN_ID_LITTLE
+ 
++/* RISC-V */
++#elif defined(__riscv) || defined(__riscv__)
++# define KWIML_ABI_ENDIAN_ID KWIML_ABI_ENDIAN_ID_LITTLE 
++
+ /* Unknown CPU */
+ #elif !defined(KWIML_ABI_NO_ERROR_ENDIAN)
+ # error "Byte order of target CPU unknown."
diff -Nru vtk7-7.1.1+dfsg1/debian/patches/series 
vtk7-7.1.1+dfsg1/debian/patches/series
--- vtk7-7.1.1+dfsg1/debian/patches/series  2018-12-17 09:03:58.0 
+
+++ vtk7-7.1.1+dfsg1/debian/patches/series  2019-03-13 21:37:13.0 
+
@@ -17,3 +17,4 @@
 109_java-jar-nonjavafiles.patch
 110_python-371.patch
 111_fix_perl.patch
+112_riscv_support.patch

Bug#507706: Missing sources for d-i components/kernel of etch-n-half images

[Daniel Baumann]

reopen 507706
thanks

doesn't matter if debian supports etch or not; the images with missing
sources are still distributed from cdimage.debian.org:

http://cdimage.debian.org/cdimage/archive/4.0_r4/i386/iso-cd/debian-40r4etchnhalf-i386-netinst.iso

Regards,
Daniel

Bug#924042: tomb: Multiple package relations for optionally used tools are missing (steghide, dcfldd, gettext-base, qrencode, unoconv, lsof, swish-e)

[Raphael Hertzog]

Control: severity -1 important

On Fri, 08 Mar 2019, Axel Beckert wrote:
> tomb's exhume subcommand calls steghide:
> 
> ~ → tomb exhume /tmp/example.jpg
> tomb [E] Steghide not installed: cannot exhume keys from images.

The failure mode is rather clean, I don't think the missing
recommends/suggests warrants a serious bug. I'm downgrading
this bug to important.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#924609: libsdl1.2: Multiple security issues

[Moritz Muehlenhoff]

Source: libsdl1.2
Severity: grave
Tags: security

Hi,
a number of security issues were found in SDL, please see the following
links for references.

https://security-tracker.debian.org/tracker/CVE-2019-7638
https://security-tracker.debian.org/tracker/CVE-2019-7637
https://security-tracker.debian.org/tracker/CVE-2019-7636
https://security-tracker.debian.org/tracker/CVE-2019-7635
https://security-tracker.debian.org/tracker/CVE-2019-7578
https://security-tracker.debian.org/tracker/CVE-2019-7577
https://security-tracker.debian.org/tracker/CVE-2019-7576
https://security-tracker.debian.org/tracker/CVE-2019-7575
https://security-tracker.debian.org/tracker/CVE-2019-7574
https://security-tracker.debian.org/tracker/CVE-2019-7573
https://security-tracker.debian.org/tracker/CVE-2019-7572

Some bugs have links to upstream fixes, I think we can go ahead and
merge those. The others have proposed patches, but let's not rush
any upload and wait until these are properly reviewed/merged by
upstream.

Cheers,
Moritz

Bug#924610: libsdl2: Multiple security issues

[Moritz Muehlenhoff]

Source: libsdl2
Severity: grave
Tags: security

Hi,
a number of security issues were found in SDL, please see the following
links for references.

https://security-tracker.debian.org/tracker/CVE-2019-7638
https://security-tracker.debian.org/tracker/CVE-2019-7637
https://security-tracker.debian.org/tracker/CVE-2019-7636
https://security-tracker.debian.org/tracker/CVE-2019-7635
https://security-tracker.debian.org/tracker/CVE-2019-7578
https://security-tracker.debian.org/tracker/CVE-2019-7577
https://security-tracker.debian.org/tracker/CVE-2019-7576
https://security-tracker.debian.org/tracker/CVE-2019-7575
https://security-tracker.debian.org/tracker/CVE-2019-7574
https://security-tracker.debian.org/tracker/CVE-2019-7573
https://security-tracker.debian.org/tracker/CVE-2019-7572

Some bugs have links to upstream fixes, I think we can go ahead and
merge those. The others have proposed patches, but let's not rush
any upload and wait until these are properly reviewed/merged by
upstream.

Cheers,
Moritz

Bug#497471: sarge images have syslinux binaries without source

[Daniel Baumann]

reopen 497471
thanks

it doesn't matter if debian supports sarge or
not; the images with missing sources are still distributed from
cdimage.debian.org:

http://cdimage.debian.org/cdimage/archive/3.1_r0/i386/iso-cd/debian-31r0-i386-netinst.iso

Regards,
Daniel

Bug#924608: oggvideotools FTBFS in buster. Can't find file for test.

[peter green]

Package: oggvideotools
Version: 0.9.1-4.1
Severity: serious
Tags: patch

oggvideotools FTBFS in buster. I first noticed this in raspbian, but it's also 
visible on the reproducible builds tests.

http://buildd.raspbian.org/status/fetch.php?pkg=oggvideotools=armhf=0.9.1-4.1=1552572977
https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/oggvideotools.html

+ /build/oggvideotools-0.9.1/obj-x86_64-linux-gnu/src/binaries/oggCut -s 500 -e 
1000 /usr/share/python-mecavideo/video/Effet_force_magnetique.ogv out.ogv
FileRepository::open failed: No such file or directory
Error: can not open file 


It seems that this is a result of changes in the pymecavideo source package. 
The binary package was renamed and a provides added. In doing so
the path for the file in question was changed.

This bug is masked in sid because the cruft package is still present there and 
the autobuilder dependency resolvers choose the real
(but cruft) package over the virtual package. In buster on the other hand the 
cruft package is gone, so the dependency resolver
is forced to use the virtual package.

The fix is simple enough, just update the dependency and the filepath. I have 
uploaded the fix to raspbian, a debdiff should appear soon at
https://debdiffs.raspbian.org/main/o/oggvideotools . Note that said debdiff 
will include a raspbian specific change that you probablly
don't want in Debian (raspbian's valgrind is kinda broken :( )

Bug#924607: RM: libnvidia-cfg1 nvidia-cuda-mps nvidia-detect nvidia-driver nvidia-driver-bin nvidia-kernel-dkms nvidia-kernel-source nvidia-kernel-support nvidia-smi xserver-xorg-video-nvidia [i386 ar

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

Let's clean up some cruft, armhf and i386 are only supported by the 390xx
legacy driver.


Andreas

Bug#924450: [pkg-apparmor] Bug#924450: Bug#924450: Bug#924450: apparmor: Write Buster release notes snippet about AppArmor

[Christian Boltz]

Hello,

Am Donnerstag, 14. März 2019, 16:11:46 CET schrieb Jonas Meurer:
> Done in
> https://salsa.debian.org/ddp-team/release-notes/merge_requests/8

Thanks!

> So this bugreport can be closed now, right?

Yes :-) - but I'll let intrigeri or you do the "paperwork" ;-)


Regards,

Christian Boltz
-- 
We looked at the recommended way how to do Debian packaging,
but found it quite insane. [Michal Hrušecký on
https://events.opensuse.org/conference/osc15/proposal/534]


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

Bug#756954: subscription by uploaders

[Raphael Hertzog]

Hello Afif,

sorry for the delay.

On Sun, 03 Feb 2019, Afif Elghraoui wrote:
> The way I was hoping this could work is that Uploaders are automatically
> subscribed. I don't know of any reason why an Uploader should not be
> following their packages. I think it would also motivate people who
> really don't co-maintain a package to get themelves removed from the
> Uploaders list, thereby correcting the package metadata.

Uploaders should be following their packages but they might already be
following their packages in some other way: through a (tracker-)team
subscription. Or through a mailing list that is referenced in the
Maintainer field.

So maintainers should be able to opt-out from this automatic subscription
or at least blacklist some packages (so that a manual unsubscription is
not followed by an automatic subscription because of the Uploaders field).

> I think this would also be simpler to implement than subscription
> keywords in d/control (as mentioned in the OP). If it's still too far
> out of you way, I'd be willing to implement a patch, but would
> appreciate a tip about where to look in the code-base. I looked around
> it and couldn't find a good starting point in the file hierarchy.

I believe this feature is important and it would be nice to have it
working in the not too distant future but I'm unfortunately not actively
working on the tracker lately (just look at how much time it took me to
respond to your mail!).

A good start would be to modify the database so that we can record the
origin of each subscription. I imagine it would be a simple text value
associated to the subscription: "manual:web" or "manual:email" for a
manual subscription from the web interface or from the email interface. Or
"auto:uploaders" for this new feature.

You will have to modify the Subscription model in
distro_tracker/core/models.py and you probably want to create a new
task in distro_tracker/core/retrieve_data.py (or modify an existing one?)
to create/delete the subscriptions as appropriate.

You will have to review the places where the subscriptions are created
and add the required origin value.

The task should be smart enough to detect when the given email already
gets the package notifications through a tracker team or through a pre-existing
(manual) subscription or through an alternate email associated to the same
user.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#924589: Decrease severity

[Xavier]

Control: severity -1 important

Package seems usable with its 2 reverse dependencies: node-superagent 
which is a dependency of node-multiparty. Only node-multiparty package 
provides real test. I tested both build and autopkgtest with the 2 
versions of node-formidable (old and upgraded) with success.

Bug#924605: Depend on icedtea-netx instead of icedtea-netx-common.

[Matthias Klose]

Package: src:sweethome3d-textures-editor
Version: 1.6-1
Severity: serious
Tags: sid buster patch

Depend on icedtea-netx instead of icedtea-netx-common (nbs).

Patch at
http://launchpadlibrarian.net/415168607/sweethome3d-textures-editor_1.6-1_1.6-1ubuntu1.diff.gz

Bug#924606: skimage: autopkgtest needs update for new version of python-scipy: ValueError: No warning raised matching: matrix subclass

[Paul Gevers]

Source: skimage
Version: 0.14.2-1
Severity: important
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:python-scipy

[X-Debbugs-CC: debian...@lists.debian.org,
python-sc...@packages.debian.org, debian-rele...@lists.debian.org]

Dear maintainers,

With a recent upload of python-scipy the autopkgtest of skimage fails in
testing when that autopkgtest is run with the binary packages of
python-scipy from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
python-scipy   from testing1.1.0-4
skimagefrom testing0.14.2-1
all others from testingfrom testing

The latest upload of python-scipy was an effort to fix the autopkgtest
of python-scipy (see bug 919929 for background info), which was blurred
by loads of deprecation warnings from python-numpy. As part of the
solution, python-scipy was patched to prevent specific deprecation
warnings, but apparently the autopkgtest of skimage relies on these
warnings. I copied some of the output at the bottom of this report.

If I read the text in your error log correctly, you can mark the check
for these warnings as optional. Can you please do that? Or discuss with
the python-scipy maintainers how to resolve this issue.

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/s/skimage/2107462/log.gz

=== FAILURES
===
__ test_2d_bf
__

def test_2d_bf():
lx = 70
ly = 100
data, labels = make_2d_syntheticdata(lx, ly)
with expected_warnings([NUMPY_MATRIX_WARNING]):
>   labels_bf = random_walker(data, labels, beta=90, mode='bf')

/usr/lib/python3/dist-packages/skimage/segmentation/tests/test_random_walker.py:74:

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
/usr/lib/python3.7/contextlib.py:119: in __exit__
next(self.gen)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

matching = ['matrix subclass']

@contextmanager
def expected_warnings(matching):
"""Context for use in testing to catch known warnings matching
regexes

Parameters
--
matching : list of strings or compiled regexes
Regexes for the desired warning to catch

Examples

>>> from skimage import data, img_as_ubyte, img_as_float
>>> with expected_warnings(['precision loss']):
... d = img_as_ubyte(img_as_float(data.coins()))

Notes
-
Uses `all_warnings` to ensure all warnings are raised.
Upon exiting, it checks the recorded warnings for the desired
matching
pattern(s).
Raises a ValueError if any match was not found or an unexpected
warning was raised.
Allows for three types of behaviors: `and`, `or`, and `optional`
matches.
This is done to accomodate different build enviroments or loop
conditions
that may produce different warnings.  The behaviors can be combined.
If you pass multiple patterns, you get an orderless `and`, where
all of the
warnings must be raised.
If you use the `|` operator in a pattern, you can catch one of
several
warnings.
Finally, you can use `|\A\Z` in a pattern to signify it as optional.

"""
if isinstance(matching, str):
raise ValueError('``matching`` should be a list of strings
and not '
 'a string itself.')
with all_warnings() as w:
# enter context
yield w
# exited user context, check the recorded warnings
# Allow users to provide None
while None in matching:
matching.remove(None)
remaining = [m for m in matching if '\A\Z' not in m.split('|')]
for warn in w:
found = False
for match in matching:
if re.search(match, str(warn.message)) is not None:
found = True
if match in remaining:
remaining.remove(match)
if not found:
raise ValueError('Unexpected warning: %s' %
str(warn.message))
if len(remaining) > 0:
msg = 'No warning raised matching:\n%s' %
'\n'.join(remaining)
>   raise ValueError(msg)
E   ValueError: No warning raised matching:
E   matrix subclass

/usr/lib/python3/dist-packages/skimage/_shared/_warnings.py:130: ValueError
__ test_2d_cg
__

def test_2d_cg():
lx = 70
ly = 100
data, labels = make_2d_syntheticdata(lx, ly)
with expected_warnings(['"cg" mode' + '|' + SCIPY_RANK_WARNING,
   

Bug#924603: unblock: python-tesserocr/2.4.0-4

[Michael Fladischer]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package python-tesserocr

It fixes a FTBFS error triggered by a runtime assertion that checks for LC_ALL 
to
be set to "C" locale.

See attached debdiff for changes.

unblock python-tesserocr/2.4.0-4

- -- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

Kernel: Linux 4.19.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlyKwY0RHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WoAiAgAuSRiCpKvXbk1U+v7uRIhlp1x1hz2gm+Y
XRUhob1XHd3fDdP0z5PwKtGpfo6AC+B/lqWVZwMKH8HP2g5ZyarmVSE8GXtmrvIU
OVPRupwitpsPwiXIRWh450EOVp1B4zHXqfBzzZO84WjeCvG41WTeo3Re8U44Dyow
lyLcVpP4dWYMmZ5ndFszc3HyGehPw+qXW6NyX53/Hq98utLGn1NPtMJWiD1LYCzy
1b+DOZO6CRWfWpInhazrJ6TMQozMTuBjVCt6kBBP73yXOz3vexlAotSG0d9prYGr
D2oy/LAWgjh5cuBPNmM6f0Z2OKa3awhH9mKjbzb6KYiFdaIvYcmMYw==
=g5Gm
-END PGP SIGNATURE-
diff -Nru python-tesserocr-2.4.0/debian/changelog 
python-tesserocr-2.4.0/debian/changelog
--- python-tesserocr-2.4.0/debian/changelog 2019-02-02 19:44:43.0 
+0100
+++ python-tesserocr-2.4.0/debian/changelog 2019-03-14 14:41:28.0 
+0100
@@ -1,3 +1,10 @@
+python-tesserocr (2.4.0-4) unstable; urgency=medium
+
+  * Set LC_ALL=C during build as tesserocr checks for it during tests
+(Closes: #923781). Thanks Sergei Golovan for the hint.
+
+ -- Michael Fladischer   Thu, 14 Mar 2019 14:41:28 +0100
+
 python-tesserocr (2.4.0-3) unstable; urgency=medium
 
   * Change binary package name to python3-tesserocr.

Bug#924604: Depend on icedtea-netx instead of icedtea-netx-common

[Matthias Klose]

Package: src:sweethome3d-furniture-editor
Version: 1.24-1
Severity: serious
Tags: sid buster patch

Depend on icedtea-netx instead of icedtea-netx-common (nbs).

Patch at
http://launchpadlibrarian.net/415168474/sweethome3d-furniture-editor_1.24-1_1.24-1ubuntu1.diff.gz

Bug#924601: unblock: remmina/1.3.3+dfsg-2

[Matteo F. Vescovi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package remmina

Version 1.3.3+dfsg-2 (now in unstable/sid) aims to fix a particular
issue introduced in former 1.3.3+dfsg-1 revision about SSH plugin
failing to work properly if a public key is not provided.

Upstream noticed this and via #924319 requested a new upload to fix the
problem, providing a simple patch to achieve it. The main rationale for
this change is explained in the bug report above.

Attached, you'll find a debdiff for 1.3.3+dfsg-1 -> 1.3.3+dfsg-2.

unblock remmina/1.3.3+dfsg-2

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

diff -Nru remmina-1.3.3+dfsg/debian/changelog remmina-1.3.3+dfsg/debian/changelog
--- remmina-1.3.3+dfsg/debian/changelog	2019-02-28 22:39:06.0 +0100
+++ remmina-1.3.3+dfsg/debian/changelog	2019-03-12 20:51:31.0 +0100
@@ -1,3 +1,10 @@
+remmina (1.3.3+dfsg-2) unstable; urgency=medium
+
+  * debian/patches/: patchset updated
+- 01-SSH_fix.patch added (Closes: #924319)
+
+ -- Matteo F. Vescovi   Tue, 12 Mar 2019 20:51:31 +0100
+
 remmina (1.3.3+dfsg-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru remmina-1.3.3+dfsg/debian/patches/01-SSH_fix.patch remmina-1.3.3+dfsg/debian/patches/01-SSH_fix.patch
--- remmina-1.3.3+dfsg/debian/patches/01-SSH_fix.patch	1970-01-01 01:00:00.0 +0100
+++ remmina-1.3.3+dfsg/debian/patches/01-SSH_fix.patch	2019-03-12 20:46:20.0 +0100
@@ -0,0 +1,165 @@
+Description: SSH plugin not working if pubkey is not supplied
+Author: Antenore Gatta 
+Bug: https://gitlab.com/Remmina/Remmina/issues/1850
+Bug-Debian: https://bugs.debian.org/924319
+Date: 2019-03-11
+
+diff --git a/src/remmina_sftp_client.c b/src/remmina_sftp_client.c
+index 0f43f2b3..3540e1c1 100644
+--- a/src/remmina_sftp_client.c
 b/src/remmina_sftp_client.c
+@@ -507,7 +507,7 @@ remmina_sftp_client_thread_main(gpointer data)
+ 		if (!sftp) {
+ 			sftp = remmina_sftp_new_from_ssh(REMMINA_SSH(client->sftp));
+ 			if (!remmina_ssh_init_session(REMMINA_SSH(sftp)) ||
+-			remmina_ssh_auth(REMMINA_SSH(sftp), NULL) <= 0 ||
++			remmina_ssh_auth(REMMINA_SSH(sftp), NULL, NULL, NULL) <= 0 ||
+ 			!remmina_sftp_open(sftp)) {
+ remmina_sftp_client_thread_set_error(client, task, (REMMINA_SSH(sftp))->error);
+ remmina_ftp_task_free(task);
+@@ -980,7 +980,7 @@ remmina_sftp_client_new_init(RemminaSFTP *sftp)
+ 	gdk_display_flush(display);
+ 
+ 	if (!remmina_ssh_init_session(REMMINA_SSH(sftp)) ||
+-	remmina_ssh_auth(REMMINA_SSH(sftp), NULL) <= 0 ||
++	remmina_ssh_auth(REMMINA_SSH(sftp), NULL, NULL, NULL) <= 0 ||
+ 	!remmina_sftp_open(sftp)) {
+ 		dialog = gtk_message_dialog_new(GTK_WINDOW(gtk_widget_get_toplevel(client)),
+ 			GTK_DIALOG_MODAL, GTK_MESSAGE_ERROR, GTK_BUTTONS_OK,
+diff --git a/src/remmina_sftp_plugin.c b/src/remmina_sftp_plugin.c
+index af55c4cf..08994ac1 100644
+--- a/src/remmina_sftp_plugin.c
 b/src/remmina_sftp_plugin.c
+@@ -135,7 +135,7 @@ remmina_plugin_sftp_main_thread(gpointer data)
+ 		/* Create SFTP connection based on existing SSH session */
+ 		sftp = remmina_sftp_new_from_ssh(ssh);
+ 		if (remmina_ssh_init_session(REMMINA_SSH(sftp)) &&
+-		remmina_ssh_auth(REMMINA_SSH(sftp), NULL) > 0 &&
++		remmina_ssh_auth(REMMINA_SSH(sftp), NULL, gp, remminafile) > 0 &&
+ 		remmina_sftp_open(sftp)) {
+ 			cont = TRUE;
+ 		}
+diff --git a/src/remmina_ssh.c b/src/remmina_ssh.c
+index 9e6ba2a8..851d4446 100644
+--- a/src/remmina_ssh.c
 b/src/remmina_ssh.c
+@@ -229,13 +229,16 @@ remmina_ssh_auth_pubkey(RemminaSSH *ssh)
+ 
+ 	g_snprintf (pubkey, sizeof(pubkey), "%s.pub", ssh->privkeyfile);
+ 
+-	ret = ssh_pki_import_pubkey_file( pubkey, );
+-	if (ret != SSH_OK) {
+-		remmina_ssh_set_error(ssh, _("SSH public key cannot be imported: %s"));
+-		return 0;
++	/*G_FILE_TEST_EXISTS*/
++	if (g_file_test(pubkey, G_FILE_TEST_EXISTS)) {
++		ret = ssh_pki_import_pubkey_file(pubkey, );
++		if (ret != SSH_OK) {
++			remmina_ssh_set_error(ssh, _("SSH public key cannot be imported: %s"));
++			return 0;
++		}
++		ssh_key_free(key);
+ 	}
+ 
+-	ssh_key_free(key);
+ 
+ 	if ( ssh_pki_import_privkey_file( ssh->privkeyfile, (ssh->passphrase ? ssh->passphrase : ""),
+ 		NULL, NULL,  ) != SSH_OK ) {
+@@ -258,10 +261,33 @@ remmina_ssh_auth_pubkey(RemminaSSH *ssh)
+ }
+ 
+ static gint
+-remmina_ssh_auth_auto_pubkey(RemminaSSH* ssh)
++remmina_ssh_auth_auto_pubkey(RemminaSSH *ssh, RemminaProtocolWidget *gp, RemminaFile *remminafile)
+ {
+ 	

Bug#924602: systemd - regression: syslog msg from units not routed according to StandardOutput=

[Bastian Blank]

Package: systemd
Version: 241-1
Severity: normal

syslog messages from units are not longer routed according to
the StandardOutput setting, but I don't see a new setting to change it.

My test case is:

/etc/systemd/service/test.service:
| [Service]
| ExecStart=/usr/local/bin/service-test
| StandardOutput=journal+console
/usr/local/bin/service-test:
| #!/bin/bash
| logger "message syslog"
| echo message stdout
| echo message stderr >&2

In Buster the following shows up in the journal:
| Mär 14 20:54:24 debian-9 systemd[1]: Started test.service.
| Mär 14 20:54:24 debian-9 root[738]: message syslog
| Mär 14 20:54:24 debian-9 service-test[737]: message stdout
| Mär 14 20:54:24 debian-9 service-test[737]: message stderr
| Mär 14 20:54:24 debian-9 systemd[1]: test.service: Succeeded.

But only the following on the console:
| [   56.224716] service-test[737]: message stdout
| [   56.268206] service-test[737]: message stderr

The message written to syslog via logger is missing from the console
output.

In Stretch, the syslog message was sent to the console as well.  This
makes that a regression.

Bastian

-- Package-specific info:

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

Kernel: Linux 4.20.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#924600: unblock: google-compute-image-packages/20190124-3

[Lucas Kanashiro]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package google-compute-image-packages

Sorry for requesting unblock for this package again but a bug was reported [1]
with severity grave against the version 20190124-2 (previously unblocked). The
bug is fixed in version 20190124-3. 

The changes made can be found here:
https://salsa.debian.org/cloud-team/google-compute-image-packages/compare/debian%2F20190124-2...debian%2F20190124-3

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923889

Thank you for considering that.

unblock google-compute-image-packages/20190124-3

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#924599: qtbase-opensource-src: Several copyright issues

[Dmitry Shachnev]

Source: qtbase-opensource-src
Version: 5.11.3+dfsg-5
Severity: serious

While working on copyright update for Qt 5.12, I noticed the following
copyright issues that are applicable to Qt 5.11 too.

1) src/3rdparty/gradle/gradle/wrapper/gradle-wrapper.jar — built file
   without source code;

2) src/3rdparty/iaccessible2/idl/ia2_api_all.idl — not in the preferred
   form of modification: it is a concatenation of 24 different files
   according to the ‘File Name’ headers;

3) src/3rdparty/sqlite/sqlite3.c — not in the preferred form of
   modification: it is a concatenation of 139 different files according
   to the ‘Begin file’ headers;

4) src/3rdparty/wintab/wintab.h — the license does not explicitly permit
   modification and derived works.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#924546: wordpress: Comments may create a XSS

[Salvatore Bonaccorso]

Control: retitle -1 wordpress: CVE-2019-9787: Comments may create a XSS

On Thu, Mar 14, 2019 at 09:20:05PM +1100, Craig Small wrote:
> Source: wordpress
> Version: 5.0.3+dfsg1-1
> Severity: important
> Tags: security
> 
> This release also includes a pair of security fixes that handle how
> comments are filtered and then stored in the database. With a
> maliciously crafted comment, a WordPress post was vulnerable to
> cross-site scripting.
> 
> WordPress versions 5.1 and earlier are affected by these bugs, which
> are fixed in version 5.1.1. Updated versions of WordPress 5.0 and
> earlier are also available for any users who have not yet updated to
> 5.1.

CVE-2019-9787 has been assigned for this issue.

Regards,
Salvatore

Bug#924598: checkstyle: CVE-2019-9658: loads external DTDs by default

[Salvatore Bonaccorso]

Source: checkstyle
Version: 8.15-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for checkstyle.

CVE-2019-9658[0]:
| Checkstyle before 8.18 loads external DTDs by default.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-9658
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9658
[1] https://github.com/checkstyle/checkstyle/issues/6474
[2] https://github.com/checkstyle/checkstyle/issues/6478
[3] https://github.com/checkstyle/checkstyle/pull/6476

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#924597: unblock: mailman-suite/0+20180916-7

[Jonas Meurer]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hello,

Please unblock package mailman-suite 0+20180916-7

This update fixes two bugs, one of them being RC. Up to now, the
mailman3-web binary package tried to configure the mailman3 django site
domain+name via debconf. This code turned out to be very buggy and
error-prone. Therefore we decided to remove this functionality
altogether. It's left to the local admin to configure the mailman3
django site domain+name (which is super easy anyway by navigating
through the web interface).

Installation, upgrades and functionality of the package have been tested
before uploading.

Below you find the changelog, and the debdiff is attached to the mail.
The size of the debdiff is mainly due to the fact that we removed a
debconf template along with the feature.

mailman-suite (0+20180916-7) unstable; urgency=medium

* d/templates, d/po/*.po, d/mailman3-web.{config,postinst}:
  - Remove the whole logic to configure django site domain and name via
debconf. The code was very error-prone and it's better to leave this
exercise to the local admin. (Closes: #924330)
* d/mailman3-web-postinst:
  - Fix logic to run init_django at install and update_django at upgrade.


unblock mailman-suite/0+20180916-7

Thanks for your work as release team!

Cheers
 jonas

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
diff -Nru mailman-suite-0+20180916/debian/changelog 
mailman-suite-0+20180916/debian/changelog
--- mailman-suite-0+20180916/debian/changelog   2019-02-22 22:16:03.0 
+0100
+++ mailman-suite-0+20180916/debian/changelog   2019-03-12 13:07:32.0 
+0100
@@ -1,3 +1,14 @@
+mailman-suite (0+20180916-7) unstable; urgency=medium
+
+  * d/templates, d/po/*.po, d/mailman3-web.{config,postinst}:
+- Remove the whole logic to configure django site domain and name via
+  debconf. The code was very error-prone and it's better to leave this
+  exercise to the local admin. (Closes: #924330)
+  * d/mailman3-web-postinst:
+- Fix logic to run init_django at install and update_django at upgrade.
+
+ -- Jonas Meurer   Tue, 12 Mar 2019 13:07:32 +0100
+
 mailman-suite (0+20180916-6) unstable; urgency=medium
 
   * d/contrib/settings_local.py.sample:
diff -Nru mailman-suite-0+20180916/debian/gitlab-ci.yml 
mailman-suite-0+20180916/debian/gitlab-ci.yml
--- mailman-suite-0+20180916/debian/gitlab-ci.yml   1970-01-01 
01:00:00.0 +0100
+++ mailman-suite-0+20180916/debian/gitlab-ci.yml   2019-03-12 
13:07:32.0 +0100
@@ -0,0 +1,6 @@
+include:
+ - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+ - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+
+variables:
+ RELEASE: 'unstable'
diff -Nru mailman-suite-0+20180916/debian/mailman3-web.config 
mailman-suite-0+20180916/debian/mailman3-web.config
--- mailman-suite-0+20180916/debian/mailman3-web.config 2019-02-22 
22:16:03.0 +0100
+++ mailman-suite-0+20180916/debian/mailman3-web.config 2019-03-12 
13:07:32.0 +0100
@@ -31,27 +31,6 @@
 django_admin="python3 /usr/bin/django-admin"
 django_admin_args="--verbosity 0 --no-color --pythonpath 
/usr/share/mailman3-web --settings settings"
 
-# set django_site
-
-db_get mailman3/django-site && django_site="$RET"
-
-if [ -f /usr/share/mailman3-web/manage.py ] && \
-   [ -f /etc/mailman3/mailman-web.py ]; then
-# Try to get django_site from the Django project. Fails at initial
-# installation due to missing database. That's why the result of
-# django-admin is only taken if command was successfull.
-if django_site_tmp="$($su_cmd "$django_admin shell $django_admin_args \
-   --command \"from django.contrib.sites.models import Site; \
-   print Site.objects.all()[0].domain\"" www-data 2>/dev/null)"; then
-django_site="$django_site_tmp"
-fi
-elif [ -z "$django_site" ]; then
-if [ -f /etc/mailname ]; then
-django_site="$(cat /etc/mailname)"
-fi
-fi
-[ -n "$django_site" ] && db_set mailman3-web/django-site "$django_site"
-
 # set emailname
 
 db_get mailman3-web/emailname && emailname="$RET"
@@ -59,16 +38,13 @@
 if [ -f /etc/mailman3/mailman-web.py ]; then
 emailname="$(get_config_option EMAILNAME)"
 elif [ -z "$emailname" ]; then
-if [ -n "$django_site" ]; then
-emailname="$django_site"
-elif [ -f /etc/mailname ]; then
+if [ -f /etc/mailname ]; then
 emailname="$(cat /etc/mailname)"
 fi
 fi
 [ -n "$emailname" ] && db_set mailman3-web/emailname "$emailname"
 
 db_beginblock
-db_input medium mailman3-web/django-site || true
 db_input medium mailman3-web/emailname || true
 db_input medium mailman3-web/superuser-name || true
 db_input medium mailman3-web/superuser-mail || true
diff -Nru mailman-suite-0+20180916/debian/mailman3-web.postinst 
mailman-suite-0+20180916/debian/mailman3-web.postinst
--- 

Bug#924596: network-manager-openvpn: GUI cannot import openvpn from config-file

[Jürgen Bausa]

Package: network-manager-openvpn
Version: 1.2.8-2
Severity: normal

Dear Maintainer,

I use NM with the kde applet. I tried to import an openvpn config file from the 
gui, but the connection
does not work. the config   file seems to be valid:

 - I can run it directly from the command line -> vpn connection works
 - after importing it from the command line to NM (as root), the connection 
works (connection started 
   by user through kde-NM applet)

So I think there must be something wrong with the import process from the gui 
applet. Maybe information
needs to be stored as root?

I am unsure if this unsure if this is a bug in NM or NM-openvpn.

I am using the stretch-backport of NM 1.14.4-2~bpo9+1 (for other reasons) but 
NM-openvpn from stretch. I also tried the
stretch-backport of NM-openvpn 1.2.8-2 but with the same result.

Regards,

Jürgen

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

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

Versions of packages network-manager-openvpn depends on:
ii  adduser  3.115
ii  libc62.24-11+deb9u4
ii  libglib2.0-0 2.50.3-2
ii  libnm0   1.14.4-2~bpo9+1
ii  network-manager  1.14.4-2~bpo9+1
ii  openvpn  2.4.0-6+deb9u3

network-manager-openvpn recommends no packages.

network-manager-openvpn suggests no packages.

-- no debconf information

Bug#924595: backup2l: Sometimes fails to detect running instance.

[wayne]

Package: backup2l
Version: 1.6-3
Severity: normal
Tags: upstream patch

Dear Maintainer,

backup2l can sometimes fail to detect a running instance, such that
two instances are running at the same time.  This occurs when backup2l
is run manually, and then disowned such that backup2l no longer
belongs to the shell I used to start it.  If I then run backup2l again
while the disowned backup2l is still running, the second run will
start running rather that complaining about the lock file and
existing.  Or, if the daily cron job runs, it will start another
instance of backup2l.

To reproduce, do this as root, in bash:

backup2l -b
disown %1

Then while the disowned instance is still running:

backup2l -s

This will run, instead of complaining about the lockfile as expected.
It then removes the lock file.

I believe this occurs because backup2l is using `ps -a` to find the
running backup2l instances, but a disowned backup2l does not show up
in `ps -a`.  Instead, `ps -ax` needs to be used.  The attached patch,
which has this change, seems to fix the problem for me.

Background: I disowned the manual backup2l because I needed the
long-running manual backup to continue even if the SSH session were
interrupted.

-- System Information:
Debian Release: 8.10
  APT prefers oldstable
  APT policy: (990, 'oldstable'), (500, 'oldstable-updates'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-5-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)

backup2l depends on no packages.

Versions of packages backup2l recommends:
ii  bzip2  1.0.6-7+b3

Versions of packages backup2l suggests:
ii  xz-utils  5.1.1alpha+20120614-2+b3

-- Configuration Files:
/etc/backup2l.conf changed:
FOR_VERSION=1.5
VOLNAME="all"
SRCLIST=(/mnt/sdc/mls/nwmls /mnt/sdf/terabitz)
SKIPCOND=(-xdev -path ./documents.new -prune)
BACKUP_DIR="/mnt/hcf/diamond_backups"
MAX_LEVEL=8
MAX_PER_LEVEL=8
MAX_FULL=2
GENERATIONS=1
CREATE_CHECK_FILE=1
PRE_BACKUP ()
{
echo "  pre-backup: nothing to do"
# e. g., shut down some mail/db servers if their files are to be backup'ed
# On a Debian system, the following statements dump a machine-readable list 
of
# all installed packages to a file.
#echo "  writing dpkg selections to /root/dpkg-selections.log..."
#dpkg --get-selections | diff - /root/dpkg-selections.log > /dev/null || 
dpkg --get-selections > /root/dpkg-selections.log
}
POST_BACKUP ()
{
# e. g., restart some mail/db server if its files are to be backup'ed
echo "  post-backup: nothing to do"
}
AUTORUN=0
SIZE_UNITS=""# set to "B", "K", "M" or "G" to obtain unified units in 
summary list
DRIVER_MY_AFIOZ ()
{
case $1 in
-test)
# This function should check whether all prerequisites are met, 
especially if all
# required tools are installed. This prevents backup2l to fail in 
inconvenient
# situations, e. g. during a backup or restore operation. If 
everything is ok, the
# string "ok" should be returned. Everything else is interpreted as 
a failure.
require_tools afio
# The function 'require_tools' checks for the existence of all 
tools passed as
# arguments. If one of the tools is not found by which(1), an 
error message is
# displayed and the function does not return.
echo "ok"
;;
-suffix)
# This function should return the suffix of backup archive files. 
If the driver
#�does not create a file (e. g. transfers the backup data 
immediately to a tape
# or network device), an empty string has to be returned. backup2l 
uses this suffix
# to select a driver for unpacking. If a user-configured driver 
supports the same
# suffix as a built-in driver, the user driver is preferred (as in 
this case).
echo "afioz"
;;
-create)# Arguments: $2 = BID, $3 = archive file name, $4 = 
file list file
# This function is called to create a backup file. The argument $3 
is the full file
# name of the archive file including path and suffix. $4 contains 
an alphabetically
# sorted  list of files (full pathname) to be backed up. 
Directories are not contained,
# they are handled by backup2l directly without using the driver.
# All output to stderr should be directed to stdout ("2>&1").
afio -Zo -G 9 -M 30m -T 2k $3 < $4 2>&1
# This line passes some additional options to afio (see 
afio(1)):
# '-G 9' maximizes the compression by gzip.
# '-M 30m' increases the size of the internal file buffer. 
Larger files have to
# be compressed twice.
# '-T 2k' prevents the compression of files smaller than 2k in 
order to save 

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Helmut Grohne]

On Thu, Mar 14, 2019 at 07:50:27AM +0100, Johannes Schauer wrote:
> > I would certainly consider a lot cleaner to add a new field to base-files in
> > the form "Bootstrap-Depends: base-passwd" than converting all chowns in
> > postinst to use integer numbers.
> 
> I agree that we should not expect maintainers to write numeric user and group
> ids into their maintainer scripts. This is not only hard to write but also 
> hard
> to read and maintain. In my opinion, using numeric ids should only be a
> temporary measure until we have a declarative method or other helper that does
> the correct translation instead. But since no such helper exists right now,
> numeric ids are probably the best way to fix this bug for buster.

I object to this view. It was never suggested to have anyone write
numeric ids. What Simon suggested was writing symbolic names and have
the package build use static allocations to translate these symbolic
names to numeric ids at build time. This is a whole different story than
having to write them.

If we agree that this would be the best fix for buster, I volunteer to
write a patch for base-files to implement that. Doing so would be easier
if using a more featureful template interpolation language than sed. Do
you (Santiago) have any preference here? I could think of
m4/sh/perl/python. sed will work, but might be ugly.

On Thu, 14 Mar 2019 10:21:30 +0100, Santiago Vila wrote:
> The way I see it, if base-files fails during bootstrapping it's not
> because it does not "help" the bootstrapping tool, but because the
> bootstrapping tool didn't bootstrap base-passwd in the first place.

I think this view is difficult. How is a bootstrap tool supposed to know
that it must configure base-passwd before base-files? Where should we
document that? Basically everyone in this thread except you argued that
requiring such out-of-band knowledge is bad. And if that really is
required, I think policy should be a little explicit about that. Even
though Guillem found a paragraph that supports this view, it is quite
implicit at present.

> Now the question would be if we really need to add a paragraph to
> Debian Policy, "Recommendations/guidelines for bootstrapping tools",
> clearly stating that bootstrapping tools should bootstrap base-passwd
> before trying to configure base-files. I think that would be quite
> clear by now, but I could be wrong.

I actually don't think that policy should document this dependency,
because it really should be an implementation detail. From my
perspective, making it explicit that policy only applies post-bootstrap
is sufficient (e.g. copying the "configured at least once" language from
section 6.5).

If on the other hand, we require the literal interpretation that
base-files must be able to configure while other essential packages are
only unpacked and never configured, it all becomes a lot easier to
reason about. Simon's proposal implements that easily and is a
maintainable solution.

Helmut

Bug#922306: linux: btrfs corruption (compressed data + hole data)

[Salvatore Bonaccorso]

Hi Christoph,

On Thu, Mar 14, 2019 at 08:06:52PM +0100, Christoph Anton Mitterer wrote:
> Hey Ben, Salvatore.
> 
> Thanks for cherry-picking the bug for unstable.
> 
> AFAIU stretch and jessie[-backports] should be affected as well.
> Shouldn't it go there, too?

Yes it needs to be adressed there as well. I have already included the
fix in the next upload for stretch, cf.
https://salsa.debian.org/kernel-team/linux/commit/e6d100021039bdea8be12e5b882f767bb8a1b6b7

Regards,
Salvatore

Bug#922306: linux: btrfs corruption (compressed data + hole data)

[Christoph Anton Mitterer]

Hey Ben, Salvatore.

Thanks for cherry-picking the bug for unstable.

AFAIU stretch and jessie[-backports] should be affected as well.
Shouldn't it go there, too?

At least at the upstream mailing list it was said[0] the the bug was
introduced around October 2008, which should be roughly kernel 2.6.23.

Cheers,
Chris.


[0] 
https://lore.kernel.org/linux-btrfs/cal3q7h599_kdpdfhmrqswnlxktanc7aaqbe+hm6jjpr37us...@mail.gmail.com/

Bug#924581: lintian: license-problem-gfdl-invariants false positive in src:linux's fdl-appendix.rst

[Chris Lamb]

Hi Ben,

> I don't think it is practicable for lintian to recognise arbitrary
> markup within the sentence

As it happens, Lintian already strips LaTeX markup before doing this
check (or at least something is ringing a bell in my memory right
now...) so doing it for .rst too is probably both easy and practical.

> not that lintian warned at all, but that this was treated as being a
> sufficiently reliable check as to trigger an auto-reject.

Nod, had grokked that. :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#924594: Build-depend on icedtea-netx instead of icedtea-netx-common

[Matthias Klose]

Package: src;sweethome3d
Version: 6.1.2+dfsg-1
Severity: serious
Tags: sid buster

Build-depend on icedtea-netx instead of icedtea-netx-common (nbs).

Patch at
http://launchpadlibrarian.net/415155485/sweethome3d_6.1.2+dfsg-1_6.1.2+dfsg-1ubuntu1.diff.gz

Bug#924593: Build-depend on icedtea-netx instead of icedtea-netx-common

[Matthias Klose]

Package: src:geogebra
Version: 4.0.34.0+dfsg1-6
Severity: serious
Tags: sid buster

Build-depend on icedtea-netx instead of icedtea-netx-common (nbs).

Patch at
http://launchpadlibrarian.net/415155213/geogebra_4.0.34.0+dfsg1-6_4.0.34.0+dfsg1-6ubuntu1.diff.gz

However, the build fails then with:

   debian/rules override_jh_build
make[1]: Entering directory '/<>/geogebra-4.0.34.0+dfsg1'
dh /usr/share/topgit/tg2quilt.mk --with javahelper
dh: Unknown sequence /usr/share/topgit/tg2quilt.mk (choose from: binary
binary-arch binary-indep build build-arch build-indep clean install install-arch
install-indep)
xsltproc -''-nonet -''-param man.charmap.use.subset "0"
/usr/share/sgml/docbook/stylesheet/xsl/docbook-xsl/manpages/docbook.xsl
debian/geogebra.man.xml
I/O error : Attempt to load network entity
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
debian/geogebra.man.xml:55: warning: failed to load external entity
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;
]>
  ^
Note: Writing geogebra.1
xsltproc -''-nonet -''-param man.charmap.use.subset "0"
/usr/share/sgml/docbook/stylesheet/xsl/docbook-xsl/manpages/docbook.xsl
debian/ggthumb.man.xml
I/O error : Attempt to load network entity
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
debian/ggthumb.man.xml:55: warning: failed to load external entity
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;
]>
  ^
Note: Writing ggthumb.1
jh_build -N -mgeogebra.GeoGebra
warning: [options] bootstrap class path not set in conjunction with -source 7
warning: Supported source version 'RELEASE_6' from annotation processor
'org.netbeans.modules.openide.util.NbBundleProcessor' less than -source '7'
src/geogebra/main/Application.java:5602: warning: [removal]
traceMethodCalls(boolean) in Runtime has been deprecated and marked for removal
runtime.traceMethodCalls(on);
   ^
src/geogebra/gui/util/BrowserLauncher.java:36: warning: non-varargs call of
varargs method with inexact argument type for last parameter;
  Method getDesktop = desktopClass.getDeclaredMethod("getDesktop", 
null);
   ^
  cast to Class for a varargs call
  cast to Class[] for a non-varargs call and to suppress this warning
src/geogebra/gui/util/BrowserLauncher.java:38: warning: non-varargs call of
varargs method with inexact argument type for last parameter;
  Object desktopObj = getDesktop.invoke(null, null);
  ^
  cast to Object for a varargs call
  cast to Object[] for a non-varargs call and to suppress this warning
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
5 warnings
java.nio.file.NoSuchFileException: /tmp/geogebra.jar16755156232387376076.jar ->
/<>/geogebra-4.0.34.0+dfsg1/geogebra.jar/geogebra.jar
at 
java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
at 
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at java.base/sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:478)
at
java.base/sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:263)
at java.base/java.nio.file.Files.move(Files.java:1421)
at jdk.jartool/sun.tools.jar.Main.validateAndClose(Main.java:466)
at jdk.jartool/sun.tools.jar.Main.run(Main.java:349)
at jdk.jartool/sun.tools.jar.Main.main(Main.java:1681)
jh_build: cd debian/_jh_build.geogebra && /usr/lib/jvm/default-java/bin/jar cfm
"/<>/geogebra-4.0.34.0+dfsg1/geogebra.jar/geogebra.jar"
../_jh_manifest.geogebra * returned exit code 1
make[1]: *** [debian/rules:39: override_jh_build] Error 2
make[1]: Leaving directory '/<>/geogebra-4.0.34.0+dfsg1'
make: *** [debian/rules:19: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Bug#855811: release.debian.org: release.d.o WWW should explicitly recommend against uploading to sid during the freeze

[Paul Gevers]

Hi Sean,

On 08-03-2019 02:12, Sean Whitton wrote:
> No, I don't think so.  You have to think moderately hard to infer, "oh,
> stop uploading to sid" from that text.  I would suggest appending
> "I.e. only upload to sid changes for which you plan to request an unblock."

I the attached patch what you are looking for?

Paul
From 6bd6b8f8c8120e01084715429e09cd657c22fe8b Mon Sep 17 00:00:00 2001
From: Paul Gevers 
Date: Thu, 14 Mar 2019 19:45:02 +0100
Subject: [PATCH] freeze_policy.md add recommendation to not upload to unstable
 during the freeze

Closes: #855811
---
 www/buster/freeze_policy.md | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/www/buster/freeze_policy.md b/www/buster/freeze_policy.md
index 0e2e9fc..2e6fb72 100644
--- a/www/buster/freeze_policy.md
+++ b/www/buster/freeze_policy.md
@@ -203,7 +203,10 @@ point.
 We strongly prefer changes that can be done via unstable instead of
 testing-proposed-updates. If there are unrelated changes in unstable, you
 should consider reverting these instead of making an upload to
-testing-proposed-updates.
+testing-proposed-updates. Hence, and also because it may impact other packages
+in unstable that try to migrate to buster, it is recommended to not upload
+changes to unstable in this period that you don't intent to request an unblock
+for.
 
 
 Applying for an unblock
-- 
2.20.1



signature.asc
Description: OpenPGP digital signature

Bug#922049: libpam-poldi: ed25519 support patch

[Eric Taylor]

Dear Maintainer,

I've wrote and tested the attached patches. They seem seem to resolve this
issue. They also add infrastructure to make it easier to add support for
different signing algorithms.
diff --git a/src/util/simplelog.c b/src/util/simplelog.c
index 07191d9..5bed40d 100644
--- a/src/util/simplelog.c
+++ b/src/util/simplelog.c
@@ -228,7 +228,7 @@ static gpg_error_t
 internal_log_write (log_handle_t handle, log_level_t level,
 		const char *fmt, va_list ap)
 {
-  gpg_error_t err;
+  gpg_error_t err = 0;
 
   assert (handle->backend != LOG_BACKEND_NONE);
 
@@ -270,7 +270,6 @@ internal_log_write (log_handle_t handle, log_level_t level,
 	}
 	  
   vsyslog (LOG_MAKEPRI (LOG_AUTH, syslog_priority), fmt, ap);
-  err = 0;
 }
   else if (handle->backend == LOG_BACKEND_STREAM
 	   || handle->backend == LOG_BACKEND_FILE)
@@ -314,7 +313,6 @@ internal_log_write (log_handle_t handle, log_level_t level,
   vfprintf (stream, fmt, ap);
   putc ('\n', stream);
 
-  err = 0;
 }
 
   return err;
diff --git a/src/pam/auth-method-localdb/Makefile.am b/src/pam/auth-method-localdb/Makefile.am
index c033f16..ac528b0 100644
--- a/src/pam/auth-method-localdb/Makefile.am
+++ b/src/pam/auth-method-localdb/Makefile.am
@@ -11,7 +11,7 @@
 # ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
 # or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
 # License for more details.
-# 
+#
 # You should have received a copy of the GNU General Public License
 # along with this program; if not, write to the Free Software
 # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
diff --git a/src/pam/auth-method-localdb/auth-localdb.c b/src/pam/auth-method-localdb/auth-localdb.c
index d73808d..f9041f7 100644
--- a/src/pam/auth-method-localdb/auth-localdb.c
+++ b/src/pam/auth-method-localdb/auth-localdb.c
@@ -1,18 +1,18 @@
 /* auth-localdb.c - localdb authentication method for Poldi.
Copyright (C) 2004, 2005, 2007, 2008, 2009 g10 Code GmbH
- 
+
This file is part of Poldi.
- 
+
Poldi is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
- 
+
Poldi is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
General Public License for more details.
- 
+
You should have received a copy of the GNU General Public License
along with this program; if not, see
.  */
@@ -33,15 +33,17 @@
 
 #include "scd/scd.h"
 #include "util/support.h"
+#include "util/key-types.h"
+#include "util/debugTools.h"
 #include "auth-support/ctx.h"
 #include "auth-support/wait-for-card.h"
 
 #include "usersdb.h"
 #include "key-lookup.h"
 
-
 
 #if 0
+
 /* Currently, the localdb method doesn't require a special cookie. */
 
 static gpg_error_t
@@ -79,6 +81,7 @@ auth_method_localdb_auth_do (poldi_ctx_t ctx,
   size_t challenge_n;
   size_t response_n;
   gcry_sexp_t key;
+  key_types key_type;
   gpg_error_t err;
   char *card_username;
   const char *username;
@@ -143,8 +146,24 @@ auth_method_localdb_auth_do (poldi_ctx_t ctx,
   if (err)
 goto out;
 
+  /* Retrieve key type */
+  err = get_key_type(_type, key);
+  if(err) {
+//unsupported crypto
+log_msg_error (ctx->loghandle,
+   "Unsupported Key Type\n");
+
+   goto out;
+ }
+  /*Print out key type if debug is enabled */
+  if (ctx->debug) {
+log_msg_debug (ctx->loghandle,
+   "Key Type "
+   "`%s'", key_type_to_str(key_type));
+  }
+
   /* Generate challenge.  */
-  err = challenge_generate (, _n);
+  err = challenge_generate (, _n, key_type);
   if (err)
 {
   log_msg_error (ctx->loghandle,
@@ -154,7 +173,7 @@ auth_method_localdb_auth_do (poldi_ctx_t ctx,
 }
 
   /* Let card sign the challenge.  */
-  err = scd_pksign (ctx->scd, "OPENPGP.3",
+  err = scd_pksign (ctx->scd, "OPENPGP.3", key_type,
 		challenge, challenge_n,
 		, _n);
   if (err)
@@ -165,8 +184,47 @@ auth_method_localdb_auth_do (poldi_ctx_t ctx,
   goto out;
 }
 
+  /*DEBUG LOG S Expressions */
+  if (ctx->debug) {
+char outBuff[4096];
+gcry_sexp_t sexp_signature = NULL;
+
+switch (key_type)
+{
+  case kType_rsa:
+  err = gcry_sexp_build (_signature, NULL, "(sig-val(rsa(s%b)))",
+   response_n,response);
+break;
+
+  case kType_ecc_Ed25519:
+  err = gcry_sexp_build (_signature, NULL, "(sig-val(eddsa(r%b)(s%b)))",
+ (int)response_n/2, response,
+ (int)response_n/2, response + response_n/2);
+break;
+
+  default:
+err = GPG_ERR_CONFIGURATION;
+}//switch
+//log public key
+//log_msg_debug(ctx->loghandle, "%s","Public_KEY");
+

Bug#912549: icedtea-web FTBFS with OpenJDK 11

[Andreas Tille]

On Wed, Mar 13, 2019 at 10:25:06PM +0100, Emmanuel Bourg wrote:
> On 13/03/2019 21:30, Markus Koschany wrote:
> 
> >> please look at the new upstream 1.7.2 and 1.8 releases.

May be that's sensible for Buster+1

> > In https://bugs.debian.org/855686 Emmanuel wrote that icedtea-web will
> > be removed. I don't have a strong opinion in this case. If Michael's
> > workaround works, why not. However I think it is too late now for new
> > upstream releases as doko seems to imply.
> > 
> > Please note there are several other RC issues that are marked as pending
> > but I believe the "fix" is to remove the package from Debian.
> 
> FYI I'm working on a fix, I plan to upload it next week if it works, or
> the Michael's patch if it doesn't.

Thanks a lot.  We have simply several rdepends of this package which
would be really hard if they get lost.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#924560: cryptsetup luksOpen requires 1GB of RAM in the default configuration

[Guilhem Moulin]

Hi Milan,

On Thu, 14 Mar 2019 at 19:22:42 +0100, Milan Broz wrote:
>>> I think diverging from upstream (and other distros) with respect to
>>> default algorithms requires careful consideration.  And in that case,
>>> compared to PBKDF2 Argon2 has interesting properties (such as resistance
>>> to GPU cracking) which would be a shame not to benefit from out of the
>>> box.
> 
> For this case you need to specify PBKDF parameters directly and skip benchmark
> (these PBKDF options were added exactly for this use case).
> 
> This problem is there even with PBKDF2 for the iterations time - on some
> IoT devices with LUKS device (formatted on developer's machine) the unlocking
> time increases to many minutes. (With Argon PBKDF it is just worse because 
> memory
> can be unavailable.)

Aha, you beat me to it :-)
 
>> I guess dracut with systemd in the initrd might be affected worse,
>> than initramfs-tools. I wonder if I should open a bug report in
>> systemd, to potentially execute luks2 unlock with some locking /
>> sequentially.
> 
> FYI we know about that parallel unlocking problem already and we are trying
> to find (with systemd people) some solution (perhaps based on cgroups memory 
> limits
> and some locking).

Cool, do you have a link to refer to?  Couldn't find anything from a
quick glance at systemd's issue tracker.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#709366: autofs: automount doesn't work with numerical IPv6 address

[Mike Gabriel]

Control: tags -1 moreinfo

Hi Philippe,

On Wed, 22 May 2013 21:22:06 +0200 Philippe Latu 
 wrote:

> Package: autofs
> Version: 5.0.7-3
> Severity: wishlist
>
> Dear Maintainer,
> *** Please consider answering these questions, where appropriate ***
>
> * What led up to the situation?
> While setting up a new lab based on IPv4 NIS + IPv6 NFSv4 + IPv6 
autofs, I

> encountered an automount failure with numerical IPv6 address.
>
> Using an FQDN host name with valid  and PTR DNS RRs makes 
automount work fine.

>
> I would like to know if FQDN names are mandatory.
>
> Here are the troubleshooting steps I followed before to mail this bug 
report.

>
> ~
> 1. Numerical IPv6 static mount OK
> ~
> # mount -t nfs4 [2001:db8:feb2:10::12]:/home /ahome
> root@clnt:/home/etu# ls -lAh /ahome/etu-nis/
> total 16K
> -rw--- 1 etu-nis etu-nis 385 mai 21 2013 .bash_history
> 
>
> # mount | grep nfs4
> [2001:db8:feb2:10::12]://home on /ahome type nfs4 \
> (rw,relatime,vers=4,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp6, \
> 
timeo=600,retrans=2,sec=sys,clientaddr=2001:db8:feb2:10::11,minorversion=0, 
\

> local_lock=none,addr=2001:db8:feb2:10::12)
>
> ~~
> 2. Numerical IPv6 automount KO
> ~~
> # cat /etc/auto.master
> /ahome /etc/auto.home
>
> # cat /etc/auto.home
> * -port=2049,-fstype=nfs4 [2001:db8:feb2:10::12]:/home/&
>
> # service autofs start
> [ ok ] Starting automount
> # automount -m
>
> autofs dump map information
> ===
>
> global options: none configured
>
> Mount point: /ahome
>
> source(s):
>
> instance type(s): file
> map: /etc/auto.home
>
> * | -port=2049,-fstype=nfs4 [2001:db8:feb2:10::12]:/home/&
>
> # ls -lAh /ahome/etu-nis

I will provide an upload of autofs to experimental soon where I will 
close this bug. The fix enables libtirpc support in autofs which helps 
with IPv6 DNS hostname resolution. Please check, if IPv6 IP number 
support is working with the upcoming version (5.1.5-1).


If not, please reopen.

Thanks,
Mike

Bug#924560: cryptsetup luksOpen requires 1GB of RAM in the default configuration

[Guilhem Moulin]

Control: tag -1 + wontfix
Control: tag -1 - moreinfo
Control: severity -1 normal

On Thu, 14 Mar 2019 at 17:31:05 +, Dimitri John Ledkov wrote:
> On Thu, 14 Mar 2019 at 16:55, Guilhem Moulin  wrote:
>> AFAICT it does.  What I guess doesn't is if the machine's resources are
>> significantly reduced between luksFormat/luksAddKey and luksOpen.
> 
> I guess that is the reason here. Majority of IoT / pi / etc devices
> might prepare rootfs / SDcard / golden image / etc on a bigger
> developer machine, prior to flashing it onto SDcard to then deploy on
> the target device.

I see.

> So the solution there is to run the benchmark on the device, once,
> record parameters and use those when creating the golden image for
> memory, threads and possibly iterations too?

Yup, you can re-use the parameters from a previous benchmark run on the
target system (where the volume will be unlocked) and use it to
luksFormat elsewhere.

This applies to PBKDF2 too by the way, though skipping this step doesn't
have the same severity; for PBKDF2 the benchmark only affect the
iteration time, so if the volume is formatted on a fast system, unlocking
on a slower one will slower than it should be (but won't OOM).

> I wonder if I should open a bug report in systemd, to potentially
> execute luks2 unlock with some locking / sequentially.

Seems sensible.
 
> I guess this bug should be tagged wontfixing and lowered priority to
> normal, or something.

Alright :-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#924592: ITP: hcxdumptool -- Small tool to capture packets from wlan devices

[Paulo Roberto Alves de Oliveira (aka kretcheu)]

Package: wnpp
Severity: wishlist
Owner: "Paulo Roberto Alves de Oliveira (aka kretcheu)" 

* Package name: hcxdumptool
  Version : 5.1.4
  Upstream Author : ZeroBeat
* URL : https://github.com/ZerBea/hcxdumptool
* License : MIT
  Programming Lang: C
  Description : Small tool to capture packets from wlan devices

 Tool to run several tests to determine if wifi access points or clients are
 vulnerable.

 This package is used with wifite to get pmkid handshake from some wifi access
 points without connected clients.

Bug#924560: [pkg-cryptsetup-devel] Bug#924560: cryptsetup luksOpen requires 1GB of RAM in the default configuration

[Milan Broz]

>> I think diverging from upstream (and other distros) with respect to
>> default algorithms requires careful consideration.  And in that case,
>> compared to PBKDF2 Argon2 has interesting properties (such as resistance
>> to GPU cracking) which would be a shame not to benefit from out of the
>> box.

For this case you need to specify PBKDF parameters directly and skip benchmark
(these PBKDF options were added exactly for this use case).

This problem is there even with PBKDF2 for the iterations time - on some
IoT devices with LUKS device (formatted on developer's machine) the unlocking
time increases to many minutes. (With Argon PBKDF it is just worse because 
memory
can be unavailable.)

So the suggestion above is correct - you need to measure some viable
parameters and use them directly.

If you run luksFormat on a small IoT system directly, it trims parameters and
memory use according to system (it will never use more than half of physical
available memory).
...

> I guess dracut with systemd in the initrd might be affected worse,
> than initramfs-tools. I wonder if I should open a bug report in
> systemd, to potentially execute luks2 unlock with some locking /
> sequentially.

FYI we know about that parallel unlocking problem already and we are trying
to find (with systemd people) some solution (perhaps based on cgroups memory 
limits
and some locking).
(Parallel unlocking can cause OOM killer to kill even different processes here.)

You can change PBKDF parameters for existing device (preserving data) with
cryptsetup luksConvertKey command, it takes the same PBKDF options.
(So you can "downgrade" to PBKDF2 or decrease limits.)

Milan

Bug#708256: Does this autofs bug also happen with a i386 kernel

[Mike Gabriel]

Control: tags -1 wontfix
Control: close -1

Hi,

On Mon, 19 Aug 2013 10:16:54 -0400 "John E. Davis"  
wrote:
> On Mon, 19 Aug 2013 10:55:38 +0200, Reinhard Tartler 
 said:

> >from your logs, I notice that you are running an i386 userland with
> >amd64 kernel. Can you confirm the segfaults also with a non-mixed
> >setup, that is, a i386 kernel with i386 userland, or an amd64 kernel
> >with amd64 userland?
>
> With a non-mixed setup, there is no problem. Thanks, --John
>

Well then, we won't fix this for wheezy anymore and it may even not be 
fixable with mixed architectures of autofs kernel module and userland 
daemon.


Mike

Bug#910367: autofs: No way to mount smb share with a dollar sign at the end

[Mike Gabriel]

Hi,

On Fri, 05 Oct 2018 14:18:08 +0200 Vincent Danjean  
wrote:

> Package: autofs
> Version: 5.1.2-1
> Severity: important
>
> Hi,
>
> Since stretch update, there is no way to automount a smb share with a 
'$' at
> the end of its name anymore. But these names are automaticcaly 
generated by

> windows when the share is hidden by default...
>
> The auto.smb script has a awk script to protect the '$' character.
> It works for the local mount path and options (cf user='...' 
parameter below),

> but not for the server path.
>
> # /etc/auto.smb nas-stbm
> -fstype=cifs,multiuser,cruid=0,sec=krb5,user="HOSTNAME\$" \
> "/GENOME$" "://nas-stbm/GENOME\$" \
> [...]
>
> I tweak /etc/auto.smb to get the options I wanted. But I tried
> to generate both version (quoted or not) :
> A: "/GENOME$" "://nas-stbm/GENOME\$"
> B: "/GENOME$" "://nas-stbm/GENOME$"
>
> Both fails.
> Running autofs in debug mode, for A, I got:
> Oct 5 13:30:50 ge91097 automount[14285]: attempting to mount entry 
/srv/cifs2/nas-stbm/GENOME$
> Oct 5 13:30:50 ge91097 automount[14285]: lookup_mount: 
lookup(program): /srv/cifs2/nas-stbm/GENOME$ -> 
-fstype=cifs,multiuser,cruid=0,sec=krb5,user=HOSTNAME\$ ://nas-stbm/GENOME\$
> Oct 5 13:30:50 ge91097 automount[14285]: parse_mount: parse(sun): 
expanded entry: -fstype=cifs,multiuser,cruid=0,sec=krb5,user=HOSTNAME\$ 
://nas-stbm/GENOME\$
> Oct 5 13:30:50 ge91097 automount[14285]: parse_mount: parse(sun): 
gathered options: fstype=cifs,multiuser,cruid=0,sec=krb5,user=HOSTNAME$
> Oct 5 13:30:50 ge91097 automount[14285]: sun_mount: parse(sun): 
mounting root /srv/cifs2/nas-stbm/GENOME$, mountpoint 
/srv/cifs2/nas-stbm/GENOME$, what //nas-stbm/GENOME\$, fstype cifs, 
options multiuser,cruid=0,sec=krb5,user=HOSTNAME$
> Oct 5 13:30:50 ge91097 automount[14285]: do_mount: 
//nas-stbm/GENOME\$ /srv/cifs2/nas-stbm/GENOME$ type cifs options 
multiuser,cruid=0,sec=krb5,user=HOSTNAME$ using module generic
> Oct 5 13:30:50 ge91097 automount[14285]: mount_mount: mount(generic): 
calling mkdir_path /srv/cifs2/nas-stbm/GENOME$
> Oct 5 13:30:50 ge91097 automount[14285]: mount_mount: mount(generic): 
calling mount -t cifs -o multiuser,cruid=0,sec=krb5,user=HOSTNAME$ 
//nas-stbm/GENOME\$ /srv/cifs2/nas-stbm/GENOME$

> => note the '\' before '$' that is kept in the server path
> [...]
> Oct 5 13:30:50 ge91097 automount[14285]: mount(generic): failed to 
mount //nas-stbm/GENOME\$ (type cifs) on /srv/cifs2/nas-stbm/GENOME$

>
> For B, I got:
> Oct 5 13:43:17 ge91097 automount[15058]: lookup_mount: 
lookup(program): /srv/cifs2/nas-stbm/GENOME$ -> 
-fstype=cifs,multiuser,cruid=0,sec=krb5,user=HOSTNAME\$ ://nas-stbm/GENOME$
> Oct 5 13:43:17 ge91097 automount[15058]: parse_mount: parse(sun): 
expanded entry: -fstype=cifs,multiuser,cruid=0,sec=krb5,user=HOSTNAME\$ 
://nas-stbm/GENOME
> Oct 5 13:43:17 ge91097 automount[15058]: parse_mount: parse(sun): 
gathered options: fstype=cifs,multiuser,cruid=0,sec=krb5,user=HOSTNAME$
> Oct 5 13:43:17 ge91097 automount[15058]: sun_mount: parse(sun): 
mounting root /srv/cifs2/nas-stbm/GENOME$, mountpoint 
/srv/cifs2/nas-stbm/GENOME$, what //nas-stbm/GENOME, fstype cifs, 
options multiuser,cruid=0,sec=krb5,user=HOSTNAME$
> Oct 5 13:43:17 ge91097 automount[15058]: do_mount: //nas-stbm/GENOME 
/srv/cifs2/nas-stbm/GENOME$ type cifs options 
multiuser,cruid=0,sec=krb5,user=HOSTNAME$ using module generic
> Oct 5 13:43:17 ge91097 automount[15058]: mount_mount: mount(generic): 
calling mkdir_path /srv/cifs2/nas-stbm/GENOME$
> Oct 5 13:43:17 ge91097 automount[15058]: mount_mount: mount(generic): 
calling mount -t cifs -o multiuser,cruid=0,sec=krb5,user=HOSTNAME$ 
//nas-stbm/GENOME /srv/cifs2/nas-stbm/GENOME$

> => note the missing '$' in the server path
> [...]
> Oct 5 13:43:17 ge91097 automount[15058]: mount(generic): failed to 
mount //nas-stbm/GENOME (type cifs) on /srv/cifs2/nas-stbm/GENOME$

>
>
> I workaround the problem by renaming /sbin/mount.cifs into 
mount.cifs.real

> and writing the following script in /sbin/mount.cifs:
> #!/bin/bash
> SHARE="${1/\\\$/\$}"
> shift
> exec "$0".real "$SHARE" "$@"
>
>
> Please, propose a way (whatever it is) to quote the share name.

This is interesting. The double quote feature for the "$" sign in 
locations got added in 2007 [1].


Maybe a regression?

Mike

[1] 
https://git.kernel.org/pub/scm/linux/storage/autofs/autofs.git/commit/?id=3243d2ffbe53eb3fe24e03b239ffcc5cb21e75e4

Bug#924591: fastboot format:ext4 misses /usr/lib/android-sdk/platform-tools/mke2fs

[Jonas Meurer]

Package: fastboot
Version: 1:8.1.0+r23-4
Severity: serious

Hello,

after dist-upgrade to Buster, 'fastboot format:ext4' is broken. It tries
to execute '/usr/lib/android-sdk/platform-tools/mke2fs' which doesn't
exist and is not available in the Debian archive:

$ fastboot format:ext4:0xcd3771e00 userdata
Warning: userdata size is0xcd3779e00, but 0xcd3771e00 was requested for 
formatting.
Invalid erase-block-size 512: must be a power of 2 and at least 4096.
Invalid logical-block-size 512: must be a power of 2 and at least 4096.
/usr/lib/android-sdk/platform-tools/mke2fs failed with status 1
mke2fs failed: 1
error: Cannot generate image for userdata

$ ls /usr/lib/android-sdk/platform-tools/mke2fs
ls: cannot access '/usr/lib/android-sdk/platform-tools/mke2fs': No such file or 
directory


I chose severity serious as this bug is a severe regression that makes
'fastboot format' unusable. Therefore, the bug should be fixed before
the release of Buster.

Cheers
 jonas


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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fastboot depends on:
ii  android-libadb 1:8.1.0+r23-4
ii  android-libbase1:8.1.0+r23-4
ii  android-libcutils  1:8.1.0+r23-4
ii  android-libf2fs-utils  8.1.0+r23-2
ii  android-libsparse  1:8.1.0+r23-4
ii  android-libutils   1:8.1.0+r23-4
ii  android-libziparchive  1:8.1.0+r23-4
ii  libc6  2.28-8
ii  libgcc11:8.3.0-2
ii  libstdc++6 8.3.0-2

fastboot recommends no packages.

fastboot suggests no packages.

-- no debconf information

Bug#861992: autofs: Fail while installing (arm64)

[Mike Gabriel]

Control: tags -1 moreinfo

Hi,

On Sun, 07 May 2017 10:22:06 +0500 Anton Karmanov 
 wrote:

> Package: autofs
> Version: 5.0.8-2+deb8u1
> Severity: important
>
> Dear Maintainer,
> I'am trying to get autofs package whith apt on an arm64 machine.
> During installation I get the messages:
>
> Setting up autofs (5.0.8-2+deb8u1) ...
> update-rc.d: warning: start and stop actions are no longer supported; 
falling back to defaults
> Job for autofs.service failed. See 'systemctl status autofs.service' 
and 'journalctl -xn' for details.

> invoke-rc.d: in itscript autofs, action "start" failed.
> dpkg: error processing package autofs (--configure):
> subprocess installed post-installation script returned error exit 
status 1

> Errors were encountered while processing:
> autofs
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> After all autofs has been installed, but systemd fails to start it's 
unit.


Please switch autofs to debug mode (/etc/autofs.conf) and provide the logs.

Thanks,
Mike

Bug#924590: freeipa-client: /usr/local/share/ca-certificates/ipa-ca.crt contains multiple certificates and extra non-certificate data

[Sam Morris]

Package: freeipa-client
Version: 4.7.2-2
Severity: wishlist

My FreeIPA's CA certificate is signed by an external root CA certificate.
Consequenty, ipa-client-install puts both the external root CA certificate
and the intermediate CA certificate into
/usr/local/share/ca-certificates/ipa-ca.crt.

This has caused problems with the clients of ca-certificates in the
past. For instance, p11-kit expects the files in that directory to not
contain any comments or other text. When it encountered the file that
ipa-client-install put there, it 'failed shut' and as a result the trust
list ended up being empty!

This was fixed on the p11-kit end, but on reflection I feel that even
though the exact specification of what is valid in
/usr/local/share/ca-certificates is not written down anywhere,
freeipa-client should not violate the following rules:

 1. .crt files in that directory should only contain root CA certificates
 2. .crt files in that directory should not contain comments or any
non-certificate data
 3. .crt files in that directory should contain only one certificate

You might argue that if update-ca-certificates wants to enforce any or
all of the above rules, that it should at least warn when they are
violated and skip the file, rather than silently including it into
/etc/ssl/certs/ca-certificates.crt for it to confuse clients. I wouldn't
necessarily disagree; feel free to reassign this to ca-certificates if
that is the case, for the maintainers of that package to consider if
what freeipa-client is doing is right or wrong. :)

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (570, 'testing-debug'), (570, 'testing'), (540, 
'unstable-debug'), (540, 'unstable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages freeipa-client depends on:
ii  bind9utils   1:9.11.5.P4+dfsg-1
ii  certmonger   0.79.6-1
ii  curl 7.64.0-1
ii  dnsutils 1:9.11.5.P4+dfsg-1
ii  freeipa-common   4.7.2-2
ii  krb5-user1.17-2
ii  libbasicobjects0 0.6.1-2
ii  libc62.28-8
ii  libcollection4   0.6.1-2
ii  libcom-err2  1.44.5-1
ii  libini-config5   0.6.1-2
ii  libk5crypto3 1.17-2
ii  libkrb5-31.17-2
ii  libldap-2.4-22.4.47+dfsg-3
ii  libnspr4 2:4.20-1
ii  libnss-sss   1.16.3-3.1
ii  libnss3  2:3.42.1-1
ii  libnss3-tools2:3.42.1-1
ii  libpam-sss   1.16.3-3.1
ii  libpopt0 1.16-12
ii  libref-array10.6.1-2
ii  libsasl2-2   2.1.27+dfsg-1
ii  libsasl2-modules-gssapi-mit  2.1.27+dfsg-1
ii  libssl1.11.1.1b-1
ii  libsss-sudo  1.16.3-3.1
ii  libxmlrpc-core-c31.33.14-8+b1
ii  oddjob-mkhomedir 0.34.4-1
ii  python   2.7.15-4
ii  python-dnspython 1.16.0-1
ii  python-gssapi1.4.1-1+b1
ii  python-ipaclient 4.7.2-2
ii  python-ldap  3.1.0-2
ii  python-sss   1.16.3-3.1
ii  sssd 1.16.3-3.1

Versions of packages freeipa-client recommends:
ii  chrony  3.4-2

Versions of packages freeipa-client suggests:
pn  libpam-krb5  

-- no debconf information

Bug#740647: lwipv6: use dh-autoreconf instead of autotools-dev to fix FTBFS on ppc64el

[Roger]

With Version 1.5a-4, build is now successful on buster - Does that mean
that bug can be closed ?

Thanks


On Mon, 03 Mar 2014 14:38:46 -0500 Logan Rosen 
wrote:
> Package: lwipv6
> Version: 1.5a-2
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu trusty ubuntu-patch
> 
> Dear Maintainer,
> 
> For the ppc64el architecture in Ubuntu, since this package uses libtool, a 
> full
> autoreconf is necessary instead of just config.{sub,guess} updates with
> autotools-dev. This is because we need new libtool macros for ppc64el.
> 
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * Use dh-autoreconf instead of autotools-dev to fix FTBFS on ppc64el.
> 
> Thanks for considering the patch.
> 
> Logan Rosen
> 
> 
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers trusty-updates
>   APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 
> 'trusty'), (100, 'trusty-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.13.0-14-generic (SMP w/1 CPU core)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash

Bug#897897: Kernel security fix (for CVE-2018-1108) -> AutoFS won't start

[Mike Gabriel]

Control: close -1

Hi Cedric,

On Sun, 13 May 2018 10:07:58 +0200 
=?UTF-8?Q?C=c3=a9dric_Dufour_-_Idiap_Research_Institute?=

 wrote:
> It seems this problem is adressed more globally as per bug #897599: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897599

>
> Which led to fix for CVE-2018-1108 being reverted (temporarily ?), as 
per DSA 2018-4096: https://www.debian.org/security/2018/dsa-4196

> --
> Cédric Dufour @ Idiap Research Institute

I will close this bug for now. I agree that waiting for entropy is 
something that service should avoid.


And I also agree that autofs should receive some 
restart-if-no-working-correctly-logic.


However, this specific bug, I will close now. Feel free to reopen and 
retitle if you think it is needed.


Thanks,
Mike

Bug#924589: node-formidable: Unusable with Node.js >= 7

[Xavier Guimard]

Package: node-formidable
Version: 1.0.13-1
Severity: grave
Tags: upstream
Justification: renders package unusable

node-formidable is unusable with Node.js >=7:

  Error [ERR_NO_LONGER_SUPPORTED]: Buffer.write(string, encoding, offset[, 
length]) is no longer supported
at Buffer.write (buffer.js:926:11)
at MultipartParser.initWithBoundary 
(/usr/lib/nodejs/formidable/multipart_parser.js:61:17)
at IncomingForm._initMultipart 
(/usr/lib/nodejs/formidable/incoming_form.js:299:10)
at IncomingForm._parseContentType 
(/usr/lib/nodejs/formidable/incoming_form.js:246:12)
at IncomingForm.writeHeaders 
(/usr/lib/nodejs/formidable/incoming_form.js:125:8)
at IncomingForm.parse (/usr/lib/nodejs/formidable/incoming_form.js:117:8)
...

According to https://github.com/felixge/node-formidable it has to be
upgraded at least to version 1.1.1

Cheers,
Xavier

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (600, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages node-formidable depends on:
ii  nodejs  10.15.2~dfsg-1

node-formidable recommends no packages.

node-formidable suggests no packages.

-- no debconf information

Bug#924588: ITP: Standford Javascript Crypto Library - sjcl

[Joseph Nuthalapati]

Package: wnpp
Severity: wishlist
Owner: Joseph Nuthalapati 

* Package name: node-sjcl
  Version : 1.0.8
  Upstream Authors : Emily Stark, Mike Hamburg and Dan Boneh
* URL : https://github.com/bitwiseshiftleft/sjcl
* License : BSD-2-Clause OR GPL-2.0-only
  Programming Lang: Javascript
  Description : SJCL is a library for cryptography in Javascript

The Stanford Javascript Crypto Library is a project by the
Stanford Computer Security Lab to build a secure, powerful,
fast, small, easy-to-use, cross-browser library for cryptography
in Javascript.

SJCL uses the industry-standard AES algorithm at 128, 192 or 256
bits; the SHA256 hash function; the HMAC authentication code; the
PBKDF2 password strengthener; and the CCM and OCB
authenticated-encryption modes with sensible defaults.

SJCL has no dependencies.

-- 
Regards,
Joseph Nuthalapati



signature.asc
Description: OpenPGP digital signature

Bug#832628: autofs: Autofs does not unmount mounted filesystems after HUP

[Mike Gabriel]

Control: fixed -1 5.1.0-1
Control: tags -1 jessie

HI,

On Wed, 27 Jul 2016 16:05:17 -0400 Colten Levi 
 wrote:

> Package: autofs
> Version: 5.0.8-2+deb8u1
> Severity: important
> Tags: patch
>
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
> I was able to patch autofs 5.0.8 with:
> 
https://www.kernel.org/pub/linux/daemons/autofs/v5/patches-5.0.9/autofs-5.0.8-fix-task-manager-not-getting-signaled.patch

> That patch was effective.
>
> * What was the outcome of this action?
> The automount process is responsive to USR1 and TERM, and also unmounts
> expired mounts after running the patched code.
>
> * What outcome did you expect instead?
> I would like to ask the maintainer to apply the patch to the autofs
> 5.0.8 package to Jessie.

It seems that this issue has been fixed since Debian upload 5.1.0-1.

Thus adding the necessary meta data to this bug and marking the bug as a 
jessie-only issue.


Mike

Bug#924587: please add nfs-idmapd.service to nfs-client.target

[Mike Gabriel]

Package: nfs-common
Severity: important
Version: 1:1.3.4-2.4
X-Debbugs-Cc: debian-...@lists.debian.org
User: debian-...@lists.debian.org
Usertags: debian-edu

Dear maintainers,

we are trying to fix a race condition between autofs(-ldap), the NFSv4  
client service stack and the network-online.target.


What test results have shown is that adding nfs-idmapd.service to  
nfs-client.target helps a lot to narrow down system boots where NFS  
homes would not be accessible albeit a started autofs(-ldap).


For details, see [1].

Thanks,
Mike Gabriel

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842199

--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpKZ73iPuBGT.pgp
Description: Digitale PGP-Signatur

Bug#924581: lintian: license-problem-gfdl-invariants false positive in src:linux's fdl-appendix.rst

[Ben Hutchings]

On Thu, 2019-03-14 at 11:49 -0400, Chris Lamb wrote:
> Package: lintian
> Version: 2.9.1~bpo9+1
> Severity: normal
> X-Debbugs-CC: ans...@debian.org, b...@decadent.org.uk, 
> ftpmas...@ftp-master.debian.org>
> 
> Ansgar wrote:
> 
> > Ben Hutchings writes:
> > > On Wed, 2019-03-13 at 12:07 +, Debian FTP Masters wrote:
> > > > linux source: lintian output: 'license-problem-gfdl-invariants
> > > > Documentation/media/uapi/fdl-appendix.rst invariant part is:
> > > > published by the free software .. foundation, with no invariant
> > > > sections, no front-cover texts .. and no back-cover texts',
> > > > automatically rejected package.
> > > > linux source: If you have a good reason, you may override this lintian 
> > > > tag.
> > > 
> > > We keep getting false positives for this, because lintian doesn't
> > > recognise the "no invariant sections" part with markup.  This should
> > > not be an auto-reject.
> > 
> > I've removed it from the list of auto-rejects for now[1].  Also CC'ed
> > the lintian maintainers to make them aware of the problem (if they
> > aren't already).
> > 
> > Ansgar
> > 
> >   [1] 
> > https://salsa.debian.org/ftp-team/dak/commit/44fe84b9e24c59ac932f303cd25f1df3b8a20e82
> 
> (We were not aware.) Filing bug so this doesn't get lost…

I don't think it is practicable for lintian to recognise arbitrary
markup within the sentence, which is why I previously overrode the
warning for other files rather than opening a bug.  So my complaint was
not that lintian warned at all, but that this was treated as being a
sufficiently reliable check as to trigger an auto-reject.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered
an expert.




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

Bug#842199: autofs should pull in network-online.target and nfs-client.target and related issues

[Mike Gabriel]

Hi Daniel,

I am currently adopting the orphaned autofs package. The issue you 
reported here as something that we have been observing in Debian Edu 
deployments for years. Thanks for proposing a fix.


On Wed, 26 Oct 2016 13:28:01 -0700 Daniel Lakeland 
 wrote:

>
> Package: autofs
> Version: 5.1.1-1
> Severity: important
> Tags: patch
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where
> appropriate ***
>
> * What led up to the situation?
>
> Boot machine that has autofs configured to mount directories under
> /home/ via nfs4.
> The machine comes up but directories don't get mounted.
>
> For this to work properly we need several things to happen:
>
> 1) rpc.idmapd and rpc.gssd need to run
> 2) autofs needs to start up after the network is online
>
> Add the following line to autofs.system
> Requires=network-online.target nfs-client.target
>
> Add the following line to nfs-client.target
> Requires=nfs-idmapd.service rpc-gssd.service
>
> After these changes, autofs starts up late enough that the network is
> online, and
> when it tries to mount nfs4 mounts it works

However, I suspect that we cannot entangle autofs and NFS as much as you 
propose here. Note that people also may use autofs for local device 
mounting and don't run NFS with it at all.


So, for the autofs side of things, I propose this (a Wants= solution 
rather than a Requires= solution):


```
commit 9e1569ac32e53a6b364241fe68377579ffcbd5db (HEAD -> master)
Author: Mike Gabriel 
Date:   Thu Mar 14 15:04:46 2019 +0100

    debian/autofs.service: Add nfs-client.target to Wants= key. 
Hopefully, this is sufficient to fix #842199, if not, please reopen the 
bug. (Closes: #842199).


diff --git a/debian/autofs.service b/debian/autofs.service
index 8d7afa2..33a3d4e 100644
--- a/debian/autofs.service
+++ b/debian/autofs.service
@@ -1,7 +1,7 @@
 [Unit]
 Description=Automounts filesystems on demand
 After=network.target ypbind.service sssd.service network-online.target 
remote-fs.target

-Wants=network-online.target
+Wants=network-online.target nfs-client.target

 [Service]
 Type=forking
```

You possibly may want to check, if that works as well. We will do heavy 
testing here soon, too.


Mike

Bug#924560: [pkg-cryptsetup-devel] Bug#924560: cryptsetup luksOpen requires 1GB of RAM in the default configuration

[Dimitri John Ledkov]

On Thu, 14 Mar 2019 at 16:55, Guilhem Moulin  wrote:
>
> > For example many IoT and Pi devices have 1GB of ram in total, and thus
> > would OOM kill when trying to luksOpen.
>
> Is that something you experienced?  I just deployed a fresh a Debian sid
> VM with 2vCPUs, 1GiB RAM a default encryption stack (LVM2 on top of
> LUKS/dm-crypt).  Works just fine :-)  The actual memory cost is about
> half of the physical memory.
>
> Works equally fine on a VM with 512MiB RAM.  There the memory cost is
> set to ~250MiB.
>

Nice.

> > Please consider reducing the default memory requirement of the argon2i
> > in luks2 by default, or switching to pbkdf2 for LUKS2 as well.
>
> I think diverging from upstream (and other distros) with respect to
> default algorithms requires careful consideration.  And in that case,
> compared to PBKDF2 Argon2 has interesting properties (such as resistance
> to GPU cracking) which would be a shame not to benefit from out of the
> box.
>
> > I think it is unfortunate to not support default encryption on 1GB big
> > devices and VMs.
>
> AFAICT it does.  What I guess doesn't is if the machine's resources are
> significantly reduced between luksFormat/luksAddKey and luksOpen.
>

I guess that is the reason here. Majority of IoT / pi / etc devices
might prepare rootfs / SDcard / golden image / etc on a bigger
developer machine, prior to flashing it onto SDcard to then deploy on
the target device.

So the solution there is to run the benchmark on the device, once,
record parameters and use those when creating the golden image for
memory, threads and possibly iterations too? I.e. I think I managed to
use

printf test | sudo cryptsetup luksFormat --debug --key-file=-
--pbkdf-memory=505372 --pbkdf-parallel=2 --pbkdf-force-iterations=4
/dev/nbd0

To create an "easy" encrypted filesystem with matching algo parameters
for a "small" device, on my "big" desktop.

> OTOH parallel unlocking might be an issue indeed, especially if the
> devices are unlocked in an unattended fashion (for instance via key
> files).  That said on my 1GiB VM I could reliably boot with
>
> $ cat /etc/crypttab
> root_crypt /dev/vda4  noneluks
> swap_crypt /dev/vda2  /etc/keys/swap.key  luks,swap
> home_crypt /dev/vda3  /etc/keys/home.key  luks
>
> (root_crypt being unlocked an initramfs stage, the other two later by
> systemd) and
>
> $ cat /etc/fstab
> /dev/vda1   /boot  ext2  defaults  0  2
> /dev/mapper/swap_crypt  none   swap  sw0  0
> /dev/mapper/root_crypt  /  ext4  defaults  0  1
> /dev/mapper/home_crypt  /home  ext4  defaults  0  2
>
> However the OOM killer does trigger when I add a third volume.  I guess
> the boot process is racy and might, or might not, abort depending on
> what's being started at the same time.  But I'd argue that setup is far
> from a typical installation, and the same goes for low-memory devices
> with plenty of encrypted disks attached.  (Moreover Debian's default
> initramfs implementation comes from initramfs-tools, where unlocking is
> sequential.  So root-device encryption is out of the picture.)
>
> Having a separate encrypted /home partition (unlocked by systemd)
> doesn't seem to cause any problem when formatted with the default
> parameters, which I understood is what this bug report is about.
>

I guess dracut with systemd in the initrd might be affected worse,
than initramfs-tools. I wonder if I should open a bug report in
systemd, to potentially execute luks2 unlock with some locking /
sequentially.

Similarly, I shall probably back out hardcoding of --pbkdf pbkdf out
of s390-tools zkey.

I guess this bug should be tagged wontfixing and lowered priority to
normal, or something.

-- 
Regards,

Dimitri.

Bug#924586: uwsgi: drop unecessary libqdbm-dev build-depends

[Andreas Hasenack]

Package: uwsgi
Version: 2.0.18-1
Severity: low

Dear Maintainer,

uwsgi got a libqdbm-dev build dependency on 1.9.11-1:
uwsgi (1.9.11-1) unstable; urgency=low
(...)
  * New binary package uwsgi-plugin-php. (Closes: #699174)
- New Build-Depends libphp5-embed, php5-dev, libonig-dev, libdb-dev,
  libqdbm-dev and libbz2-dev.
(...)
 -- Janos Guljas   Mon, 27 May 2013 03:55:54 +0200

The uwsgi-plugin-php package was however later dropped:
uwsgi (2.0.15-10) unstable; urgency=medium

  * Simplify packaging by offloading some parts to separate source:
+ Stop build plugins for PHP.
+ Drop binary package uwsgi-plugin-php.
+ Stop build-depend on php-dev libphp-embed.
(...)
 -- Jonas Smedegaard   Fri, 20 Oct 2017 16:13:39 +0200

But the build-depends was left. Looking at the produced deb binaries,
and reverse-depends, there is nothing in uwsgi linking to libqdbm
anymore. There is no hit for the string "qdbm" either in the build
logs, other than installing the unused build dependency.

If my analysis is correct, I suggest to drop the libqdbm-dev build dependency.

Bug#924560: [pkg-cryptsetup-devel] Bug#924560: cryptsetup luksOpen requires 1GB of RAM in the default configuration

[Guilhem Moulin]

Control: tag -1 moreinfo

Hi Dimitri,

On Thu, 14 Mar 2019 at 12:36:13 +, Dimitri John Ledkov wrote:
> Currently the new cryptsetup defaults to LUKS2 format with the
> following parameters:
> 
> Default PBKDF for LUKS2: argon2i
> Iteration time: 2000, Memory required: 1048576kB, Parallel threads: 4

The actual parameters used for the KDF are determined by benchmark upon
luksFormat (or luksAddKey).  See cryptsetup(8):

--pbkdf 
[…]

Note that increasing memory cost also increases time, so the final
parameter values are measured by a benchmark. The benchmark tries to
find iteration time (--iter-time) with required memory cost
--pbkdf-memory. If it is not possible, the memory cost is decreased
as well. The parallel cost --pbkdf-parallel is constant, is is
checked against available CPU cores (if not available, it is
decreased) and the maximum parallel cost is 4.

> For example many IoT and Pi devices have 1GB of ram in total, and thus
> would OOM kill when trying to luksOpen.

Is that something you experienced?  I just deployed a fresh a Debian sid
VM with 2vCPUs, 1GiB RAM a default encryption stack (LVM2 on top of
LUKS/dm-crypt).  Works just fine :-)  The actual memory cost is about
half of the physical memory.

$ cryptsetup luksDump /dev/vda5 | grep -Fe "Time cost:" -e "Memory:" -e 
"Threads:"
Time cost:  4
Memory: 505372
Threads:2

$ dd if=/dev/zero of=/tmp/disk.img bs=1M count=64
$ printf test | cryptsetup luksFormat --debug --key-file=- /tmp/disk.img
[…]
# Running argon2i() benchmark.
# PBKDF benchmark: memory cost = 32, iterations = 4, threads = 2 (took 2 ms)
# PBKDF benchmark: memory cost = 512, iterations = 4, threads = 2 (took 1 
ms)
# PBKDF benchmark: memory cost = 8192, iterations = 4, threads = 2 (took 18 
ms)
# PBKDF benchmark: memory cost = 113777, iterations = 4, threads = 2 (took 
233 ms)
# PBKDF benchmark: memory cost = 122078, iterations = 4, threads = 2 (took 
234 ms)
# PBKDF benchmark: memory cost = 130425, iterations = 4, threads = 2 (took 
249 ms)
# PBKDF benchmark: memory cost = 130948, iterations = 4, threads = 2 (took 
251 ms)
# PBKDF benchmark: memory cost = 505422, iterations = 8, threads = 2 (took 
2015 ms)
# Benchmark returns argon2i() 8 iterations, 505422 memory, 2 threads (for 
512-bits key).
[…]
Command successful.

$ printf test | cryptsetup luksOpen --debug --key-file=- /tmp/disk.img 
crypt_disk
[…]
# Only 2 active CPUs detected, PBKDF threads decreased from 4 to 2.
# Not enough physical memory detected, PBKDF max memory decreased from 
1048576kB to 505422kB.
# PBKDF argon2i, hash sha256, time_ms 2000 (iterations 0), max_memory_kb 
505422, parallel_threads 2.
[…]
Command successful.

Works equally fine on a VM with 512MiB RAM.  There the memory cost is
set to ~250MiB.

> Please consider reducing the default memory requirement of the argon2i
> in luks2 by default, or switching to pbkdf2 for LUKS2 as well.

I think diverging from upstream (and other distros) with respect to
default algorithms requires careful consideration.  And in that case,
compared to PBKDF2 Argon2 has interesting properties (such as resistance
to GPU cracking) which would be a shame not to benefit from out of the
box.

> I think it is unfortunate to not support default encryption on 1GB big
> devices and VMs.

AFAICT it does.  What I guess doesn't is if the machine's resources are
significantly reduced between luksFormat/luksAddKey and luksOpen.

OTOH parallel unlocking might be an issue indeed, especially if the
devices are unlocked in an unattended fashion (for instance via key
files).  That said on my 1GiB VM I could reliably boot with

$ cat /etc/crypttab 
root_crypt /dev/vda4  noneluks
swap_crypt /dev/vda2  /etc/keys/swap.key  luks,swap
home_crypt /dev/vda3  /etc/keys/home.key  luks

(root_crypt being unlocked an initramfs stage, the other two later by
systemd) and

$ cat /etc/fstab 
/dev/vda1   /boot  ext2  defaults  0  2
/dev/mapper/swap_crypt  none   swap  sw0  0
/dev/mapper/root_crypt  /  ext4  defaults  0  1
/dev/mapper/home_crypt  /home  ext4  defaults  0  2

However the OOM killer does trigger when I add a third volume.  I guess
the boot process is racy and might, or might not, abort depending on
what's being started at the same time.  But I'd argue that setup is far
from a typical installation, and the same goes for low-memory devices
with plenty of encrypted disks attached.  (Moreover Debian's default
initramfs implementation comes from initramfs-tools, where unlocking is
sequential.  So root-device encryption is out of the picture.)

Having a separate encrypted /home partition (unlocked by systemd)
doesn't seem to cause any problem when formatted with the default
parameters, which I understood is what this bug report is about.

Cheers,
-- 
Guilhem

Bug#916797: linux-image-4.19.0-1-amd64-unsigned: 4.19 + amdgpu + 144 hz = screen corruption / flickering

[Axel Regnat]

I'm going to close the bug. It only affects kernel 4.19. The newer 
Kernels like 4.20 or 5.0 are not affected and it seems that the fix 
won't be backported to 4.19.

Bug#924580: upgrade from old version w/o ssl_dh in conf file breaks ssl

[Apollon Oikonomopoulos]

Control: tags -1 + confirmed

Hi Joey,

Thanks for the report!

On 11:45 Thu 14 Mar , Joey Hess wrote:
> My dovecot installation dates from 2014 (2.2.13) and on upgrade to 
> this
> version, it started failing on ssl connections:
> 
> Mar 13 19:01:40 kite dovecot[9278]: imap-login: Error: Failed to initialize 
> SSL server context: Can't load DH parameters: error:1408518A:SSL 
> routines:ssl3_ctx_ctrl:dh key too small: user=<>, rip=xxx, lip=xxx, 
> session=<45XeyQGEZOzOSmkw>
> 
> Fixing this involved adding this line to the config:
> ssl_dh =  
> There was no ssl_dh setting in my config before, so I guess it was using
> some other file by default which no longer provides valid DH params.

The old setting was called ssl_parameters and apart from the name 
change, the file format has also changed from DER to PEM. This is 
documented in the dovecot wiki[1], which is also being pointed to from 
within NEWS.Debian.

[1] https://wiki2.dovecot.org/Upgrading/2.3#dhparams

I'll give it some more thought, but I'm afraid that trying to resolve 
this automatically is not trivial, especially since the SSL config was 
managed outside the conffiles system for many years. I think the best 
thing to do is document this in the release notes, what do you think?

> 
> I also moved /var/lib/dovecot/ssl-parameters.dat out of the way, 
> which may or may not have been needed.

It was not needed, but the file is not useful anymore anyway.

> 
> This seems like the kind of upgrade breakage that would be worth documenting,
> or avoiding, rather than leave the user to diff conffiles and scratch their
> head.

Cheers,
Apollon