On Fri, Jun 23, 2017 at 07:43:52PM +0200, gregor herrmann wrote: > On Fri, 23 Jun 2017 17:22:52 +0200, gregor herrmann wrote: > > > > So what is not there anymore is PERL_USE_UNSAFE_INC=1. > > > > Dom, I think you're our expert on dot-in-inc; do you think my hunch > > is correct that we need to add PERL_USE_UNSAFE_INC back? > > (And if yes, where would be the best place - in the $dot_in_inc_code, > > and if yes within the if(); or after $dot_in_inc_code is output in > > the second hunk of the above diff? > > So this seems to work (as in: libcatmandu-sru-perl builds again, if I > change /usr/share/perl5/Module/Build/Base.pm in the chroot): > > --- a/lib/Module/Build/Base.pm > +++ b/lib/Module/Build/Base.pm > @@ -1866,6 +1866,7 @@ BEGIN { > $quoted_INC > ); > $dot_in_inc_code > +\$ENV{"PERL_USE_UNSAFE_INC"} = 1; > } > > close(*DATA) unless eof(*DATA); # ensure no open handles to this script > > > I didn't have any success when playing with the new $dot_in_inc_code > string, seems like the condition is never met. (And to be honest, I > don't understand the logic ...) [0] > > So it looks like we really need PERL_USE_UNSAFE_INC, and we might > want to insert it unconditionally manually where we did prior to the > accidental removal in the last upload. > > > Cheers, > gregor > > [0] > my $dot_in_inc_code = $INC[-1] eq '.' ? <<'END' : ''; > if ($INC[-1] ne '.') { > push @INC, '.'; > } > END > > What also works is reverting the logic: > > --- /usr/share/perl5/Module/Build/Base.pm~ 2017-06-19 17:25:18.000000000 > +0000 > +++ /usr/share/perl5/Module/Build/Base.pm 2017-06-23 17:42:01.820466942 > +0000 > @@ -1824,7 +1824,7 @@ > my $shebang = $self->_startperl; > my $magic_number = $self->magic_number; > > -my $dot_in_inc_code = $INC[-1] eq '.' ? <<'END' : ''; > +my $dot_in_inc_code = $INC[-1] ne '.' ? <<'END' : ''; > if ($INC[-1] ne '.') { > push @INC, '.'; > } > > > Then PERL_USE_UNSAFE_INC is not needed. But testing $INC[-1] ne '.' > two times make as little sense to me as first testing eq '.' and then ne '.' > ...
It does rather look like a mistaken attempt to solve this problem, and I agree that the logic is a bit odd, but this seems like the patch likely to get accepted upstream; can you send this patch to the module author? I feel like we should try and not diverge further from upstream; that seems almost guaranteed to end up with similar issues later. Cheers, Dominic.