[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Downloader for "wrapped" tarbar?

From: Hartmut Goebel
Subject: Re: Downloader for "wrapped" tarbar?
Date: Sat, 6 Jun 2020 17:29:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

Am 02.06.20 um 21:41 schrieb Marius Bakke:
> It would be ideal to have an origin method that could extract the
> "inner" tarball, i.e. contents.tar.gz for and data.tar.gz in the
> case of RubyGems.  As zimoun mentioned, a good place to start is look at
> how other origin methods are implemented such as url-fetch/tarbomb, etc.

I started implementing into this direction and would like your advice on
the design. I found two options:

1. When implementing some "url-fetch/wrapped" (name tdb), *two* items
will be kept in the store: the "outer" and the "inner" tarball. This is
since "url-fetch" and siblings use the built-in downloader, which AFAIK
always puts the downloaded files into the store.

In this case we need to check the hash of the "outer" tarball, as the
built-in downloader requires a hash to be passed and to match. But then
we can not check the hash of the "outer" tarball. How would this work
with substitutes and download-nar?

2. When implementing some "wrapped-fetch" (name tdb), modeled like
"git-fetch", there is no easy way for the user to verify the hash, as
this is taken from the "inner" tarball. How does this work with
substitutes, download-nar and SWH?

Hartmut Goebel

| Hartmut Goebel          |               |
| | compilers which you thought are impossible |

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]