Commit d2496990 authored by Niko Tyni's avatar Niko Tyni

Update description of base-pm-amends-pt2.diff

parents 90cfe707 12a52157
# see git-dpm(1) from git-dpm package
From 275e5dec730be629875c79a8e1a8b3f50392f565 Mon Sep 17 00:00:00 2001
From 12a52157658e56796eb1ede38a2715f62242490f Mon Sep 17 00:00:00 2001
From: Aristotle Pagaltzis <>
Date: Mon, 13 Feb 2017 01:28:14 +0100
Subject: wip
Subject: Limit dotless-INC effect on with guard:
[latest version of no-dot-in-inc fix,
backported to Debian 5.20 by Niko Tyni]
This introduces a more refined and accurate solution for removing
'.' from @INC while reducing the false positives.
Origin: upstream,
The following explanation is roughly what is avaiable in the code
comments. If you stumble upon this and feel like the commit message
or the comments are not helpful enough, please introduce another
commit that adds more explanation or improve the code comments
(or both).
if ($INC[-1] eq '.' && %{"$base\::"})
We decide that:
The package already exists => this an optional load
And: there is a dot at the end of @INC => we want to hide it
However: we only want to hide it during our *own* require()
(i.e. without affecting nested require()s).
So we add a hook to @INC whose job is to hide the dot, but which
first checks checks the callstack depth, because within nested
require()s the callstack is deeper.
Since CORE::GLOBAL::require makes it unknowable in advance what
the exact relevant callstack depth will be, we have to record it
inside a hook. So we put another hook just for that at the front
of @INC, where it's guaranteed to run -- immediately.
The dot-hiding hook does its job by sitting directly in front of
the dot and removing itself from @INC when reached. This causes
the dot to move up one index in @INC, causing the loop inside
pp_require() to skip it.
Loaded coded may disturb this precise arrangement, but that's OK
because the hook is inert by that time. It is only active during
the top-level require(), when @INC is in our control. The only
possible gotcha is if other hooks already in @INC modify @INC in
some way during that initial require().
Note that this jiggery hookery works just fine recursively: if
a module loaded via uses itself, there will be
one pair of hooks in @INC per base::import call frame, but the
pairs from different nestings do not interfere with each other.
(cherry picked from commit 571931bfa1120564fe207965f9ec2ea0f8bbbb8a)
[This is a forward-port, with improved commit message by Sawyer X
<>, of the commit that was cherry-picked into
maint-5.22 and maint-5.24 as commits a93da9a38c and 1afa289000
(cherry picked from commit fa71f6670dda393818d17f2f3bd2bee165347849)
[ backported to Debian 5.20 by Niko Tyni, patch description from
Origin: backport,
Patch-Name: debian/CVE-2016-1238/base-pm-amends-pt2.diff
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment