Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

[Guillem Jover]

On Wed, 2016-12-14 at 14:05:44 +0100, Bálint Réczey wrote:
> 2016-12-13 9:29 GMT+01:00 Bálint Réczey :
> > 2016-11-27 23:11 GMT+01:00 Bálint Réczey :
> >> 2016-11-23 2:30 GMT+01:00 Guillem Jover :
> >>> My mine concern is and has always been that bindnow changes the
> >>> run-time behavior (instead of the build-time one) and could break
> >>> things such as dlopen() on shared libraries or plugins and similar.
> >>> And detecting problems becomes harder, and reverting this change
> >>> iff we notice that it breaks too much might imply rebuilding an
> >>> unspecified number of packages. So in a way it feels kind of like
> >>> a transition?
> >>>
> >>> OTOH Ubuntu seems to have been enabling not only PIE and bindnow by
> >>> default in gcc for a long time, but also relro, stack-protector and
> >>> fortify. Which would seem to imply this might not break that much?
> >>> (I'm not sure why we are not enabling all those in gcc in Debian
> >>> too, but that's probably a different conversation to have if at all.)
> >>
> >> Lucas already performed the archive-wide rebuild with bindnow
> >> enabled by dpkg and we have not observed breakages specific to
> >> bindnow. IMO this is mostly due to packages already disabling
> >> bindnow through dpkg-buildflags.

But you didn't do the requested archive-wide autopkgtest run (because
"it was hard"), and even though the coverage is not great it would
be better than nothing. Requested in this case because bindnow changes
the *run-time* behavior, which is not visible or noticable in normal
circumstances by just *building* packages.

> >> Considering that we are already in the transition freeze I suggest
> >> going with enabling bindnow for all architectures in dpkg and
> >> for Stretch+1 the responsibility of setting some hardening flags
> >> could be transferred to gcc.
> >> IMO this is not a transition because the change does not affect
> >> package interdependencies.
> >
> > Is there any update on this?

I've not seen any reply from the release team, no. And as explicitly
mentioned before multiple times now, this has the potential to impact
the release by introducing subtle and possibly hard to spot errors at
*run-time*, which might be triggered by simple a upload or a binNMU w/o
the maintainer being in the loop and knowing they have enabled bindnow.
So I want the release team to be involved in ACKing this potentially
release breaking change.

I guess this is "The current PIE situation is already an unholy mess"
(which I'll cover in another mail), so let's make the mess bigger
approach to releasing the distribution…

> > We are running out of time...
> 
> I have uploaded a dpkg NMU with bindnow enabled to DELAYED/10
> according to current NMU rules. If the Release Team increases the
> severity of #835146 it can reach unstable earlier.

… seriously I'm not sure why I bothered with this thread really? And
this makes no sense whatsover. The currently uploaded dpkg 1.18.16 does
*not* contain the change, and neither will subsequent uploads, as long
as the conditions stated in my initial mail on this thread are not met,
I'm not going to merge this change for Stretch.

> >>> So at this point, I guess I still have concerns, but only very mild
> >>> ones, and would not mind one way or another, but would like input
> >>> from at least the release team, because I don't feel like possibly
> >>> deciding on this on my own, even more at this stage of the release.

Whatever,
Guillem

piuparts blocking testing migration

[Dominic Hargreaves]

Hi,

I must have missed the memo, but according to

https://qa.debian.org/excuses.php?package=ircd-hybrid

this package is not migrating because of a piuparts failure.
In fact, the failure is not caused by irc-hybrid directly, but because
of this bug in openssl:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689490

It doesn't seem appropriate for this issue to block migration of
a package which uses openssl (I'm not even sure why this behaviour
is in violation of the FHS, although, although I can see why it is 
a problem in the context of maintainer scripts). And there doesn't seem
to be any plan to do anything with that bug before stretch is released.

What to do? It seems that the testing blocker needs to be smarter
about issues which are actually related to the package, or at least
for there to be a way to request an exception. Even better, reverting
to the idea of having manual review of piuparts output and then filing
RC bugs if appropriate seemed better, although maybe it was too much
work for people, which I do understand.

However at the moment people's packages risk being outdated in testing
for completely spurious reasons and maintainers not being told about
them. I only noticed this by chance.

Cheers,
Dominic.

Bug#848365: jessie-pu: package coquelicot/0.9.2-4+deb8u1

[Jérémy Bobbio]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Hi!

I would like to important issues affecting coquelicot in jessie:

#809351: properly run coquelicot under the 'coquelicot' user and not
as root. It was always intended that way, that's why the cron is running
under the coquelicot user already. The issue has been fixed a while ago
for stretch (in 0.9.4-1, uploaded September 2015). This backports the
changes from the unstable branch which switched to using
init-d-script(5).

#808018: silence deprecation warnings coming from cron. While the
warnings actually come from ruby-fast-gettext, they make the garbage
collection cron send an email on every run.

debdiff is attached.

Better late than never the old issues, and thanks for your review!

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
diff -Nru coquelicot-0.9.2/debian/changelog coquelicot-0.9.2/debian/changelog
--- coquelicot-0.9.2/debian/changelog	2014-09-01 18:08:55.0 +0200
+++ coquelicot-0.9.2/debian/changelog	2016-12-16 18:08:03.0 +0100
@@ -1,3 +1,14 @@
+coquelicot (0.9.2-4+deb8u1) stable; urgency=medium
+
+  * Backport init.d fixes from stretch to properly run the daemon as
+coquelicot:coquelicot. Thanks Edouard GAULUE for noticing this
+needed to be fixed in jessie. (Closes: #809351)
+  * Suppress deprecation warnings when running the daemon and garbage
+collection in cron. Thanks Matteo Calorio for the report.
+(Closes: #808018)
+
+ -- Jérémy Bobbio   Fri, 16 Dec 2016 18:08:03 +0100
+
 coquelicot (0.9.2-4) unstable; urgency=medium
 
   * Fix Build-Depends for activesupport. (Closes: #759921)
diff -Nru coquelicot-0.9.2/debian/control coquelicot-0.9.2/debian/control
--- coquelicot-0.9.2/debian/control	2014-09-01 18:08:55.0 +0200
+++ coquelicot-0.9.2/debian/control	2016-12-16 17:46:12.0 +0100
@@ -54,6 +54,7 @@
  ruby-sinatra-contrib,
  ruby-upr,
  ruby | ruby-interpreter,
+ sysvinit-utils (>= 2.88dsf-50),
  ${misc:Depends},
  ${shlibs:Depends}
 Recommends: apache2 | nginx | pound
diff -Nru coquelicot-0.9.2/debian/coquelicot.cron.d coquelicot-0.9.2/debian/coquelicot.cron.d
--- coquelicot-0.9.2/debian/coquelicot.cron.d	2014-09-01 18:08:55.0 +0200
+++ coquelicot-0.9.2/debian/coquelicot.cron.d	2016-12-16 18:07:45.0 +0100
@@ -1,4 +1,4 @@
 # crontab fragment for coquelicot
 
 # Run the garbage collection procedure every 15 minutes
-11,26,41,56 * * * * coquelicot [ -x /usr/bin/coquelicot ] && [ -f /etc/coquelicot/settings.yml ] && /usr/bin/coquelicot gc
+11,26,41,56 * * * * coquelicot [ -x /usr/bin/coquelicot ] && [ -f /etc/coquelicot/settings.yml ] && RUBYOPT="-W0" /usr/bin/coquelicot gc
diff -Nru coquelicot-0.9.2/debian/coquelicot.init.d coquelicot-0.9.2/debian/coquelicot.init.d
--- coquelicot-0.9.2/debian/coquelicot.init.d	2014-09-01 18:08:55.0 +0200
+++ coquelicot-0.9.2/debian/coquelicot.init.d	2016-12-16 18:07:45.0 +0100
@@ -1,4 +1,8 @@
 #!/bin/sh
+# kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and sourcing.
+if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
+set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
+fi
 ### BEGIN INIT INFO
 # Provides:  coquelicot
 # Required-Start:$remote_fs
@@ -10,91 +14,38 @@
 #with a focus on protecting users' privacy.
 ### END INIT INFO
 
-# Do NOT "set -e"
+# Author: Jérémy Bobbio 
 
-PATH=/sbin:/usr/sbin:/bin:/usr/bin
 DESC='Coquelicot "one-click" file sharing web application'
-NAME=coquelicot
 DAEMON=/usr/bin/coquelicot
 DAEMON_ARGS="start"
-PIDFILE=/var/run/$NAME.pid
-SCRIPTNAME=/etc/init.d/$NAME
+PIDFILE=/var/run/coquelicot/coquelicot.pid
 
-. /lib/lsb/init-functions
+# can be overriden in /etc/default/coquelicot
+USER=coquelicot
+GROUP=coquelicot
 
-do_start()
-{
-	start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \
-		|| return 1
-	LC_ALL=C.UTF-8 start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
-		$DAEMON_ARGS \
-		|| return 2
+
+do_start_prepare() {
+	START_ARGS="--chuid $USER:$GROUP"
+	/usr/bin/install -m 02750 -o "$USER" -g "$USER" -d "$(dirname "$PIDFILE")"
+
+	# suppress deprecation warnings
+	export RUBYOPT="-W0"
 }
 
-do_stop()
-{
-	start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME
+# We can't use init-d-script(5) do_stop_cmd() because it matches on the
+# executable path and Coquelicot is written in Ruby. So this is almost
+# the same function but without `--exec` when calling `start-stop-daemon`.
+# We still send QUIT before sending TERM to be hope that worker will
+# terminate gracefully.
+do_stop_cmd() {
+	start-stop-daemon --stop --quiet 

Bug#848341: jessie-pu: package intel-microcode/3.20161104.1~deb8u1

[Henrique de Moraes Holschuh]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

I would like to update the intel-microcode packages in stable to address
several critical errata in newer Intel processors.

The updated packages being proposed in this bug report are identical to
the ones in unstable/testing and jessie-backports, other than
debian/changelog and version numbering.

These changes have been tested in unstable since 2016-11-09, in testing
since 2016-11-15, and in jessie-backports since 2016-11-17, without any
issues being reported.

The large change in the "upstream" changelog reflects a change on
iucode-tool v2.0 output when listing microcodes: the "pf mask" field was
renamed to "pf_mask" to get rid of the embedded space.


Relevant information from debian/changelog:

+ Supposed to fix critical Intel TSX erratum BDE85 on Xeon-D 1500 Y0

+ Known to fix critical errata on several Xeon-D 1500 models which
  will crash vmware (KB2146388) and likely cause problems for Linux
  as well

+ Fixes likely critical errata (which ones unknown) on Broadwell-E
  (Core extreme edition 5th gen, Xeon E5v4, Xeon E7v4)

+ Removes (very likely outdated) microcode for the C3500 and C5500 family
  of embedded Xeon (Jasper Forest).  These embedded Xeons are typically
  found on (older) network equipment appliances such as firewalls/IPS/IDS,
  and also on data storage devices, and thus are supposed to receive
  microcode updates through their vendors

This microcode update is important to get Debian to run in a more stable
way on the Xeon-D 1500, and on the Broadwell-E processors.


As usual, you will find attached the debdiff output with the changes in
the microcode data files removed for brevity.  Note that an older
microcode data file (20101123) that was *not* used by the build process
anymore was also removed.


Diffstat:
 Makefile   |   21 
 changelog  |  726 
 debian/changelog   |   56 
 debian/compat  |2 
 debian/control |4 
 microcode-20101123.dat |27048 -
 microcode-20160714.dat |59389 ---
 microcode-20161104.dat |61630 +
 8 files changed, 62079 insertions(+), 86797 deletions(-)

(diffstat of the abridged debdiff, for better resolution):
 Makefile |   21 +
 changelog|  726 +++
 debian/changelog |   56 
 debian/compat|2 
 debian/control   |4 
 5 files changed, 449 insertions(+), 360 deletions(-)

Thank you!

-- 
  Henrique Holschuh
diff -Nru intel-microcode-3.20160714.1~deb8u1/changelog intel-microcode-3.20161104.1~deb8u1/changelog
--- intel-microcode-3.20160714.1~deb8u1/changelog	2016-07-31 18:11:41.0 -0300
+++ intel-microcode-3.20161104.1~deb8u1/changelog	2016-12-16 08:53:58.0 -0200
@@ -1,496 +1,508 @@
+2016-11-04:
+  * New Microcodes:
+sig 0x00050663, pf_mask 0x10, 2016-10-12, rev 0x70d, size 20480
+sig 0x00050664, pf_mask 0x10, 2016-06-02, rev 0xf0a, size 21504
+
+  * Updated Microcodes:
+sig 0x000306f2, pf_mask 0x6f, 2016-10-07, rev 0x0039, size 32768
+sig 0x000406f1, pf_mask 0xef, 2016-10-07, rev 0xb1f, size 25600
+
+  * Removed Microcodes:
+sig 0x000106e4, pf_mask 0x09, 2013-07-01, rev 0x0003, size 6144
+
 2016-07-14:
   * Updated Microcodes:
-sig 0x000306f4, pf mask 0x80, 2016-06-07, rev 0x000d, size 15360
-sig 0x000406e3, pf mask 0xc0, 2016-06-22, rev 0x009e, size 97280
-sig 0x000406f1, pf mask 0xef, 2016-06-06, rev 0xb1d, size 25600
-sig 0x000506e3, pf mask 0x36, 2016-06-22, rev 0x009e, size 97280
+sig 0x000306f4, pf_mask 0x80, 2016-06-07, rev 0x000d, size 15360
+sig 0x000406e3, pf_mask 0xc0, 2016-06-22, rev 0x009e, size 97280
+sig 0x000406f1, pf_mask 0xef, 2016-06-06, rev 0xb1d, size 25600
+sig 0x000506e3, pf_mask 0x36, 2016-06-22, rev 0x009e, size 97280
 
 2016-06-07:
   * New Microcodes:
-sig 0x000406e3, pf mask 0xc0, 2016-04-06, rev 0x008a, size 96256
-sig 0x000406f1, pf mask 0xef, 2016-05-20, rev 0xb1c, size 25600
-sig 0x00050662, pf mask 0x10, 2015-12-12, rev 0x000f, size 28672
-sig 0x000506e3, pf mask 0x36, 2016-04-06, rev 0x008a, size 96256
+sig 0x000406e3, pf_mask 0xc0, 2016-04-06, rev 0x008a, size 96256
+sig 0x000406f1, pf_mask 0xef, 2016-05-20, rev 0xb1c, size 25600
+sig 0x00050662, pf_mask 0x10, 2015-12-12, rev 0x000f, size 28672
+sig 0x000506e3, pf_mask 0x36, 2016-04-06, rev 0x008a, size 96256
 
   * Updated Microcodes:
-sig 0x000306c3, pf mask 0x32, 2016-03-16, rev 0x0020, size 22528
-sig 0x000306d4, pf mask 0xc0, 2016-04-29, rev 0x0024, size 17408
-sig 0x000306f2, pf mask 0x6f, 2016-03-28, rev 0x0038, size 32768
-sig 0x000306f4, pf mask 0x80, 2016-02-11, rev 0x000a, size 15360
-sig 0x00040651, pf mask 0x72, 2016-04-01, rev 0x001f, size 20480
-sig 0x00040661, 

Bug#847273: jessie-pu: package mapserver/6.4.1-5

[Sebastiaan Couwenberg]

On 12/06/2016 10:00 PM, Sebastiaan Couwenberg wrote:
> Sorry for the outdated debdiff, for p-u the distribution has been
> changed to stable.

With mapserver (7.0.3-1) having migrated to testing and the subsequent
update of the backport, CVE-2016-9839 is now fixed everywhere except in
jessie itself. I'd like to fix that, can I go ahead?

Kind Regards,

Bas

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