GNU bug report logs -
#28602
Unpack fails with no error message when using a .zip source
Previous Next
Reported by: nee <nee <at> cock.li>
Date: Mon, 25 Sep 2017 20:11:01 UTC
Severity: normal
Tags: patch
Done: zimoun <zimon.toutoune <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28602 in the body.
You can then email your comments to 28602 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#28602
; Package
guix
.
(Mon, 25 Sep 2017 20:11:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
nee <nee <at> cock.li>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Mon, 25 Sep 2017 20:11:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello,
right now unpacking .zip sources only works when unzip is added as
native input. That's all right, but there is no error message, just:
starting phase `unpack'
phase `unpack' failed after 0.0 seconds
It should say something like:
starting phase `unpack'
Archive with .zip suffix failed to unpack. Please add unzip as
native-input to the package, e.g. (native-inputs `(("unzip" ,unzip)))
phase `unpack' failed after 0.0 seconds
I tested this in the cmake-build-system
Information forwarded
to
bug-guix <at> gnu.org
:
bug#28602
; Package
guix
.
(Wed, 04 Oct 2017 18:18:01 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
Does the .zip file have a a single directory on the root?
If not, then we can call it a zipbomb/tarbomb. These bombs are bad
because they can replace things without notice, and can be very
difficult to track what was added. Last time I checked Guix expects only
a single directory in the root of the file --- this might have changed,
but I didn't test it since one year ago.
nee <nee <at> cock.li> writes:
> Hello,
>
> right now unpacking .zip sources only works when unzip is added as
> native input. That's all right, but there is no error message, just:
>
> starting phase `unpack'
> phase `unpack' failed after 0.0 seconds
>
> It should say something like:
>
> starting phase `unpack'
> Archive with .zip suffix failed to unpack. Please add unzip as
> native-input to the package, e.g. (native-inputs `(("unzip" ,unzip)))
> phase `unpack' failed after 0.0 seconds
>
> I tested this in the cmake-build-system
--
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
gratis).
- "WhatsApp"? Ele não é livre. Por favor, use o GNU Ring ou o Tox.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
(apenas sem DRM), PNG, TXT, WEBM.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#28602
; Package
guix
.
(Mon, 09 Oct 2017 21:01:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 28602 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello here is a patch to fix this bug. It changes the gnu-build-system,
so the hashes of almost all packages will also change. I guess
core-updates is the right branch for this.
[0001-guix-gnu-build-system-warn-about-missing-unzip-input.patch (text/x-patch, attachment)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#28602
; Package
guix
.
(Mon, 09 Oct 2017 21:06:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 28602 <at> debbugs.gnu.org (full text, mbox):
Am 04.10.2017 um 20:17 schrieb Adonay Felipe Nogueira:
> Does the .zip file have a a single directory on the root?
>
> If not, then we can call it a zipbomb/tarbomb. These bombs are bad
> because they can replace things without notice, and can be very
> difficult to track what was added. Last time I checked Guix expects only
> a single directory in the root of the file --- this might have changed,
> but I didn't test it since one year ago.
Hello, this is a different problem. Tarbombs are still a problem, but
unrelated to this.
The gnu-build-system does not have unzip by default. If a package's
source comes in a zip the package must have unzip as native-input. If it
isn't the (system* "unzip" source) call in the unpack function will fail
because there is no unzip executable.
Happy hacking!
Added tag(s) patch.
Request was from
nee <nee <at> cock.li>
to
control <at> debbugs.gnu.org
.
(Sun, 26 Nov 2017 18:28:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#28602
; Package
guix
.
(Mon, 05 Jul 2021 11:59:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 28602 <at> debbugs.gnu.org (full text, mbox):
Hi,
Thanks for the patch and sorry for the delay.
On Mon, 09 Oct 2017 at 23:00, nee <nee <at> cock.li> wrote:
> Hello here is a patch to fix this bug. It changes the gnu-build-system,
> so the hashes of almost all packages will also change. I guess
> core-updates is the right branch for this.
>
>>From 089b9741a734f0682a671df6c0c36dfefcbd407c Mon Sep 17 00:00:00 2001
> From: nee <nee.git <at> cock.li>
> Date: Mon, 9 Oct 2017 22:49:12 +0200
> Subject: [PATCH] guix: gnu-build-system: warn about missing unzip input during
> unpack.
>
> ---
> guix/build/gnu-build-system.scm | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/guix/build/gnu-build-system.scm b/guix/build/gnu-build-system.scm
> index e37b75140..c16d15964 100644
> --- a/guix/build/gnu-build-system.scm
> +++ b/guix/build/gnu-build-system.scm
> @@ -67,6 +67,21 @@ See https://reproducible-builds.org/specs/source-date-epoch/."
> #f
> dir))
>
> +(define (unzip filepath)
> + "Unzip archive file.
> +Warn the user when unzip fails and the executable is not present."
> + (define exit-code (system* "unzip" filepath))
> + (define program-not-found-code 32512)
> + (cond ((zero? exit-code) #t)
> + ((eqv? exit-code program-not-found-code)
> + (format (current-error-port)
> + "warning: Archive with .zip suffix failed to unpack.
> +Please add unzip as native-input to the package,
> +e.g. (native-inputs `((\"unzip\" ,unzip)))")
> + (newline (current-error-port))
> + #f)
> + (else #f)))
Give a look at 'invoke' from (guix build utils).
> (define* (set-paths #:key target inputs native-inputs
> (search-paths '()) (native-search-paths '())
> #:allow-other-keys)
> @@ -154,7 +169,7 @@ working directory."
> #:keep-mtime? #t)
> #t)
> (and (if (string-suffix? ".zip" source)
> - (zero? (system* "unzip" source))
> + (unzip source)
> (zero? (system* "tar" "xvf" source)))
> (chdir (first-subdirectory ".")))))
After 9a87649c863e1ff8b073b356875eb05eecedbcf7, this part uses 'invoke'.
Instead of your 'unzip', the exception raised by 'invoke' should be
catched and then should trigger the hint message. WDYT?
All the best,
simon
Information forwarded
to
bug-guix <at> gnu.org
:
bug#28602
; Package
guix
.
(Fri, 26 Nov 2021 01:55:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 28602 <at> debbugs.gnu.org (full text, mbox):
Hi,
This patch [1] had been submitted in 2017 and fallen in the cracks. The
code below requires improvement and I am not convinced by the feature.
Therefore closing?
<http://issues.guix.gnu.org/issue/28602
On Mon, 05 Jul 2021 at 13:46, zimoun <zimon.toutoune <at> gmail.com> wrote:
> On Mon, 09 Oct 2017 at 23:00, nee <nee <at> cock.li> wrote:
>> Hello here is a patch to fix this bug. It changes the gnu-build-system,
>> so the hashes of almost all packages will also change. I guess
>> core-updates is the right branch for this.
>>
>>>>From 089b9741a734f0682a671df6c0c36dfefcbd407c Mon Sep 17 00:00:00 2001
>> From: nee <nee.git <at> cock.li>
>> Date: Mon, 9 Oct 2017 22:49:12 +0200
>> Subject: [PATCH] guix: gnu-build-system: warn about missing unzip input during
>> unpack.
>>
>> ---
>> guix/build/gnu-build-system.scm | 17 ++++++++++++++++-
>> 1 file changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/guix/build/gnu-build-system.scm b/guix/build/gnu-build-system.scm
>> index e37b75140..c16d15964 100644
>> --- a/guix/build/gnu-build-system.scm
>> +++ b/guix/build/gnu-build-system.scm
>> @@ -67,6 +67,21 @@ See https://reproducible-builds.org/specs/source-date-epoch/."
>> #f
>> dir))
>>
>> +(define (unzip filepath)
>> + "Unzip archive file.
>> +Warn the user when unzip fails and the executable is not present."
>> + (define exit-code (system* "unzip" filepath))
>> + (define program-not-found-code 32512)
>> + (cond ((zero? exit-code) #t)
>> + ((eqv? exit-code program-not-found-code)
>> + (format (current-error-port)
>> + "warning: Archive with .zip suffix failed to unpack.
>> +Please add unzip as native-input to the package,
>> +e.g. (native-inputs `((\"unzip\" ,unzip)))")
>> + (newline (current-error-port))
>> + #f)
>> + (else #f)))
>
> Give a look at 'invoke' from (guix build utils).
>
>> (define* (set-paths #:key target inputs native-inputs
>> (search-paths '()) (native-search-paths '())
>> #:allow-other-keys)
>> @@ -154,7 +169,7 @@ working directory."
>> #:keep-mtime? #t)
>> #t)
>> (and (if (string-suffix? ".zip" source)
>> - (zero? (system* "unzip" source))
>> + (unzip source)
>> (zero? (system* "tar" "xvf" source)))
>> (chdir (first-subdirectory ".")))))
>
> After 9a87649c863e1ff8b073b356875eb05eecedbcf7, this part uses 'invoke'.
> Instead of your 'unzip', the exception raised by 'invoke' should be
> catched and then should trigger the hint message. WDYT?
Cheers,
simon
Information forwarded
to
bug-guix <at> gnu.org
:
bug#28602
; Package
guix
.
(Tue, 04 Jan 2022 22:58:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 28602 <at> debbugs.gnu.org (full text, mbox):
Hi,
On Fri, 26 Nov 2021 at 02:49, zimoun <zimon.toutoune <at> gmail.com> wrote:
> This patch [1] had been submitted in 2017 and fallen in the cracks. The
> code below requires improvement and I am not convinced by the feature.
> Therefore closing?
>
> <http://issues.guix.gnu.org/issue/28602
If no answer before the next release [1], I will close it.
1: <https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00055.html>
Cheers,
simon
Reply sent
to
zimoun <zimon.toutoune <at> gmail.com>
:
You have taken responsibility.
(Wed, 23 Mar 2022 10:42:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
nee <nee <at> cock.li>
:
bug acknowledged by developer.
(Wed, 23 Mar 2022 10:42:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 28602-done <at> debbugs.gnu.org (full text, mbox):
Hi,
On Tue, 04 Jan 2022 at 23:55, zimoun <zimon.toutoune <at> gmail.com> wrote:
> On Fri, 26 Nov 2021 at 02:49, zimoun <zimon.toutoune <at> gmail.com> wrote:
>
>> This patch [1] had been submitted in 2017 and fallen in the cracks. The
>> code below requires improvement and I am not convinced by the feature.
>> Therefore closing?
>>
>> <http://issues.guix.gnu.org/issue/28602
>
> If no answer before the next release [1], I will close it.
Well, 11 weeks later without an answer, I am closing.
Cheers,
simon
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 20 Apr 2022 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 4 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.