Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
uscan enhancement take 3: script hook
2 views
Skip to first unread message
Andreas Tille
Aug 29, 2012, 3:00:02 AM8/29/12
to
Hi,
as you might have noticed I implemented some way to teach uscan
excluding certain files from upstream tarball to make it dfsg compatible
(see bug #685787). 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).
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).
The rules for applying the hook would be very similar to the
Files-Excluded behaviour (and would also involve the compression
suggestion I had given in my previous mail). In short: If such hook is
found a repackaging of an upstream tarball is done and uscan tries hard
to create a "reasonable" tarball with features of potential undirtying
and naming conventions as given in DevRef §6.7.8.2.
BTW, I'd be happy if more people would test the file removal feature
using Files-Excluded with the new uscan which is available in Git[1].
Kind regards
Andreas.
[1] http://anonscm.debian.org/gitweb/?p=users/tille/devscripts.git;a=blob;f=scripts/uscan.pl;hb=HEAD
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120829065...@an3as.eu
as you might have noticed I implemented some way to teach uscan
excluding certain files from upstream tarball to make it dfsg compatible
(see bug #685787). 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).
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).
The rules for applying the hook would be very similar to the
Files-Excluded behaviour (and would also involve the compression
suggestion I had given in my previous mail). In short: If such hook is
found a repackaging of an upstream tarball is done and uscan tries hard
to create a "reasonable" tarball with features of potential undirtying
and naming conventions as given in DevRef §6.7.8.2.
BTW, I'd be happy if more people would test the file removal feature
using Files-Excluded with the new uscan which is available in Git[1].
Kind regards
Andreas.
[1] http://anonscm.debian.org/gitweb/?p=users/tille/devscripts.git;a=blob;f=scripts/uscan.pl;hb=HEAD
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120829065...@an3as.eu
Simon McVittie
Aug 29, 2012, 4:20:02 AM8/29/12
to
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
> 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).
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?
(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).
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[1], unless it
was run with the --trust-maintainer option (or something) which means it
runs uscan.hook as designed.
S
[1] 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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jakub Wilk
Aug 29, 2012, 5:00:02 AM8/29/12
to
* Simon McVittie <sm...@debian.org>, 2012-08-29, 09:17:
executes arbitrary code, unless it was called with --report:
"Finally, if a third parameter (an action) is given in the watch file
line, this is taken as the name of a command, and the command
command --upstream-version version filename
is executed, using either the original file or the symlink name. A
common such command would be uupdate(1)."
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012082908...@jwilk.net
>>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.
It might be a security flaw, but not a new one. :) uscan already
>>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.
executes arbitrary code, unless it was called with --report:
"Finally, if a third parameter (an action) is given in the watch file
line, this is taken as the name of a command, and the command
command --upstream-version version filename
is executed, using either the original file or the symlink name. A
common such command would be uupdate(1)."
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bastien ROUCARIES
Aug 29, 2012, 5:00:02 AM8/29/12
to
Le 29 août 2012 10:17, "Simon McVittie" <sm...@debian.org> 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 ?
Andreas Tille
Aug 29, 2012, 6:10:01 AM8/29/12
to
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
> 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?
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...)
> > 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.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages