Message ID | 87h993nh3w.fsf@gnu.org |
---|---|
State | New |
Headers | show |
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).
Also, I forgot to tell: I found their Git repository, and that offers the source files in a directory inside a compressed file.
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’.
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"?
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
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`. :)
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’.
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.
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