opencv: Remove hash file
PATCH 1/3 opencv: Remove hash file
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.
--- package/opencv/opencv.hash | 3 --- 1 file changed, 3 deletions(-) delete mode 100644 package/opencv/opencv.hash
package/opencv/opencv.hash deleted +0 -3
@@ -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
Signature · 1 line
2.1.1
PATCH 2/3 libevent: Remove hash file
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
--- package/libevent/libevent.hash | 2 -- 1 file changed, 2 deletions(-) delete mode 100644 package/libevent/libevent.hash
package/libevent/libevent.hash deleted +0 -2
@@ -1,2 +0,0 @@ -# Locally calculated after checking pgp signature -sha256 22a530a8a5ba1cb9c080cba033206b17dacd21437762155c6d30ee6469f574f5 libevent-2.0.21-stable.tar.gz
Signature · 1 line
2.1.1
PATCH 3/3 manual: Add notes about GitHub and hashes
In reply to Maxime HadjinlianWe 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.
--- docs/manual/adding-packages-directory.txt | 5 +++++ 1 file changed, 5 insertions(+)
docs/manual/adding-packages-directory.txt +5 -0
@@ -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:
Signature · 1 line
2.1.1
PATCH 3/3 manual: Add notes about GitHub and hashes
Maxime, All,
On 2014-10-26 17:35 +0100, Maxime Hadjinlian spake thusly:
Quoted 1 line
We can't take hash from GitHub, unless the tarball has been uploaded by
*hashes
Quoted 1 line
the maintainer, otherwise it will generated and may change over time,
...it is generated...
Quoted 13 lines
which renders hash files, useless.
Signed-off-by Maxime Hadjinlian <[email protected]>Cc "Yann E. MORIN" <[email protected]>--- docs/manual/adding-packages-directory.txt | 5 +++++ 1 file changed, 5 insertions(+)docs/manual/adding-packages-directory.txt +0
-0
docs/manual/adding-packages-directory.txt the hashes of the downloaded files for the +libfoo+ package. · line 377
Quoted 6 lines
docs/manual/adding-packages-directory.txt +3
-0@@ -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/
docs/manual/adding-packages-directory.txt the hashes of the downloaded files for the +libfoo+ package. · line 378
Quoted 1 line
docs/manual/adding-packages-directory.txt +1
-0+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.
Quoted 6 lines
docs/manual/adding-packages-directory.txt +0
-0The 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:Signature · 1 line
2.1.1
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
PATCH 3/3 manual: Add notes about GitHub and hashes
In reply to Maxime HadjinlianDear Maxime Hadjinlian,
docs/manual/adding-packages-directory.txt the hashes of the downloaded files for the +libfoo+ package. · line 378
Quoted 4 lines · Maxime Hadjinlian
docs/manual/adding-packages-directory.txt +4
-0+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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 3/3 manual: Add notes about GitHub and hashes
Thomas, All,
On 2014-10-26 18:08 +0100, Thomas Petazzoni spake thusly:
Quoted 10 lines · Maxime Hadjinlian
docs/manual/adding-packages-directory.txt the hashes of the downloaded files for the +libfoo+ package. · line 378
Quoted 5 lines
docs/manual/adding-packages-directory.txt +4
-0+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.
Quoted 2 lines
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.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'
PATCH 3/3 manual: Add notes about GitHub and hashes
Dear Yann E. MORIN,
Quoted 6 lines · Yann E. MORIN
Quoted 3 lines
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?
Quoted 4 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com