On 26/07/16 00:52, Dominic Hargreaves wrote: > On Mon, Jul 25, 2016 at 06:34:01PM +0200, Emilio Pozuelo Monfort wrote: >> On 25/07/16 17:20, Dominic Hargreaves wrote: >>> Hello, >>> >>> As you will see from the below DSA, a class of vulnerabilities in >>> perl programs has been announced today. We have fixed the worst parts of >>> this in Debian, but ultimately we'd like to (in keeping with upstream's >>> intentions for 5.26) remove the current directory from the module search >>> path altogether. >>> >>> At the moment, this would cause around 40 packages to FTBFS (that was >>> the number of jessie - it will be a bit different for sid). >> >> The advisory only mentions about a dozen packages. Is that estimate of ~40 >> accurate? > > The confusion here is that the recent update did two things; it fixed > some known vulnerabilities, and also paved the way for being able > to remove '.' from @INC in the future (by allowing perl itself to build, > and fixing some of the toolchain - ie debhelper, cdbs, libmodule-build-perl). > This brought the number of FTBFS packages with '.' removed down from a > few hundred to ~ 40. The remaining 40 need individual uploads to fix. > I think most of them should be fairly easy to patch. > >>> In the near term, changing the default is a matter of uncommenting a line >>> in a conffile (and can therefore be easily reverted by the user if needed). >>> >>> I'd like to upload such a change to sid ASAP (probably just after the >>> initial sid upload, due any minute now, migrates to testing). If the >>> impact of that measured against sid/stretch is manageable, we'd also like >>> to consider making the change by default in a future point release, >>> although the number of packages that need updates may still be too large; >>> we'd obviously discuss that with you in the normal way via a transition >>> bug. >>> >>> Are you happy for us to introduce such a change in sid later this week, >>> and start filing RC bugs about problems in other packages caused by >>> the change? >> >> Are these problems to difficult to change? This should be fine, but if you >> can >> give an approximate list of affected packages that would be appreciated. > > I think they're mostly pretty easy - eg adding -I. to explicit Makefile.PL > invocations in old style rules files, and so on. > > Here is the list from our jessie testing: > > kdesrc-build_1.15.1-1 > kgb-bot_1.33-2 > libalgorithm-dependency-perl_1.110-1 > libcache-simple-timedexpiry-perl_0.27-2 > libclass-c3-perl_0.26-1 > libclass-c3-xs-perl_0.13-2 > libclass-default-perl_1.51-2 > libconfig-record-perl_1.1.2-1 > libdevel-declare-parser-perl_0.17-1 > libfile-nfslock-perl_1.24-1 > libfile-userconfig-perl_0.06-2 > libfilter-eof-perl_0.04-2 > libgraph-writer-dsm-perl_0.006-1 > libhtml-html5-parser-perl_0.301-1 > libimage-info-perl_1.28-1 > libintl-perl_1.23-1 > liblocal-lib-perl_2.000014-1 > liblwp-authen-wsse-perl_0.05-2 > libmethod-alias-perl_1.03-1 > libmp3-info-perl_1.24-1 > libnet-ldap-filterbuilder-perl_1.0004-1 > libnet-proxy-perl_0.12-6 > libpoe-component-client-ident-perl_1.07-2 > libpoe-component-server-simplehttp-perl_2.18-1 > libtest-file-perl_1.41-1 > libtheschwartz-perl_1.07-1 > libvalidate-net-perl_0.6-1 > makepp_2.0.98.5-1 > munin_2.0.25-1 > net-telnet-cisco_1.10-5 > ocsinventory-agent_2.0.5-1 > ooolib-perl_0.1.9-1 > pari_2.7.2-1 > pdl_2.007-4 > rt-extension-calendar_0.17-1 > rt-extension-spawnlinkedticketinqueue_0.06-1 > slack_0.15.2-6 > spamassassin_3.4.0-6 > xemacs21-packages_2009.02.17.dfsg.2-2 > xmltv_0.5.63-2 > > The list might of course be shorter for sid as more rules files will > have been modernised.
OK. That should be fine. Let's get this issue finally fixed. Thanks, Emilio
