2017-02-22 4:47 GMT+09:00 Matt S Trout <mst@shadowcat.co.uk>: > Dealing with the fallout of removing '.' from @INC has been an interesting > exercise, but in the case of require()d files, I think overall a worthy one. > > I'm rather less convinced about do(). > > In fact, I didn't until very recently realise that do() searched @INC, my > mental model of it had always been 'run this path and return the result', > and every piece of code I've seen in the wild that used it appeared to be > based on the same expectation. > > Which means simply saying "welp, . isn't in @INC anymore" is going to leave > a vast number of broken scripts, most of them likely the ones whose users > are least knowledgable about perl (do 'config.pl' is very common baby perl, > I think). > > Also, if a do() user doesn't check $@ - and most don't realise to - they won't > even see the "Can't find" error. > > I'm not sure what to do about this - my best thought so far is to have a > warning that's emitted for "do 'file.pl'" where 'file.pl' exists in '.' but > not in @INC that recommends switching to "do './file.pl'". I think that's > better than 'apparently silent failure'. I don't know if there's a better > option still. > > But I think lots and lots of people are going to have code that just > suddenly, silently, doesn't work, on the current path, and I think that's > something we should really try and address *somehow*. > > Thoughts? Is it possible/reasonable to remove the . (or any insecure relative directory in @INC) only when it's confirmed unreasonably insecure (not by a name but by testing actual permission), in order not to affect people running their scripts under a directory with proper permissions like their home? Kenichi > > -- > Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue > > http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/ > > Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN > commercial support, training and consultancy packages could help your team.Thread Previous | Thread Next