[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: zipbomb handling should not be done in url-fetch/zipbomb
From: |
Ludovic Courtès |
Subject: |
Re: zipbomb handling should not be done in url-fetch/zipbomb |
Date: |
Sat, 17 Jun 2017 22:13:33 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
Arun Isaac <address@hidden> skribis:
> * Proposal
>
> zip bomb (zip archives without a top level directory) handling should
> not be done in `url-fetch/zipbomb'. It should be implemented as a
> boolean argument to the `unpack' phase.
I guess the Boolean argument would determine whether to do (chdir
(first-subdirectory ".")), right?
Unfortunately that’s not enough for the cases where an origin has
patches or a snippet, because that code also assumes there’s only one
subdirectory (see ‘patch-and-repack’ in (guix packages)).
Perhaps the right fix would be to fix ‘patch-and-repack’ somehow.
> * Rationale
>
> I'm changing the download method of a few packages to url-fetch/zipbomb,
> and the source gets downloaded again. This should not happen. It is the
> same source archive after all. Why download another copy? In my
> particular case, these source archives happen to be quite big (around
> 500 MB) as well.
The only reason it triggers a redownload is because the name is
different (specifically, ‘url-fetch/zipbomb’ prepends “zipbomb-” to the
name.)
To avoid the redownload you could do “guix download file://…” with the
right file name.
> The download method in source/origin/method should only be involved in
> downloading. It should not handle how the downloaded source archive is
> unpacked. That is the job of the `unpack' phase. url-fetch/zipbomb
> unnecessarily duplicates the "unzip" command invocation.
I admit it was a bit of a hack :-), but fixing the ‘unpack’ phase won’t
be enough.
Thanks,
Ludo’.