Le 29 août 2012 10:17, "Simon McVittie" <email@example.com> a écrit :
> 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?
Yes this seems a good idea. But we may need a policy about this:why prefer new tarball instead of patching ?
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?
> (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...)
> > 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.
> You could make it safe like this: If uscan.hook exists, uscan warns and
> exits with a nonzero code distinct from normal failures, unless it
> was run with the --trust-maintainer option (or something) which means it
> runs uscan.hook as designed.
>  so that, e.g., DEHS can catch that error code and report it as
> "looks mostly OK, but I can't test it fully because there's a uscan.hook".
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
> Archive: 503DD00F.email@example.com">http://lists.debian.org/503DD00F.firstname.lastname@example.org