On Mon, Oct 17, 2016 at 10:52:21PM +0200, Sawyer X wrote: > > I don't see how you can ship that as a maintenance update. > > I understand it is important to you, Michael, and I respect that. I hope > you understand it is important to us as well and that is why we decided > on this course of action. It is our position that security in this case > takes precedence. Ok, let me state again my two points. This is all "IMHO", so feel free to ignore me. 1) For a maintainence update not breaking things should be the top priority. Some times (like with security changes) breaking some code can't be helped. But with the current code there's a case where you break code without need: this is when %{"$base\::"} is empty. In that case you know that this is not an optional load. So it would be in the spirit of the rest of the fixes to not remove '.' from @INC. Nevertheless you do it because of "consistency reasons". That's not "security takes precedence". Also note that the big reworded error message is only shown in this case, i.e. when there is actually no need to remove '.'. 2) The security relevant case is when %{"$base\::"} is not empty. In that case it is not clear if this is an optional or mandatory module load. Here I'm fine with removing '.' from @INC, but it is somewhat risky. The problem is that in this case the code does not die, it will just continue leading to errors where it is not easy to find the cause. The "security takes precedence" argument is good here, but it's still quite a nasty change. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}Thread Previous | Thread Next