[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: uscan enhancement take 3: script hook



On Wed, Aug 29, 2012 at 09:17:19AM +0100, Simon McVittie wrote:
> On 29/08/12 07:55, Andreas Tille wrote:
> > When trying to get rid of some get-orig-source
> > scripts I noticed that besided some file removals I need to execute
> > some extra code.  This is basically fetching some extra files like
> > sources for documentation, uncompressed JS files etc from external
> > sources (http, VCS).
> 
> Shouldn't this be put in the debian directory or in a dpkg-source v3
> secondary tarball? Putting them in the repacked tarball seems a bit
> inconsistent: if you weren't repacking for DFSG reasons already, surely
> you wouldn't repack just to add the missing bits, you'd incorporate them
> via the debian directory or an extra tarball instead?

I admit I would only use it when repackaging for DFSG reasons anyway.  I
was just checking what get-orig-source script I could replace when using
the Files-Excluded field in debian/copyright.  I learned that there are
some remaining exceptions that could be easily handled via a script.  So
it might make sense to restrict this hook only for the usage in
connection with this field ... on the other hand I do not see any real
need for such a restriction because it simply enhances flexibility which
never was a drawback.  Finally you will never prevent people from
repackaging - we just could provide some tools to make it consistent.
 
> (Indeed, one of my packages used to add its top-level Makefile as the
> first patch in the quilt series, because upstream distributed it in svn
> but forgot to put it in the released tarball...)

That's a perfect example were I also would not use the suggested method.

> > IMHO this could be done quite simple if we would enable uscan to call a
> > script say debian/uscan.hook (feel free to propose a better name).
> 
> This is a security flaw if you want uscan to be safe to use on untrusted
> source (e.g. in DEHS). It seems that uscan tries to make its use of
> regexes, at least, not imply arbitrary code execution.

This was answered by Jakub in another mail ...

Kind regards

     Andreas. 

-- 
http://fam-tille.de


Reply to: