Patchwork Writing recipe for Crypto++, and getting build errors

login
register
mail settings
Submitter Ludovic Courtès
Date Sept. 26, 2016, 9:30 a.m.
Message ID <87h993nh3w.fsf@gnu.org>
Download mbox | patch
Permalink /patch/16019/
State New
Headers show

Comments

Ludovic Courtès - Sept. 26, 2016, 9:30 a.m.
Hello!

Adonay Felipe Nogueira <adfeno@openmailbox.org> skribis:

> Archive:  /gnu/store/52v106n4y88myk2c8nykymfidq6080ws-cryptopp-5.6.4.zip
>   inflating: 3way.cpp                
>   inflating: 3way.h                  

[...]

>    ?: 0 [chdir "3way.cpp"]
>
> ERROR: In procedure chdir:
> ERROR: In procedure chdir: Not a directory

The problem here is that this .zip file is a “tar bomb”, meaning that it
unpacks everything in the current directory, which the apply-snippet
logic isn’t prepared to deal with.

The way we’ve addressed it in the past is by using the
‘url-fetch/tarbomb’ procedure defined in (guix download).  That method
is currently limited to tarballs, so we’d need a variant that deals with
zip files (see patch below).

If ‘url-fetch/zipbomb’ from the patch below works for you, I’ll apply
it.

Thanks!

Ludo’.
Adonay Felipe Nogueira - Sept. 30, 2016, 11:35 a.m.
Sorry for taking so long to answer.

How do I use the patch in the source file?

It seems to refer to some Guix internal, not a package definition.

Meanwhile, I'll try to take the patch's content and apply it directly to
the recipe (although my knowledge is very limited).
Adonay Felipe Nogueira - Sept. 30, 2016, 11:39 a.m.
Also, I forgot to tell: I found their Git repository, and that offers
the source files in a directory inside a compressed file.
Ludovic Courtès - Sept. 30, 2016, 8:10 p.m.
Hi,

Adonay Felipe Nogueira <adfeno@openmailbox.org> skribis:

> Sorry for taking so long to answer.
>
> How do I use the patch in the source file?
>
> It seems to refer to some Guix internal, not a package definition.

Right, what I posted is a patch for Guix.  You can store it in a file
and apply it to your local tree with:

  patch -p1 < that-thing.patch

Then, in your package recipe, replace ‘url-fetch’ by ‘url-fetch/zipbomb’.

HTH!

Ludo’.
Adonay Felipe Nogueira - Oct. 15, 2016, 8:47 p.m.
Note: I'm using Guix with other distribution, not GuixSD.

I was trying to find out what is the "working tree" in my case, and I
decided to investigate "/gnu/store", and I found three possible places
that are directories:

/gnu/store/...-guix-0.11.0-1.4420
/gnu/store/...-guix-latest
/gnu/store/...-guix-source

Which one is my "working tree"?
Efraim Flashner - Oct. 15, 2016, 8:53 p.m.
On Sat, Oct 15, 2016 at 05:47:01PM -0300, Adonay Felipe Nogueira wrote:
> Note: I'm using Guix with other distribution, not GuixSD.
> 
> I was trying to find out what is the "working tree" in my case, and I
> decided to investigate "/gnu/store", and I found three possible places
> that are directories:
> 
> /gnu/store/...-guix-0.11.0-1.4420
> /gnu/store/...-guix-latest
> /gnu/store/...-guix-source
> 
> Which one is my "working tree"?

ls -l .config/guix/latest
on my machine it points to /gnu/store/...-guix-latest
Adonay Felipe Nogueira - Oct. 15, 2016, 9:47 p.m.
Thank you very much! :)

I have good news: The patch suggested by Ludovic does work. :)

I did a test with a simple recipe (because I no longer need to deal with
zipbomb itself, since I found the tar.gz generated by their repository,
which luckly isn't a tarbomb).

Now, reverting the patch with `patch -p1 -R`. :)
Ludovic Courtès - Oct. 17, 2016, 1:11 p.m.
Adonay Felipe Nogueira <adfeno@openmailbox.org> skribis:

> I have good news: The patch suggested by Ludovic does work. :)
>
> I did a test with a simple recipe (because I no longer need to deal with
> zipbomb itself, since I found the tar.gz generated by their repository,
> which luckly isn't a tarbomb).
>
> Now, reverting the patch with `patch -p1 -R`. :)

So the proposed ‘url-fetch/zipbomb’ is no longer needed, right?

Thanks for trying it out.

Ludo’.
Adonay Felipe Nogueira - Oct. 17, 2016, 1:22 p.m.
Indeed, you're right: I no longer need it. But I decided to test it so
that people can make use of the patch you suggested.

Patch

diff --git a/guix/download.scm b/guix/download.scm
index 649e96b..7f82ff2 100644
--- a/guix/download.scm
+++ b/guix/download.scm
@@ -35,6 +35,7 @@ 
   #:export (%mirrors
             url-fetch
             url-fetch/tarbomb
+            url-fetch/zipbomb
             download-to-store))
 
 ;;; Commentary:
@@ -427,6 +428,28 @@  own.  This helper makes it easier to deal with \"tar bombs\"."
                                           "xf" #$drv)))
                       #:local-build? #t)))
 
+(define* (url-fetch/zipbomb url hash-algo hash
+                            #:optional name
+                            #:key (system (%current-system))
+                            (guile (default-guile)))
+  "Similar to 'url-fetch' but unpack the zip file at URL in a directory of its
+own.  This helper makes it easier to deal with \"zip bombs\"."
+  (define unzip
+    (module-ref (resolve-interface '(gnu packages zip)) 'unzip))
+
+  (mlet %store-monad ((drv (url-fetch url hash-algo hash
+                                      (string-append "tarbomb-" name)
+                                      #:system system
+                                      #:guile guile)))
+    ;; Take the zip bomb, and simply unpack it as a directory.
+    (gexp->derivation name
+                      #~(begin
+                          (mkdir #$output)
+                          (chdir #$output)
+                          (zero? (system* (string-append #$unzip "/bin/unzip")
+                                          #$drv)))
+                      #:local-build? #t)))
+
 (define* (download-to-store store url #:optional (name (basename url))
                             #:key (log (current-error-port)) recursive?)
   "Download from URL to STORE, either under NAME or URL's basename if