From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: zipbomb handling should not be done in url-fetch/zipbomb Date: Sat, 17 Jun 2017 22:13:33 +0200 Message-ID: <878tkqbceq.fsf@gnu.org> References: <9f5ff0ec.AEAALfWcKw0AAAAAAAAAAAOtZhgAAAACwQwAAAAAAAW9WABZQ6jZ@mailjet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dMK6F-0003xs-Hw for guix-devel@gnu.org; Sat, 17 Jun 2017 16:13:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dMK6C-0007xX-Cp for guix-devel@gnu.org; Sat, 17 Jun 2017 16:13:39 -0400 In-Reply-To: <9f5ff0ec.AEAALfWcKw0AAAAAAAAAAAOtZhgAAAACwQwAAAAAAAW9WABZQ6jZ@mailjet.com> (Arun Isaac's message of "Fri, 16 Jun 2017 15:15:54 +0530") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Arun Isaac Cc: guix-devel@gnu.org Arun Isaac 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=E2=80=99s not enough for the cases where an origin has patches or a snippet, because that code also assumes there=E2=80=99s only o= ne subdirectory (see =E2=80=98patch-and-repack=E2=80=99 in (guix packages)). Perhaps the right fix would be to fix =E2=80=98patch-and-repack=E2=80=99 so= mehow. > * 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, =E2=80=98url-fetch/zipbomb=E2=80=99 prepends =E2= =80=9Czipbomb-=E2=80=9D to the name.) To avoid the redownload you could do =E2=80=9Cguix download file://=E2=80= =A6=E2=80=9D 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 =E2=80=98unpack=E2=80=99= phase won=E2=80=99t be enough. Thanks, Ludo=E2=80=99.