Hi Guillem, 2016-12-19 1:34 GMT+01:00 Guillem Jover <guil...@debian.org>: > On Sat, 2016-12-17 at 09:20:40 +0100, Bálint Réczey wrote: >> 2016-12-17 3:14 GMT+01:00 Guillem Jover <guil...@debian.org>: >> > 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 <bal...@balintreczey.hu>: >> >> > 2016-11-27 23:11 GMT+01:00 Bálint Réczey <bal...@balintreczey.hu>: >> >> >> 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. >> >> I'm surprised you raise the autopkgtest run question. > > I mentioned it explicitly on a private mail Lucas sent to me, Niels and > Kurt, which prompted me to update the dpkg FAQ, and then again a week > after in <https://lists.debian.org/debian-devel/2016/08/msg00384.html>. > > In addition on that private conversation I also mentioned this: > > And this still leaves many packages that might fail at run-time (not > to mention the startup slow down), so this option seems potentially > dangerous to enable globally. OTOH at least both Gentoo and Fedora > seem to have done so: > > <https://wiki.gentoo.org/wiki/Hardened/Toolchain> > <https://fedoraproject.org/wiki/Changes/Harden_All_Packages> > > And some known issues: > > <http://www.zsh.org/mla/workers/2015/msg02981.html> > <https://bugzilla.redhat.com/show_bug.cgi?id=1199775> > The Gentoo wiki also mentions that X is not happy about this, but > I'm not sure how current that is. > > Which then updated <https://wiki.debian.org/Hardening> with some of > those relevant links, but maybe that was too subtle.
Note that you did not list autopkgtest as a strong requirement: https://lists.debian.org/debian-devel/2016/08/msg00384.html ... From dpkg PoV enabling both, would at least require a full-archive rebuild, for bindnow ideally also a full autopkgtest run (as the updated dpkg FAQ states now, after Lucas Nussbaum approached me some weeks ago mentioning he was willing to do such archive-wide rebuild). ... Note the word "ideally". Those emails were the exact reasons why I asked a proper clarification on 10 October to be able to at least give autopkgtest a try in time: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835146#12 > >> I asked for clarification then because the on 13 Aug you added the >> following line to dpkg FAQ which does not seem to be a strong >> requirement: >> * For flags that change run-time semantics, ideally an additional run >> of the autopkgtest for packages that ship them (although this cannot >> be deemed conclusive as our coverage is not great yet). >> ( https://wiki.debian.org/Teams/Dpkg/FAQ?action=diff&rev1=28&rev2=29 ) > > It certainly is not going to be conclusive as a way to verify it correct, > as even with no failures would not mean there's no potential problems; > this would merely apply the principle of "falsificationism" to the > proposal. So it might be helpful as an additional data point to try to > gauge the possible fallout, but not as a way to say "everything ok, no > problems found". Which I guess does not play in your favor, I'll > update the FAQ to makes this more clear. I agree with that. > >> I would like to kindly ask the Release Team to share its position on the >> bindnow question since Guillem don't seem to let this move forward >> without that. > > BTW, in contrast to PIE, to be able to use bindnow globally on your > system you don't even have to recompile anything. You can simply add > LD_BIND_NOW=1 in your /etc/environment for example (man ld.so(8)). It may work for a some systems but this would also set bindnow for programs not working properly with bindnow in contrast to enabling bindnow in dpkg globally and disabling it per problematic package. > > Also according to the release schedule, it appears to me people still > have up to 10 days before 2017-02-05 to enable bindnow in their > packages? True, I have updated my blog post with that later date. Thanks for pointing that out. > > And in any case, I've written down to propose enabling this at the > beginning of the dpkg 1.19.x release cycle (which will match the buster > release cycle) in <https://wiki.debian.org/Teams/Dpkg/RoadMap>. Thanks. If I could perform the autopkgtest run with bindnow this year would it be convincing enough given only a small amount of breakages to enable bindnow early in January? Thanks, Balint > > Regards, > Guillem
