[3/3] manual: Add notes about GitHub and hashes

We can't take hash from GitHub, unless the tarball has been uploaded by
the maintainer, otherwise it will generated and may change over time,
which renders hash files, useless.

Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 docs/manual/adding-packages-directory.txt | 5 +++++
 1 file changed, 5 insertions(+)

Maxime, All,

On 2014-10-26 17:35 +0100, Maxime Hadjinlian spake thusly:
> We can't take hash from GitHub, unless the tarball has been uploaded by

*hashes

> the maintainer, otherwise it will generated and may change over time,

...it is generated...

> which renders hash files, useless.
> 
> Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
> ---
>  docs/manual/adding-packages-directory.txt | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/docs/manual/adding-packages-directory.txt b/docs/manual/adding-packages-directory.txt
> index c145829..28312d6 100644
> --- a/docs/manual/adding-packages-directory.txt
> +++ b/docs/manual/adding-packages-directory.txt
> @@ -372,6 +372,11 @@ the hashes of the downloaded files for the +libfoo+ package.
>  The hashes stored in that file are used to validate the integrity of the
>  downloaded files.
>  
> +If +libfoo+ is from GitHub, we can only accept +.hash+ file if the
> +package has a release section and the maintainer has uploaded a release
> +tarball. Otherwise, the automated generated tarball may change through

s/through/over/

> +time, rendering a +.hash+ file invalid.

    time, and thus its hashes may be different each time it is downloaded,
    making the +.hash+ file irrelevant for that tarball.

However, the .hash file is not completely irrelevant, in case the
package has extra downloads (with FOO_EXTRA_DOWNLOADS). I'm not sure if
the above makes completely sense...

Regards,
Yann E. MORIN.

>  The format of this file is one line for each file for which to check the
>  hash, each line being space-separated, with these three fields:
>  
> -- 
> 2.1.1
>

Dear Maxime Hadjinlian,

On Sun, 26 Oct 2014 17:35:15 +0100, Maxime Hadjinlian wrote:

> +If +libfoo+ is from GitHub, we can only accept +.hash+ file if the
> +package has a release section and the maintainer has uploaded a release
> +tarball. Otherwise, the automated generated tarball may change through
> +time, rendering a +.hash+ file invalid.

I don't really understand this. If the tarball is automatically
generated, then it should always be the same for a given version/tag of
a certain repository, no?

It would be scary if it was not possible to validate the integrity of
all the packages we download from github.

Best regards,

Thomas

Thomas, All,

On 2014-10-26 18:08 +0100, Thomas Petazzoni spake thusly:
> On Sun, 26 Oct 2014 17:35:15 +0100, Maxime Hadjinlian wrote:
> 
> > +If +libfoo+ is from GitHub, we can only accept +.hash+ file if the
> > +package has a release section and the maintainer has uploaded a release
> > +tarball. Otherwise, the automated generated tarball may change through
> > +time, rendering a +.hash+ file invalid.
> 
> I don't really understand this. If the tarball is automatically
> generated, then it should always be the same for a given version/tag of
> a certain repository, no?

The content of the extracted archive is always the same, except for
timestamps, so, the archive is not reproducible itself.

> It would be scary if it was not possible to validate the integrity of
> all the packages we download from github.

But then that's the case for generated tarballs from github: we have
absolutely no way to check them, unless we want to have hashes for the
extracted files themselves (which I doubt we want, as it would be a
nightmare to handle).

Regards,
Yann E. MORIN.

Dear Yann E. MORIN,

On Sun, 26 Oct 2014 10:13:05 -0700, Yann E. MORIN wrote:

> > I don't really understand this. If the tarball is automatically
> > generated, then it should always be the same for a given version/tag of
> > a certain repository, no?
> 
> The content of the extracted archive is always the same, except for
> timestamps, so, the archive is not reproducible itself.

The timestamps change each time you generate the tarball? This would be
really weird from github to not have planned to make the tarballs
reproducible for a given version of the repository. If that's really
the case, then maybe it's something we should report to github?

> But then that's the case for generated tarballs from github: we have
> absolutely no way to check them, unless we want to have hashes for the
> extracted files themselves (which I doubt we want, as it would be a
> nightmare to handle).

Indeed, we don't want to go this way.

Thomas