Re: [RFC] Enabling bindnow by default in dpkg-buildflags?
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
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
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 --retry=QUIT/5/TERM/5/KILL/5 \ + $STOP_ARGS \
Bug#848341: jessie-pu: package intel-microcode/3.20161104.1~deb8u1
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, p
Bug#847273: jessie-pu: package mapserver/6.4.1-5
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