[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 hex.pm 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?
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goebel@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
signature.asc
Description: OpenPGP digital signature