[Buildroot] [PATCH 1/3] opencv: Remove hash file

[Buildroot] [PATCH 1/3] opencv: Remove hash file

[Maxime Hadjinlian]

Since the tarball we download is generated from GitHub, there's no
saying that the tarball won't differ in a month from now.
So the hash has no value there.

An update to the manual should be done.

Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
---
 package/opencv/opencv.hash | 3 ---
 1 file changed, 3 deletions(-)
 delete mode 100644 package/opencv/opencv.hash

diff --git a/package/opencv/opencv.hash b/package/opencv/opencv.hash
deleted file mode 100644
index fc3b750..0000000
--- a/package/opencv/opencv.hash
+++ /dev/null
@@ -1,3 +0,0 @@
-# From https://github.com/itseez/opencv/archive/2.4.10/
-md5	3346a59310d788d3845f4fd6043a108a	opencv-2.4.10.tar.gz
-sha1	a0c2d5944364fc4f26b6160b33c03082b1fa08c1	opencv-2.4.10.tar.gz
-- 
2.1.1

[Buildroot] [PATCH 2/3] libevent: Remove hash file

[Maxime Hadjinlian]

Since the tarball we download is generated from GitHub, there's no
saying that the tarball won't differ in a month from now.
So the hash has no value there.

An update to the manual should be done

Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
---
 package/libevent/libevent.hash | 2 --
 1 file changed, 2 deletions(-)
 delete mode 100644 package/libevent/libevent.hash

diff --git a/package/libevent/libevent.hash b/package/libevent/libevent.hash
deleted file mode 100644
index efa0dc5..0000000
--- a/package/libevent/libevent.hash
+++ /dev/null
@@ -1,2 +0,0 @@
-# Locally calculated after checking pgp signature
-sha256	22a530a8a5ba1cb9c080cba033206b17dacd21437762155c6d30ee6469f574f5	libevent-2.0.21-stable.tar.gz
-- 
2.1.1

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

[Maxime Hadjinlian]

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(+)

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
+time, rendering a +.hash+ file invalid.
+
 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

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

[Yann E. MORIN]

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
> 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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

[Thomas Petazzoni]

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 Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

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

[Yann E. MORIN]

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.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com