Bug#878901: dh-make-perl: FTBFS with dpkg >= 1.19: "Insecure dependency in eval while running with -T switch"

[Damyan Ivanov]

-=| Guillem Jover, 17.10.2017 22:16:31 +0200 |=-
> On Tue, 2017-10-17 at 19:48:07 +0300, Niko Tyni wrote:
> > It looks like Dpkg::Vendor::get_vendor_info() contents have become
> > tainted, probably due to changes in Dpkg::Control::HashCore. It used to
> > dig the values out with regexp captures but now uses split.
> > 
> >  https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?h=sid&id=9e5e03e9a6ddf74bb22ffc5ea8794a14a592d6b6
> > 
> > A test case is
> > 
> >   perl -T -MDpkg::Vendor=get_vendor_info -MScalar::Util=tainted -e 'die if tainted get_vendor_info()->{Vendor}'
> > 
> > which dies on libdpkg-perl 1.19.0.1 but not 1.18.24.
> > 
> > I don't know if the earlier untainting was accidental or intended.
> > Copying the dpkg maintainers.
> 
> TBH, I was not aware that anyone was running Dpkg modules in taint
> mode. And I don't think anyone has writen code for the modules with
> that in mind. I'm not sure either how much of it is taint clean, for
> example.
> 
> If people are really running this code in taint mode, I'm willing to
> discuss which parts of the API would make sense to cover or not, and
> what tradeoffs related to performance to take, etc.

I think that using taint mode wasn't justified in that one case, so 
imposing that on Dpkg::* would not be necessary.

During discussion, Matt S. Trout suggested on IRC that the check for 
a valid package name is better written as $input =~ 
/\A([A-Za-z]\w*(?:::\w+)*)\Z/. If no hierarchy is possible, then 
/\A([A-Za-z]\w*/ would be enough.

(Perhaps this belongs to the place where $name is interpreted as 
a module name, not when parsing generic label:value lines).

That may be considered nitpicking, especially without a view on the 
big picture, but I'd rather mention it here in case it is useful.

-- dam